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 saying that 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 a rapidly changing, ambiguous, turbulent 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, 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
cases this leads to a solution that is hard to maintain and evolve, likely
redundant (solving the same again and again), and suffers from quality issues
typically related to testability, security and performance. Multiply this by
the number of development teams and number of years having that kind of
development in a large organisation and you have an idea where some of the
complexity comes from.
In our experience best architectures enable the 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 catalogue. 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, you will see behaviour, 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. 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 and ensure your architecture is created to manage these, while keeping options open for everything else.
technology catalogue 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
catalogue can provide stability if the choices allow for flexibility in
building solutions and the governance around managing the catalogue is lean and
not too cumbersome (e.g. with many layers of decision). Basically, the purpose
of the technology catalogue is to provide a boundary where the people building
solutions can make decisions on their own and avoid going through heavy
compliance processes and slowing down the process.
just two examples on how architecture can provide stability as a foundation for
the organisation to be agile.
architecture ensure stability, while creating room for flexibility in your
 This is basically Conway’s law