How to Get Ahead in Architecture
A Pattern Language for the Introduction and Practice of Software
Architecture
David Harvey September 1998
Motivation
There are plenty of patterns and pattern catalogues in the literature which
address the design and implementation of software systems (idioms, design
patterns, architectural styles and patterns). There is, however, nothing
that situates these (generally) point patterns in the context of the development
of architectural software development itself. How to Get Ahead in Architecture
(HTGAIA) started as a vehicle for my own reflection on the practice
of architecture: it is published here as a work-in-progress for comment,
refutation, corroboration, extension…
The systems I have been involved with building over the last few years
have been similar in scope and intent:
-
Large
-
Distributed
-
Strong workflow component
-
Transactional (a property of the system as a whole, not necessarily any
specific component or interaction, hence this doesn't necessarily imply
"real" transactions)
-
Fundamentally perform information processing (capture, transform, record,
present)
So there's no intention here to cover real-time systems such as those developed
in control domains. When it comes to the detailed description of technologies,
capabilities, requirements, the language will be based firmly in the experience
of its contributors.
These ideas were explored during a workshop of the same name at the
Object Technology 98 conference. A group of participants adopted draft
patterns resulting from that workshop: while it must be said the collaboration
hasn't been particularly active, I'd like to take this opportunity to credit
those involved and make the draft patterns from the workshop available.
Why architecture?
An overloaded term. The properties of objects, an abstraction over those
properties (architectural style), the work done by architects. The metaphor
(for such it is) can be thought of as just another example of an insecure
profession's envy-complex (yesterday we aspired to be engineers, today
architects, tomorrow?), but it is more appropriate than engineering, which
it subsumes with other vital concerns:
-
Engineering (properties and appropriate use of materials)
-
Utility (design for use)
-
Aesthetics (architecture as fine art)
-
Culture (common expression of a shared approach)
Why patterns?
-
Medium for reflection
-
Appropriate for craft
-
Basis in (shared)experience
Why a pattern language?
Much of the current software patterns literature takes the form of single
stand-alone patterns or pattern catalogues. These have their place as records
of point solutions or samplings of patterns applicable to one or more domains
in the development process. Yet for me they fail to capture the resonance
of a full pattern language, of which the towering example is (of course)
Alexander's. Characteristics of a pattern language which go beyond the
point pattern or catalogue:
-
Instruction
A pattern language makes an attempt to offer a comprehensive description
of a body of culture. It is possible to use this as a primer in that culture:
we can use a pattern language to answer the question "why do we do X this
way?". If the language has no good answer to that question in its domain,
then it is incomplete.
-
Mindmap
A pattern language, like an unlearned natural language, needs to overlap
with our experience. The familiarity of parts of the language (perhaps
giving us names to talk about and relate concepts we already "knew" at
some level) acts as a powerful hook for acquiring the rest of the language.
Once the map is acquired, we start working with the language as a given.
(In this view a pattern language is a self-reinforcing collection of memes,
with the idea of Pattern Language itself a meme).
-
Vehicle of change
By expressing a culture in a form which can be readily accessed, a
pattern language states a vision of how much better things could
be.
-
Manifesto
A much better term (given the political and cultural connotations unavoidable
when discussing the kind of quality we want to inspire), and a much
better medium, than a methodology or standards body.
Inspiration
HTGAIA is directly inspired by Alexander's pattern language. It aims to
mirror the breadth of the exemplar in describing a culture of architectural
development in a large organisation, solving problems of timely and accurate
information capture, processing and presentation. (Alexander's first pattern
concerns the distribution of self-governing states in a territory: the
last talks about what to put on your shelves and walls.)
Patterns
This is work in progress, so the list here includes patterns at varying
stages of completion. The status of individual patterns is noted:
| Placeholder |
no pattern yet |
| Sketch |
bare bones of pattern outlined |
| Draft |
full pattern in draft form |
| Beta |
polished draft |
| Final |
as final as it gets |
As more and more of the placeholders get filled, and as new patterns
are added, the language will become more and more connected. Of the patterns
outlined above the most fundamental is the first: for now this is a good
place to start, but be warned – there are currently all too many dead-ends
in the links from pattern to pattern.
Observations, questions
The Naming of Patterns
The Naming of Cats is a difficult matter,
It isn't just one of your holiday games
Avoid the temptation to give a pattern a fancy or clever name. A pattern
is best named after the most salient aspect of the solution, rather
than the problem. (What about naming a pattern langue? Here I think there's
more leeway. This one is named after the film How to Get Ahead in Advertising
starring Richard E Grant, during which an advertising executive with an
attack of conscience grows an immoral second head which takes over his
life...)
What makes a pattern more than
-
A deliverable?
-
A process step?
-
A good idea?
Some of the patterns in HTGAIA are at this stage too close to one or more
of these three poles. For example, Architecture Map might look too
much like a deliverable from a process, rather than a pattern. I've tried
to make it more general than a standard methodology deliverable (sure,
make a map, but it's up to you exactly how you do it and what goes into
it – driven of course by subsequent, pattern-expressed decisions).
Maxims
-
Quality is not (only) a property of a product or process. It is rarely
measurable.
-
This sort of quality (call it QWAN, if you can) is a cultural resultant
-
Control (all too often repression) of culture is politics
-
Therefore quality is a political issue.
-
You can't expect others to care about what you do and how you do it, unless
you do.
-
If you don't think about how you do things, how can you care about it?
-
Only reflect!
© 1998 David Harvey. All rights reserved
Created 8 September ,1998
Updated 8 September, 1998
Home
Mail