0 7 4 0 - 7 4 5 9 / 0 5 / $ 2 0 . 0 0 © 2 0 0 5 I E E E M a r c h / A p r i l 2 0 0 5 I E E E S O F T W A R E 1 9
focus
implications for the environment in which the
architecture is to be deployed. We believe that
a key to demystifying architecture products—
to dispel or reduce the “magic”—lies in the ar-
chitecture decisions concept.
Why architecture decisions?
Decisions. We make them every day. Some are
big, some small. So what’s the big deal? In most
architecture development processes, decisions
aren’t documented explicitly but are implicit in
the models the architect builds. Architects make
structuring decisions, such as choosing patterns,
in the component (logical) model, and deploy-
ment decisions, such as choosing runtime pat-
terns, in the physical model. However, stake-
holders such as developers, customers, and
even other architects don’t have the energy to
pore through architectural views to understand
the architecture. Developers want clear, decisive
guidance on how to proceed with a design. Cus-
tomers want a clear understanding of the envi-
ronmental changes that must occur and assur-
ance that the architecture meets their business
needs. Other architects want a clear, salient un-
derstanding of the architecture’s key aspects, in-
cluding the rationale and options the original ar-
chitect considered.
Traditional architectural approaches such
as RM-ODP (Reference Model for Open Dis-
tributed Processing), 4+1, or RUP (Rational
Unified Process) don’t satisfy these wants in a
clear and simple manner.1–3 These approaches
break down in several areas, such as
■ Conveying change. In an evolutionary envi-
ronment, it is challenging to document ar-
chitecture changes through conventional
views in a way developers or designers can
understand. Developers don’t want to wade
Architecture Decisions:
Demystifying Architecture
I t’s hard to count the “mystical” software architectures we’ve reviewedover the years. Their creators seem to want us to take many things onfaith. They require us to assume that the solution is somehow tied tobusiness drivers, that their architectural choices have rationales and
are implementable, and that they adequately considered competing alterna-
tives. Yet at times, the architecture seems to have no grounding in business
needs, and it’s difficult to see if the architects understand their decisions’
postmodern software design
Jeff Tyree and Art Akerman, Capital One Financial
You can make
your architecture
more transparent
and clarify its
rationale for
all stakeholders
by explicitly
documenting
major architecture
decisions.