Insight · TOGAF governance

TOGAF Architecture Governance with Sparx EA: ARBs, ADRs and Compliance Reviews

Q: How is an ADR different from a risk register entry?

An ADR records a decision and its rationale; it is authoritative and forward-looking. A risk register entry records an uncertainty and its mitigation; it is monitoring-focused. Some decisions create residual risks, in which case the ADR should reference the corresponding risk register entry. They are different governance instruments for different purposes, and both belong in Sparx EA.

Q: How do we avoid the ARB becoming a bottleneck?

Three mechanisms. Define clear thresholds in the charter so small decisions do not go to the ARB. Maintain the building block library so approved SBB selections need no review. And use pre-screening so the ARB only sees issues that require human judgment. An ARB that is a bottleneck has either too low a threshold, an inadequate building block library, or insufficient pre-screening.

Q: Can a Phase G compliance review be run by someone other than the solution's architect?

Yes, and ideally it should be. Independent compliance review is more rigorous than self-assessment. In large organizations a dedicated governance architect runs Phase G reviews; in smaller teams, a peer architect from a different domain is appropriate. The ARB chair should not run Phase G reviews for solutions they helped design, to avoid a conflict of interest.

By Sparx Services · December 24, 2025 · 9 min read

Architecture governance is the TOGAF capability organizations most often implement badly — not for lack of intent, but because the mechanisms live in slide decks and SharePoint folders instead of the model. Done well, governance runs on three connected mechanisms, and all three can live in Sparx EA.

Key takeaways

The Architecture Review Board (ARB) approves decisions and reviews deviations — it needs a charter defining authority, composition, cadence, and triggers, or it becomes a discussion forum.
Architecture Decision Records (ADRs) capture each decision — context, decision, rationale, alternatives, consequences — as structured model elements, not lost Word files.
Phase G compliance reviews check implemented solutions against the approved architecture, modeled as packages that link findings to the elements they govern.
When ADRs and compliance findings carry consistent structure, the model becomes queryable — precedent decisions and standards conflicts surface in minutes.

The common failure modes

Governance fails in recognizable ways:

An ARB that meets monthly, reviews PowerPoint decks, and produces no structured decision record
ADRs that are Word documents in a SharePoint folder no one can find
A Phase G process that exists on paper but is never actually run
Architecture standards that are documented but not enforced

Each failure has a structural cause, and Sparx EA addresses each one by moving the artifact into the model where it can be linked, queried, and enforced.

Architecture Review Board: charter, cadence and scope

The ARB is not a committee — it is a decision-making body with defined authority, scope, and process. Without a charter that specifies these, it becomes a forum where nothing is formally decided. A good charter pins down:

Authority. What decisions require ARB approval? Typically: new technology additions to the approved SBB library, proposed deviations from standards, cross-domain integration architecture, and strategic platform choices. Not every technical decision needs ARB approval — that is micromanagement, not governance. The charter specifies thresholds.

Composition. Who sits on the ARB? Typically the Chief Architect (chair), domain architects (application, data, technology, security), a senior business representative, and the CTO or equivalent. External vendors should not sit on the ARB — they may be invited to present but not to vote.

Cadence. For an active architecture program, fortnightly is appropriate; for steady state, monthly. Define a quorum rule — decisions cannot be made without minimum attendance.

Review triggers. What prompts a review request? A project architecture assessment submission, a proposed SBB addition or deprecation, a proposed exception to a standard, or a Phase G compliance finding requiring a governance decision.

Decision record. Every ARB decision must be recorded in an ADR in Sparx EA. This is not optional — undocumented ARB decisions are unenforceable.

Architecture Decision Records in Sparx EA

ADRs are the unit of governance. Each ARB decision — and each significant decision made during TOGAF ADM phases — produces an ADR.

Create an Architecture Decision Records package under your governance root. Each ADR is a Requirement element (or a custom «ADR» stereotype element) carrying these tagged values:

adr_id — unique identifier (ADR-2026-047)
decision_date — date the decision was made
decision_maker — ARB reference, or individual architect if below ARB threshold
status — Proposed / Accepted / Deprecated / Superseded
context — the situation that required a decision
decision — what was decided
rationale — why this decision was made
alternatives_considered — what options were evaluated
consequences — positive and negative consequences
related_adrs — links to ADRs this decision depends on or supersedes
review_date — when this decision should be reviewed

The element name should be the decision statement: "Use Azure Service Bus for all asynchronous messaging in the claims processing domain." Link each ADR to the architecture elements it governs using ArchiMate Association relationships. This creates a queryable map: given any element in the model, you can find all ADRs that govern it.

The ADR as a compliance instrument. During Phase G review, the assessor asks the model "what ADRs govern the proposed solution's integration architecture?" and the compliance check is whether the solution conforms to them. Without ADRs in the model, that check is manual and unreliable.

The Phase G compliance review process

TOGAF Phase G is Architecture Governance — ongoing monitoring of implementation against the approved architecture. It is not a one-time activity; it runs continuously during delivery. In Sparx EA, run it as a repeatable sequence rather than a one-off document.

Link the solution under review

Create a Compliance Reviews package under the governance root and add a link to the solution architecture being reviewed, so the review traces back to the live design.

Build the compliance checklist

Add a set of Constraint elements, each linked to the relevant ADR or architecture standard. The checklist asks: does the solution conform to the approved architecture, use approved SBBs, and comply with applicable ADRs?

Record findings with severity

Capture each compliance gap as a Requirement element tagged with severity (Critical / Major / Minor), the resolution required, and the responsible owner — so findings are tracked, not buried in meeting notes.

Raise dispensations where justified

If the solution genuinely cannot comply and the deviation is justified, create a formal dispensation element, get ARB approval, and link it from the solution architecture. Dispensations should be time-limited.

The compliance review package is a model package, not a Word document. It creates traceable relationships between the implemented solution and the governance framework that governs it. Cadence: run reviews at architecture-significant milestones — solution design approval, end of build, and post-implementation — with a lightweight checkpoint at each sprint review on complex programs to catch issues earlier.

How AI tools support ARB work

This is where governance gets genuinely useful. When ADRs, building block approvals, and compliance findings all live in Sparx EA with consistent structure and tagged values, AI tools that can query the repository can do work that previously required manual research.

Querying decision history. An architect preparing an ARB submission can ask: "What decisions have we made about event streaming architecture?" The tool queries the ADR package, finds relevant ADRs by keyword and relationship, and returns a structured summary — instead of an unreliable manual search through a SharePoint folder.

Finding precedent decisions. Before a review, the chair can ask: "Have we previously approved a deviation from the API Gateway standard, and under what conditions?" The relevant ADRs come back with their context, rationale, and consequences, so the ARB decides from documented precedent rather than collective memory.

Checking proposed changes against constraints. When a team submits an architecture assessment, a pre-check can flag "does the proposed stack include any elements not in the approved SBB library?" or "does the proposed integration pattern conflict with any existing ADRs?" These catch obvious issues before the meeting, keeping reviews focused on genuinely complex decisions.

Generating compliance reports. "List all compliance reviews completed last quarter, with findings by severity and resolution status" is a query against the structured model, surfaced to an assistant or to a reporting dashboard.

The governance maturity progression

Most organizations start governance at Level 1 — informal, document-based, reactive — and the path to systematic, model-based governance typically takes 12 to 24 months. The progression runs:

Level 1 — Informal: an ARB exists but decisions are not formally recorded; no ADR structure; compliance reviews are ad hoc.
Level 2 — Structured: ADRs documented in Word or SharePoint; the ARB has a charter; compliance reviews happen at project milestones.
Level 3 — Model-based: ADRs in Sparx EA with tagged values and relationships; ARB decisions queryable; Phase G artifacts in the model.
Level 4 — Assisted: governance queries run against the model; compliance dashboards published; AI tools support ARB preparation and proactive deviation detection.

For where your own practice sits on this curve, the glossary entry on architecture maturity is a useful frame.

Frequently asked questions

How is an ADR different from a risk register entry?

An ADR records a decision and its rationale — authoritative and forward-looking. A risk register entry records an uncertainty and its mitigation — monitoring-focused. Some decisions create residual risks, in which case the ADR should reference the corresponding risk register entry. They are different governance instruments for different purposes, and both belong in Sparx EA.

What is the right format for an ADR?

The Michael Nygard format is the standard: Context, Decision, Status, Consequences. The Sparx EA tagged value structure maps directly to it. Keep ADRs short — ideally one page. If a decision needs extensive background, link to a separate architecture assessment document; the ADR itself should be a quick read.

How do we handle decisions made before we established an ADR process?

Backfill the most important historical decisions — the ones that are still active governance constraints, such as technology standards, integration patterns, and security controls. Do not try to document every historical decision; capture the ones that still govern current choices, with decision_date set to the actual date and status = Accepted.

What is a dispensation and when is one needed?

A dispensation is formal ARB approval for a project to deviate from a standard. It is needed when a project cannot comply for a legitimate reason — a vendor-imposed constraint, a regulatory requirement that conflicts with the standard, or a time-critical delivery that cannot wait for a standard to be updated. Dispensations should be time-limited and should trigger a review of the standard if they become common.

How do we avoid the ARB becoming a bottleneck?

Three mechanisms. First, define clear thresholds in the charter so small decisions skip the ARB. Second, maintain the building block library so approved SBB selections need no review. Third, use pre-screening so the ARB only sees issues that require human judgment. An ARB that is a bottleneck has too low a threshold, an inadequate building block library, or insufficient pre-screening.

Can the Phase G compliance review be run by someone other than the solution's architect?

Yes, and ideally it should be. Independent review is more rigorous than self-assessment. In large organizations a dedicated governance architect runs Phase G reviews; in smaller teams, a peer architect from a different domain is appropriate. The ARB chair should not run Phase G reviews for solutions they helped design — that is a conflict of interest.

How does Sparx EA's MDG Technology extension support ADR governance?

An MDG Technology lets you define custom stereotypes («ADR»), tagged value sets (adr_id, status, decision_date, and so on), and governance diagram types. It ensures ADR elements are consistently structured across the team — no one can create an ADR without the required tagged values — and supplies custom toolbox icons that make ADR creation a one-click operation.

What is the relationship between TOGAF governance and COBIT or ISO 42010?

TOGAF governance focuses on architecture practice governance — ARBs, ADRs, compliance reviews. COBIT is broader IT governance, including risk, performance, and strategic alignment. ISO/IEC/IEEE 42010 is the international standard for architecture description, defining the structure of frameworks and viewpoints. A mature program is typically TOGAF-compliant for ADM process, uses 42010 terminology for artifact description, and aligns with COBIT for IT governance integration. Sparx EA supports all three through its flexible metamodel.

Where Sparx Services fits

If your ARB produces decisions that are not recorded, your ADRs live in documents no one can find, or your Phase G process is theoretical, Configure the Solution is designed for exactly this. We deliver the ARB charter, the Sparx EA ADR structure, the MDG Technology governance extensions, and the model-query capability that makes governance visible and actionable — part of how we take leaders from paralysis to a plan.

Decisions made but never recorded?

Talk to a practitioner about model-based governance on Sparx EA — ARB charter, ADR structure, and Phase G compliance that actually runs.

Book a call →

Keep reading