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
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.
[Fowler 96] Fowler, M. Analysis Patterns: Reusable Object Models,
Addison-Wesley, Reading MA, in press.
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,
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
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.