1 year, 8 months ago

Belief #2 Best architectures are developed iteratively and just enough to guide decisions

Link: http://architecture-therapy.com/belief-2-best-architectures-are-developed-iteratively-and-just-enough-to-guide-decisions/?utm_source=rss&utm_medium=rss&utm_campaign=belief-2-best-architectures-are-developed-iteratively-and-just-enough-to-guide-decisions

Have you ever made an elaborate architecture, and then learned that a decision was made based on completely different criteria? You are not alone. This is a common experience among architects – even though few talks 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 ensure understanding and acknowledging the concerns and priorities of the decision makers you intend to support or maybe providing less details or maybe you were simply answering the wrong questions.

Our belief is that best architectures are aware of the decisions they guide and the purpose they service in the organisation. And they are provided iteratively, both in detail and over time.

Iteratively means that we revise the architecture adding more details to answer more detailed questions the closer we get to implementation or we iterate over the 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, e.g. decisions on portfolio level, Value Stream level, Domain level and Team level. 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 of these 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. 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 constraint of 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 but have a long-term commitment to maintain and make effective their architecture 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 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 people resource 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, and 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 this design 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 to maintain and make effective their architecture. 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?