Have you ever made an elaborate architecture, and then learned a decision was made based on completely different criteria? You are not alone. This is a common experience among architects – even though few talk about it. You can be angry with the ignorant and short-sighted leaders, but to be more constructive: would a different approach have helped? For example, maybe you provide less details or maybe you were simply answering the wrong questions. As another example, maybe ensure understanding and acknowledging the concerns and priorities of the decision makers you intend to support.
Our belief is that best architectures are aware of the decisions they guide and the purpose they service in the organisation. Therefore they are developed iteratively, both in detail and over time.
Iterative in details means that we revise the architecture adding more details to answer more detailed questions the closer we get to implementation. Iterative in time means we iterate over the same solution with new requirements.
The main reason we want to develop architecture iteratively is the fact that large organisations have several levels of decision making that impacts the design. This means that decisions on Portfolio Level, Value Stream level, Domain level and Team level all impacts the design differently. We believe it is of key importance to design architecture services and architecture artefacts in a way that communicates just-in-time, and just-enough to guide those decisions. Consequently, we need to understand the purpose of each decision-levels in our organization. Some are more related to funding and strategy alignment, some more related to placing the responsibility for various elements and planning for dependencies, where others aim at the architectural quality of the solution. Another reason for the iterative approach is the evolutionary nature of the business and hence the architecture must change with the business.
For example, on the portfolio level you make enough architecture to decide a good split in value streams and services. Hence the architecture provides guidance which value stream and services are impacted by a new business need. You also use the portfolio level architecture to make decisions on investments. Will you invest in a new area or in improvements of an existing area?
Another example on the domain level. In the credit domain of a bank you will need architecture to make decisions on how to best support the multiple loan and credit products. Thus, the architecture on the domain level here will focus on the right split in services as well as which technology will best serve the need within the constraints of the IT strategy.
An iterative approach implicitly means that current architecture work takes the outset in previous architectures to retain knowledge and transparency of decisions – unless the current architecture is the first one. This sounds obvious but is far from trivial. It requires an architecture capability, where architects are not delivering one-off deliverables. Instead it has a long-term commitment to maintain and make architecture effective by working together with architects representing higher and lower level iterations.
The future is unpredictable, yet we will be using too much time refactoring, if we have no idea what is more certain and what is less certain. The Scaled Agile Framework for Enterprises (SAFe) has a principle stating, “Assume variability; preserve option”. This addresses the fact that we are often inclined to make early design decisions to limit and constrain, what we must consider and think about. This is even strongly enforced in a project-based organization, where detailed project description and business cases covering time estimates, software licenses and hardware investments are usually required to gate pass and get funding. But what happens is that we get wiser on our requirements and options as time goes. Hence, too early commitments to specific solutions leads to wasted time or a sub-optimal design.
So how do we know where to “preserve option” – or at least design for flexibility? Gerben Wierda suggests in his book “Chess and the Art of Enterprise Architecture”, that we should change our approach from making future state “designs” to making requirements for later designs. The most important aspect to consider here is what he calls “Robustness under Uncertainty”. Instead of only looking at current strategy – which is often limited to a few years where core elements of our architectures often will have a 15-year life-span – we need to ask about the specific uncertainties that the design should take into account. In other words what cannot be assumed. This could be that a given architecture should not necessarily only work for this product, asset, country, segment etc.
To summarize we believe that best architectures are developed iteratively in a way that enables just-in-time, and just-enough decision making according to the purposes they support in the organisation. Best architectures retain knowledge and transparency of decisions, which requires architects to have a long-term commitment in maintaining and making their architecture effective. Specifically, we should learn not to hide away uncertainties, but to be explicit about them to preserve option in the right places.
So, do you agree and develop your architecture iteratively?
2 thoughts on “Belief #2 Best architectures are developed iteratively”