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