How to effectively manage changes in architecture

Yesterday I had very interesting conversation with one Gartner Enterprise Architect, one thing he pointed out that one of the most important aspects of EA is to manage and document changes instead of documenting goal state blueprint, things are constantly changing, technology is also evolving, blueprint will only be in the game of catching it up with reality.

Reflecting on what he said, in fact it is also completely true in application architecture design and even at most lowest level class object modeling. One of the OO principle - Open-closed principle, is essentially guiding OO design to manage the OO dependency thereby change can be introduced in a more efficient manner - more consistent, quicker, easier and no side effect to the existing code base.

This also applies to information modeling. if the information designer takes the mindset of developing blueprint information model, in reality it will end up trying to catching up with real needs, and becomes irrelevant in the end. Two real practical difficulties make the goal state blueprint information model unrealistic, 1) It is hard to know all the possible use cases and scenarios upfront. 2) Business need is always evolving, new use case or scenario will arise. For more detail, you can refer to my earlier post about the fallacy of superset information model.


Having said the above, then shall we do not do any thing, just wait for things to happen and then passively react to it? No, we still need to create some level of goal state artifact, but bear in the mind things will change, and thus refine the architecture to manage the changes proactively and efficiently with the following steps

1) Think about the potential possibly changes that might be introduced in the future
2) Treat these changes as external stimulus, analyze the impact to the existing architecture
3) Within the architecture, different components will react to the changes with different level of sensitivity, some could be very fragile and subject to every minor changes, some might be relatively stable.
4) Based on the level of sensitivity, re-structure the design, group the components based on its sensitivity to external stimulus, and organize the component relationship and dependency so that the dependency is managed consistently
5) During re-structuring the component design, you may find some components react to changes inconsistently, fragile in one scenario, but rather stable in another scenario. If we encounter this situation, we may need to think about whether the component has too many responsibilities, so what we need to do is to separate the concerns.
6) During the refactoring the design, you may find that there are just too many permutations that the architecture can manage the future changes efficiently. That's when we should remember that architecture is things hard to change, you can further read Martin Folwer's article - Who Needs an Architect?

Hope the above useful.