Organisations institute architecture review to stop expensive mistakes and frequently get a ceremony instead. An engineer presents a diagram, senior people ask a few questions, approval is granted, and nobody's decision changed. The cost is real — the delay, the preparation, the meeting — and the benefit is close to zero, because a design cannot be meaningfully assessed by people encountering it for the first time in a room.
The fix is to make the artefact do the work. A written proposal circulated in advance, read before the meeting, containing the things that actually determine whether a design is sound: what problem this solves, what alternatives were considered and why they were rejected, what this makes difficult later, what the failure modes are, and what would have to be true for this to be the wrong choice. A diagram shows structure; only prose can carry reasoning, and reasoning is what is being reviewed.
The question that most improves these reviews is what did you reject and why. A proposal with one option is an announcement. A proposal with three, and an argument for one, gives reviewers something to engage with and reveals whether the author explored the space or settled early. It also produces the record you will want in eighteen months when somebody asks why the system works this way — which is the second and longer-lasting purpose of the exercise.
Scope the process to decisions that deserve it, or it will be resented and circumvented. Reviews should apply to choices that are expensive to reverse: a datastore, a service boundary, an external dependency, a data model, anything touching money or personal data, anything that commits you to a vendor. A framework requiring review for routine work teaches engineers to frame everything as routine, and the genuinely consequential decision then arrives unreviewed.
Be deliberate about who reviews. The useful reviewer is someone who will have to operate or extend the thing, or who has been burned by a similar decision, not simply the most senior person available. Seniority-based review produces deference, and deference produces approval. Two or three engaged readers with relevant context beat a committee, and a written asynchronous review often beats a meeting entirely — it gives people time to think and produces comments you can point to later.
Finally, record the outcome as a decision rather than an approval. What was decided, what was rejected, what conditions or follow-ups were attached, and who agreed. That record is the single most valuable artefact the process produces: it is what a new engineer reads to understand the system's reasoning, and it is what stops the same argument being had again in two years by people who have forgotten it was settled.
