Direct Answer: An Architecture Review Board is a governance forum that reviews and approves technology and architecture decisions above a defined threshold of scope, cost, or strategic impact. Its mandate is to enforce architectural standards, reduce technology risk, and ensure new investments are aligned with the target state architecture. In Sparx EA, the ARB is supported by the repository — architecture decisions are documented as elements, review statuses are tracked via tagged values, and approved patterns are published from the shared model. The most common ARB failure mode is becoming a bottleneck: when every decision goes to the ARB, velocity collapses and project teams find ways around the process. Effective ARBs are selective, well-structured, and quick to return decisions. Sparx EA and Kernaro Assist can materially reduce ARB review time by making the impact analysis step — “what does this decision affect?” — fast rather than slow.
Key Takeaways
- The ARB mandate matters more than the ARB structure. Define clearly what goes to the ARB and what does not — and enforce the boundary.
- Sparx EA supports ARB governance through Architectural Decision Records (ADRs), review status tracking, and architecture principle documentation — all as first-class model elements.
- The most damaging ARB anti-pattern is scope creep: when the ARB reviews everything, it slows everything. A tiered review model prevents this.
- AI tooling (Kernaro Assist, Kernaro AI Hub) changes the ARB workflow by accelerating impact analysis — architects can present “here is what this decision affects” in minutes rather than days.
- Amplify builds the ARB governance model alongside the Sparx EA repository structure that supports it.
What an ARB Is and Why EA Teams Need One
An Architecture Review Board is a governance mechanism, not a committee meeting. The distinction matters. A committee exists to discuss and share information. A governance forum exists to make or ratify decisions according to a defined authority model.
An ARB’s governance mandate answers these questions:
- What decisions require ARB review? Technology investment above a cost threshold (e.g., >£50K), new vendor or platform introductions, changes to the integration architecture, deviations from approved technology standards.
- Who has authority to decide? The ARB vote? The Chief Architect’s single-decision authority? Delegated authority for specific domain types?
- What does ARB approval mean? Architects approved the proposal. What is the mechanism for projects that bypass review? What happens to unapproved deviations discovered post-implementation?
Without clear answers to these questions, the ARB is advisory at best and performative at worst. Projects that know the ARB has no enforcement mechanism treat it as a box-ticking exercise. The governance discipline that makes an ARB valuable is institutional: it requires sponsorship from a CTO, CIO, or equivalent who has the authority to enforce the mandate.
Defining the Governance Mandate
The ARB mandate needs a tiered scope model to avoid becoming a universal bottleneck:
Tier 1: Mandatory ARB review. New strategic platform decisions, vendor contract commitments above a defined threshold, changes to core integration architecture, deviations from approved technology standards. Full ARB review with voting quorum.
Tier 2: Architecture lead sign-off. Mid-range technology decisions (specific tool selections within an approved category, minor integration extensions, infrastructure changes within approved platforms). Delegated to a chief or lead architect without requiring full ARB convening.
Tier 3: Self-serve with documented rationale. Routine decisions within approved parameters — using an approved language and framework, selecting from an approved vendor list, implementing a documented integration pattern. Project teams document their decision, reference the approved standard, and proceed. No ARB review required; pattern compliance is verified at delivery.
This tiered model keeps the ARB focused on genuinely significant decisions. Projects move faster at Tier 3 because they are working within pre-approved guardrails rather than waiting for a review slot. The ARB’s time is reserved for decisions that genuinely require strategic judgment.
ARB Structure: Membership, Quorum, Cadence
Membership. The ARB should include the chief or lead architect (chair), domain architects (application, data, security, infrastructure), a representative from IT delivery (typically a programme or delivery manager), and a business representative with technology sponsorship accountability (CTO, CIO, or their delegate). Do not populate the ARB with too many members — seven is a practical maximum. Larger boards produce longer meetings and diffuse accountability.
Quorum. Define the minimum attendance for a binding decision. A quorum of the chair plus two domain architects is typical for Tier 1 decisions. Document who may send a delegate and in what circumstances.
Cadence. Most ARBs run fortnightly. Monthly is too infrequent (projects stall waiting for reviews); weekly is too frequent (members struggle to attend consistently). Establish an exception process for urgent decisions — a documented email approval or an ad hoc convening procedure.
Submission process. Define what a well-formed ARB submission looks like: a brief (one to two pages), covering the decision being made, the options considered, the recommended option, the architectural impact assessment, alignment to technology standards, and the risk profile. Poor-quality submissions are the primary cause of extended ARB meetings. Enforce the template.
Sparx EA Repository Support for ARB Governance
Sparx EA is not just the modelling tool of record for the EA team — it is the system that supports ARB governance artefacts.
Architectural Decision Records (ADRs). In Sparx EA, architectural decisions can be modelled as elements (using a custom «ArchitecturalDecision» stereotype in your MDG profile) with tagged values for Decision Status (Proposed, Under Review, Approved, Superseded, Rejected), Decision Date, Owner, and linked alternatives considered. This creates a searchable, versioned record of architectural decisions that can be queried (“what decisions affect Application X?”) and referenced in future reviews.
Architecture Principles. The ARB’s governing standards — your approved technology list, integration architecture standards, security requirements — are documented as Architecture Principle elements in Sparx EA. ARB submissions can reference these principles. Deviation requests are linked to the specific principle being deviated from, with the justification documented.
Review status tracking. Projects seeking ARB approval create an ARB submission package in the repository. The review status is tracked on the submission element. Approved submissions link to the design elements they govern. Rejected submissions carry the rejection rationale. Over time, this builds an institutional record of what the ARB has reviewed and decided — visible to all architects, searchable via Kernaro Assist or EA GraphLink queries.
Impact analysis support. When an ARB submission proposes a change to a component, Sparx EA’s relationship traversal — combined with Kernaro Assist — makes impact analysis faster. “What is affected if we replace this integration middleware?” is a query the EA repository can answer in minutes if the connectivity model is accurate. This is one of the highest-value contributions the repository makes to ARB quality.
How AI Tooling Changes the ARB Workflow
The most time-consuming part of an ARB review is impact analysis: determining what the proposed decision affects, which systems depend on the component under consideration, which architectural standards are relevant, and what risks the proposal introduces.
In a Level 2 or 3 EA practice, impact analysis is a manual exercise. An architect spends two to four days compiling the affected-systems list, reviewing dependencies, and mapping the proposal against the technology radar. This is the delay that makes ARBs feel slow.
In a Level 4 or 5 EA practice, with a machine-readable repository and EA GraphLink or Kernaro Assist available, the impact analysis step takes hours. The query “which applications have a direct dependency on the Payment Processing middleware being replaced?” runs against the repository in seconds. The results — provided MDG and connectivity data is accurate — give the ARB chair a current, reliable impact list to present at review.
Kernaro AI Hub extends this to business stakeholders. A business sponsor on the ARB can query — “What capabilities depend on this system?” — and receive a structured answer from the live repository without requiring an architect to compile a briefing. The ARB becomes less dependent on architect availability for information that the repository can provide directly.
ARB Anti-Patterns
1. Universal scope. When every technology decision — including minor tool selections and routine infrastructure changes — goes to the ARB, the forum becomes a bottleneck and teams work around it. Enforce the tiered scope model.
2. Retrospective review. When projects present decisions that have already been implemented, the ARB becomes a rubber stamp or a source of post-hoc conflict. Review happens before commitment, not after. If this is difficult to enforce, examine whether the submission process is fast enough for project timelines.
3. No enforcement mechanism. An ARB with advisory-only authority depends entirely on team goodwill. When project pressure increases, unenforced governance is the first casualty. Ensure the ARB has a named executive sponsor with authority to enforce the mandate.
4. Process over judgment. When the ARB spends more time reviewing submission template compliance than evaluating architectural risk, the process is blocking the purpose. Submission templates should be lightweight enough to complete in a day and thorough enough to enable informed review. Calibrate regularly.
5. No feedback loop. When ARB decisions are made but never followed up — whether the project implemented what was approved, whether the risk materialised, whether the decision aged well — the ARB cannot learn and improve. Close the loop: a brief post-implementation review on significant decisions is worth the effort.
FAQ
What is an Architecture Review Board and what does it do? An Architecture Review Board (ARB) is a governance forum that reviews and approves technology and architecture decisions above a defined threshold of scope, cost, or strategic impact. It enforces architectural standards, reduces technology risk, and ensures investments align with the target state architecture. The ARB does not make every technology decision — it governs the significant ones according to a defined mandate.
What decisions should go to the ARB? A tiered model works best. Tier 1 (mandatory ARB): new strategic platforms, vendor commitments above a defined threshold, deviations from approved standards, changes to core integration architecture. Tier 2 (architecture lead sign-off): mid-range tool selections and minor architectural extensions. Tier 3 (self-serve with documented rationale): decisions within pre-approved guardrails. The boundary between tiers should be defined clearly in the ARB charter and enforced consistently.
How does Sparx EA support ARB governance? Sparx EA supports ARB governance through Architectural Decision Record elements (with review status, decision date, and rationale as tagged values), Architecture Principle documentation, and submission package tracking in the repository. This creates a versioned, searchable institutional record of architectural decisions. Combined with EA GraphLink, the decision record can be queried via AI tools — enabling architects and stakeholders to ask “what decisions govern this component?” and receive structured answers.
How do I prevent the ARB from becoming a bottleneck? Three measures: enforce a tiered scope model that keeps routine decisions out of the ARB; make the submission template lightweight enough to complete in a day; and set a target decision time (typically two weeks from submission to decision for standard Tier 1 reviews). When teams consistently wait longer than the target, investigate whether scope is too broad, membership attendance is too low, or submission quality is causing extended discussion.
What is the minimum effective ARB structure? A chief or lead architect as chair, two to four domain architects, one delivery or programme representative, and one business sponsor or delegate. Quorum: chair plus two domain architects for binding decisions. Cadence: fortnightly. Maximum effective membership: seven. Larger boards dilute accountability and extend meetings. Smaller boards risk missing critical domain expertise.
How does Kernaro Assist change the ARB review process? Kernaro Assist can dramatically reduce the time required for impact analysis in ARB review preparation. Queries like “what applications depend on this integration middleware?” or “which projects have active dependencies on this platform?” can be answered from the repository in minutes if the model is well-governed. This reduces the typical two-to-four day manual impact analysis step to hours, which accelerates ARB review cycle time and improves the quality of information available to reviewers.
Should the ARB include business representatives? Yes. An ARB composed entirely of technical architects tends to optimise for technical standards and miss business impact considerations. At minimum, one business representative — a CIO, CTO, or senior digital leader with technology decision authority — should be a standing member. Their role is not to evaluate technical merit but to ensure that architectural decisions are evaluated in the context of business priorities and risk tolerance. Kernaro AI Hub can support their participation by giving them direct access to architecture impact information without requiring technical mediation.
How do we handle ARB decisions on projects that are already in flight? For projects already in flight when the ARB is established, conduct a one-time retrospective review of in-flight technology decisions above the Tier 1 threshold. Document findings as ADR elements in the repository — approved as-is, approved with conditions, or flagged for remediation. This creates the baseline record without requiring retrospective sign-off that implies historical governance that did not exist. Going forward, the ARB scope applies to new decisions and significant changes to in-flight architecture.
Build the Governance Capability That Makes Architecture Matter
Sparx Services’ Amplify offering builds ARB governance structures alongside the Sparx EA repository capabilities that support them — decision records, principle documentation, impact analysis tooling, and Kernaro Assist for accelerated review preparation.
A well-designed ARB is one of the most powerful levers for making EA practice matter in an organisation. Amplify helps you build one that works.
