Business Object Workshop II

Business Objects, Business Patterns

Comments:

• Spottiswoode's Critique

Introduction

Christopher Alexander's notion of 'patterns' as a way of seeing and building the world in a manner that is natural, self-reinforcing, self-maintaining and (ultimately) good has influenced information systems design practises and methodologists a great deal recently. And, even though systems pattern thinking has been (largely) a bastardization of Alexander's underlying concepts, the results have been powerful.

Emboldened by the success of systems patterns, and prompted by an interest in revisiting Alexander's ideas directly, I've been working with some colleagues on applying pattern thinking to business strategy, modeling and analysis, extending the idea of Business Objects in a variety of ways. While still exploratory, the results have been encouraging.

In particular, they reinforce the recent efforts by Booch, amongst others, to formalize the role of patterns in the world of object orientation. His proposal to classify patterns into 'frameworks', 'mechanisms' and 'idioms', and then to incorporate patterns within Use Cases and to use Use Cases to detail patterns is very much in synch with the conceptual framework we've been using.

As Booch puts it

(The) most sophisticated patterns (represent) both a thing and a process. A thing (as a structure showing) a particular collaboration of classes and objects and... resulting behavior. A process (as) a means of generating an instance (of that structure in) ..a real system. Furthermore… the best patterns disappear once they manifest themselves in a system.

In the same way that Booch weaves a modelling language pattern from objects, use cases and (recursively) patterns at different levels, we've been looking at how to model a business by weaving business objects, business use cases and business patterns.

And for the same reason…. a good business model should be more than a document of the business. It should act as a tool for designing improvements to the business processes and provide a starting point for designing the supporting information systems. Business patterns -- recurring responses to problems and opportunities that 'design' the business -- are a conceptual tool for building good business models and one that is especially useful for taking advantage of object technology.

A Business Modelling Pattern

The Problem we were tackling with this Pattern was how to understand a business on it's own terms, but in a way that facilitates building a business system. Jacobson's idea that a business can be modeled as a system is, of course, correct, but this is not the same thing as being able to represent the business as understood by the community and culture that are its core.

The Context we started with, in general (and Alexandrian) terms, is that a business can be seen as an ongoing response to a set of problems and opportunities. The success of the response is measured against business objectives, one of which may be to make a profit. And, because of the ongoing nature of the response, the business reflects a 'corporate culture' that shapes its actions over time.

Another part of the Context was that a key requirement in modeling a business should be to separate 'the organization' from 'the business'. The internal organization is NOT the business, but rather the machinery that the business uses to provide resources and money to support business activities. The underlying organizational and functional views merely clarify and support the aspects of the business model. Internal processes and activities (e.g. creating a budget, scheduling training, allocating staff) are 'organization activities', not business events at the strategic (i.e. core process) level.

Finally, although recognizing that the model should be driven by the business and NOT by any potential system solution or way of conceptualizing a solution, there is a need to be able to bridge the gap from business to possible systems in a way that is as simple and consistent as possible. To us, that meant that a solution would have to accommodate three elements as a minimum modeling structure:

• Business Events

a specific interaction between the business and the outside world which initiates a business process, calls corporate forces and resources into play to respond… additional, internal business events may be needed to support the particular business implementation of the process (e.g., decisioning, authorizations, etc

• Business Processes

triggered by a business event… the activities detailing the solution to the problem/opportunity represented by the business event

• Business Objects

following the Object Management Group definition 'a representation of a thing active in the business domain.... for example, a person, place or concept', extended to include business processes as objects (e.g. tasks and workflows), and perhaps business functions as well (the nexus of resource and organization)

Our Solution was:

A Business Model based on business patterns, business processes and business objects that

• explains why the business is 'in business'
• defines how it 'does business'
• establishes what it considers serious 'business-like' behavior.

In particular, we came up with a structure that resembles the proposed means for incorporating patterns into the emerging Unified Modeling Language…

• a classification of patterns into frameworks ("a microarchitecture.... that provides reuse in the large"), mechanisms (structures "where objects collaborate to.. satisfy a requirement of the problem domain" to solve "common problems in common ways" and idioms "an expression peculiar to a certain… organizational culture (which supports) reuse in the small".
• an extended form of use cases to reference and leverage patterns.

A Business Pattern Framework

Following Alexander's approach, a Business Pattern is expressed in the form 'problem-context-solution'.

At the level of mechanisms, Business Patterns can extend system design patterns that are already acknowledged as useful. The obvious example is Gamma's chain of responsibility, described by Booch as "often found in event-driven systems (especially GUI systems)..... a client sends a message to a handler, asking it to handle some request. That handler is actually part of a chain of handlers, and so either handles the request directly, or passes on the request to its successor. This delegation continues until the request floats up to a handler that takes responsibility for the request."

This pattern is typically found in business processes where some form of authorization is required, and levels of approval are established. The Business Use Case describing one of these processes could reference the pattern as part of an alternative flow. It could also be used as a form of placeholder, suggesting the form of the activity without tying it down to one or more objects or roles.

We can also identify the equivalent of idioms in business policies and rules, again using pattern language to capture the context and the business reasoning.

The highest level Business Patterns are frameworks which we call 'business themes', following Peter Coad's description of object patterns as 'repetitive forms, just like those in music'. The culture and objectives of a business can be expressed as a small series of business themes. Each theme addresses a variation on the question 'why are we in business', but in a way that is particular and practical, rather than the abstract language often used in Mission or Vision statements. Business Themes are those patterns that constitute the real Vision behind a business. They are applied, reapplied, combined, varied and reused in practical realizations that constitute the life of the business.

One simplistic example of a theme from the leasing world might be 'Providing value-added services to dealers throughout the life-cycle of a leased product'. This business theme would be realized by one or more business use cases, which would in turn incorporate business patterns, such as 'Minimizing Lease Losses'…..

• The problem is that dealers may lose money on products coming off lease without a buy back.
• The context is that these products have to be resold quickly, but customers have the control over the termination of the lease.
• The solution is proactive lease termination, a process of contacting lease customers prior to termination and offering incentives to terminate early in exchange for new product.

(This pattern is more generically something like 'cut your losses')

A Business Theme provides the context for one or more Business Events, identifying the corporate forces and culture creating the need to respond to the event, and shaping the response.

The Business Process triggered by a Business Event can be described in a Business Use case that details the activities and patterns required to solve the problem/opportunity the Business Event offers. And, of course, from a Business Use Case we derive Business Objects, System Use Cases and so on.

We end up with a simple but effective way of capturing the essence of a business in terms that are readily accessible by business people, that is consistent with and, in fact, extends, some of the emerging ideas within OO.