To do that let's look at how architectural evolution
occurs in practice. Ideally when a system evolves, its prescriptive
architecture should be modified first. Just like when you
modify a building. You change the blueprint and then you
change the actual building. You don't go the other
way around. In software, unfortunately this rarely ever happens in
practice. In practice the system, and therefore it's descriptive
architecture are often directly modified. Like in this case that
I'm showing here. So what happens is that the architecture
as conceived does not change. Whereas the architecture as implemented, does
change. And therefore these two things start diverging. And this really
happens for a number of reasons. So I'm just going to list
a few of those reasons here. In some cases it
just happens for plain sloppiness. I need to make this modification
and I don't really want to go back and look at
the prescriptive architecture modified. I'm just going to make the change, and
maybe I'll fix the description later. And then you never really get
to it. In other cases you do this because of the perception
of short deadlines. If you have to do something by this afternoon,
you're not going through a four
month software architecture review, you normally just
get to it, and do it. In some cases a prescriptive architecture
is not even present, so there's a lack of documentation. So in these
cases, clearly, you cannot go and modify something that does not even
exist, and so you jump directly to the code and start modifying that.
And as I said there's many, many more
other reasons why that happen. But important point here is
that it does happen and it does happen often
and the result is that prescriptive and descriptive architectures diverge.