Back Room Front Room 2

In the world of buildings and towns, architecture
is sometimes an end in itself: an artistic statement.
Such is rarely the case in software. Good aesthetics
compensate neither for lack of structural soundness
nor for human inconvenience. The goal of
architecture, and therefore of patterns, should be the
morally profound, coherent wholes that generate
human comfort.
2.1 Architecture and Process
Software developers sometimes use the term
“architect” as a verb. Architecture is a noun; the
verb is design. Design is the process we use to solve
a problem. It starts with a vague understanding of
the problem and gradually builds system structure.
In doing so, it also builds an increased understanding
of the problem.
The process is more than just mapping an
understanding of the problem onto solution
structures that can subsequently be built. Most of the
work on a new system focuses on identifying what
the system should do and then, to a lesser degree, on
how the system should accomplish these ends. After
the first release comes maintenance. The process of
maintenance design focuses on recovering some
understanding of what the system does and how it
does it, understanding that has been lost over time.
One does maintenance to fix problems in the
software, problems that have arisen as the user
community interfaces with the software architecture
and its applications. It is perhaps only on the first
round of maintenance that requirements become
clear. Anything prior to that is either a hope or a
guess.
The architecture of a system is therefore not a
truth—or, if it is a truth, it is a truth at a given point
of time that emerges from the process of
development itself. Software design is dialectic
between the development community and the
architecture. The architecture “learns” from the
processes of the organizations that build it, and
serves the processes of the organizations that use it.
In a healthy development, there is good feedback
from the user process to the designer process.
Architecture has meaning only in the context of
these associated processes. These processes owe to
the structure and values of the organizations in
which they arise. Carried out well, these processes
can improve quality of life for inhabitants of both
the design and user communities.
ORGANIZATIONAL PATTERNS 45
3 THE HUMAN SIDE OF
ARCHITECTURE
Alexander believed that the whole focus of
architecture should be quality of life. He had no
time for architecture as art for its own sake; the
artistic quality of architecture should emanate from
its human scale and its suitability to human needs.
He went beyond the saw of “form follows function”
to embrace form also as the source of beauty and as
the foundation of harmony in a system. Architecture
exists for the sake of those who inhabit it.
Software architecture in fact has, or should have,
an analogous focus. The software itself doesn’t care
what its architecture is. In fact, many stock
principles of architecture such as coupling and
cohesion work against desiderata such as
performance. Why, then, are we concerned about
architecture?
In a 1968 Datamation article (Conway 1968),
Conway proposed that the structure of any software
architecture reflects the structure of the organization
that builds it. Suppose you were going to form a
company to write compilers. If the company were
divided into three departments, it is almost certain
that the company will produce a three-pass compiler.
Software architecture must align with the structure
of the organization that builds it. If the organization
already exists, the architecture should reflect that
existing structure.
We can think of software developers as
“inhabiting” the code. We too often forget that the
users of a program are also “inhabitants” of the code.
That suggests that software architecture must align
not only with the structure of the organization that
builds it, but also with that of the organization that
uses it. Consider a CAD system that will be used to
build an airplane. The enterprise using the tool has a
design group, a manufacturing group, and a
maintenance group (and other groups as well, no
doubt). Each group has its own culture and
expertise. We will want to build the CAD system
with one component optimized for the designers,
another component optimized for manufacturing,
and another for field maintenance. In short, the
architecture of the CAD system should follow the
structure of the using organization. One can elicit
this structure using techniques such as domain
analysis (Coplien 1998), which aligns the overall
system architecture with the structure of the
business. The final alignment to attend to is that
between the software architecture and that of the
development organization. Naïvely put, the business
structure shapes the software architecture and the
software architecture shapes the development teams.
In reality, some development teams have historic