Architecture Review Board

An architecture review board, often shortened to ARB, is the forum where major technology decisions are checked before they are carried out. Project teams present proposed designs, such as a new application, a significant integration or the adoption of a new platform, and the board assesses whether they fit the organization's standards and direction. The board can approve a design, approve it with conditions, ask for changes or grant an exception to a standard where there is a good reason.

Architecture review boards exist because individual projects naturally optimize for their own goals. Without a check, each project may choose its own tools, create its own copy of data or build its own integration, adding cost and complexity that the whole organization pays for later. A well-run board prevents these problems while keeping delays to a minimum. For IT strategy and finance, it is one of the main ways architecture decisions protect future costs and keep the organization moving toward its target architecture.

Definition of Architecture Review Board

An architecture review board is a governance body, usually chaired by a senior architect or technology leader, that reviews and approves architecture decisions above a defined threshold. It is a central part of architecture governance, also called enterprise architecture governance.

TOGAF describes the board's role in its guidance on architecture governance. Many organizations also call it an architecture council, design authority or technical review board.

Typical Membership

Members usually include enterprise architects, senior solution architects and representatives from security, infrastructure, data and operations. Rotating some seats among senior engineers helps the board stay close to day-to-day delivery.

Many boards also include business representatives or a member of the IT finance team, so that decisions consider business impact and cost as well as technical fit.

Membership should be small enough to make decisions efficiently, often between five and ten people, with specialists invited for specific topics.

A secretary or coordinator manages the agenda, records decisions and follows up on conditions attached to approvals.

What the Board Reviews

Boards typically review new applications or platforms, major changes to existing systems, significant integrations, changes to data ownership and requests for exceptions to standards.

Most set thresholds, such as a cost level, risk level or the introduction of new technology types, so that only significant decisions come before the full board.

Smaller decisions are handled by lighter processes, such as checklists, self-assessment or review by a single architect. This keeps the board focused on the decisions that matter.

Importance of Architecture Review Boards in Enterprise Architecture

The board turns architecture principles and standards into decisions. Without a review step, standards are often ignored under project deadlines. Over time, the board's decisions also become a body of precedent that teams can consult before designing their solutions.

It prevents duplication. By seeing proposals from across the organization, the board can spot when two teams plan similar solutions and direct them toward a shared one. Few other forums see proposals from every part of the organization in one place.

It also manages risk, ensuring that security, data protection, resilience and supportability are considered before designs are built rather than after.

Protecting Future Costs

Many long-term technology costs are set by early design choices, such as which platform to use, whether to build a custom integration or whether to keep a separate copy of data.

A board that considers total cost of ownership can steer projects toward options that cost less to run over many years, even if they cost slightly more to build.

Reviewing new purchases against the application inventory also prevents the organization from buying another tool for a capability it already supports.

Some boards track the estimated costs avoided through their decisions, which helps demonstrate the value of governance.

Avoiding Common Problems

Boards that meet infrequently or require heavy documentation become bottlenecks. Teams may then work around them or present designs too late for meaningful change.

Boards that only say no lose support. Successful boards explain their reasoning, offer alternatives and grant exceptions when a good case is made. Exceptions should have an owner and an expiry date, so that temporary deviations do not become permanent.

Late reviews are costly. Engaging with teams early, when designs are still flexible, produces better outcomes than formal approval at the end. Some boards hold short early consultations as well as formal reviews.