Most architecture review processes I have seen fail in one of two ways. Either they are so heavy that engineers route around them, or they are so light that they are just a rubber stamp. The first produces unreviewed systems. The second produces reviewed systems that are exactly as bad as the unreviewed ones.
The version my teams use now takes about five minutes to write and is read before any code that would be expensive to undo.
The format
It is three questions, answered in a paragraph each, in a document anyone on the team can comment on.
- What are we building, and what are we explicitly not building? The second half does more work than the first.
- What is the decision that would be expensive to reverse? Every design has one or two. Name them. Everything else can be changed later and does not need this document.
- What did we consider and reject, and why? This is the part future-you will want, when someone asks why the system is shaped this way.
That is the whole thing. No template with twelve headings, no required diagrams, no approval gate.
Why it works
It works because it is scoped to the only part of architecture review that has leverage: the expensive, hard-to-reverse decisions. A review that tries to cover everything covers the cheap, reversible stuff too, which is wasted attention, because that stuff is cheap and reversible.
It also works because writing it is fast enough that nobody routes around it. The moment a process costs more than the mistake it prevents, engineers will, correctly, skip it. Five minutes is under that line.
The failure mode to watch for is the document that answers question two with “everything is reversible.” Sometimes that is true. Usually it means the author has not found the expensive decision yet, and that is exactly the conversation the review exists to start.