Architecture is Context

For architects designing complex solutions, a well-documented set of requirements can never be the sole basis of the architecture. Architects have to undestand why these specific requirements are relevant to their stakeholders, and most likely will have to ask “why?” again and again to understand the stakeholders’ real needs, so as to design the architecture that best fulfills those needs and the goals behind them.  When talking to architects about their work, I often summarize this principle as “Architecture is Context”.

The importance of context

What makes it so important for architects to understand the wider context of their solution? When we view architecture as a set of design decisions, a good measure of a decision’s architectural significance is the economic impact of that decision on the collective stakeholders affected by it (see RCDA: Architecting as a Risk- and Cost Management Discipline). So in order for architects to understand the significance of their decisions, they need to have a firm grasp of the economic context of the solution they are architecting.

A second reason architects need to understand context and background is because requirements (especially non-functional or quality attribute requirements) often turn out to cause conflicts in design decisions: for example, making certain company data available in a mobile app may be good for  productivity, but bad for security. Architects can only make these types of trade-offs if they not only know the requirements, but also fully understand the business and technology drivers behind them (asking your stakeholders to prioritize NFRs doesn’t really help, since this quickly becomes a meaningless exercise if it is done separate from the design – see Issues Dealing with Non-Functional Requirements across the Contractual Divide).

Flavors of context

A complex solution has many types of stakeholders, each of which have their own goals and needs, contributing to the integral solution context. When focusing on economic impact, the first thing that comes to mind is the business context defined by the business stakeholders, who pay for or benefit from the solution. Architectural significance, however, is determined by a much wider range of stakeholders. Examples are operational and delivery stakeholders, for whom we need to understand the technology and project/release context, and citizens affected by the solution’s safety, security and privacy context.

Understanding context

What can architects do to improve their understanding of a solution’s context, and design architectures that better fit their stakeholders’ underlying needs?

Talk to stakeholders. Architects who talk to their stakeholders get a better understanding of their context – well duh, talk about kicking in an open door. And yet… I still run into architects that are so focused on documentation, or on a particular subset of stakeholders, that they forget to interact with the rest. This goes both ways: being too exclusively focused on your technical stakeholders (“architects must code!”) is as bad as only being interested in “the business” side of things. Make sure you speak your stakeholders’ language – watch Jochem Schulenklopper’s SATURN 2015 talk “Why they just don’t get it” if you want to know how. Without actually talking to stakeholders, my other two tips (modeling context and trace decisions to context) lose most of their value.

Modeling context. Modeling system context has been part of software design methodologies since the early days. In the 70s, the Yourdon Structured Design method involved a context diagram, which showed which external systems and users interacted with a system – a technique many (including me) still consider essential for clarifying the solution boundary and external dependencies. In fact, the first C in Simon Brown’s C4 model stands for Context, represented by just such a context diagram. UML’s use case diagrams fulfill a similar role (but much less clearly). Michael Jackson’s problem frames go a step further by modeling not just physical and logical context of the system itself, but also the wider context needed to understand the design problem to be solved.

Trace design decisions to context. Once we have gone to all the trouble of understanding the context of the solution we are architecting, it is paramount that we record the impact of that understanding on our architecture. The perfect place to do that is in the ‘rationale’ section of our architectural decision record. Here is where we show that our decision is based on something in the real world, real concerns, goals or other drivers from our stakeholders. This not only helps us get buy-in for the decision, but also brings huge benefits if the context changes (or should I say “when the context changes”, because it usually does). If we have to revisit an architectural decision, knowing the full context of the original decision rationale makes re-appraising the trade-offs much easier. Putting it in economic terms, tracing your architectural decisions to their context lowers the cost of change – making your architecture more agile.

In conclusion, context is key in architecture, and there are several ways in which architects can improve their understanding of context and its impact. The most important tip is to talk to your stakeholders, and keep asking them “why?”. What is your take on this? Do you always draw a context diagram? How much context do you put in your architectural decision records?

More ideas about architecture in the digital age on eltjopoort.nl?