Quick Navigation
- Start here — Why reviews exist
- Types of review
- Who sits in which forum
- Running effective reviews
- Decision authority
- Technical leadership groups
- Common failure modes
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Architecture reviews aren't meetings to approve diagrams. They're the structured spaces where decisions are evaluated against principles, trade-offs are surfaced, and alignment is verified. I've sat in review boards where everything got approved without challenge — and in others where every decision got blocked for weeks. Neither extreme is governance. Both are theatre.
Architecture review forums are where governance becomes real — where decisions are challenged, approved, and communicated. The format of a review must match the significance of the decision. Not every decision needs a board; every significant decision needs a review.
Approval isn't the goal. Good decisions are the goal. A review that rubber-stamps everything is theatre. A review that blocks everything is a bottleneck. The sweet spot is a review that challenges decisions constructively and fast.
Keep it in mind.
1. Why review forums exist — The problems they prevent
Without review forums, architecture decisions are made in isolation — by individuals, in meetings, or by default. Nobody challenges them. Nobody verifies alignment. Nobody communicates them.
Review forums prevent four specific problems:
Inconsistent decisions — teams choose differently for the same problem. Misalignment — decisions contradict strategy. Hidden decisions — nobody knows what was decided. Poor quality — no challenge, no improvement.
flowchart TD
NO_REVIEW["No Review Forums"] --> INCONSIST["Inconsistent decisions\nTeams choose differently"]
NO_REVIEW --> MISALIGN["Misalignment\nDecisions contradict strategy"]
NO_REVIEW --> HIDDEN["Hidden decisions\nNobody knows what was decided"]
NO_REVIEW --> POOR["Poor quality\nNo challenge, no improvement"]
INCONSIST --> COST["💸 Cost\nRework · Fragmentation\nSecurity gaps"]
MISALIGN --> COST
HIDDEN --> COST
POOR --> COST
REVIEW["✅ Review Forums"] --> PREVENT["Prevent all four\nproblems"]
What a good review provides: Challenge — someone asks "have you considered...?" before the decision is locked. Alignment — someone checks "does this support the strategy?" Communication — someone ensures "do affected teams know about this?" Learning — teams learn from each other's decisions and approaches.
Reviews prevent inconsistency, misalignment, hidden decisions, and poor quality — all four matter.
Try it yourself — The review gap
Which of these four problems exist in your organisation?
| Problem | Evidence |
|---|---|
| Inconsistent decisions | e.g. Three teams chose three different databases for the same use case |
| Misalignment | |
| Hidden decisions | |
| Poor quality |
If you can name evidence for two or more, you need review forums. Not more meetings — better ones.
2. Types of review — Match the format to the significance
Using the same review format for every decision creates a bottleneck. A database technology choice needs deep review. An API endpoint design within established patterns doesn't.
Match the review format to the decision significance:
flowchart TD
DEC["Decision"] --> SIGN{"Significance?"}
SIGN -->|"Routine"| NO_REVIEW["No review\nFollow the convention"]
SIGN -->|"Small"| ASYNC["Async Review\nComment on ADR PR\n1-3 days"]
SIGN -->|"Medium"| DESIGN["Design Review\n2-3 reviewers\nFocused session"]
SIGN -->|"Large"| BOARD["Architecture Board\nFull review\nScheduled meeting"]
Here's how the types compare:
| Type | When to use | Participants | Duration | Output |
|---|---|---|---|---|
| No review | Routine, within standards | None | N/A | Proceed |
| Async review | Small decisions, one domain | 2-3 reviewers | 1-3 days | Commented ADR |
| Design review | Medium decisions, one domain | Domain architect + peers | 1 hour | Reviewed ADR |
| Architecture Board | Cross-domain, strategic, high-risk | Board members | 1-2 hours | Approved/rejected ADR |
The async review process is simple: author drafts ADR, opens a PR to the architecture repo with reviewers tagged, reviewers comment asynchronously in 1-3 days, author resolves comments, merge — decision is accepted.
Match the review format to the significance — not every decision needs a board.
Try it yourself — The classification test
Take three recent decisions from your team. Classify each one:
| Decision | Scope | Reversibility | Risk | Review type needed |
|---|---|---|---|---|
| e.g. Chose PostgreSQL | Multi-team | Hard to reverse | Medium | Architecture Board |
If everything is going to the board, you have a bottleneck. If nothing is, you have a rubber stamp.
3. Who sits in which forum — Decision rights and representation
The wrong people in a review forum create the wrong outcomes. Too many people and the review becomes a lecture. Too few and critical perspectives are missed. The wrong people and decisions get politicised.
Forum composition must be deliberate — who has decision rights, who provides input, and who is informed.
flowchart TD
FORUM["🏛️ Architecture Board"] --> DECIDERS["🎯 Deciders\n2-3 people with authority\nto approve or reject"]
FORUM --> CONTRIBUTORS["💡 Contributors\nPeople with expertise\nwho provide input"]
FORUM --> OBSERVERS["👁️ Observers\nPeople who need to know\nbut don't decide"]
DECIDERS --> RULE["Rule: Deciders must have\nauthority to bind the organisation"]
CONTRIBUTORS --> RULE2["Rule: Contributors add\nevidence, not votes"]
OBSERVERS --> RULE3["Rule: Observers stay silent\nunless asked"]
The RACI for architecture decisions: Accountable — final decision authority. Lead architect, Architecture Board chair. Responsible — prepares the decision, drafts the ADR. Decision-maker or architect. Consulted — provides input before the decision. Domain architects, security, platform team. Informed — notified after the decision. Affected teams, stakeholders.
Board size rules: minimum 3 deciders — below this, it's a conversation, not a forum. Maximum 8 deciders — above this, it becomes a lecture, not a review. Optimal: 5-6 — enough perspectives, fast enough to decide.
Deciders decide, contributors advise, observers observe — every person in a review must have a clear role.
Try it yourself — The board audit
Who sits on your architecture review body today?
| Person | Role | Decider, contributor, or observer? | Should they be there? |
|---|---|---|---|
If you have more than 8 deciders, your board is too big. If you can't classify people, your roles are unclear.
4. How to run an effective architecture review — Preparation, process, and outcomes
Most architecture reviews are poorly run — no preparation, no agenda, no outcome. They become conversations that wander, debates that escalate, or presentations that nobody challenges.
An effective review has three phases — preparation, execution, and follow-up. Each phase has specific requirements.
flowchart LR
PREP["📋 Preparation\nADR written\nOptions evaluated\nReviewers briefed"] --> EXEC["🎯 Execution\nPresent · Challenge\nDiscuss · Decide"]
EXEC --> FOLLOW["📝 Follow-up\nDecision communicated\nADR updated\nAction items tracked"]
Before the review: ADR is complete — context, options, recommendation, consequences. Reviewers have read the ADR — at least 24 hours before. Presenter knows the decision is not pre-made — the review can change it.
During the review: Presenter explains the context and recommendation (5-10 min). Reviewers challenge — options, trade-offs, risks (15-30 min). Decision is made — accept, reject, or revise (5 min). Decision is recorded — who decided, what, and why.
After the review: ADR is updated with the final decision. Decision is communicated to affected teams. Action items are tracked and followed up.
Questions reviewers should ask: "Is the problem statement accurate?" "Were all realistic options considered?" "What does this decision sacrifice?" "Does this support the target state?" "What could go wrong? What's the blast radius?" "Can we undo this?" "Who else is affected?"
Effective reviews = prepared presenters + briefed reviewers + clear outcomes.
Try it yourself — The review checklist
When was the last architecture review you attended? Run it through the checklist:
| Checklist item | Was it done? |
|---|---|
| ADR was complete before the meeting | |
| Reviewers had read it 24 hours before | |
| Presenter knew the decision could change | |
| Reviewers challenged options and trade-offs | |
| Decision was recorded and communicated |
If fewer than three were done, the review wasn't effective. Fix the preparation first.
5. Decision authority — RACI for architecture, and what happens when it's unclear
When decision authority is unclear, one of three things happens: decisions are delayed (nobody wants to decide), decisions are contested (everybody thinks they should decide), or decisions are made by default (whoever acts first decides).
Decision authority must be explicit — who decides what, at what level, with what escalation path.
flowchart TD
UNCLEAR["Unclear Authority"] --> DELAY["⏱️ Delays\nNobody decides\nWaiting for someone"]
UNCLEAR --> CONFLICT["⚔️ Conflicts\nMultiple people claim authority"]
UNCLEAR --> DEFAULT["🤷 Defaults\nWhoever acts first decides"]
DELAY --> COST["💸 Cost\nSlow delivery\nMissed opportunities"]
CONFLICT --> COST
DEFAULT --> COST
CLEAR["✅ Clear Authority"] --> FAST["Fast decisions\nRight person decides"]
CLEAR --> CONSIST["Consistent decisions\nSame authority every time"]
CLEAR --> ACCOUNT["Accountability\nClear who is responsible"]
The decision rights matrix:
| Decision type | Decides | Consulted | Informed |
|---|---|---|---|
| Strategic technology choice | Architecture Board | Domain architects, security | All teams |
| Cross-domain integration pattern | Lead architect | Domain architects of both sides | Affected teams |
| Domain-specific pattern | Domain architect | Team lead | Other domain architects |
| Implementation approach | Team lead | Domain architect | — |
When authority is contested: check the decision rights matrix. If authority is clear, enforce it. If not, escalate to the next level and update the matrix for future clarity.
Explicit authority = fast, consistent, accountable decisions — ambiguity is the enemy of speed.
Try it yourself — The authority test
Pick a recent architecture decision. Who had the authority to make it?
| Question | Your answer |
|---|---|
| Who was accountable? | |
| Who was consulted? | |
| Who was informed? | |
| Was this clear before the decision? |
If the answer to the last question is "no," your decision rights matrix doesn't exist or isn't published.
6. Technical leadership groups — The informal governance that matters most
Formal review forums are important but insufficient. The most influential architecture decisions are often made in informal conversations — between senior engineers, tech leads, and architects who trust each other.
Technical leadership groups are the informal network where decisions are shaped before they reach a formal forum. Recognising and supporting these groups — rather than trying to replace them — amplifies governance effectiveness.
flowchart TD
FORMAL["🏛️ Formal Forum\nArchitecture Board\nScheduled, documented"] --> FORMAL_DEC["Formal Decisions\nApproved, recorded"]
INFORMAL["💬 Informal Network\nTech leads, senior engineers\nAd-hoc conversations"] --> INFORMAL_DEC["Shaped Decisions\nPre-aligned before formal review"]
INFORMAL_DEC -->|"Feeds into"| FORMAL
FORMAL_DEC -->|"Communicated to"| INFORMAL
BOTH["✅ Both Together"] --> EFFECTIVE["Effective Governance\nFormal authority + informal influence"]
How to support informal governance: Architecture guilds — regular meetups where architects share decisions and approaches. Tech lead forums — monthly sessions where tech leads discuss cross-cutting concerns. Architecture office hours — open time when architects are available for informal consultation. Slack channels — dedicated channels for architecture discussions and questions.
Formal forums have authority — informal groups have influence — you need both.
Try it yourself — The informal network map
Who are the people in your organisation whose opinion shapes architecture decisions — even if they're not on the formal board?
| Person | Role | How much influence do they have? |
|---|---|---|
If you can name three or more, you have an informal network. Are you supporting it or ignoring it?
7. Common failure modes — When review forums become bottlenecks or rubber stamps
Review forums fail in predictable ways. Knowing the failure modes helps prevent them.
The two most common failures are opposite extremes:
flowchart LR
BOTTLENECK["🔴 Bottleneck\nEverything goes through the board\nWeeks of waiting\nTeams route around it"] --> RESULT_1["Governance ignored\nStandards bypassed"]
RUBBER["🟡 Rubber Stamp\nEverything is approved\nNo real challenge\nNo improvement"] --> RESULT_2["Governance theatre\nExists but does not influence"]
BOTTLENECK --> FIX_1["Fix: Delegate, automate\nclassify decisions"]
RUBBER --> FIX_2["Fix: Raise the bar\nchallenge constructively"]
All seven failure modes:
| Failure mode | Symptom | Fix |
|---|---|---|
| Bottleneck | Teams wait weeks for approval | Delegate routine decisions; automate compliance |
| Rubber stamp | Everything approved without challenge | Raise the bar; require options analysis |
| Ivory tower | Board disconnected from delivery reality | Embed board members in delivery teams |
| Popularity contest | Loudest voice wins, not best evidence | Require evidence-based presentation |
| Re-decision | Same decisions debated repeatedly | ADRs provide history; enforce documented decisions |
| No follow-up | Decisions made but not implemented | Track action items; verify compliance |
| Wrong audience | Too many or too few people | Classify decisions; match audience to significance |
The review forum health check: average turnaround under 5 days? Last rejection or revision within the last month? Decisions communicated to all affected? If any answer is "no," your forum needs fixing.
The two deadly sins: bottleneck (too much governance) and rubber stamp (too little) — avoid both.
Try it yourself — The health check
Run your review forum through the health check:
| Question | Your answer |
|---|---|
| Average turnaround under 5 days? | |
| Last rejection/revision within the last month? | |
| Decisions communicated to all affected? |
Any "no" means your forum has a problem. Start with the worst one.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
DEC["🎯 Architecture Decision"] --> CLASSIFY{"Significance?"}
CLASSIFY -->|"Routine"| NO["No review\nFollow convention"]
CLASSIFY -->|"Small"| ASYNC["Async review\nADR PR"]
CLASSIFY -->|"Medium"| DESIGN["Design review\nFocused session"]
CLASSIFY -->|"Large"| BOARD["Architecture Board\nFull review"]
NO --> OUTCOME["✅ Decision Made"]
ASYNC --> OUTCOME
DESIGN --> OUTCOME
BOARD --> OUTCOME
OUTCOME --> COMM["📢 Communicated"]
OUTCOME --> TRACK["📊 Tracked"]
COMM --> VALUE["Shared understanding\nTeams informed"]
TRACK --> VALUE
The foundation:
Match the review format to the decision significance — not every decision needs a board; every significant decision needs a review. Reviews have four purposes: quality, alignment, communication, learning — if your review only does approval, it's missing three-quarters of its value. Bottleneck and rubber stamp are the two deadly sins — too much governance creates resentment, too little creates chaos. Measure and adjust. Approval isn't the goal. Good decisions are the goal. The best reviews make decisions better, not just approved.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Review purposes | Quality, alignment, communication, learning | Challenge constructively, don't just approve |
| Review types | No review, async, design review, board | Match format to significance |
| Decision rights | Who decides what | Publish the matrix, train everyone |
| Board composition | Deciders + contributors + observers | 5-8 deciders, clear roles |
| Effective review | Prepared presenters + briefed reviewers + clear outcomes | Checklist: before, during, after |
| Informal governance | Guilds, forums, office hours | Support the informal network, don't replace it |
| Failure modes | Bottleneck and rubber stamp | Monitor and adjust |
| Decision authority | Explicit, documented, communicated | Ambiguity is the enemy of speed |
How to know if this landed
You'll know this has landed when someone stops treating reviews as approval gates and starts treating them as decision improvement sessions. Decision classification exists — not every decision goes through the same process. Average review turnaround is under 5 business days. The board has rejected or revised at least one decision in the last month — not rubber-stamping. Decision rights matrix is published and understood by all architects. Review outcomes are communicated to all affected teams. Informal governance mechanisms exist — guilds, office hours, or forums. And teams report reviews as helpful, not obstructive.
What changes when the mental model clicks
I've run this session with teams where all architecture decisions went through a weekly board meeting — fifteen items per session, twelve-day turnaround, ninety-five percent approval without challenge. The gap at the start is usually not about understanding reviews — it's about matching the review format to the decision significance.
What changes after this session:
Teams stop treating every decision as a board item and start classifying by significance. The decision classification exercise — "score your real decisions by scope, reversibility, risk" — is always the moment things click. People stop treating reviews as approval gates and start treating them as decision improvement sessions. Their results get better. They stop complaining about bottlenecks when the real problem was that routine decisions were going through the board.
The review facilitation practice tends to immediately change how teams run their reviews. They start requiring options analysis before the meeting. Their challenge quality goes up. They stop approving everything when the real problem was that nobody was asked to challenge.
Book a Workshop
Ready to design review forums that produce good decisions efficiently?
or
Half-day workshop includes review forum assessment — where are your current reviews on the spectrum, decision classification exercise — score your real decisions by significance, board design workshop — composition, charter, and process for your context, review facilitation practice — running a mock review with challenge framework, decision rights matrix creation for your organisation, and architecture board design guide + review charter template + decision rights matrix.