RESUMEN
Every interesting
software-intensive system has an architecture. While some of
these architectures are intentional, most appear to be accidental. Philippe Kruchten has observed that "the life of
a software architect is a
long and rapid succession of suboptimal
design decisions taken partly in the dark." The journey between
vision and ultimate executable system is complex,
and for every
interesting software-intensive
system that path is marked
by myriad decisions, some large and
some small, some of which
advance progress while others represent
vestigial dead ends or trigger
points for scrap and rework.
As Philippe also observes, the architecture of classical systems
comes primarily from theft, whereas the architecture of unprecedented systems comes largely from intuition carried out in the context of a controlled
exploratory process. The fact that
this is so for software-intensive systems shouldn't come as a surprise, for as Henry Petroski explains in his book To
Engineer Is Human (Vintage, 1992), all sound engineering disciplines advance by building on past successes
while simultaneously mitigating causes of observable failure.Thus, having an accidental architecture is not necessarily
a bad thing, as long as the decisions that
make up that architecture are made manifest and the essential
ones are made visible as soon
as they are instituted and then allowed
to remain visible throughout the meaningful life of that system.
Insofar as we can then name these
architectures after they're formed, we can use these names and their
associated semantics to communicate decisions using a common language, just as we can do now with design
patterns, and perhaps even reuse
these architectural patterns in future systems. In other words, by naming these accidental architectures, we again raise
the level of abstraction by which we can describe and reason about
a system.