Architecture Board and decision rights
This is the second of 6 EA Capability and Governance modules. It explains the Architecture Board from G21I in full, including composition, remit, decision rights, meeting cadence, and the London board design. The Board is the single most visible expression of architecture governance because it is the place where cross-enterprise coherence is protected deliberately.
By the end of this module you will be able to:
- Explain the purpose of the Architecture Board using the G21I definition
- Describe the recommended board composition, remit, and escalation logic
- Define decision rights and explain why they must be explicit rather than assumed
- Design a meeting cadence and standing agenda that keeps the board selective
- Recognise the signs that a board is reviewing too much or too little
- Apply board and decision-rights thinking to London's regulated utility case
Real-world case · 2019
247 items reviewed. 11 decided. Delivery teams learned the board was a formality.
A government agency established an Architecture Review Board in 2019. Within a year, the board had reviewed 247 items. It had decided 11. The remaining 236 had been discussed, commented on, noted, and forwarded without a clear decision.
Delivery teams learned to bring items to the board as a formality rather than for resolution. When a genuinely cross-enterprise integration decision needed board attention, it was buried in a queue of routine items and received the same twenty-minute slot as a minor API naming convention.
The post-mortem identified three root causes. First, the board charter said it would "review and advise on all architecture matters" without defining what counted as a board-level decision. Second, decision rights were assumed rather than documented, so nobody could say what the board was authorised to decide versus what it could only recommend. Third, there was no triage process to separate board-level items from items that could be handled by domain architects or delivery teams.
The board was not failing because it lacked authority. It was failing because it had no principled way to distinguish what it should decide from what should stay delegated elsewhere.
If a board reviews everything but decides almost nothing, is it governing or performing?
That story illustrates what happens when board scope is unbounded. This module explains how to design a board that is selective, explicit, and willing to decide.
53.1 The G21I definition of the Architecture Board
G21I defines the Architecture Board as the governance body responsible for reviewing and maintaining the overall coherence of the architecture. The key word in that definition is coherence. The board exists to protect the enterprise from decisions that would create cross-enterprise divergence, not from every local design choice.
G21I positions the Architecture Board as the primary governance forum for architecture decisions. It is not the only governance forum in the enterprise, and it should not try to be. Investment decisions belong to investment committees. Technical design decisions within a bounded solution belong to solution architects and delivery teams. The Architecture Board owns the decisions that sit between those levels: choices that affect enterprise direction, cross-domain coherence, and the integrity of the architecture roadmap.
“The Architecture Board is the governance body responsible for reviewing and maintaining the overall coherence of the architecture.”
The TOGAF Standard, 10th Edition - G21I, Architecture Governance
The scope is coherence, not completeness. A board that tries to review everything dilutes its ability to protect what actually matters. The G21I formulation is deliberately bounded.
53.2 Recommended board composition
G21I recommends that the Architecture Board includes representation from business, technology, delivery, and architecture functions. The rationale is that architecture decisions affect all four areas, and a board without business or delivery representation will make decisions that those groups do not recognise or respect.
A practical board composition for a medium-to-large enterprise typically includes the following roles.
- Chair (typically chief architect or CTO). Responsible for agenda, decision recording, and ensuring the board remains selective.
- Business representatives. Senior business leaders or business architects who can assess whether architecture decisions align with business strategy and priorities.
- Domain architects. Architects responsible for specific domains (business, data, application, technology) who bring domain expertise to cross-cutting decisions.
- Delivery or programme representatives. Programme managers or delivery leads who can assess whether architecture decisions are deliverable and can identify downstream impact.
- Technology leadership. CTO or technology director representation to connect architecture decisions to technology strategy, platform choices, and operational constraints.
- Security and risk representation. In regulated enterprises, a cyber or risk representative ensures that architecture decisions are assessed against security and resilience requirements.
The board should be small enough to make decisions (typically 6 to 10 members) and senior enough that its decisions carry authority. A board with 25 members is a committee, not a decision forum.
53.3 What the board should own
The board's remit should be explicit and bounded. G21I identifies several categories of decision that typically belong at board level.
Target-state and transition decisions. Choices that define or change the enterprise direction, transition-state acceptance criteria, or the integrity of the roadmap.
Material exceptions and dispensations. Deviations from the target architecture that could create future divergence, resilience weakness, or cross-enterprise cost if approved casually. Module 54 covers the compliance and waiver process in detail.
Cross-domain integration decisions. Choices where two or more architectural domains intersect and no single domain architect has sufficient authority to resolve the conflict alone.
Release conditions with enterprise consequence. Moments where the enterprise needs to know whether the next transition step is safe enough and aligned enough to proceed.
Principle interpretation and precedent. Situations where applying an architecture principle to a specific case requires interpretation that will set precedent for future decisions.
Equally important is what the board should not own. Routine design decisions within a single domain, minor configuration choices, and operational incidents should not reach the board. If they do, the board becomes the bottleneck described in the opening story.
Common misconception
“A board that reviews everything is the most thorough form of governance.”
A board that reviews everything usually decides little. G21I positions the board as a coherence protector, not a universal review body. Its value depends on selectivity and clarity of remit, not on the volume of items it processes.
53.4 Decision rights: the concept that changes everything
Decision rights are the explicit assignment of authority to decide specific types of question. They answer the question: who is authorised to make this decision, and under what conditions must it be escalated?
Without explicit decision rights, every governance interaction becomes a negotiation. Delivery teams do not know which decisions need board review. Domain architects do not know which decisions they can make locally. The board does not know which items deserve its attention. The result is the pattern from the opening story: everything comes to the board, little gets decided, and delivery teams learn to route around the process.
A practical decision-rights matrix assigns each category of decision to one of three levels.
- Board decides. The Architecture Board has authority to approve, reject, or conditionally approve. Examples: target-state changes, major exceptions, cross-domain integration conflicts, release conditions with enterprise consequence.
- Domain architect decides, board is informed. The domain architect has authority to make the decision within defined boundaries. The board receives a summary for awareness and can intervene only if the decision crosses the board-level threshold. Examples: domain-specific design choices, minor deviations with bounded impact.
- Delivery team decides within guardrails. The delivery team makes the decision within published principles, standards, and patterns. No escalation is required unless the decision falls outside the guardrails. Examples: technology configuration within approved platforms, UI design choices, implementation sequencing within an approved work package.
This three-level structure is simple but powerful. It means delivery teams can predict which decisions need board review, domain architects know their authority boundaries, and the board reserves its time for decisions that genuinely need enterprise-level attention.
“Good decision rights are about predictability. If a delivery lead cannot predict whether a decision needs board review, the rights are not clear enough.”
Working definition derived from G21I governance guidance - Decision rights design
Predictability is the practical test. If delivery teams have to guess, they will either over-escalate (clogging the board) or under-escalate (creating invisible divergence). Neither outcome is acceptable.
53.5 Meeting cadence and standing agenda
The board's meeting cadence should match the enterprise's decision pace. Too frequent and the board becomes a status meeting. Too infrequent and decisions queue up, creating delay that delivery teams resent.
For most medium-to-large enterprises, a fortnightly cadence works well. The standing agenda should be structured to protect decision time.
- Decision items (60% of time). Items that require a board decision. Each item has a named proposer, a decision paper circulated in advance, and a clear question for the board to answer.
- Exception review (20% of time). Active exceptions and dispensations. The board reviews status, expiry dates, and compensating controls. Any exception approaching its expiry without resolution is escalated.
- Information items (15% of time). Domain architect decisions reported for board awareness. The board can escalate any item to decision status if it identifies a cross-enterprise concern.
- Forward look (5% of time). Upcoming decisions that will need board attention in the next 4 to 8 weeks, allowing members to prepare.
The chair's most important discipline is protecting decision time. If information items expand to consume the meeting, the board becomes a briefing forum rather than a decision body.
53.6 Diagnostic signs: too much or too little
Signs the board is reviewing too much. Decision items routinely carry over between meetings because there is not enough time. Delivery teams reclassify work to avoid triggering board review. The board rarely says "this is not a board-level item" and returns it to the appropriate level. Board meetings feel like status updates rather than decision sessions.
Signs the board is reviewing too little. Cross-domain divergence is discovered months after the fact. Major exceptions are handled informally without board awareness. Delivery teams make enterprise-level choices without realising they have crossed a decision-rights boundary. The board meets infrequently and struggles to find agenda items.
Both patterns indicate a decision-rights problem. The remedy is not more or fewer meetings but clearer boundaries about what belongs at each decision level.
London Grid Distribution: board design
London's Architecture Board is designed around the G21I framework with explicit decision rights tailored to a regulated utility context.
Composition (8 members)
- Chief architect (chair)
- Head of customer operations (business)
- Head of network operations (business)
- Data governance lead
- Chief information security officer
- Programme director (delivery)
- Technology director
- Regulatory affairs representative
Decision rights
- Board decides: target-state changes affecting more than one domain, transition-state acceptance, exceptions with cross-domain impact, release conditions for enterprise milestones, principle interpretation precedents.
- Domain architect decides, board informed: domain-specific design choices within approved target state, minor deviations with compensating controls in place, technology selection within approved platform catalogue.
- Delivery team decides within guardrails: implementation sequencing within approved work packages, configuration choices within approved platforms, local user-interface design.
Meeting cadence
Fortnightly, 90 minutes. Decision papers circulated 48 hours in advance. Decision log published within 24 hours of each meeting. Escalation to the investment committee when a decision has budgetary consequence above the architecture authority threshold.
Regulatory interface
Because London operates under Ofgem regulation, the board's decision log feeds into regulatory submissions. Architecture decisions that affect the ED3 business plan, data publication obligations, or cyber resilience commitments are tagged for regulatory traceability. The regulatory affairs representative ensures this traceability is maintained.
An Architecture Board reviews 50 items per quarter but makes clear decisions on only 5. What is the most likely problem?
A delivery team adopts a non-standard authentication approach without consulting the Architecture Board. The deviation is discovered six months later. What does this suggest about decision rights?
A board charter says the board will 'review and advise on all architecture matters.' What is wrong with this scope statement?
London's Architecture Board has a regulatory affairs representative as a member. Why?
Key takeaways
- The Architecture Board from G21I is a coherence protector, not a universal review body.
- Board composition should include business, technology, delivery, and architecture representation, typically 6 to 10 members.
- Decision rights must be explicit: board decides, domain architect decides with board informed, or delivery team decides within guardrails.
- Meeting cadence should protect decision time. A fortnightly 90-minute meeting with a structured agenda is a common pattern.
- A board that reviews everything but decides little is scoped too broadly. A board that rarely meets is scoped too narrowly.
Standards and sources cited in this module
The TOGAF Standard, 10th Edition (C220)
Part 5, Governance and Architecture Board guidance
The core standard covering board design, decision rights, and governance behaviour.
Full guide
Primary guide defining the Architecture Board, its composition, remit, and governance practice.
G184, Leader's Guide to Establishing and Evolving an EA Capability
Full guide
Leadership guidance on governance structure as a capability component.
ED3 Business Plan Guidance, Ofgem
Full guidance
Regulatory context for the London board design and decision traceability requirements.
You now understand the Architecture Board as a selective decision forum with explicit rights and bounded scope. The next question is how compliance reviews, waivers, and architecture contracts protect integrity without becoming rigid. That is Module 54.
Module 53 of 64 · EA Capability and Governance