Is your technical architecture driving the right outcomes?

As a civil servant, you’re likely involved in a programme or project with ambitious goals such as ‘improving how citizens interact with the government’ or ‘driving organisational efficiency’. You’ve considered every detail to ensure success against these critical outcomes – but have you taken a close look at your technical architecture?

In this blog, I explore the role of technical architecture in driving outcomes and the tools and approaches that will help you ensure success by defining non-negotiables, collaborating with stakeholders, communicating clearly, and managing risks. 

Establish the non-negotiables

The first step in establishing a technical architecture approach that drives the right outcomes is to set a north star. When push comes to shove and difficult priority calls need to be made, what is your single most important non-negotiable? This could be a particular technology choice, a cost saving that needs to be made, or the team shape available. Whatever it is, identify it and accept that all other decision points exist to support that goal. 

It’s important to listen to what users and the experts within your organisation are saying. That said, different stakeholders will likely have different priorities, so non-negotiables may differ depending on who you ask. So as a technical architect, the ability to communicate, build rapport, influence and advise, are all skills I keep sharp in my tool box. Have the conversations – lots of them. Find common ground, bring people on the journey with you and get buy-in. Once you’ve identified what your non-negotiables are, you’ll be able to have meaningful conversations about where to compromise, and what hard constraints you’ll have to navigate. 

Get agreement on key architecture qualities

One effective way to reach a consensus on architecture quality is through collaboration. Here’s a Open and transparent collaboration is always an effective way to reach a consensus on architecture quality. Here’s a straightforward approach that I’ve found works:

1. Gather stakeholders: Bring together key representatives from each stakeholder group for a whiteboard session
2. List architecture qualities: Write a list of architecture qualities
3. Rank priorities: Have each stakeholder list their top 5 most important qualities in order of priority. Let them share their unique perspectives with the group
4. Assign points: Assign points based on priority (e.g., 5 points for priority 1, 1 point for priority 5). You might need more granular scoring but it’s the discussions that follow that matter most
5. Discuss and agree: Count up the votes, discuss the outcome, and agree on the top 5-7 most important qualities as a group

I’ve found that this collaborative exercise builds empathy among stakeholders and surfaces important qualities. It reveals a potentially long list of qualities that, as a group, no one is overly concerned about, as well as insights into what has mattered historically and what may become more important in the future. 

Communicate your technical architecture

Technical communication done well enables digital and non digital teams/stakeholders to understand if an architecture is driving the right outcomes. 

My rule of thumb is that if you need to provide in-depth explanations or detailed walk-throughs to make your diagrams make sense, they’re probably not as effective as you thought. I recommend modelling your architecture in code. to help you to describe it accurately and concisely, it will also ensure consistency and promote reuse. 

The C4 Model with Structurizr is my go-to practice and tool of choice. It helps present the relevant parts of your architecture, at the right level of abstraction based on your audience. That makes it ideal for communicating your technical architecture effectively, and it’s extremely powerful when it comes to helping you diagnose issues in a collaborative way. Like all diagram techniques, it does take some practice. Using the C4 Model diagrams requires discipline. I’d urge you to focus on what exactly you’re trying to achieve with it and always think about your audience. It’s not about documenting everything in a diagram, it’s about building a shared understanding.

What’s great about using Structurizr is that the constraints imposed by the domain-specific language (DSL) help you rationalise and describe the architecture of each system in a consistent way. Once you have a model of your architecture, it then takes minutes to create clear and concise visualisations.

Assess performance

The next step is to view your architecture from the perspective of a particular quality goal or outcome that you feel your architecture is struggling to meet. 

On many projects I work on, we uncover and reveal key issues that stop an organisation from achieving their desired outcomes, simply by using system context diagrams. These diagrams are crucial because they are digestible by both technical and non-technical stakeholders. 

Working with one particular government organisation, we brought together leaders from across various departments and ran a risk storming exercise on their entire technical estate. What we learned changed how we viewed their architecture, brought to light how the current set-up was impacting their goals, and helped us focus on the most critical issues for the organisation from that point on.

We also gained valuable insights into their specific quality goals, such as system resilience. We produced detailed system container diagrams for different engineering teams within a complex technical environment. This enabled us to run a collaborative risk storming session with all squads simultaneously, with prompts to focus their thinking towards reliability engineering concepts. This highlighted clear high risk areas which we explored together to help them decide where to focus their mitigation efforts and identify which were low risks they could tolerate.

Regular risk storming is my preferred method for evaluating how a system’s architecture is performing, whether looking at the most important qualities or specific outcomes. They’re also useful for sprint retrospectives, post-mortems, or rebuilding stakeholder trust. The key is to keep assessing and addressing your biggest risks.

However, running these sessions can be challenging. I recommend careful planning, active stakeholder engagement, clear prompts for the attendees, and creating a safe environment for discussion.

Standing on the shoulders of giants

Crafting an effective technical architecture can be challenging and daunting, given the sheer number of options available and the need to meet user and organisational needs. The list of giants that have elevated our understanding of what software is, and what it can do, is a long one. I won’t attempt to list them all here, but the following are the main ones that influence the way I work with clients. 

• Mark Richards, Neil Ford, Pramod Sadalage & Zhamak Dehghani for giving us the books “Fundamentals of Software Architecture: An Engineering Approach” and the sequel “Software Architecture: The Hard Parts”. These provide the foundation for understanding the essential practices of modern software architecture and how to perform effective trade-off analysis across distributed systems.  

• Murat Erder and Pierre Pureur for giving us the book “Continuous Architecture In Practice” which takes a principled approach and focuses on how to continuously deliver an evolving architecture that drives quality. 

• Simon Brown’s C4 Model and collaborative risk identification technique risk-storming. As described within this blog, I’ve found this instrumental in my day-to-day work.

By standing on the shoulders of these giants (and the many others), we can see further. We are armed with a wealth of knowledge that helps us build architectures that truly drive the right outcomes for end users and citizens. I encourage you to draw on these resources, blend them with your own experiences, and continually adapt as your organisation evolves.

What I’ve shared here comes from my own experiences and the valuable insights from others in the field. As you use these strategies, know that they’re part of a bigger picture of knowledge, practice and completely yours to make your own.

About the Author