EARB
Walk in knowing what they'll ask.
Most submissions fail for the same handful of reasons, and almost all of them are fixable the week before. This runs your item through an architecture review board's actual tests — does it even belong here, is the paper reviewable, and which weaknesses will get picked up in the room.
A rehearsal, not a ruling. Everything stays in your browser — no account, no server, nothing stored.
Not sure you need a board at all?
Start one step earlier. Ten questions will tell you whether this needs no architecture engagement, one architect, or a formal board — before you write anything.
Do I need EA? →A board is
- A stage gate. It decides whether an initiative may proceed, not whether it gets funded.
- A conformance test against published standards, principles and technology positions.
- A forum for challenge before commitment, when a team asks for it.
- A record. The reasoning behind a decision outlives the people who made it.
A board is not
- A funding body. If it controls money it will be lobbied rather than consulted.
- A design authority. Boards that redesign solutions in the room produce worse designs and slower delivery.
- A rubber stamp. If nothing is ever returned, the gate is theatre and everyone knows it.
- A place to invent standards. A gate that tests against unpublished opinion is just senior preference.
What are you asking for? DIA, plus one
- D — Decision
- You are asking the board to rule on something you cannot or should not decide alone.
- C — Consultation
- You are not asking for a ruling. You want challenge on a direction before you commit to it, while changing course is still cheap.
- I — Information
- The board needs to know this because it affects decisions it has made or will make. No ruling is sought.
- A — Awareness
- Context the board benefits from holding. No action, no decision, no follow-up.
Where it should be decided
- Delegated — no board needed
- Reversible, contained and conventional. The domain architect or the team decides and records it. Bringing this to the board costs more than the decision is worth.
- Service level — Same week, by the accountable architect
- Fast path — chair and one domain architect
- Material or novel, but not irreversible and not wide-reaching. Reviewed out of cycle by the chair plus the relevant domain architect, and reported to the next full board.
- Service level — 5 working days
- Full board
- Irreversible, cross-cutting, or a genuine first for the estate. This is what the board is for. Full paper, pre-read, quorum, minuted decision.
- Service level — Next scheduled board, paper 48 hours ahead
The 10 readiness criteria
- The problem, in business terms — Can someone outside your team state what problem this solves, without using a product name?
- The ask is explicit — Is the decision, or the challenge sought, written as a single answerable question?
- Options, including do-nothing — Have you set out the alternatives you rejected, and why — including doing nothing?
- Estate impact — Have you stated what this duplicates, replaces or retires in the existing estate?
- Standards conformance — Have you tested this against published principles and technology positions, and declared every deviation?
- Security, data and resilience — Have identity, data classification, residency, and failure behaviour been addressed — not just mentioned?
- Cost over life, not cost to build — Do you have run, licence, support and exit costs — not only the delivery estimate?
- Reversibility and exit — If this is wrong in eighteen months, do you know what it takes to unwind it?
- A named risk owner — Is there a named individual accountable for the risks being accepted — not a team or a function?
- Pre-read circulated — Was the paper circulated at least 48 hours before the board?
The six outcomes
- Approved
- Proceed as presented. The board has no outstanding concerns.
- Approved with conditions
- Proceed, but specific things must be true by specific dates. The most common healthy outcome.
- Returned for rework
- The direction may be sound but the submission is not reviewable, or a material concern is unresolved.
- Deferred — information missing
- The board cannot responsibly decide with what it has been given.
- Rejected
- This should not proceed in this form. Rare, and should be unambiguous when it happens.
- Noted
- For information and awareness items. The board has received it; no decision was sought.
The full operating model — triage, integrity rules, waivers, service levels, health metrics and anti-patterns — is on the framework page.
Common questions
- What is an Enterprise Architecture Review Board?
- An EARB is a stage gate for business and technology initiatives. A chief architect, domain architects and federated architects from the business units review proposals against published standards and decide whether they may proceed. It is not a funding body and not a design authority — it tests conformance, challenges direction, and records the reasoning behind decisions.
- What does DIA mean in an architecture review board?
- DIA classifies what a team is asking the board for: Decision (a ruling is required), Information (the board needs to know, no ruling sought) or Awareness (context only). A fourth mode, Consultation, is worth adding — the team wants challenge on a direction before committing, while changing course is still cheap. Stating the ask at submission is the single cheapest way to stop a board treating every item as a decision.
- What should come to the board, and what should not?
- Triage on four tests: reversibility, blast radius, novelty and materiality. Reversible, contained, conventional and small decisions should be delegated and recorded. Irreversible, cross-cutting or genuinely novel ones belong at the full board. Everything in between takes a fast path — the chair plus one domain architect, reported back to the next board.
- What outcomes can a review board give?
- Six: approved; approved with conditions; returned for rework; deferred because information is missing; rejected; or noted for information and awareness items. Approved with conditions is the most common healthy outcome — but only if every condition has an owner, a date and closure evidence. Untracked conditions make it identical to unconditional approval.
- How do you stop a review board becoming a bottleneck?
- Delegate aggressively using entry criteria, publish a service level for decisions, run a fast path for anything that is not irreversible or cross-cutting, and measure decision cycle time. Boards that take weeks get routed around, which means you lose visibility of the riskiest work first.
- How do you measure whether a review board is working?
- Decision cycle time, first-time approval rate, condition closure rate, waiver ageing, bypass rate, agenda mix and rework rate. A board that does not measure itself cannot defend its existence when budgets tighten — and governance functions are cut early.