IT management
Architecture review board
An architecture review board is a standing group of architects and specialists that checks significant designs against an organization's standards before build.
Organizations set up an architecture review board when designs that affect many teams keep getting approved by nobody in particular: a program picks a second integration platform or a project builds on a technology the organization is trying to retire. The board is where enterprise architecture standards meet real designs, and where exceptions to them get decided on purpose instead of by default.
Why have an architecture review board?
- To enforce standards consistently. Principles and reference architectures only matter if someone checks designs against them.
- To catch cross-team effects early. A design that looks fine inside one program may duplicate a platform, copy master data or depend on a system being retired. Reviewers from other domains see what the program cannot.
- To make exceptions explicit. Every organization deviates from its standards. A board turns silent deviations into recorded exceptions with an owner and an expiry date.
- To build a record. Decisions with their reasoning, kept as architecture decision records, stop the same arguments being replayed by the next program.
Who sits on an architecture review board?
A typical board has a chair, usually the lead enterprise architect, and a core of domain architects for applications, data, infrastructure and security. Finance or portfolio management attends when a decision has cost consequences. The submitting team’s solution architect presents and answers questions but does not vote. Some boards add a rotating engineer from delivery teams to keep the board grounded in what is practical.
What does an architecture review board review?
Not everything, or the board becomes the slowest step in every project. Most set a few triggers:
- A new platform, product or technology not already on the approved list.
- A new copy or new owner of master data such as customer, product or policy records.
- A new integration pattern or a change to a shared interface other teams depend on.
- Spend above a threshold or a decision that commits the organization for years, such as a core system replacement.
- A request for an exception to a published standard.
Everything below the threshold goes through a team-level design review instead.
How does an architecture review run?
The diagram at the top of this page shows the common shape. The solution architect or tech lead submits a design package: the problem, the proposed solution architecture, architecture diagrams, the data involved and the standards it touches. A lead reviewer does a pre-review over two to five days, checking the package against standards, data rules and security requirements and sending questions back, so the meeting deals only with what is unresolved. The board meets, the author presents briefly and the chair records a decision within the meeting or the next day.
The decision is one of three. Approve: the team builds, and the decision is recorded as an ADR. Approve with conditions: the team builds, but named conditions must be met by a date, and any exception to a standard carries an expiry after which it comes back to the board. Reject: the design returns as a new version through the same door. Conditions and exceptions are tracked to closure, with the board checking them at the next gate.
How does a lightweight board differ from a heavyweight one?
| Aspect | Lightweight | Heavyweight |
|---|---|---|
| Trigger | A short list of thresholds; most designs never come | Every project at every stage gate |
| Package | A few pages and a diagram, in the team’s own format | A formal template with required sections and sign-offs |
| Turnaround | Days, with async approval for clean designs | Weeks, waiting for a meeting slot |
| Decision | Chair decides, recorded as an ADR | Committee vote, recorded in minutes |
| Exceptions | Granted with an expiry date and an owner | Rarely granted, which drives deviations underground |
Most organizations start heavyweight, because the board was created in response to a failure, and move lighter once trust builds. The lightweight model depends on published standards and a good pre-review.
What are common architecture review board failure modes?
- Reviewing too late. A design that arrives after procurement or after the first sprint cannot be changed cheaply, so the board either waves it through or becomes the villain. Review while the design is still a document.
- Reviewing everything. Projects queue, teams route around the board and the standards stop being enforced anywhere.
- Untracked conditions. Approve with conditions is the most common outcome and the least followed up. Give every condition an owner and a date.
- A stale current state. Reviewers asking whether a design duplicates something need to know what exists. A CMDB and an application portfolio that are out of date lead to confident wrong answers.
How does an architecture review board relate to design reviews and ADRs?
A design review is run by a team for its own designs, with peers as reviewers and a decision owner in the team. It asks whether the design is sound. The board sits above team reviews and asks a different question: whether the design fits the organization’s standards and target state, where it sits on the IT roadmap and what it does to other teams. In TOGAF terms this is phase G, implementation governance. A design normally passes its team review before it comes to the board, and only a minority of designs come to the board at all.
The architecture decision record is the output format for both. A board decision written as an ADR, with context, decision, consequences and alternatives, lives with the program’s other records and can be found by the next team that faces the same choice.
What tools help with an architecture review board?
- Work tracking tools. Submissions, conditions and exceptions as tickets in the tracker teams already use, so follow-ups do not depend on anyone’s memory.
- Document and wiki tools. The design package, the decision and its ADR in one place the whole organization can read.
- AI diagramming tools. Tools like Eraser produce the architecture diagram a package needs from a written design or from live infrastructure, so reviewers see the real current state and the proposed change in the same format.
For more on this kind of diagram, see design docs.
Frequently asked questions
-
What is the difference between an architecture review board and a change advisory board?
A change advisory board reviews individual changes to production, such as a release or a configuration change, for operational risk, usually days before they happen. An architecture review board reviews designs for fit with standards and the target architecture, months before anything reaches production. Both exist in ITIL-style organizations and should stay separate.
-
How often should an architecture review board meet?
Often enough that waiting for a slot is never the slowest part of a project. Weekly is common in large organizations. Many boards also approve asynchronously between meetings for designs the pre-review found clean, and keep the meeting for designs with open questions or exceptions.
-
Who chairs an architecture review board?
Usually the lead enterprise architect, since the board enforces the standards that role owns. The chair sets the agenda, runs the meeting, makes the final call where members disagree and is accountable for the board's turnaround time. Some organizations rotate the chair among domain architects to spread the load and the judgment.
-
Can a team appeal an architecture review board decision?
There should be a route, typically to the CIO or CTO, and it should rarely be used. A board whose decisions are regularly overturned has lost its mandate, and one whose decisions are never challenged may be rubber-stamping. Recording each decision with its reasoning makes appeals rarer.
