Belief #5 Best architectures enable organisational agility

Have you ever experienced that your architecture is limiting your agility?

We have indeed and often it is because of no or too much architecture guidance. We have also experienced people stating agility is about fast changes, and therefore contradicts the up-front creation of architecture.

We agree that agility is the ability of an organization to renew itself, adapt, change quickly, and succeed in an ambiguous and rapidly changing environment. However, we disagree that agility is incompatible with stability—quite the contrary. Agility requires stability and architecture thinking can provide that stability.

For example, with no architecture guidance or boundaries the playing field is completely open. Then people will often make specific choices based on

• The easiest to do right now
• Hey – this is the new shiny technology (and then it was not …)
• I just learned these new patterns and approaches let’s use them

In most cases this leads to a solution that is hard to maintain and evolve. It will likely be redundant (solving the same again and again) and suffer from quality issues typically related to test-ability, security and performance. Multiply this by the number of development teams and number of years with that kind of development in a large organisation, then you have an idea where some of the complexity comes from.

In our experience best architectures enables organizational agility by defining elements of the design that are stable, and elements that require a flexible structure. And best architectures only define enough detail to guide the decisions at hand. Consequently, the architecture keep options open, while providing a stable foundation for the solution to evolve.

So, what could be stable elements? Two examples: the logic in your business domain and a technology catalog. One is a given, the other is decided.

When you abstract your architecture from the current use of IT and the current organisational setup, and look at what is being done, what are the dependencies, the sequence and rules. Then you will see the behavior, structure and logic which really constitute the domain knowledge. This is fundamentally stable and should guide the definition of stable structures in our systems, i.e. the structure in your architecture and your organisation[1]. The key in using domain knowledge, is to avoid creating artificial dependencies due to how you have organised. Rather using the domain knowledge, you figure out the dependencies inherent in the domain. You ensure your architecture is created to manage these, while keeping options open for everything else.

A technology catalog can provide a set of technology choices enabling fast decisions as well as ensuring that the organisation does not steadily increase the number of technologies to maintain and monitor. Hence a technology catalog provides stability if the choices allow for flexibility in building solutions, and the governance around managing the catalog is lean and not too cumbersome (e.g. with many layers of decision). Basically, the purpose of the technology catalog is to provide a boundary, where the people building solutions can make decisions on their own. Thus avoiding the need to go through heavy compliance processes and slowing down the process.

These are just two examples on how architecture can provide stability as a foundation for the organisation to be agile.

Does your architecture ensure stability, while creating room for flexibility in your organisation?

---

[1]  This is basically Conway’s law