decision-makingestablished · medium operational burden

Architecture Review Process

Also known as: arch-review, design-review, architecture-review-board, rfc-process

Intent

Structured architecture review: lightweight, scalable, decision-focused — preventing rubber-stamp approvals and ensuring trade-offs are explicit.

Problem

Architecture reviews are either bottlenecks (heavy process) or rubber stamps (no teeth). Need lightweight, decision-focused process that scales.

Forces

•Speed vs Rigor: lightweight for most, rigorous for high-risk
•Authority vs Autonomy: central board vs team ownership
•Documentation: capture decisions, not just approvals
•Scalability: process must work at 10 teams and 100 teams

Solution

✓ When to Use

•Team > 5 engineers
•Cross-team dependencies increasing
•Architecture decisions causing incidents
•New hires confused by architecture

✗ When Not to Use

•Small team (<5), low complexity
•Pre-product (velocity > process)

Pros

+Prevents architectural mistakes early
+Shares knowledge across teams
+Creates decision audit trail
+Balances speed vs rigor

Cons

−Process overhead (meetings, docs, reviews)
−Can become bottleneck if not scaled
−Requires culture: psychological safety, disagreement
−Board members need bandwidth (10-20% time)

Cost Profile

Infrastructure

Low — templates, calendar, tools

Operational

Medium — meetings, reviews, follow-up

Cognitive

Medium — design thinking, trade-off analysis

Failure Modes

Process theater: checklist done, no real review
Bottleneck: Tier 3 queue blocks teams
Rubber stamp: no real scrutiny
Bike-shedding: focus on trivial, miss critical
Authority without accountability: board decides, team owns risk

Real-World Examples

Alternatives

ad-hoc
pr-only
architecture-committee
no-review

Related Patterns

architecture-decision-records
design-doc
rfc
peer-review
design-doc
technical-debt
deployment-strategies

Competency Domains

decision makingeconomics evolutiondistribution communicationreliability opsdeploymentsecurity compliance