Back Room Front Room 2

44
ENTERPRISE INFORMATION SYSTEMS VI
2 THE ARCHITECTURAL
METAPHOR
It all started at IBM in the early 1960s. Fred Brooks
approached Jerry Weinberg with the idea that
architecture might be a good metaphor for what we
do in software development. Jerry encouraged him
to pursue the metaphor, and the rest is history.
Of course, it didn’t end there; many others would
rediscover the metaphor from different perspectives
over the years. One of them would be Peter Naur,
who noted this in 1968:
…software designers are in a similar position to
architects and civil engineers, particularly those
concerned with the design of large
heterogeneous constructions, such as towns and
industrial plants. It therefore seems natural that
we should turn to these subjects for ideas about
how to attack the design problem. As one single
example of such a source of ideas I would like to
mention: Christopher Alexander: Notes on the
Synthesis of Form. (Naur 1968)
As time progressed the metaphor took on a life
of its own, and the word took on a meaning that
might strike is originators as foreign or off-centre.
This problem wasn’t unique to software. The
architect Christopher Alexander also maintained that
architecture of the modern age had lost its roots.
Alexander argued that in early human cultures and in
contemporary rural cultures, people built their own
houses from materials familiar to them from
everyday life. They didn’t hire architects and
perhaps not even carpenters, but invested themselves
in the building of their homes or businesses.
Sometimes a community would come together for a
barn raising, or neighbours would lend a hand if
someone were re-building after a fire. However, the
homeowner was in touch with the materials of the
craft and with the details of the product itself.
Alexander faults technology with a decrease in
the quality of construction and decay in beauty. That
reinforced steel beams are available as construction
materials makes it possible to create a 70-foot span
in the lobby of a skyscraper hotel. That one can
build such structures doesn’t mean they are
beautiful. Another key aspect of technology is its
affinity for pre-manufactured and often massproduced
parts. Alexander noted that premanufactured
parts have all their degrees of freedom
fixed at the factory, and thus cannot be made to fit in
the context where they belong.
But it is impossible to form anything which has
the character of nature by adding preformed
parts.
When parts are modular and made before the
whole, by definition then, they are identical, and
it is impossible for every part to be unique,
according to its position in the whole.
(Alexander, 1979: p. 368)
This key idea gained the attention of the objectoriented
software community, a community that had
developed a stake in pre-manufactured software
parts called objects. The word of the day was reuse,
and objects had offered hope that pre-manufactured
objects could achieve this vision. The evidence
suggested otherwise. Reuse wasn’t working,
certainly not in the object-oriented world.
The other aspect of Alexander’s worldview that
gained the attention of the object-oriented
community was Alexander’s attentiveness to the
human side of design. Alexander’s notion of design
went far beyond utilitarianism to broader quality of
human life and to the core itself of human existence.
Patterns were ultimately about people.
At the time, the pattern community took this
human element as a value and a watchword but
failed to make it a central agenda. Having suffered
lapses in architectural thinking over the years, the
software community focused on the architectural
aspect of patterns as its end. This led to a
technological cornucopia of patterns, mostly lacking
in the life that was central to Alexander’s original
work. Alexander initially offered this insight on
software patterns ten years ago (and published the
perspective in 1999), but not much has changed in
the interim:
Have you asked whether a particular system of
patterns, taken as a system, will generate a
coherent computer program? If so, I have not yet
heard about that. But the point is, that is what we
were looking for all the time. Again, I have no
idea to what extent that is true for you and
whether you are looking for the same thing when
you work on software patterns.
So far, as a lay person trying to read some of the
works that have been published by you in this
field, it looks to me more as though mainly the
pattern concept, for you, is an inspiring format
that is a good way of exchanging fragmentary,
atomic ideas about programming. Indeed, as I
understand it, that part is working very well. But
these other two dimensions, (1) the moral
capacity to produce a living structure and (2) the
generativity of the thing, its capability of
producing coherent wholes—I haven’t seen very
much evidence of those two things in software
pattern theory. (Alexander 1999: p. 75)