I am a consultant who does analysis and design of business systems. It didn't take too many years of this work to realize that I kept running into similar situations. My growing experience allowed me take a model from a previous project and adapt it the needs of a new one. This store of previous models became a key part of skills. This led me to want to write down and publish some of these useful models. These brought me into contact with the patterns community who saw my work as a way of bringing the idea of patterns into analysis. My work has led to a book on analysis patterns [Fowler 96].

As a practicing developer I've also been interested in the notion of Business Objects. The idea of a market of standard objects which solve recurring business problems in very appealing. This position paper looks at my work on analysis patterns and its relationship to business objects, including a few opinions which I've formed in the process of capturing analysis objects.

What is an Analysis Pattern?
There are various people out there who are working on analysis patterns, but little has been published so far. The best way for me to define an analysis pattern is for me to give a small example.

Figure 1 shows the measurement pattern from my book. The specific context is that of capturing measurements about a patient in a health care setting. The obvious way to capture measurements of a patient is to represent them as attributes of the patient. This works well if there are not too many, but a hospital can measure hundreds or thousands of such measurements. Defining an attribute for each one would mean that person would have thousands of operations - an untenably complex interface. A solution to this is to consider all the various things that can be measured (height, weight, blood glucose level, and so on) as instances of the object type phenomenon type. Now a person may have many measurements each of which assigns a quantity to a specific phenomenon type. A person now has only one attribute for all its measurements and the complexity of dealing with these measurements is shifted to querying thousands of instances of measurement and phenomenon type. A further advantage of this approach is that we may now add further attributes to the measurement to record such things as who did it, when it was done, where it was done, etc.

Figure 1: The measurement pattern in UML notation

Example: John Smith is 6 feet high would be represented by a measurement with person John Smith, phenomenon type of height, and quantity 6 feet.

This is a very simple pattern but we can build on it to achieve more complex patterns. These explore the recording of qualitatative as well as quantitative information and cause and effect relationships between observations.

The Measurement patterns, and the patterns that are built upon it, were developed during modeling of the health care process for the British National Health Service (NHS). As such they are clearly based on health care needs. The interesting thing is that a couple of years later I took many of these patterns and used them on a project for corporate financial analysis for a large US manufacturer. The patterns proved to be a very valuable starting point for our work, and although some changes were needed, the business financial analysis model was still recognizably based on the health care model. Indeed many of the changes can be used in health care.

Analysis Patterns and Business Objects
So what are the differences and similarities between analysis patterns and business objects. The key difference to me is that Business Objects are prescriptive while patterns are suggestive. If I buy business objects for accounting I have to use them in exactly the way they are written. I can make some changes by appropriate subclassing and modification, but the changes are very much based on what the writer of the business object allows me to alter. An analysis pattern is a model and a discussion of why the model is the way it is and its strengths and weaknesses. I am free to tweak the pattern in any way I like before implementing it. If the pattern comes with sample code then I can use the code, but again I'm free to make any alterations I like. The really important thing about a pattern is not the model (or code) but the rationale behind it.

Thus Business Objects have a lot strengths over analysis patterns. All you have to do to use a business object is to buy and install it, while with a pattern you are just given the idea and have to implement it yourself. Even sample code is meant more as an explanation than as a useful unit on its own.

Business objects also help more in integration. If two systems are based on the same business objects integration should be easy. However being based on the same pattern means little. The basic idea, the classes and interactions will be similar, but names would probably be all different and so the integration would still be hard work. There are still advantages in the using the same pattern, the similarities will make it much easier to understand what is going on.

So business objects seem so much better than analysis patterns that you wonder why we might need analysis patterns. I have two reasons. Firstly analysis patterns can document the business objects. They can show why the business objects are they way they are, and why they work the way they do. That makes them easier to use.

The second reason is more depressing. Business objects require you to, at least some extent, buy into their way of doing things. I've spent much of my career around people who have been trying to come up with standard plans for businesses, such as corporate data models. On the whole, they don't work. A colleague of mine remembers a case in a large corporation when they tried to come up with a standard definition of account. The business had 13 incompatible definitions, and could not resolve them. That was a single corporation. Most organizations can relate similar tales. Sometimes the issues that sink the standardization are political, sometimes they reflect real conceptual differences. Either way the standard is doomed. The prescriptiveness of business objects is a two-edged sword. Patterns are easier to promulgate. Since they are suggestive they more likely to spread. The benefits of patterns are less, but you are more likely to realize them. Thus you can patterns as a low impact way to get some commonality amongst systems, with business objects acting as a high demand / high payoff approach.

In this way of looking at things, analysis patterns and business objects are complementary to the other and we should develop both ideas using the appropriate approach depending on circumstances.

Working on analysis patterns has led to another thought. When people discuss business objects they talk about objects for vertical markets: health care, manufacturing, finance, and so on. But my experience with the measurement patterns showed that patterns and business objects in health care were usable for corporate finance. This crosses those vertical domains. The patterns are really about the diagnostic process, and the diagnostic process is used in many vertical domains. I believe that analysis patterns and business objects are best organized by abstract processes, for example diagnosis, accounting, planning, and trading. I'm not sure exactly how these divide up, or what the overall picture of abstract processes is. But I think that is the direction to go in.

--------------------------------------------------------------------------------
References
[Fowler 96] Fowler, M. Analysis Patterns: Reusable Object Models, Addison-Wesley, Reading MA, in press.
Further Reading
Since my book is not out until OOPSLA, these give you some pointers to other places where there are examples of analysis patterns, as well as work by other people in this field.

Fowler, M. "Modelling Organisation Structures," Report on Object Analysis and Design, 2,2, (1995), pp. 20-23.
An early paper that discusses the accountability pattern.

Fowler, M., Cairns, T. and Thursz, M. "Observations and Measurement," Report on Object Analysis and Design, 2,3, (1995), pp. 20-24,37.
An early paper that discusses the observation patterns

Fowler, M. "Accountability and Organization Structures," In Pattern Languages of Program Design 2, Vlissides, J.M. et al. ed., Addison-Wesley, (1996), pp.353-370.
A paper that covers the same material as the ROAD article on organisation structures, but uses a more pattern-like form.

Fowler, M. Recurring Events, Portland Pattern Repository, <http://c2.com/ppr/titles.html>, 1996.
A more recent paper on handling such things as 'as every second thursday in June'.

Hay, D. Data Model Patterns: conventions of thought, Dorset House, New York, NY, 1996.
A very similar book to mine, but using a relational modeling technique.

Coad, P., North, D. and Mayfield, M. Object Models: strategies, patterns and applications, Prentice Hall, Englewood Cliffs, 1995.
These patterns are really quite different to mine, at least in intent. They are more abstract and are aiming at trying to generate models, rather than examples of actual models.

Scheer, A.-W. Business Process Engineering: reference models for industrial enterprises, (Second Edition), Spinger-Verlag, Berlin, Germany, 1994.
These are not patterns, but rather a proposed reference model for manufacturing. It is very relational in nature, but a good source of ideas for patterns.