Insight · TOGAF governance

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

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

Architecture governance is the TOGAF capability organizations most often implement badly. Intent is rarely the problem. The mechanisms live in slide decks and SharePoint folders instead of the model, so nobody can find a past decision or check a solution against it. Done well, governance runs on three connected mechanisms: the Architecture Review Board (ARB), Architecture Decision Records (ADRs) and Phase G compliance reviews. All three can live in Sparx EA.

Moving governance into the model has a second benefit now. When decisions, standards and findings are structured model content, AI can do the preparation work that used to consume architects’ time: finding precedent, pre-screening submissions, drafting records and compiling compliance reports. The judgment stays with the architects and the board. This guide covers how to set up each mechanism in Sparx EA and what changes when the work is AI-augmented.

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 and is never run
Architecture standards that are documented and 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 checked.

Architecture Review Board: charter, cadence and scope

The ARB 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. Sending every technical decision to the ARB is micromanagement. The charter specifies thresholds.

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

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

Review triggers. A project architecture assessment submission, a proposed SBB addition or deprecation, a proposed exception to a standard, or a Phase G compliance finding that needs a governance decision.

Decision record. Every ARB decision is recorded in an ADR in Sparx EA. 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 the TOGAF ADM phases, produces an ADR.

Create an Architecture Decision Records package under your governance root. Each ADR is a Requirement element, or an element with a custom «ADR» stereotype, 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 the 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 an ArchiMate Influence or Association relationship. That creates a queryable map: for any element in the model, you can find every ADR that governs it.

The ADR as a compliance instrument. During a Phase G review, the assessor asks which 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 Implementation Governance: ongoing oversight of implementation against the approved architecture. It runs throughout delivery. In Sparx EA, run it as a repeatable sequence with its results in the model.

Link the solution under review

Create a Compliance Reviews package under the governance root and link it 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 whether the solution conforms to the approved architecture, uses approved SBBs and complies with the 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 instead of buried in meeting notes.

Raise dispensations where justified

If the solution 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 model content that creates traceable relationships between the implemented solution and the framework that governs it. Cadence: run reviews at architecture-significant milestones, such as solution design approval, end of build and post-implementation, with a lightweight checkpoint at sprint reviews on complex programs to catch issues earlier.

Running governance AI-augmented

When ADRs, building block approvals and compliance findings live in Sparx EA with consistent structure, AI working in the repository can take on the preparation. Each task below changes in the same way: the architect states what is needed, AI does the searching and drafting, and the architect judges the result.

Finding precedent. Today an architect preparing a submission or chairing a review searches folders and asks colleagues whether the organization has decided this before. Working AI-augmented, they ask, for example, whether the board has previously approved a deviation from the API Gateway standard and under what conditions, and AI returns the relevant ADRs with their context, rationale and consequences. The skill is asking a precise question and reading the precedent critically, because the circumstances may have changed.

Pre-screening submissions. Today the chair or a domain architect reads each submission to find stack elements outside the approved SBB library or patterns that conflict with existing ADRs. Working AI-augmented, AI checks each submission against the SBB library, the standards and the ADRs before the meeting and lists what it finds. Automation checks completeness, people own correctness. Whether a flagged conflict is a real problem, or a case for a dispensation, is the board’s call.

Recording decisions and compiling reports. AI drafts the ADR from the meeting notes, links it to the elements it governs and sets its status for the chair to confirm. It can also compile the compliance picture for a period, with findings by severity and resolution status, from the model or into a dashboard in Prolaborate or Power BI.

Tools that help include Claude or GitHub Copilot with AI Power Tools for Sparx EA, and Kernaro Assist in the EA client. Which fits depends on who does the preparation and where they work.

The governance maturity progression

Many organizations start governance at Level 1, informal and document-based, and move up as the mechanisms move into the model:

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. AI-augmented: AI prepares precedent, pre-screens submissions and drafts records against the model; compliance dashboards are published; architects and the board spend their time on judgment.

For where your own practice sits, 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; 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, 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 so the ADR itself stays a quick read.

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

Backfill the historical decisions that are still active governance constraints, such as technology standards, integration patterns and security controls. AI can draft these from old documents and link them to the elements they govern, with decision_date set to the actual date and status set to Accepted. An architect confirms each one is still in effect and that the rationale is right.

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 the 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?

Define clear thresholds in the charter so small decisions skip the ARB. Maintain the building block library so approved SBB selections need no review. Pre-screen submissions, with AI checking them against ADRs, standards and the SBB library, so the ARB only sees issues that need human judgment. A bottlenecked ARB usually has too low a threshold, a thin building block library or no 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, because 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 such as «ADR», tagged value sets (adr_id, status, decision_date and so on) and governance diagram types. It keeps ADR elements consistently structured across the team, supports checks that required tagged values are filled in, and puts ADR creation in the toolbox. It also gives AI a defined structure to draft and check ADRs against.

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

TOGAF governance focuses on architecture practice: ARBs, ADRs and 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 often follows TOGAF for the ADM process, uses 42010 terminology for describing artifacts, and aligns with COBIT for IT governance. Sparx EA supports all three through its flexible metamodel.

How we help

If your ARB makes decisions that are never recorded, your ADRs live in documents no one can find, or your Phase G process is theoretical, we can help. We can write the ARB charter with you, set up the ADR structure and governance MDG in your repository, and teach your architects and board to run governance AI-augmented. If you are earlier on, Paralysis to a Plan turns the governance question into a plan. See also AI-augmented governance.

Decisions made but never recorded?

We can teach your architects to run the ARB, ADRs and Phase G reviews AI-augmented on your own repository, and mentor them until it sticks. Or we can set up the governance structure, MDG and model for you and hand them over.

Book a call

Keep reading