Ideas
Why architecture reviews often fail
Reviews happen at the wrong time, with the wrong question. What has made them useful in my experience
Most architecture reviews I have sat through failed for the same reason: they happened at the wrong moment, with the wrong question.
The wrong moment is the end. By the time a design reaches a review board, a team has spent weeks on it and has a delivery date. The reviewers can nod or delay; they cannot really change anything without becoming the reason the project is late. So they nod, with remarks that nobody will implement.
The wrong question is “is this architecture good?”. Nobody can answer that in a meeting. The questions that can be answered are narrower and more useful: what is the decision we are actually taking here? What does it make cheaper, and what does it make more expensive? What would have to be true for this to be the wrong choice, and how would we know?
Three things have made reviews useful in my experience.
Review decisions, not documents. One page per decision, with the options considered and the reason for the choice, is worth more than a fifty-page target architecture.
Review early and often, in small doses. Half an hour with the architects when the boundaries are being drawn changes more than a two-hour board when the code exists.
Write down what would make us revisit. A decision with a stated expiry condition (“if the volume goes past this”, “if a second team needs it”) is a living decision.
One without is a dogma waiting to be broken quietly
None of this needs a committee.
It needs the habit of stating decisions as decisions, and of letting the people who will live with them ask their questions while the answer can still change