And there are two important and related concepts that
have to do with the way software architecture
evolves. The first one is Architectural Drift, which is
the introduction of architectural design decisions that are orthogonal to
a system's prescriptive architecture. That is, they're not included
in, encompassed by, or implied by the prescriptive architecture.
And the result of Architectural Drift is that you
start from a clean architecture, like the one that I'm
showing here, and then you start adding pieces without following a clear plan.
Like, for example, here, we add an additional room here, but we don't really
do it in the right way so we need to add something else
to keep it stable. And then maybe we want some more room so we
add a tent. And then another side of the house, it doesn't really
follow the same architecture but it doesn't matter, we just put it there because
we want to expand. And maybe then we want to put something classic
there, even though it doesn't really fit
the overall design and the overall architecture.
So I think you get my point, the fact
that the architecture then becomes unnecessarily complex, hard to understand
and ultimately awkward, just like the one that I'm
showing here, that goes from the original building into this
final monstrosity. The second concept is Architectural Erosion, which
is the introduction of architectural design decisions that violate a
system prescriptive architecture. So in this case, that we were
introducing decisions that were orthogonal,
here, were introducing this decisions
that don't comply with the prescriptive
architecture. And the result of Architectural Erosion
is typically a poor architecture an
architecture that is going to have problems in
the future. So both Architectural Drift
and Architectural Erosion take you away in
different ways from what you think your software architecture is or should be.