Architecture Review Boards

Production engineering guide for architecture review boards covering patterns, implementation strategies, and operational best practices.

Architecture Review Boards (ARBs) are formal, recurring forums where engineering teams present significant architectural proposals to a cross-functional group of senior engineers, architects, and technical leaders. They matter when a decision carries long-term consequences—shifting infrastructure, adopting a new technology stack, integrating critical services, or rearchitecting core systems—where early missteps are costly and hard to reverse. An ARB is not a meeting; it is a process. The board evaluates proposals not only for technical soundness but also for alignment with organizational goals, scalability, maintainability, and risk.

Preparing for a Review

Submitting a Proposal

A proposal begins with a decision record (DR) in a shared repository, typically using a standard template. The DR must include:

The proposal is submitted via a pull request (PR) to the architecture/decisions directory. The PR includes:


title: Migrate monolith to microservices
description: |
  Migrate core order processing service to a microservices architecture using Kubernetes and gRPC.
target: 2025 Q2
status: draft
reviewers:
  - [email protected]
  - [email protected]
  - [email protected]
dependencies:
  - event-sourcing-core-service
  - auth-migration
  - database-migration
  - service-discovery-v2

The PR is tagged with arch-review and assigned to the ARB lead. The board expects the proposal to be ready for discussion, not just documentation.

Reviewing the Proposal

Before the meeting, reviewers examine the DR and plan. The ARB uses a shared review tool like GitHub, GitLab, or Confluence. Each reviewer adds inline comments directly to the DR Markdown file. They may also:

# review.yaml
reviewer: [email protected]
date: 2024-04-18
summary: |
  Strong proposal. Consider performance impact of gRPC over HTTP/1.1.
  Suggestion: include a migration strategy for zero-downtime rollout.
rating: excellent
concerns:
  - latency impact of inter-service calls
  - data consistency across services
  - monitoring and alerting requirements
  - cost of managing 20+ microservices

Reviewers flag issues with the PR using labels:

The ARB lead compiles a review summary and sends it to the proposers 5 days before the meeting.

Conducting the Review

Agenda and Format

The ARB meeting is held weekly, lasting 90 minutes. The agenda is published in a shared calendar and includes:

The meeting is conducted via video call, with a shared screen showing:

The proposers use a shared presentation tool—typically Google Slides or Microsoft PowerPoint. The slide deck must include:

Presenting the Proposal

The proposers present in sequence:

  1. Problem and context (5 minutes).
  2. Options and trade-offs (7 minutes).
  3. Chosen solution with justification (8 minutes).
  4. Implementation plan (5 minutes).

The presentation must include a live demo of the architecture in action. The demo uses:

# demo.sh
#!/bin/bash
set -e

# Start services
docker-compose up -d

# Wait for services
sleep 10

# Test API
curl -v http://localhost:8080/api/v1/orders \
  -H "Content-Type: application/json" \
  -d '{"customer_id": 123, "items": [{"sku": "TSHIRT", "quantity": 2}]}'

# Check logs
docker-compose logs --tail=50 order-service

# Monitor metrics
curl http://localhost:9090/metrics | grep "order_service_requests_total"

The proposers must be ready to answer questions on:

Facilitating Discussion

The ARB lead acts as a facilitator, not just a note-taker. They:

The discussion focuses on three core aspects:

Common questions include:

The ARB lead uses a decision matrix to guide the discussion. The matrix lists:

The matrix is updated in real time during the discussion. The proposers must defend their scores.

After the Review

Making the Decision

At the end of the discussion, the ARB makes one of three decisions:

The decision is documented in the PR as a comment:

## Decision: Approved with changes

The ARB approves the microservices migration proposal with the following changes:

- Add a circuit breaker pattern to the order service.
- Include a data consistency strategy (event sourcing + CQRS).
- Define SLOs and SLIs for the new system.
- Clarify the rollout plan with blue-green deployment.

@alice @bob, please update the DR by 2024-05-01.

The ARB lead updates the status field in plan.yaml:

status: approved-with-changes
decision_date: 2024-04-25
reviewer_notes:
  - "Add circuit breaker pattern"
  - "Include data consistency strategy"
  - "Define SLOs and SLIs"
  - "Clarify rollout plan"

Following Up

After the meeting, the proposers:

# dependencies.yaml
dependencies:
  - service: order-service
    owner: order-team
    status: in-flight
    due: 2025-03-15
    notes: |
      Requires event-sourcing-core-service and auth-migration.
      On-call rotation starts Q2 2025.
  - service: payment-service
    owner: payments-team
    status: blocked
    due: 2025-06-30
    notes: |
      Waiting on shared database schema.
      Requires new monitoring dashboard.

The ARB lead publishes a review summary on the engineering wiki, including:

The ARB maintains a decision log in a shared database. Each decision is stored as a row in a decisions table with the following schema:

CREATE TABLE decisions (
    id UUID PRIMARY KEY,
    proposal_id UUID REFERENCES proposals(id),
    status VARCHAR(20) CHECK (status IN ('approved', 'approved-with-changes', 'deferred')),
    decision_date DATE,
    reviewer TEXT[],
    summary TEXT,
    action_items JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

The ARB also tracks review velocity using a simple script that aggregates data from the decision log:

# bin/arb-velocity.sh
#!/bin/bash

set -e

# Get all decisions from the last 30 days
psql -c "
SELECT
  COUNT(*) AS total,
  AVG( (decision_date - created_at) ) AS avg_lead_time,
  AVG( (updated_at - decision_date) ) AS avg_review_time
FROM decisions
WHERE decision_date >= CURRENT_DATE - INTERVAL '30 days'
" -t

The output is:

total | avg_lead_time | avg_review_time
------|---------------|-----------------
12    | 5.2 days      | 3.7 days

This data is used to refine the ARB process—adjusting meeting frequency, reviewer load, and review depth.

Common Pitfalls and Sharp Edges

Silent Failures

Confused Options

Production-Driven Insights

Unspoken Assumptions

These runbooks become part of the organization’s knowledge base, accessible via a shared wiki.

Summary

An Architecture Review Board is not a meeting—it is a process that ensures architectural decisions are well-considered, documented, and aligned across teams. It begins with a well-structured decision record and culminates in a shared understanding of the system’s future. The ARB is a continuous feedback loop: proposals are reviewed, decisions are made, actions are tracked, and lessons are compiled. It is the mechanism by which engineering teams collectively shape the long-term architecture of their organization.

This page was rewritten on 17 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.