Architecture Review Boards and Technical Governance
Architecture Review Boards (ARBs) provide oversight and governance for significant architectural decisions — ensuring that changes affecting multiple teams, the overall system architecture, or long-term technical direction are reviewed before implementation. When done well, ARBs prevent costly architectural mistakes; when done poorly, they become bureaucratic bottlenecks that slow engineering teams without adding value.
When to Use an ARB
Not every architectural decision needs ARB review — that would create an unmanageable bottleneck. ARBs should review: introduction of new technology platforms or major frameworks; cross-team service interface changes; significant data model changes with broad impact; security architecture decisions; and decisions that set precedents affecting many future decisions.
Lightweight Governance Alternatives
- Architecture Decision Records (ADRs): Documented decisions with context, options considered, and rationale. Lightweight, version-controlled, and searchable. The minimum viable governance for architectural decisions.
- Architecture Guild/Community of Practice: Regular forum of senior engineers to share architectural patterns, review significant proposals, and build consensus. Less formal than an ARB.
- RFC (Request for Comments) process: Written proposals circulated for comment before implementation — enables asynchronous review without mandatory approval gates
ARB Anti-patterns
- ARB as gatekeeper — review happens after design is complete, changes are impossible
- Inconsistent standards — different decisions for similar situations without explanation
- Slow turnaround — ARB meetings happen infrequently; decisions wait weeks
- Lack of follow-through — decisions made but not enforced