The Architecture Review Board is one of the most reliably ineffective governance mechanisms in corporate technology. In organisation after organisation, across sectors and decades, it exhibits the same dysfunctions: too slow to be useful, too political to be honest, too disconnected from delivery to carry real authority. Architects who have sat through hundreds of ARB (Architecture Review Board) meetings know this. The organisations that run them know this. And yet the ARB persists — because it addresses a real problem, and because nobody has agreed on what to replace it with.
This article is an attempt to diagnose why enterprise architecture governance fails so consistently, and what the approaches that actually work have in common.
Why the ARB Fails
The Architecture Review Board was designed to solve a genuine problem: ensuring that architectural decisions made across a large organisation are consistent with each other, with the organisation's strategic direction, and with the technology standards that have been established. That is a legitimate governance need. The ARB's failure is not a failure of intent — it is a failure of mechanism.
It operates at the wrong tempo. Delivery programmes move fast. The ARB meets monthly, or fortnightly, or whenever a quorum can be assembled. By the time an architectural decision reaches the ARB for review, the delivery team has often already made it — because they could not wait three weeks for a governance approval and hit their next milestone. The ARB reviews decisions that have already been made and either blesses them retroactively or creates conflict with a programme that has moved on.
It is a venue for politics, not architecture. In most organisations, the ARB is attended by the heads of the major technology domains — infrastructure, applications, data, security — each of whom has a stake in the decisions being reviewed. Architectural questions that should be resolved on technical merit are resolved on organisational influence. The loudest voice, or the most senior role, or the domain that controls the largest budget, prevails. This is not architecture governance; it is organisational politics with an architectural vocabulary.
It creates compliance theatre rather than architectural coherence. Delivery teams learn quickly that the ARB wants to see evidence of compliance with its principles, regardless of whether compliance serves the programme's actual needs. They learn to present their architecture in terms that satisfy the ARB — which is not the same as learning to build architectures that are actually consistent with the organisation's standards. The documents improve. The architecture does not.
"The ARB has become a ritual. Architects go in, show that they have considered the standards, receive a stamp, and go back to building what they were building before. The governance is real. The influence is not."
What Good EA Governance Actually Looks Like
The organisations where enterprise architecture genuinely influences what gets built share characteristics that distinguish them from the ones where it does not. None of these characteristics involves a better-designed ARB.
Architecture is embedded in delivery, not separate from it. In the organisations where EA works, architects are present in delivery programmes — not reviewing them from a governance function. They attend sprint reviews. They sit in design sessions. They make real-time decisions alongside the delivery teams rather than reviewing the decisions those teams made last month. The governance happens continuously, at working level, rather than periodically, at committee level.
Principles are short enough to remember and concrete enough to apply. The architectural principles that actually guide decisions are not the ones in the 80-page principles document that was approved two years ago. They are the ones that architects have internalised and can apply in a meeting, without consulting documentation. Effective architecture governance produces a small number of clear, concrete, memorable principles — and invests in making sure the people who need to apply them understand them.
Architectural decisions are recorded where they are made, not where they are approved. Architecture decision records — brief documents capturing what was decided, why, and what alternatives were considered — are more valuable than ARB minutes. They create an institutional memory of architectural reasoning that survives the people who made the decisions, and they exist at the point of decision rather than in a governance system that is disconnected from it.
TOGAF is the most widely adopted enterprise architecture framework in the world. It provides a comprehensive methodology for architecture governance — including the Architecture Review Board. It is also the framework most frequently cited by organisations whose EA governance is not working. The framework is sound. The implementation challenge is that TOGAF's governance mechanisms are designed for organisations with the maturity, the resources and the commitment to implement them fully. Most organisations implement a subset — typically the governance mechanisms, which are visible and auditable, without the architectural capability that would make those mechanisms effective.
The Federated Model: A Better Approach
The governance model that works best in complex organisations is not a centralised ARB but a federated architecture community. The distinction is important. A centralised ARB makes decisions that delivery teams are required to comply with. A federated architecture community sets standards and principles collaboratively, embeds architects in delivery, and uses the community as a forum for sharing decisions and learning — not for approving them.
In the federated model, the central architecture function is responsible for the overall framework: the principles, the standards, the reference architectures, and the process for handling exceptions. Domain architects — embedded in the major technology domains or delivery programmes — are responsible for applying those principles in their specific context. The community forum is where patterns are shared, where conflicts between domains are surfaced and resolved, and where the framework is maintained against the reality of what is being built.
This model requires more investment in the capability of domain architects than the centralised model does — because the governance happens at the point of delivery, and the architects doing it need to be good enough to make sound decisions without recourse to a central approval process. That investment is consistently more effective than the investment in better ARB processes.
Practical Steps for Leaders
- Audit your current ARB: what proportion of its decisions are retrospective approvals of choices already made? If the answer is more than a third, the mechanism is not working as designed.
- Assess whether your architectural principles are short enough to be memorised and concrete enough to be applied without interpretation. If they require a document to apply, they are too abstract.
- Evaluate the embed ratio: what proportion of your enterprise architects are physically present in delivery programmes versus sitting in a central governance function? The right ratio depends on context, but more than half in central governance is usually too many.
- Introduce Architecture Decision Records as a mandatory practice in delivery programmes. The discipline of documenting decisions when they are made is more valuable than any retrospective review process.
- Reframe the EA community forum as a learning and sharing vehicle rather than an approval vehicle. The questions it asks should be "what did you decide and why?" not "do we approve this?"
Enterprise architecture governance exists because architectural decisions matter — because the cumulative effect of thousands of individual technical decisions determines whether a large organisation's technology estate is coherent, maintainable, and capable of supporting the organisation's strategy. That is a real and important function. The question is not whether to govern architecture, but how to do it in a way that actually influences the decisions that matter, rather than creating documentation that records what happened after the fact.