---
title: "Facilitating Software Architecture and who gets to decide"
description: "Andrew Harmel-Law's advice process lets anyone make an architecture decision, as long as they ask the people affected first and write it down."
url: "https://michael.zazon.us/notes/facilitating-software-architecture-and-who-gets-to-decide"
published: "2025-11-25T12:00:00-05:00"
kind: "book-notes"
subject: "architecture"
tags: ["decisions"]
---
In large organizations, architecture decisions often queue up behind a small number of senior people or a standing review board. If you work in a regulated shop, eventually someone will ask you who made a decision, on what basis, and who they consulted. [Facilitating Software Architecture](https://www.oreilly.com/library/view/facilitating-software-architecture/9781098151850/) by Andrew Harmel-Law (O'Reilly, December 2024) tackles this question directly, framing it as a design problem: how do we design the way the organization makes decisions?

The usual answers are both costly: the approving review board becomes a gate, a bottleneck where delivery teams either wait or quietly find ways around it; consensus spreads the decision across everyone in the room, so nobody owns the outcome when it needs to be revisited.

The alternative that Harmel-Law proposes is the advice process, which they first described in [an article on martinfowler.com](https://martinfowler.com/articles/scaling-architecture-conversationally.html) a few years before the book was published. The rule is simple: "anyone can make an architectural decision." But before you make the decision, you need to seek advice from everyone who will be meaningfully affected by the decision, as well as people with relevant expertise. You don't need to follow the advice you receive, but you do need to request it and record it. The emphasis here is on gathering many inputs and voices before a single person makes a decision, but not on reaching consensus.

Where I land is the advice process, every decision carried by an adr/architecture decision record. Harmel-Law's version of the record includes context and options weighed, plus a section for advice received. That changes the purpose of the record. A written decision with advice recorded is better evidence of governance than an approval stamp in the minutes of a board meeting. It answers the questions an auditor might have right there on the page, with the name of the decider on it and the advice they gathered next to their own reasoning. A decision not documented is as good as not made when audit time comes.

My doubt is about scope. There are decisions that shouldn't be taken alone, like adopting a new technology or adding a third-party integration. I'd keep a short written list of the types of decisions that have to go through an open advisory forum. Per Harmel-Law, that's a weekly hour where anyone can show up. Everything else I'd leave to the team that has to live with the result. Even for the listed decisions, the forum advises, the decider still decides.

The forum's job changes from gate to conversation. I suspect the change is bigger for architects than for teams. Architects go from people who say yes to people whose advice is worth seeking. That's a different skill and a different place in the org. An agent can draft the context and options for a decision record well enough. The process only holds if the named person asked the people affected before making the call themself.