How to Identify Business Patterns, Part 1

Concepts, Strategy, and Techniques

March 4, 2004

This report introduces business patterns and their uses / benefits. It begins our examination of Customer Scenario patterns. We introduce an extended Customer Scenario example using a B2B procurement case study. And we provide guidance for finding Customer Scenario patterns.


Identifying patterns and “getting them right” when designing business practices or IT servicescan save your company both time and money. And learning how to implement patterns can give your company a leg up on the competition by helping you institute best practices. This report is the first in a series that taps into our experiences and those of our clients to help you start using business patterns quickly and effectively.

Business patterns are structured collections of business constructs that are found in most organizations—for example, a group of entities with common relationships, a Customer Scenario® with common “I Want To” statements, or a template business process that groups work in common sub-process groupings.

Business patterns express best practices and ideal end states. They capture, for example, the essential representations of business party and common business roles, the relationships between these roles, and notions like address or location. Business patterns can also capture common things that customers want to do when they configure and buy a complex product, as well as thought leaders’ responses to those wants. Business patterns are not business models, and they do not describe your business today or the details of how it works.

Business patterns are found, not created. We find business patterns in Customer Scenario® Maps, entity-relationship models, business process models, and business event charts, among other sources. Keep in mind, however, that patterns exist in the business. Models and maps are representations of the road, not the road itself. But experience indicates that patterns are easier to detect, articulate, and apply in the context of models. Thus when we discuss patterns, we use models to do so.

Some patterns are industry specific, but most are common to any business or organization. They exist because organizations have gravitated toward common ideas and ways of work; because people have cross-pollinated the best ideas—or simply the ideas that they have learned—from one organization to another; and because of common expectations, customs, laws, and ways of exchanging information.

Patterns are neutral templates used to design and improve business practices, to get data structures right, to define business services in service-oriented architectures (SOAs), to evaluate businesses and applications, and to migrate businesses and applications away from current practices toward more flexible structures and information exchange.


After decades of modeling, requirements definition, analysis, and systems design experience, many IT and business professionals agree that strong similarities exist among businesses. The popularity and success of off-the-shelf enterprise packages bear witness to this belief, as do the anecdotal experiences of many professionals.

Why, then, do our applications, databases, and businesses look so different? Why can’t companies use packaged applications without huge investments in customizing these off-the-shelf products? When such package customization is “finished,” are the
underlying commonalities still present in the modified application packages, or have these invariants been subsumed by adaptation? If we can have technical standards for operating systems and middleware, couldn’t we also have business standards? Indeed, don’t such standards already exist in the form of EDI and Internet commerce standards, accounting standards, manufacturing best practices, financial and health care industry standards, etc.? Don’t some of these business standards suggest common concepts and practices that could be used to simplify and reduce the costs of IT applications? How do XML and Web Services make this easier? And what could such standard concepts and practices do to reduce non-IT business operating costs? Wouldn’t standard business practices lower operating costs and improve efficiency?

This new series of reports will address such questions, will set forth a framework for identifying and leveraging business commonality, and will document some of the central commonalities that businesses both should be aware of and could use today...


Sign in to download the full article


Be the first one to comment.

You must be a member to comment. Sign in or create a free account.