Architecture Review Board

Architecture Review Board (ARB)

When to Use

• Establishing a technical decision governance process
• Reviewing proposed architecture changes before implementation
• Maintaining consistency across teams and services
• Building organizational knowledge through decision logs

ARB Process

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ Proposal  │───►│  Review   │───►│ Decision  │───►│ Record   │
│ (RFC)     │    │ (Meeting) │    │ (Vote)    │    │ (ADR)    │
└──────────┘    └──────────┘    └──────────┘    └──────────┘
   Author         ARB Board       Approve/        Decision
   writes          reviews        Reject/          logged
                                  Defer

RFC Template

# RFC: [Title]

**Author**: [name]
**Date**: YYYY-MM-DD
**Status**: Draft / In Review / Approved / Rejected

## Problem Statement
[What problem are we solving and why now?]

## Proposed Solution
[Technical approach with diagrams]

## Alternatives Considered
| Option | Pros | Cons |
|--------|------|------|
| Option A | ... | ... |
| Option B | ... | ... |

## Impact Analysis
- Services affected: [list]
- Database changes: [yes/no, describe]
- API changes: [breaking/non-breaking]
- Performance impact: [estimate]
- Security implications: [describe]

## Migration Plan
[How to get from current state to proposed state]

## Risks
1. [Risk with mitigation]

## Open Questions
1. [Question that needs ARB input]

Review Criteria

• [ ] Aligns with existing architecture and tech stack
• [ ] Considers security implications
• [ ] Has a migration/rollback plan
• [ ] Performance impact assessed
• [ ] Cost implications understood
• [ ] Team has expertise to implement and maintain
• [ ] Doesn't introduce unnecessary technology

When ARB Review is Required

| Change Type | Review Required? | |------------|-----------------| | New external dependency | ✅ Yes | | New database | ✅ Yes | | New programming language | ✅ Yes | | New microservice | ✅ Yes | | Architecture pattern change | ✅ Yes | | API breaking change | ✅ Yes | | Internal refactoring | ❌ No (team decision) | | Library update | ❌ No (unless major version) | | Bug fixes | ❌ No | | New feature (existing patterns) | ❌ No |

Decision Log

| ID | Date | Title | Decision | Rationale |
|----|------|-------|----------|-----------|
| ARB-001 | 2026-01 | Database choice | PostgreSQL | ACID, JSON support, team expertise |
| ARB-002 | 2026-02 | API framework | NestJS | TypeScript, modular, good ORM integration |
| ARB-003 | 2026-03 | Mobile framework | Flutter | Cross-platform, Dart performance, single codebase |

Meeting Format (30-45 minutes)

1. RFC Presentation (10 min): Author presents proposal
2. Q&A (10 min): Board asks questions
3. Discussion (10 min): Alternatives, risks, concerns
4. Decision (5 min): Approve / Reject / Defer / Request Changes
5. Action Items (5 min): Who does what by when

Board Composition

• CTO or VP Engineering (chair)
• Senior/Staff Engineers (rotating monthly)
• Security representative (for security-impacting RFCs)
• Product representative (for customer-impacting changes)

Quality Gates

• [ ] All architectural decisions documented as ADRs
• [ ] RFC submitted at least 3 business days before ARB meeting
• [ ] Meeting minutes recorded and shared
• [ ] Decision log accessible to all engineers
• [ ] Quarterly review of past decisions (are they holding up?)

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: camilooscargbaptista
• Source: camilooscargbaptista/cto-toolkit
• License: MIT

Install and usage instructions live in the source repository linked above.