Direct Answer
TOGAF architecture governance has three operational mechanisms: the Architecture Review Board (ARB), Architecture Decision Records (ADRs), and the Phase G compliance review process. The ARB is the governance body that approves architecture decisions and reviews proposed deviations from standards. ADRs are the lightweight artefacts that capture individual decisions — what was decided, why, what alternatives were considered, and the consequences. Phase G (Architecture Governance) is the ongoing compliance monitoring process that checks implemented solutions against the approved architecture. In Sparx EA, ADRs live in a Requirements package with structured tagged values; Phase G compliance artefacts are linked directly to the architecture elements they govern. AI tools (Copilot, Kernaro) operating via EA GraphLink Interface B (MCP) can query decision history, find precedent decisions, and check proposed changes against existing constraints — making the ARB faster and more informed.
The TOGAF Governance Framework in Practice
Governance is the TOGAF capability that organisations most frequently implement badly. The common failure modes are:
- An ARB that meets monthly, reviews PowerPoint decks, and produces no structured decision record
- ADRs that are Word documents in a SharePoint folder that 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 of these failures has a structural cause, and Sparx EA addresses each one.
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, the ARB becomes a discussion forum where nothing is formally decided.
ARB Charter components:
Authority. What decisions require ARB approval? Typically: new technology additions to the approved SBB library; proposed deviations from architecture standards; cross-domain integration architecture; 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: Chief Architect (chair), domain architects (application, data, technology, security), senior business representative, CTO or equivalent. External vendors should not sit on the ARB — they may be invited to present but not to vote.
Cadence. How often does the ARB meet? For an active architecture programme, fortnightly is appropriate. For a steady-state programme, monthly. The ARB should have a defined quorum rule — decisions cannot be made without a minimum attendance.
Review triggers. What triggers an ARB review request? Typically: project architecture assessment submission; proposed SBB addition or deprecation; proposed exception to an architecture standard; Phase G compliance finding that requires 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 architecture decision made during TOGAF ADM phases — produces an ADR.
Sparx EA implementation for ADRs:
Create a Architecture Decision Records package under your governance root. Each ADR is a Requirement element (or a custom < stereotype element) with the following tagged values:
adr_id— unique identifier (ADR-2026-047)decision_date— date the decision was madedecision_maker— ARB reference or individual architect if below ARB thresholdstatus— Proposed / Accepted / Deprecated / Supersededcontext— the architectural situation that required a decision (element notes field)decision— what was decided (the main element name or notes field)rationale— why this decision was made (tagged value or notes)alternatives_considered— what options were evaluated (tagged value)consequences— positive and negative consequences of the decisionrelated_adrs— links to ADRs this decision depends on or supersedesreview_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 compliance review, the assessor queries the model: “What ADRs govern the proposed solution’s integration architecture?” The query returns the relevant ADRs. The compliance check is whether the proposed solution conforms to those ADRs. Without ADRs in the model, this check is manual and unreliable.
The Phase G Compliance Review Process
TOGAF Phase G is Architecture Governance — the ongoing monitoring of implementation against the approved architecture. Phase G is not a one-time activity; it runs continuously during solution delivery.
What Phase G reviews:
- Does the implemented solution conform to the approved architecture (the ADD and its component artefacts)?
- Does it use approved SBBs from the building block library?
- Does it comply with relevant ADRs?
- Are there any deviations that need formal dispensation or architecture change request?
Sparx EA implementation of Phase G artefacts:
Create a Compliance Reviews package under your governance root. Each compliance review is modelled as a package containing:
- A link to the solution architecture being reviewed
- A compliance checklist — a set of Constraint elements in Sparx EA, each linked to the relevant ADR or architecture standard
- A finding set — Requirements elements for each compliance gap found, tagged with severity (Critical / Major / Minor), resolution required, and responsible owner
- A dispensation request — if the solution cannot comply with a standard and the deviation is justified, a formal dispensation element is created, ARB-approved, and linked from the solution architecture
The compliance review package is not a Word document. It is a model package that creates traceable relationships between the implemented solution and the governance framework that governs it.
Phase G cadence: Compliance reviews should occur at architecture significant milestones — solution design approval, end of build, and post-implementation. For complex programmes, a lightweight architecture checkpoint at each sprint review can catch governance issues earlier.
How AI Tools Support ARB Work
This is where governance gets genuinely interesting. When ADRs, building block approvals, and compliance findings are all in Sparx EA with consistent structure and tagged values, AI tools operating via EA GraphLink Interface B (MCP) can do work that previously required manual research.
Querying decision history. An architect preparing an ARB submission can ask the AI assistant: “What decisions have previously been made about event streaming architecture?” The AI queries the ADR package, finds relevant ADRs by keyword and relationship, and returns a structured summary. Without this capability, finding relevant precedent decisions means searching a SharePoint folder manually — a process that is unreliable and time-consuming.
Finding precedent decisions. Before an ARB review, the ARB chair can ask: “Have we previously approved a deviation from the API Gateway standard, and under what conditions?” The AI returns the relevant ADRs with their context, rationale, and consequences. The ARB can make an informed decision based on documented precedent rather than collective memory.
Checking proposed changes against constraints. When a project team submits an architecture assessment, the AI can pre-check: “Does the proposed technology stack include any elements not in the approved SBB library?” or “Does the proposed integration pattern conflict with any existing ADRs?” These pre-checks catch obvious governance issues before the ARB meeting, making the review faster and more focused on genuinely complex decisions.
Generating compliance reports. Phase G compliance reports can be generated from the model: “List all compliance reviews completed in the last quarter, with findings by severity and resolution status.” This is a SQL query against the Sparx EA repository, surfaced via the MCP interface to an AI assistant or via Interface A to a Power BI dashboard.
The Governance Maturity Progression
Most organisations start governance at Level 1: informal, document-based, reactive. The path to Level 3 (systematic, model-based, proactive) typically takes 12–24 months. The Amplify engagement accelerates this progression by delivering the Sparx EA configuration, process design, and team capability to reach Level 3 governance in a structured programme.
Level 1 — Informal: 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; 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 compliance artefacts in the model; AI tools active.
Level 4 — Automated: Governance checks partially automated via MCP queries; compliance dashboards in Power BI; AI assistant supports ARB preparation; deviation detection is proactive.
Frequently Asked Questions
Q: How is an ADR different from a risk register entry? A: 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, and in that case the ADR should reference the corresponding risk register entry. They are different governance instruments for different purposes. Both belong in Sparx EA.
Q: What is the right format for an ADR? A: The Michael Nygard format is the standard: Context, Decision, Status, Consequences. The Sparx EA tagged value structure maps directly to this format. Keep ADRs short — an ADR should fit on one page. If the decision requires extensive background, link to a separate architecture assessment document. The ADR itself should be a quick read.
Q: How do we handle decisions made before we established an ADR process? A: Backfill the most important historical decisions. Focus on decisions that are still active governance constraints — technology standards, integration patterns, security controls. Do not try to document every historical decision; document the ones that still govern current architecture choices. Model them with decision_date set to the actual decision date and status = Accepted.
Q: What is a dispensation and when is one needed? A: A dispensation is formal ARB approval for a project to deviate from an architecture standard. It is needed when a project cannot comply with an approved standard for a legitimate reason (e.g., 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.
Q: How do we avoid the ARB becoming a bottleneck? A: Three mechanisms. First, define clear thresholds in the charter — small decisions below the threshold do not go to the ARB. Second, maintain the building block library so that approved SBB selections do not need ARB review. Third, use AI tools to pre-check submissions so that 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 the Phase G compliance review be run by someone other than the architect who designed the solution? A: Yes, and ideally it should be. Independent compliance review is more rigorous than self-assessment. In large organisations, 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 be involved in Phase G reviews for solutions they were involved in designing — that is a conflict of interest.
Q: How does Sparx EA’s MDG Technology extension support ADR governance? A: MDG Technology allows you to define custom stereotypes (<), tagged value sets (adrid, status, decisiondate, etc.), and diagram types for governance views. The MDG extension ensures that ADR elements are consistently structured across the entire team — no one can create an ADR without the required tagged values. It also enables custom toolbox icons, making ADR creation a one-click operation rather than a multi-step configuration exercise.
Q: What is the relationship between TOGAF governance and COBIT or ISO 42010? A: TOGAF governance is focused on architecture practice governance — ARBs, ADRs, compliance reviews. COBIT is broader IT governance — including risk, performance, and strategic alignment. ISO 42010 is the international standard for architecture description — it defines the structure of architecture frameworks and viewpoints. In practice, a mature EA programme is TOGAF-compliant for ADM process, uses ISO 42010 terminology for artefact description, and aligns with COBIT for IT governance integration. Sparx EA supports all three through its flexible metamodel.
Next Step
If your ARB produces decisions that are not recorded, or your ADRs live in documents no one can find, or your Phase G compliance process is theoretical — the Amplify engagement is designed for this situation. We deliver the ARB charter, the Sparx EA ADR structure, the MDG Technology governance extensions, and the AI query capability that makes governance visible and actionable.
