Software architecture decisions: who should be involved?

At the end of 2024, Andrew Harmel-Law's Facilitating Software Architecture was published by O'Reilly. In it, he argues for and outlines how software architecture decision-making can be decentralized to empower software developers and others — rather than just software architects — to contribute to architectural decisions. To find out more we asked Andrew some questions to get a glimpse into how he thinks about today's software architecture challenges.

Richard Gall: Why have architecture and developer roles been typically kept separate? Can you explain how we got to where we are?

Andrew Harmel-Law: It seems to have just been how it evolved. A very long time ago (i.e. back when I first started writing code) there were memories of architecture being something people did as opposed to a job title that people held. Perhaps the separation of roles into different people came about because the speed of development increased so rapidly, and the number of people working on systems increased so rapidly too. Perhaps, also, things started to go wrong and there was a need for someone to be explicitly responsible and accountable for architectural decisions.

However it came about, it rapidly became embedded in the culture enough for the memes of the “ivory tower” and “hands-on" architect to be things everyone in software recognises.

RG: Hasn’t there always been collaboration between these disciplines? What are you advocating that’s different from before?

AHL: There ought to be, and in the best teams the practice of architecture remained more of a role that various people played as and when it was required. Typically, when that happens you see there is no one with the job title of “architect” anywhere near the software (though other types of architect might still be about — it's a very overloaded term in our industry, despite it not being entirely appropriate).

RG: Why now? What’s changed in the way we build software?

AHL: In the book I point to what I call five “revolutions” in the way we are able to get from an idea in someone's head to that idea being in compiled code that's actually being used. 

The first of these was the agile manifesto. That removed unnecessary planning.

The second revolution was cloud computing, which made runtimes available virtually at the click of a button.

The third revolution was the DevOps revolution, and, in particular, continuous deployment, which drastically shrunk our increments of software delivery. This ultimately meant we were able to deploy far more than we could previously.

The fourth revolution was product-thinking, which emphasized the importance of focusing on value. It also taught that the only we could actually know what was valuable was to experiment and learn from feedback.

Finally, the fifth revolution was stream aligned teams. This encouraged us to set up our organizations so delivery teams had to collaborate as little as possible to ship their code.

Taken together, all of these increase the importance of architecture, but challenge the traditional centralized ways in which it is usually practiced.

RG: When you talk about empowering developers what does that actually mean in practice? What will they be doing?

AHL: The central idea in the book is that anyone can make any decision, as long as they seek advice, but not permission, from all those affected and those with expertise. 

That’s incredibly empowering. But it’s also a significant uptick in responsibility; and when combined with architectural decision records (ADRs) there's accountability too.

For those who do then want to decide, however, it's a very powerful tool. There will still be those looking at the cross-team, whole-system architecture, but now teams can also decide for themselves as well. It results in a much more dynamic, involved and engaged approach to architecture that everyone has a stake in.

RG: Is this something developers find challenging in your experience? What does this all mean for software architects? How does their role evolve in this new world?

AHL: Some developers do find this challenging. However, just because the architecture advice process allows anyone to decide, no-one is obliged to.

In fact, the book has two target audiences: first, senior developers and dev leads who want to step into the world of architecture decisions, and, second, architects who want a new way to practice and collaborate with others. 

This is because there's a lot for developers to learn as they add deciding to their practice, but there's equally a lot for architects to learn; they can become much more like coaches, guides, communicators, space-creators-and-holders and — most importantly — conversation-starters.

RG: Who’s responsible for driving this change?

I lay out a number of approaches in the book. Typically it's architects, because they're the ones who begin with the authority to decide and can therefore choose to distribute this.

However, I also describe various strategies for teams to try the approaches too, within their current hierarchical processes, and see if they can influence those with the power to let them experiment.

RG: What are the risks of this approach? And how can they be overcome?

AHL: The biggest risk is that trust doesn’t get a chance to establish itself and grow. The architecture advice process sets up a social contract: “I trust you to decide well and engage the right people and you trust me to do the same”. ADRs are a great support in this, and I list many other supplementary elements that can be added to further bolster this: from a regular architecture advice forum to a collectively-sourced set of architectural principles and a technology radar to sense and collate guidance on the best way to deploy technologies and approaches in your specific organization.

I’m not naive though; I’m aware that the transition to a new way of distributing the power to decide isn’t always easy. For that reason there are chapters that talk about building safety and inclusion, leadership and how everyone can lead if and when they feel the need, and how to create experimentation advice process bubbles within your organization to protect you from the outside world while you are learning and things are a little fragile.

This is all because the exact culture of decentralized deciding that will result inside your organization will be very unique to you, your organization, your colleagues, your tech landscape, your customers and much more.  And that's what's exciting and most powerful about this approach to architecture practice; if you let it, it moulds to your organization in a way that's unique to you, meeting your needs. 

Thanks Andrew for taking the time to speak. 

Learn more by listening to Andrew discusss decentralizing software architecture decisions on the Technology Podcast.