Scaling the Practice of Architecture, Conversationally

When “traditional” approaches to architecture break down

I'll be honest, “traditional” approaches to software architecture (i.e. non-coding, decision-taking, diagram-drawing) are hard for me to make work at the best of times. But while using them in the world of continuously delivering autonomous teams I’ve repeatedly found myself faced with an impossible task: to be everywhere, tolerating significant contextual variance, and blocking no-one.

It made me wonder. Was there an alternative?

There was: I stopped taking architectural decisions. Completely.

In this article I’ll introduce this alternative mindset and the associated set of tools and practices which allow me to upend the traditional role of a “Software Architect” while simultaneously bringing the practice of software architecture to the fore across development teams. More importantly, I’ll explain how, within this alternative approach, everyone can do the architecting they need, safely and efficiently, without everything descending into chaos. 1

We need more ways to “do” architecture, not less.

The moves in software delivery towards ever-increasing team autonomy have, in my mind at least, heightened the need for more architectural thinking combined with alternative approaches to architectural decision-making.

Ensuring our software teams experience true autonomy raises a key problem: how might a small group of architects feed a significant number of hungry, value-stream-aligned teams? Why? Because in this environment Architects 2 now need to be in many, many more places at once, doing all that traditional “architecture”.

What we need is a workable way to approach the human-scaling challenges of team autonomy and the architectures which manifest as a result.

In the remainder of this article I’ll introduce an alternative way of doing and governing architecture. I’ll explain in detail what it is, how it works, and how you might adopt it yourself. Most importantly, I’ll highlight how to fail, in order that you might succeed.

The most fundamental element: decision-making via the “Advice Process”

Let’s take as our starting point a team which we aim to make maximally independent. Clearly this team will need somehow to engage in architectural thinking and decision-taking, but how?

These “many centres of decision making” are precisely what we need, yet straight away it’s clear that traditional, top-down architecture, with a select group of all-powerful architects taking all the decisions, runs contrary to such a decentralised model. “And yet”, the challenge is voiced “decisions still need to be made - that’s what architecture is”, and these skeptics are right.

These architectural decisions must still be made deliberately - otherwise we’ll be back where we started, or worse. Therefore, the first aspect in this alternative approach, it’s core element in fact, must describe how it delivers on decision-making. It’s called the “Advice Process”.

The Advice Process is the core element of this anarchist, decentralised approach to architecture. It’s greatest quality is it’s remarkably simplicity. It comprises one rule, and one qualifier:

That’s it. That’s the Advice Process in its entirety.

This apparent straightforwardness hides however a key concept which it’s worth making explicit; while decision-takers are in no way obliged to agree with the advice the folks in these two consulted groups give them, they must seek it out, and they must listen to and record it. We are not looking for consensus here, but we are looking for a broad range of inputs and voices.

A challenge frequently raised against this concerns just how many people must be consulted. It is a valid concern, but a mitigatable one. When deploying this technique we create a checklist to help those in the decision-making seat identify who to speak to, and in which regard. InfoSec impacted? Talk to the CISO. Getting close to PII? Engage Mary in the data team and Vanessa in legal. A potential change to the user onboarding flow? Talk to your UX lead. About to adopt a new cloud service? Chat to Kris the cloud architect. Thinking about a change to your API? Speak to all the leads of the teams who are your consumers.

Sometimes this list of consultees can be a long one. That’s fine. Some decisions are large ones, and the advice-scope is a clear indication of both size and import. Sometimes decisions can be made smaller in scope and many consequently are. Other times the sheer number of folks impacted makes the decide-ee think again. Is this thing which might make their life a little bit easier really worth the effort of consulting all those people? Or, can they split this large decision into multiple, smaller decisions? When decisions do proceed, they are frequently right-sized purely as a matter of expediency. 3

Can we push the Advice Process further? Yes we can, and we ought. I always encourage those following it to specifically seek out those who will disagree with them. Freed from the need to agree with what they hear, they inevitably engage far more seriously. Consequently the depth and breadth of advice received is greater. Decisions don’t tend to suffer as a consequence either. Neither does their learning.

Which brings us to the broader topic of benefits of the Advice Process. When deployed, I have always seen better, faster, more accountable decisions, and most importantly decisions which are understood and owned by those who implement them, precisely because the decidee is the one with the need as well as the one who is accountable.

As a side-effect, the pool of available decision-takers also grows, each of whom will soon be on the look-out for decisions which need to be made, and, given the feeling of empowered safety that the Advice Process gives them, flag them up and drive them to conclusion. The fact that a team's need for a decision to be taken can be met by themselves also leads to appropriate levels of bias-to-action, with accountability acting as a brake when it's required.

By working in this way we remove both the need for a fixed and permanent hierarchy and an abiding master decision-taker. It is for these two reasons that the Advice Process is the most fundamental element of this approach to architecture, because decentralised decision-making is the core element of anything which aspires to call itself “anarchistic”.

But wait, did we just remove in one fell swoop all need for we “traditional” architects? Not at all, but clearly our role has changed. In the following sections of this article - which introduces the supporting elements of this approach - we will see a set of rejuvenated practices and tools which allow us to get the teams, and the businesses they underpin, where they need to be.

Before we proceed to these supporting elements it is useful to take a short detour to highlight and discuss the one thing that all the remaining elements to this decentralised approach share, and also have in common with the core element: their focus on conversation, and it’s role in efficiently arriving at, and spreading, shared understanding.

The Four Supporting Elements

How this typically works in practice

Given all this, how might you see it all working in practice? Let’s take a look…

When the need for an architectural decision first arises it will most likely be vague and possibly poorly understood. It’s therefore great to open up a new ADR template right away and start trying to fill it in.

First to be tackled is the “context” section. To attempt this we need to understand the “why” of our decision as well as surrounding forces which we need to balance. We’ll probably rapidly realise we need to do some research to be able to complete even this short section.

Early ports of call in this research ought to be the architectural principles and radar. The principles, you’ll recall, give us an idea of the direction of travel which our ideal solution will ideally manifest. Not all will be relevant, but some principles ought to help our decision-making. Recall that it’s an architectural principal’s primary goal to assist in the evaluation of multiple technical possibilities, and highlight the one which fits best.

Sometimes, the experience will be a little different. One alternative is that a relevant principle cannot help you pick between two options, then there is either very little difference to choose between, or potentially, your principle isn’t S.M.A.R.T. enough. This is a good reason to revisit the principle and re-define it.

The other alternative also may end, perhaps a little later, in a re-evaluated set of principles. These arise when in order to make your decision you feel inclined to contravene one or more principles. That’s ok; good decisions can go against the principles, but to do so you’ll need to state clearly why this course of action was the right step to take. Overriding a principle is a significant step because it means we are effectively diverging from the general direction of travel. Consequently, the decision, and resulting ADR must be clearly argued and strongly justified. It might also signal the time to revisit the principle in light of this development.

The radar in comparison is a lot more advisory in nature. It will give an idea of what, if anything, is the current de-facto standard in our problem space, what’s been done in the past, and what other teams might be experimenting with. Going a different way is a lot less likely to raise eyebrows, but it is again a definite reason to address the deviation in the ADR.

Given all this, we can start to come up with our key criteria to evaluate options against, as well as a list of alternatives. Perhaps we’ve realised we really need to do some homework and in which case we might spin off a timeboxed Spike to learn more about something. Our ADR thinking will help write super-clear acceptance criteria here. If we don’t need to do a Spike, we will think instead about seeking advice.

Having these inputs from the context (which will include, for example, a technical strategy), applicable principles, radar blips, and key criteria / alternatives will in turn help us think about who to speak to for advice. In my experience it is helpful to engage in this when you are relatively confident you understand the problem space / need, but before you become too attached to a specific solution. When you go and seek advice, spend most time and effort speaking to people who will disagree with you; those who you know think along different lines and where you know you will have blind spots. Not only this, challenge yourself. Consider “what’s bad about this alternative? What are its shortcomings?” Spend the most time thinking about the alternatives which challenge your decision most directly and fundamentally.

Before you have the discussion, it helps to have the ADR ready in a rough form, and share it with them in advance. This will give them thinking time. Then when you do meet, go through every element of the ADR template. Have you missed something from the context? From the principles / blips? From the evaluation criteria? Solicit and capture their advice on all these things. More importantly, ask them why they are making these suggestions. It is the answers to these questions that the keys to learning to make better architectural decisions lie. Your advisors will help you understand how they see problems, what they’ve encountered that was similar in the past, and even entire aspects which you don’t even think about. 7

What about the AAF? Isn’t that the place to gather advice? Yes, and everything I’ve shared above should guide you wherever you have the conversation, but for the first few decisions a team or individual takes it really helps to have these in a more targeted way with the key advisors. The ADR you present before the AAF will then be really solid and focused before it is shared widely, meaning that the resulting AAF conversations will be richer and more focused. Sometimes a quick conversation in the AAF will lead to a subsequent, more in depth, 1-1 conversation.

Remember, once you have advice, wherever it came from, you must roll it into your ADR. You need not take the advice given, but you have to record it. An excellent practice here is to prioritise things in your writing which people would find non-intuitive or surprising. If you disagree with key advice, state how and why. If you are doing something new, make it clear why the current way doesn’t work for you. Remember to use the principles. Sometimes they will support your decision. Make it clear how. Sometimes you will have to contravent them. Make it clear why. Your goal is to make the reader understand why you took the decision you took. If you meet this goal, then you will not just have a solid decision, you’ll most likely have learned a great deal in the process. 8

Before I close this section, remember, all decisions are point-in-time, and no-one can ever foresee every eventuality, but you want to be able to go back later and still feel good about a decision, given what you knew / understood at the time. In this, the context and criteria you capture are key. This re-visiting of decisions is another great learning tool. With the benefit of hindsight you can now ask questions such as: “did we understand the context well enough?” and “were we honest enough with ourselves about what we knew and what we didn’t?”

How to fail

So that’s the extent of our alternative, decentralised, anarchistic approach to architecture, and an idea of how it typically all fits together. But before we conclude, we ought to address one final aspect - the key ways in which you can fail. Let’s enumerate them.

The majority of failures you will see will actually be good ones - mini failures as decisions are taken by those who are less experienced. These are good because the process facilitates quick decisions, by those who need them, and more importantly, it facilitates transparency and rapid identification of failures (as those who took the decision will be aware of the issues as they code it) and a safe means to re-visit, and share the learnings. Embrace these, calling them out specifically and celebrating them in the AAF. This is a key aspect of building a learning culture.

To learn most effectively you need to feel safe, and when learning collectively everyone benefits from the broadest, most diverse range of inputs contributing to discussions. Remember, in this approach, we are explicitly not looking for consensus, but we are looking for a broad range of inputs and voices. It is here that the next failure mode lies, and it is far more insidious and damaging than the first. This second failure mode arises when you, in your job as a conversation-starter and space-holder, fail to include all who ought to be contributing and deciding and learning. For a great part early adoption stages of this style of architecture can feel like great successes. “It’s working! More and more people are taking decisions, writing them up in ADRs, giving advice and discussing them in the AAF! I’ve never seen such engagement with principles before!”. Only later, on reflection, will you realise the gains could have been far greater. It is precisely when this first flush of satisfaction strikes that you must be most on your guard. Are you really observing mass participation and learning, or is it a core group of usual suspects? You mitigate this problem actively. Watch out for who contributes. Amplify voices and ensure others listen to the quieter contributors. Make sure influence is balanced and not based on reputation, tenure or place in the hierarchy. Actively encourage many viewpoints and highlight the value it brings so that it becomes self-sustaining.

The third failure mode is an early warning that you are encountering the preceding failure mode, however, this one lives more in the grey area between desired and unwelcome. As you proceed along this journey you will uncover off-the-grid decisions. Decisions which never came up at the AAF, and which never made it into an ADR. There are two ways to approach them. The first, correct way, is to treat the discovery as what you hope it is - an honest mistake, and an opportunity to learn and teach others. Perhaps the decide-ees weren’t even aware of the fact it was a key decision they were taking. Perhaps they were under pressure from elsewhere. Perhaps they thought it wasn’t as significant as it turned out to be. Perhaps they felt they would be shouted down in the AAF. Whatever the reason, treat it as a way for both them, and you, to learn. To improve the process. The other, wrong way to treat these, is to fall back to old ways, and take back control. Which takes us nicely to the failure mode which completely destroys this approach and all that it promises.

It’s easy to slip into this fourth and most dangerous failure mode, and so it needs constant vigilance on your part. The only thing which needs to happen to trigger this is for “capital-A” architects such as yourself to fail to trust people; it is to not practice what you preach; it is to not clear enough space for the mini failures and consequent learning opportunities just mentioned; it is to continue to perform “shadow architecture” behind the scenes to make sure things still go how you think they ought to, despite all the signals from elsewhere. The sole benefit of this failure mode is that it becomes evident very rapidly as all the benefits I’ve listed above fail to materialize.

If you’re wondering if it’s this key failure mode which makes this approach to architecture hard to pull off you’d be right. I have been lucky in the past. Colleagues have called me out when I’ve made decisions for others, and I’ve caught myself getting frustrated that folks don’t know what I know. But then I realise I’m failing in my real task as a practitioner of architecture - I’m failing to get the right conversations happening, with the right people, at the right time. Remember that (perhaps even task others with calling you out when you fail to stick to the process) and you’ll be surprised how easy (and satisfying) it is to succeed.

The five elements again, and possible further steps

Given we now have both the good and the (potentially) bad, as well as a collection of failure modes to look out for, let’s conclude. We recall we have the five elements of our alternative approach to architecture:

One core element: Advice Process

Four supporting elements:

• Architecture Advisory Forum
• Lightweight ADRs
• Team-sourced Principles
• Your own Tech Radar

Hopefully I’ve made it clear that while none of the elements may be new to you (aside from perhaps the Advice Process) there is something very different. This difference lies in the interplay/mutual reinforcement between all of these against a backdrop of conversations, learning and safety. What is hopefully enticing is the fact that, in my experience at least, this is far more likely to provide successfully deployed architectures, now, and into the future. It is my go-to for scaling myself, and making sure that the teams I work with deliver on the promises we have made to our users, which is, after all, the goal.

Afterword: What next?

Of course, while I’ve tried to keep this article focused, it’s possible to go further. I’ve seen teams working in this way naturally starting to pave their own roads - self-serving their own delivery platform before a (Delivery) Platform Team comes into existence. (See my colleague Evan Bottcher’s excellent “What I talk about when I talk about Platforms” and Skelton and Pais’ Team Topologies for more detail on this.)

I’ve also seen teams put in place their own Architectural Fitness Functions (and not just around run cost) so that they know when the collective architecture strays outside its intended bounds.

The biggest lesson I’ve learned is that, once you empower people, giving them an environment in which to succeed, and recognise their successes, they will rapidly, and as a collective, start thinking about things which haven’t even crossed your mind. That’s the real benefit of this kind of approach: access to the collective intelligence of the many, over reliance on the much more restricted intelligence of the few.