Software architecture decisions: who should be involved?

Introduction: why this book changes the game

In late 2024, Andrew Harmel-Law's book, "Facilitating Software Architecture", was published by O'Reilly. In it, he argues a simple but disruptive thesis for many organizations: architectural decision-making can, and should, be decentralized, to empower developers and other practitioners, not just dedicated software architects.

Two years after its release, the book has moved well beyond enterprise architects to shape internal platform practices, technical guilds, and architecture reviews in organizations adopting the stream-aligned team model. To understand why this approach resonates so strongly today, we asked Andrew Harmel-Law several questions about the current challenges of software architecture, how his model plays out in practice, and the risks it carries.

From the ivory-tower architect to architecture as a shared practice

Olivier V.: Why have the architect and developer roles generally been kept separate? How did we get here?

Andrew Harmel-Law: It seems to have simply been the product of evolution. Very early on, around when I started writing code, architecture was seen as an activity rather than a job title. The split of roles between different people likely came from the very rapid increase in development speed and the growing number of people working on systems. Problems probably also started to appear, creating the need for someone explicitly responsible and accountable for architectural decisions.

This division of roles quickly became entrenched in the industry's culture, to the point that the archetypes of the "ivory tower" architect and the "hands-on-keyboard" architect became figures everyone in software instantly recognizes.

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

AHL: There always should be, and in the best teams, architecture remained more of a role that different people took on as needed. When that's the case, you'll usually notice there's no one officially carrying the "architect" title anywhere near the code, even though other types of architects may still be present elsewhere in the organization, it's a very overloaded term in our industry, despite its relative mismatch with the reality of day-to-day work.

Five revolutions that made centralized architecture obsolete

OV: Why now? What's changed in how we build software?

AHL: In the book, I point to five "revolutions" that have transformed our ability to turn an idea in someone's head into compiled code that's actually used in production.

Agile, cloud, and DevOps: the delivery pace explodes

The first revolution was the Agile manifesto, which eliminated a great deal of unnecessary planning. The second was cloud computing, which made execution environments available virtually at the click of a button, provisioning a full infrastructure now takes minutes, not weeks, thanks to infrastructure as code. The third revolution was DevOps, and continuous deployment in particular, which drastically shortened software delivery cycles: organizations that once deployed to production every quarter now deploy multiple times a day. This ultimately let us deliver far more than ever before, and do it far faster.

Product thinking and stream-aligned teams: the end of central coordination

The fourth revolution was product thinking, which emphasized value over conformance to an initial plan, and which taught that the only way to truly know what's valuable is to experiment and learn from real usage feedback. Finally, the fifth revolution was that of stream-aligned teams, popularized in particular by work on the topic: it encouraged organizations to structure their teams so they need to collaborate as little as possible with one another to ship their code, reducing cross-team coordination to what's strictly necessary.

Related readAgile at scale: beyond the Spotify modelThe "Spotify model" (Squads, Tribes, Chapters, Guilds) dominated large-scale agile discussions for years. But here's a secret: even Spotify no longer follows the Spotify model.Read the article

Together, these five revolutions increase the importance of architecture, there are more decisions to make, more often, in more places, while making the traditional centralized approaches it was long practiced with untenable. An architecture committee that meets every two weeks simply can't absorb the volume of decisions produced by an organization that deploys continuously.

The architecture advice process: deciding without asking permission

OV: When you talk about empowering developers, what does that mean in practice? What will they actually do?

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

Seeking advice, not permission

That's extremely empowering. But it's also a significant increase in individual responsibility; combined with architectural decision records, it also creates a form of accountability. For people who genuinely want to decide, it's a very powerful tool. There will always be profiles focused on cross-team, system-wide architecture, but now teams can also decide for themselves within their own scope. The result is a much more dynamic, involved, and engaged approach to architectural practice, in which everyone has a direct stake in the outcome.

The role of ADRs in the age of internal platforms

In 2026, this principle rests on tooling that's become common: architectural decision records in a lightweight format, versioned directly in the code repository next to the code they concern, published automatically to the organization's internal developer portal, and increasingly summarized or indexed by AI assistants able to retrieve "why this decision was made" without reading through the entire history. This tooling doesn't replace the human conversation of the architecture advice process, but it makes the decision trail searchable, discoverable, and durable, a necessary condition for a decentralized model to stay governable across dozens of teams.

The architect's new role: coach rather than gatekeeper

OV: Is this something developers find difficult in your experience? What does it mean for software architects? How does their role evolve in this new world?

AHL: Some developers do find it difficult. But the fact that the architecture advice process lets anyone decide doesn't mean everyone is required to.

The book actually speaks to two audiences: first, experienced developers and team leads who want to step into the world of architectural decision-making; second, architects who want a new way to practice their craft and collaborate with others. There's a lot for developers to learn as they add decision-making to their daily practice, but there's just as much for architects to learn, who can become much more like coaches, guides, communicators, creators of discussion space, and, most importantly, conversation starters rather than gatekeepers of the final call.

This shift in role echoes a broader movement seen in organizations that invest in decoupled architectures and clear service boundaries: the less an architect needs to arbitrate every implementation detail, the more they can focus on the boundaries, contracts, and shared principles that let every team decide autonomously within its own scope.

Related readHexagonal architecture: principles, ports and adapters, benefitsPorts, adapters and domain isolation: the principles of hexagonal architecture, its synergy with DDD and its concrete benefits in testability over time.Read the article

Building trust: forums, shared principles, and a technology radar

OV: Who's responsible for driving this change? And what are the risks?

AHL: I describe several possible approaches in the book. Most often, it's the architects themselves who drive it, since they're the ones who initially hold the authority to decide, and can therefore choose to redistribute it. But I also describe various strategies teams can try within their existing hierarchical processes, to try to influence those who hold the power to let them experiment.

The biggest risk, however, is that trust doesn't get the chance to establish and grow. The architecture advice process rests on an implicit social contract: "I trust you to decide wisely and to consult the right people, and you trust me to do the same".

The architecture advice forum

Architectural decision records are a great support for this contract, but they aren't enough on their own. A regular architecture advice forum, a recurring, open session where decisions in progress can be presented and challenged before being finalized, gives an explicit space to exercise this right of consultation without slowing down the daily delivery pace.

Technology radar and shared principles

A set of collectively nurtured architectural principles, paired with a technology radar that collates lessons learned on the best way to deploy a technology or approach in the organization's specific context, rounds out this setup. Together, these tools lower the cognitive cost of "deciding well" for someone without fifteen years of architecture experience, and they make visible the areas of tight coupling where a local decision is more likely to have an impact elsewhere in the system.

Related readDecoupled by design: building reusable enterprise libraries and servicesWhy aiming for reusability first backfires, and how decoupling at domain boundaries, the open-closed principle and outcome-driven governance produce libraries teams actually adopt.Read the article

Andrew Harmel-Law stays clear-eyed about the limits of the exercise: transitioning to a new way of distributing decision-making power is never entirely painless. That's why the book devotes several chapters to building psychological safety and inclusion, to shared leadership, and to how to create "bubbles" for experimental advice processes within the organization, to protect the team while practices are still fragile and being learned.

A decision-making culture unique to every organization

The exact culture of decentralized decision-making that emerges within an organization will always be unique: it depends on its colleagues, its technology landscape, its customers, and many other factors specific to its context. That's precisely what makes this approach to architectural practice both demanding and powerful: if you let it, it adapts to the organization in a way that specifically meets its needs, rather than imposing a generic model from elsewhere.

Thank you, Andrew Harmel-Law, for taking the time to speak with us on these questions.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect Adservio's positions.