Christopher Spottiswoode comments from a Metaset/MACK point of view
(on Paul Evitts, Business Objects, Business Patterns):

(Please first read my Introduction to these comments on your papers.)

First some minor comments:

The Business Events / Business Processes / Business Objects categorization looks okay, sort of, but I’m not sure how helpful it is in the long run. At least, in MACK all events, processes and objects are so intertwined that it isn’t helpful there! Sure, events are momentary and processes are in general fairly transient, but their histories have persistent aspects, and their interactions with more persistent objects should - in a clean architecture - not be qualitatively different from object/object interactions.

Likewise, the presently popular frameworks / mechanisms / idioms classification is superfluous in MACK. All are provided in terms of typologies, even though the shapes of many of the various typologies might make them look as if they might have been influenced by such distinctions [7]. Particularly, frameworks and idioms should merge seamlessly (Cf. my "IDIOM" name that effectively encapsulated frameworks! [3]).

True, such distinctions can be useful up to a point when one is analysing the A&D problem-area, but if one is on the way to a useful synthesis (especially if that synthesis is as far advanced as MACK!) then one must beware of granting such distinctions any a priori status which tempts the conceptual distortions that preconceptions bring. (But then of course you know that well enough already!)

The "chain of responsibility" pattern or concept, which you cited as an example of mechanisms, is one of the "Behavioral Patterns" of Gamma et al’s Design Patterns Chap 5. My further comments on it are therefore in my comments on Ralph Johnson’s paper (considering that he was one of that Gang of Four, and seems to have had a major part in that chapter at least).

The major point in your paper started this way (Your text, in italics, was continuous despite my interjections in parentheses. Your original italics I have underlined):

Start of continuous quote:

A Business Modelling Pattern

The Problem we were tackling with this Pattern was how to understand a business on its 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.

(Your qualification is correct, in principle, but in practice that community and culture are influenced by good formalizations. Demand is satisfied when it happily adopts the terms of appropriate Supply. The market makes reality.)

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 (see my "POP" below). 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'. (But beware of oversimplification for the sake of convenience in analysis! The medium is often the message. The mechanisms of the organization may be unique assets and major contributors to competitive advantage. They may represent strategic opportunities.) 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.

End of continuous quote.

Despite my various apparently disparaging comments, I can really relate to your high-level approach! Then you continue in the same thoughtful and thought-provoking vein:

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.

I particularly like that last sentence: abstractions and practicalities can be brought a whole lot closer together than they usually are.

The conventional expression of a pattern in the form 'problem-context-solution' - that you follow - will find a natural place in MACK’s Market or Buying typologies [7].

In designing Metaset I have long been aiming for what I used to call POP: the Problem-Opportunity Perspectives in terms of which the two sides of the market would first express themselves and then be brought together (and as a result often re-express themselves). I am not referring merely to conventional wanted/offered advertising. Metaset will cater for the complexity of both sides to be brought out, and for much fine matching to take place automatically, with user input being invited where further refinement is indicated (including in the contractual phases, which will themselves have some powerful implications for market responsibility. In fact, the legal implications of the next (MACK!) generation of information systems are already a major thrust of my efforts).

With agents etc that supply-demand matching would be in a distributed way, itself much more clever and seamless than we can imagine in a Web environment. The MACK-compliant market will also have the effect that unrequited yet expressed needs will be encouraged to coalesce into opportunities that actual and potential suppliers will find difficult to ignore.

All the above applies not only to the open market but also to the intra-organizational context, where applicable within the 'business theme' concept just quoted. A business theme could likewise be a product from within the organization, and would similarly have been honed partly within the open market too.

My book advertised at the end of [2] was even centred around the principles and processes of such a concept. The general need is to help refine objectives (or business themes) for associations or focused groups of people, and in a way that ties in with their strategies and tactics. If such more practical aspects can be facilitated in an integrated or holistic way, then it greatly boosts overall effectiveness in the meeting of needs. Hence it boosts what has become more commonly known as Civil Society (See also the last paragraph in my paper).

So I am looking forward with great hope to your use of Metaset to put your insights to work!