What does the typical composition of an Architecture Review Board (ARB) look like, and what is its engagement model with delivery teams — that is, when and how do teams interact with it, independent of how it actually reaches or documents a decision?

## What an ARB actually is An Architecture Review Board is best understood as a **standing forum, not a single decision-maker** — its composition and cadence are a governance mechanism separate from how it actually rules on any individual proposal. ## Composition In most mid-to-large organizations, the ARB is a small group, typically five to ten people, deliberately kept small enough to move quickly: - a **chair** (often the Chief Architect or Head of Enterprise Architecture) - a rotating or fixed set of **senior/principal/domain architects** covering the major platform areas - **standing representation from functions whose concerns cut across every system** — security, infrastructure/platform engineering, and often data governance or compliance in regulated industries Some organizations add a rotating delivery-team representative specifically so the board hears a builder's perspective and doesn't become purely an oversight function disconnected from implementation reality. The board meets on a fixed cadence — weekly or biweekly is common — rather than convening ad hoc per request, because a predictable cadence is what lets delivery teams plan around it instead of waiting on an unscheduled invitation. ## The engagement model, in three parts The engagement model is the set of rules that determine when and how a delivery team interacts with this standing group, and it typically has three parts. 1. **First, thresholds.** Not every architecture decision goes to the ARB — only those crossing a defined bar, commonly new-technology adoption (something not already on the approved radar), cross-domain data sharing, systems above a cost or risk tier, or changes to shared/foundational platforms. Anything below the threshold stays with local Solution or Domain Architects, which is what keeps the board from becoming the centralized bottleneck a federated model is trying to avoid. 2. **Second, checkpoints.** For initiatives that do cross the threshold, engagement happens at defined stage gates rather than continuously — commonly an early 'architecture vision' or intent review before significant design work starts (cheap to redirect at this point), and a later 'detailed design' review before build begins (catches issues before code is written, still cheaper than catching them after). Some models add a lightweight post-hoc 'as-built' checkpoint for significant production changes. 3. **Third, submission format.** Engagement is normally asynchronous-first — the team submits a written artifact ahead of the meeting slot, so the live session is spent on questions and points of disagreement rather than a first read-through. This matters mechanically: a board that reads proposals live instead of in advance can only get through one or two proposals per session, which is exactly the throughput bottleneck the async-first pattern exists to avoid. ## Why structure it this way Why structure it this way rather than have every architect who wants an opinion weigh in ad hoc? The point of a fixed roster and cadence is **predictability and coverage** — a delivery team needs to know in advance who will be in the room and when, so they can prepare the right artifact and get a decision on a schedule that doesn't block their delivery plan. Standing cross-functional representation exists so cross-cutting concerns get surfaced once, in one forum, rather than requiring the delivery team to separately track down five specialist reviewers for every significant proposal. ## The trade-off The trade-off is **throughput versus coverage**, and it's a real tension. - A very **selective threshold** keeps the board fast and un-bottlenecked but risks missing genuinely cross-cutting decisions that don't happen to trip the formal criteria. - A **broad threshold** catches more risk but slows delivery across the board and pushes the ARB back toward being a universal gate, the exact failure mode federation is meant to avoid. ## Failure modes Failure modes are recognizable in practice. - **Cadence.** A board with no fixed cadence becomes a scheduling bottleneck of its own — 'we'll convene when we can' turns into weeks of delay, and teams start treating the ARB as something to avoid rather than engage with. - **Thresholds.** A board with unclear thresholds produces inconsistent behavior: one team escalates a decision that another, similar team never surfaces, because the criteria for 'must come to the board' live in institutional memory rather than a written policy. - **Submission format.** A board that reviews live instead of async-first caps its own throughput and inevitably becomes the queue that centralized-model bottlenecks are known for, regardless of what the org chart says about being federated. ## Where it shows up A concrete real-world pattern: TOGAF's Architecture Governance framework formalizes exactly this structure — a standing Architecture Board with defined membership and a Compliance Review checkpoint built into the Architecture Development Method's phases, which is this composition-and-engagement pattern codified as an industry-standard methodology rather than an ad hoc org invention.