What is an Architecture Review Board (ARB), and what decision does it typically make when a project reaches an architecture review gate?

## What the board is An **Architecture Review Board (ARB)** is a standing governance body - usually the chief/enterprise architect plus a rotating set of domain architects, security, infrastructure, and sometimes a business sponsor - whose job is to check a proposed solution design against the organization's **architecture principles**, **reference architectures**, and **technology standards** before the project is allowed to proceed to the next stage of delivery. ## How a review runs Mechanically, the process works like a **checkpoint gate**. A project team submits an architecture artifact (a solution design document, a set of ADRs, a target-state diagram) at a defined point in the SDLC - commonly at the end of a design/discovery phase and again before major implementation funding is released. The board reviews it against a checklist derived from the EA principles, e.g., 'buy before build', 'no new integration middleware without approval', 'data must live in the system of record'. It then issues one of three outcomes: 1. **Unconditional approval.** 2. **Conditional approval** - approved provided named conditions are met, often re-checked at a later gate. 3. A required **exception/waiver** if the design cannot or will not comply. ## Why it exists The reason this exists is that architecture decisions made independently by dozens of delivery teams, each locally rational, tend to be globally expensive: - duplicated integration patterns - incompatible data models - redundant tooling licenses - security gaps that only become visible when systems are composed together A single team optimizing for its own deadline has no incentive to check whether another team already solved the same problem, or whether its chosen database violates a data-residency commitment made at the enterprise level. The ARB is the mechanism that inserts an enterprise-level check into what would otherwise be a purely local decision, and it derives its **teeth** from being wired into a funding or stage gate in **project portfolio management (PPM)** - a project literally cannot draw down its next tranche of budget, or move from 'design' to 'build' in the SDLC, without a recorded ARB outcome. Without that binding to a gate, an ARB becomes advisory only, and advisory boards are the first thing project managers route around under deadline pressure. ## The trade-off The central trade-off is **speed versus enterprise-wide coherence**. Every review adds latency and a scheduling dependency - if the ARB only meets biweekly, a project can lose two weeks waiting for a slot, and if the board is broad and generalist it may lack the specific technical depth to give a fast, confident answer, so it defaults to caution and asks for more documentation, adding more delay. Organizations manage this by **tiering** review: - low-risk, low-cost, already-pattern-conformant changes get a lightweight self-attestation or automated check - only high-risk, high-cost, or novel-technology projects get a full board review Get the tiering wrong and you either bottleneck the whole portfolio or the ARB becomes a rubber stamp because it's forced to approve on a compressed timeline without real scrutiny. ## Failure modes Failure modes show up in a few recognizable patterns. - **The first is 'governance theater'**: the board exists, meets, and approves nearly everything because it has no real authority to block funding, so project teams treat the review as a formality to check off rather than a genuine design conversation - visible in audit as a near-100% approval rate with almost no conditions attached. - **The second is the opposite failure, 'bottleneck governance'**: the board becomes the long pole in every schedule because it's understaffed relative to portfolio volume, review criteria are vague so every session runs long, and teams start scheduling architecture review as if it were a construction permit. - **The third is 'stale principles'**: the board keeps enforcing standards that predate a since-adopted technology, which erodes the board's credibility and drives shadow IT, where teams build outside the ARB's visibility entirely to avoid the friction. ## A worked example A concrete example: a bank might run an ARB gate at the end of the 'solution design' phase for any project above a cost or risk threshold, requiring sign-off before the PMO releases build-phase funding; the board checks the design against a small set of non-negotiable principles using a standard checklist, and any deviation is logged as a formal exception with an **expiry date** and an **owner**, rather than silently waived. That exception log itself becomes an input to the next governance cycle - a principle that accumulates many exceptions is a signal it's either wrong or unenforceable as written, and a healthy governance process revisits and revises it rather than treating every waiver as a one-off failure of discipline.