Making architecture review boards effective
A review board earns its place by settling decisions once, so teams do not have to reopen them. Its output should be fewer open questions, not more meetings.
The requirement this answers
“Establish architecture governance, standards, guardrails and design assurance”
Govern the small number of decisions that are expensive to reverse and delegate the rest in writing.
What belongs in front of a board
Choices that are expensive to reverse: platform selection, integration patterns, data ownership boundaries, security and access models, and anything that creates a new system of record. Everything else should be pre-decided by a published standard or explicitly delegated.
At Parexel I established a board governing data platform investment across eight or more business domains. Its value came from teams being able to look up the answer for most situations and bring only the new cases forward.
Reference architectures over review cycles
A paved-road template that already satisfies the standard does more than a reviewer catching violations. When a review finds a recurring problem, the right response is usually to change the template rather than add a checklist item.
I treat TOGAF as a scaffold and customize it each time. The deliverable set that helps a CRO differs from the one that helps a bank.
How I run reviews
Written proposal first, decisions recorded with their rationale, and a standing rule that a rejected design leaves the room with a named alternative. A reviewer who cannot propose an alternative is offering an opinion rather than a decision.
Architects present their own designs. The person who made the trade-off should be the person who explains it.
How I apply it
- Publish a decision-rights matrix separating board decisions from delegated ones
- Maintain reference architectures and golden-path templates as the primary control
- Record decisions with rationale so the same debate does not recur annually
- Measure the board on cycle time as well as on rework prevented
What good looks like
- Most submissions are approved quickly because the standard was clear beforehand
- Teams reference the architecture without being asked to
- Time to decision is measured in days
- Rework attributable to architectural surprise is falling