Section 1: Architecture Governance Overview
Architecture Governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It is a critical discipline that ensures architecture decisions are made consistently, transparently, and in alignment with enterprise strategy — and it is one of the highest-weighted topics in Part 2 of the OGEA-103 exam.
The system of controls over the creation, maintenance, monitoring, and use of all architectural components and activities in an organisation. It ensures that the architecture process produces value-aligned outcomes and that implementation conforms to agreed architectural intent. — The Open Group, TOGAF Standard
Governance vs. Management
A fundamental distinction that the exam explicitly tests is the difference between governance and management. They address different questions and operate at different levels of authority:
| Dimension | Architecture Governance | Architecture Management |
|---|---|---|
| Core question | "Is the right architecture being built?" | "Is the architecture being built right?" |
| Focus | Policy, control, accountability, authority | Planning, execution, delivery, resources |
| Time horizon | Strategic and ongoing | Project and operational |
| Decision level | Enterprise-level: approve, reject, mandate | Project-level: plan, assign, monitor |
| TOGAF body responsible | Architecture Board | Architecture team / project managers |
| Key artefact | Architecture Contract, Compliance Report | Statement of Architecture Work, Architecture Plan |
Part 2 scenarios frequently involve a situation where someone is "managing" a project while failing to "govern" it architecturally. The key signal is: if the question asks who decides whether to approve or reject an architectural approach, the answer involves governance. If it asks who delivers an architecture work package, it involves management. Never confuse the Architecture Board (governance body) with the architecture team (management body).
Why Governance Is Critical for OGEA-103 Part 2
Architecture Governance is the topic most often tested through scenario-based questions in Part 2 because it requires applied judgment: you must decide which governance action is most appropriate given specific organisational circumstances. Part 2 scenarios commonly test your ability to:
- Determine whether a situation requires formal or informal compliance review
- Decide whether to grant, defer, or reject a dispensation request
- Identify what the Architecture Board should do when implementation diverges from approved architecture
- Select the correct type of Architecture Contract for a given engagement
- Recognise signs of governance failure and recommend corrective actions
Levels of Architecture Governance
TOGAF recognises that governance operates at multiple hierarchical levels within an enterprise. Each level has different scope, authority, and concerns:
The four levels interact vertically: enterprise governance sets the framework, portfolio governance aligns programmes to it, project governance enforces it through contracts and reviews, and operational governance ensures the running enterprise continues to conform to agreed standards.
Section 2: The Architecture Board
The Architecture Board is the body responsible for reviewing and maintaining the overall direction of architecture. It is the primary governance authority within the TOGAF framework and acts as the custodian of architecture quality and integrity across the enterprise.
A cross-functional, senior oversight body that is responsible for the review and maintenance of the overall direction, policies, and effectiveness of architecture governance within the enterprise. It provides the formal decision-making authority for architecture matters, including approvals, rejections, escalations, and dispensations.
Purpose and Responsibilities
The Architecture Board carries out a distinct set of responsibilities that are frequently enumerated in exam questions. These responsibilities span strategy, quality, and compliance:
- Provide the authoritative body for final architecture decision-making
- Ensure consistency between the enterprise's architecture and strategic business goals
- Manage risks associated with architecture decisions and implementation divergence
- Resolve architecture conflicts raised by projects or programme managers
- Approve new architecture standards, principles, and frameworks proposed by the architecture team
- Grant, defer, or reject dispensation requests from implementation projects
- Oversee the Architecture Compliance Review process and review compliance reports
- Monitor the health of the Architecture Repository and the currency of its content
- Ensure architecture activity aligns with business strategy changes over time
Board Composition
TOGAF recommends a diverse, cross-functional composition to ensure both strategic authority and domain expertise. A typical Architecture Board includes:
Architecture Board vs. Architecture Review Board
| Attribute | Architecture Board | Architecture Review Board (ARB) |
|---|---|---|
| Scope | Enterprise-wide, strategic | Project- or programme-level, operational |
| Mandate | Owns and approves the architecture governance framework | Conducts compliance reviews and reports to the Architecture Board |
| Membership | C-suite, senior architects, business sponsors | Enterprise architects, domain leads, project representatives |
| Key artefact | Architecture Governance Framework, Dispensation Decisions | Architecture Compliance Report |
| Meeting frequency | Monthly or quarterly | Per project milestone or on demand |
Board Powers and Operating Model
The Architecture Board holds four primary powers over implementation projects and architecture decisions:
- Approve: Grant formal approval to a proposed architecture or change, confirming it meets enterprise standards and principles
- Reject: Return a proposal for rework if it fails to meet governance criteria, with documented reasons and remediation guidance
- Grant Dispensation: Formally approve a controlled deviation from architecture standards, with conditions and an expiry date
- Escalate: Refer a decision up to a higher authority (e.g. executive committee) when the matter exceeds the Board's mandate or budget authority
Operating model: Most enterprises establish a formal meeting cadence (typically monthly), define quorum rules (e.g. at least 50% of members including the Chair), and operate a voting procedure (simple majority or consensus depending on the organisation's charter). Urgent matters may be handled via an out-of-meeting approval process with documented email sign-off.
Part 1 tests the four Board powers as a list (Approve / Reject / Grant Dispensation / Escalate). Part 2 applies them: a scenario will describe a project in conflict with architecture standards and ask what the Board should do. If there is a legitimate business reason to deviate, the answer is to grant a dispensation (not to approve or reject outright). If the conflict is strategic or exceeds Board authority, the answer is to escalate. Always match the Board action to the severity and nature of the non-conformance.
Section 3: Architecture Contracts
A joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Architecture Contracts set out the obligations of each party and provide the formal mechanism by which implementation projects commit to architectural conformance.
Architecture Contracts are a critical governance mechanism because they create a formal, documented commitment from implementation teams to comply with the approved architecture. Without them, governance becomes advisory rather than binding.
Types of Architecture Contracts
| Contract Type | Parties Involved | When Established | Typical Contents |
|---|---|---|---|
| Architecture Contract with Development Projects | Architecture team and project delivery team | Phase G (Implementation Governance) — at project initiation or handover | Architecture Definition Document references, compliance checkpoints, dispensation conditions, acceptance criteria |
| Architecture Contract with External Suppliers | Enterprise and third-party vendors or system integrators | During supplier onboarding or contract negotiation, referenced in Phase G | Technology standards adherence, API and integration conformance, data standards, audit rights, penalty clauses for non-conformance |
Architecture Contract Contents
A well-formed Architecture Contract contains the following elements. Knowing this list enables you to evaluate whether a contract is sufficient in Part 2 scenario questions:
- Scope and priority: What is being built, which architectural domains are in scope, and the relative priority of the work package
- Deliverables: The specific architecture artefacts and solution components that the project must produce or conform to
- Quality measures: Measurable criteria for architecture quality (e.g. performance SLAs, interoperability standards, security baseline)
- Fitness-for-purpose criteria: The conditions under which the delivered solution will be deemed architecturally acceptable
- Acceptance procedures: The review and sign-off process by which the Architecture Board or its delegate confirms compliance
- Architecture principles adherence: A statement of which principles apply and how the project will demonstrate adherence
- Dispensations granted: Any pre-approved deviations, with conditions and expiry dates
- Escalation path: The mechanism for resolving architecture disputes between the project and the governance body
Relationship to Statement of Architecture Work
The Statement of Architecture Work (SAW) — produced in Phase A — defines the scope and approach for the architecture development effort. The Architecture Contract — established in Phase G — governs the implementation of that architecture by delivery projects. They are complementary, not substitutes for each other:
| Statement of Architecture Work | Architecture Contract | |
|---|---|---|
| Phase | Phase A | Phase G |
| Purpose | Authorise the architecture development effort | Govern implementation conformance |
| Parties | Sponsor and architecture team | Architecture team and delivery/implementation team |
| Duration | Covers the ADM cycle | Covers the implementation project |
Part 2 scenarios frequently describe a project that was delivered without an Architecture Contract in place, then ask what governance failure occurred and how to remediate it. The correct answer: the absence of an Architecture Contract means there was no formal binding commitment from the implementation team — compliance review has no agreed baseline to measure against. Recommend that an Architecture Contract be established retroactively and a compliance review conducted immediately.
Section 4: Compliance Reviews
Architecture Compliance Reviews are formal assessments that determine whether an implementation project is conforming to its approved architecture. They are one of the most visible outputs of the Architecture Governance process and are conducted primarily in Phase G (Implementation Governance).
When Compliance Reviews Are Conducted
Reviews are not conducted only at the end of a project — they occur at multiple points in the implementation lifecycle:
- Project initiation: Before development begins, to confirm the project understands architectural constraints and has agreed to the Architecture Contract
- Design milestone: When detailed design is complete, to verify that design decisions conform to architectural intent before build begins
- Build milestone: Mid-construction review to catch divergence before rework becomes expensive
- Pre-deployment / UAT: Final conformance check before the solution enters production
- Post-implementation: To confirm the delivered solution matches what was agreed and to update the Architecture Repository
Types of Compliance Review
| Type | Trigger | Conducted By | Output |
|---|---|---|---|
| Formal Review | Mandatory milestone, significant spend threshold, or strategic project | Architecture Review Board (full panel) | Official Architecture Compliance Report; Board decision recorded in Governance Log |
| Informal Review | Routine project, low risk, or at project request for guidance | Lead Architect or small ARB subset | Advisory Compliance Note; may escalate to formal review if issues found |
The Compliance Spectrum
TOGAF defines a compliance spectrum — a continuum of compliance states that a project can occupy at any point in time. This is a high-frequency exam topic:
Architecture Compliance Report Contents
The Architecture Compliance Report is the formal output of a compliance review. Its standard contents are:
- Overview of the project and the architecture baseline against which it is assessed
- Compliance checklist — each applicable standard, principle, and constraint assessed against the project's design or implementation
- Compliance rating for each item: Conformant / Compliant / Consistent / Irrelevant / Non-Compliant
- Summary of findings, including critical non-conformances requiring immediate action
- Dispensations granted or pending, with reference to the Governance Log
- Recommended actions, owners, and target resolution dates for each non-conformance
- Board decision: Approved / Conditionally Approved / Rejected / Escalated
The compliance spectrum is tested in both Part 1 (recall the five states) and Part 2 (apply the correct state to a scenario). In Part 2, a common distractor is "Fully Compliant" — this is not actually a TOGAF term; Conformant is the highest positive state. The spectrum runs: Irrelevant → Consistent → Compliant → Conformant → (Non-Compliant with possible Dispensation). A dispensation converts a Non-Compliant finding into an approved exception for a specific item within defined conditions.
Section 5: Dispensations
A formal approval granted by the Architecture Board that allows a specific project or component to deviate from one or more architectural standards, principles, or constraints. A dispensation is time-bounded, conditioned, and recorded in the Governance Log. It does not permanently change the standard — it creates a controlled exception for a defined purpose and period.
When to Grant a Dispensation
The Architecture Board should consider granting a dispensation when one or more of the following conditions apply:
- Cost/benefit unfavourable: The cost of achieving full conformance significantly outweighs the benefit, and a controlled deviation presents acceptable risk
- Time constraint: Business urgency requires delivery before a full-conformance solution can be developed; the dispensation covers the interim period
- Legacy system constraint: An existing system cannot be modified to conform without replacement; a dispensation covers the system's remaining life
- Vendor limitation: A third-party product does not support the required standard, and replacing it is not viable within the project's scope
- Experimental or innovation initiative: A deliberate proof-of-concept that intentionally steps outside standards to test a new approach
Dispensation Process
- Request: The project team formally requests a dispensation, providing: the specific standard(s) to be deviated from, the business justification, the risk assessment, the proposed mitigations, and the duration of the deviation
- Assessment: The Architecture Review Board evaluates the request against the Architecture Principles, enterprise risk appetite, and the Governance Log (to check for similar prior cases)
- Decision: The Architecture Board approves, rejects, or conditionally approves the dispensation, specifying conditions (e.g. the deviation must be resolved in the next major release)
- Recording: The decision is recorded in the Governance Log with the date, rationale, conditions, duration, and owner
- Monitoring: The dispensation is reviewed at each subsequent compliance checkpoint; it must not be allowed to silently persist beyond its agreed expiry
Dispensation vs. Exception vs. Waiver
| Term | TOGAF Usage | Key Characteristic |
|---|---|---|
| Dispensation | The formal TOGAF term for an approved deviation from architecture standards | Time-bounded, conditioned, formally approved by Architecture Board, recorded in Governance Log |
| Exception | General industry term; not formally defined in TOGAF — often used informally to describe the same thing | May or may not have formal approval; prefer "dispensation" in TOGAF context |
| Waiver | Not a standard TOGAF term; used in some organisations to mean a permanently granted exception | Risk of permanent non-conformance; TOGAF does not endorse permanent waivers without periodic review |
In Part 1, if a question asks what the Architecture Board calls a formal approval to deviate from standards, the answer is always dispensation — not exception, not waiver, not variance. In Part 2, if a project presents legitimate legacy or cost constraints, the recommended action is to request a dispensation rather than to simply approve the non-conformance or reject the project. Always match the scenario to the correct formal TOGAF mechanism.
Section 6: Architecture Repository as a Governance Tool
The Architecture Repository is not merely a storage system — it is a live governance instrument. Six of its components are directly relevant to the governance process, and questions about the repository frequently appear alongside governance scenarios in Part 2.
| Repository Component | Governance Role | Governance-Relevant Contents |
|---|---|---|
| Architecture Metamodel | Defines the structure and rules for all architectural content — acts as the "constitution" of governance | Definitions of artefact types, relationships, and constraints that governance reviews check against |
| Architecture Capability | Documents the enterprise's ability to govern architecture — staffing, tools, and maturity | Architecture governance framework, roles, responsibilities, governance board terms of reference |
| Architecture Landscape | Provides the baseline and target reference against which compliance is measured | Strategic, segment, and capability architectures at various levels; transition architectures |
| Standards Information Base (SIB) | The definitive catalogue of approved technology and architecture standards that projects must conform to | Industry standards, technology products, data standards, security standards — all version-controlled |
| Reference Library | Provides approved patterns, best practices, and reference architectures that projects may adopt | Reference architectures, guidelines, templates, patterns — reduced compliance risk when adopted |
| Governance Log | The primary record of all governance decisions, actions, and outcomes — the legal memory of the Board | See below for detailed breakdown |
The Governance Log in Detail
The Governance Log is the most important repository component for governance purposes. It records four categories of entry:
These two components are commonly confused. The Standards Information Base defines what must be complied with (the rulebook). The Governance Log records how compliance was assessed and what decisions were made (the court record). In a Part 2 scenario asking where to find "the record of a dispensation granted last year", the answer is the Governance Log. If the question asks "where is the list of approved technology standards", the answer is the Standards Information Base.
Section 7: Governance Across ADM Phases
Architecture Governance is not confined to Phase G — it is embedded across the entire ADM lifecycle. Understanding how governance operates in each phase is essential for Part 2 scenario questions that span multiple ADM phases.
| Phase | Governance Activity | Key Governance Output |
|---|---|---|
| P Preliminary | Establish the governance framework, Architecture Board terms of reference, and governance policies | Architecture Governance Framework; Board charter |
| A Vision | Gain Architecture Board approval for the Statement of Architecture Work; define governance checkpoints | Approved Statement of Architecture Work; Architecture Vision |
| B Business Arch | Review proposed Business Architecture against enterprise principles; governance checkpoint if deviations found | Architecture Definition Document (business domain); Gap Analysis |
| C Information Systems | Verify data and application architecture conform to Standards Information Base and Reference Library | Architecture Definition Document (data, application); Gap Analysis |
| D Technology | Validate technology choices against Standards Information Base; raise dispensation requests for non-conformant technology | Architecture Definition Document (technology); Technology standards compliance note |
| E Opportunities | Board reviews and approves the Architecture Roadmap; validates work package priorities against strategy | Board-approved Architecture Roadmap (draft) |
| F Migration | Final Board approval of the Implementation and Migration Plan; roadmap sign-off | Board-approved Implementation and Migration Plan |
| G Implementation Gov. | Primary governance phase: establish Architecture Contracts, conduct compliance reviews, manage dispensations, update Governance Log | Architecture Contracts; Compliance Reports; Dispensation decisions; Updated Governance Log |
| H Change Management | Govern change requests; determine whether a change triggers a new ADM cycle or a dispensation; update governance records | Change Request decisions; updated Architecture Landscape; ADM re-trigger decision |
Phase G Focus: Governance of Implementation
Phase G is the ADM phase dedicated entirely to architecture governance during implementation. Its primary activities are:
- Confirm scope and priorities: Ensure the projects being implemented align with the Architecture Roadmap priorities agreed in Phase F
- Establish Architecture Contracts: For each implementation project, agree and sign Architecture Contracts before development begins
- Conduct compliance reviews: At each project milestone, assess conformance using the Architecture Compliance framework
- Manage dispensations: Process dispensation requests from projects; record decisions in the Governance Log
- Provide architecture guidance: Architects participate in project governance forums to provide ongoing guidance and resolve design questions
- Update the Architecture Repository: As implementation progresses, update the Architecture Landscape with as-built artefacts
- Prepare for Phase H: Identify emerging changes that may require architecture updates; prepare Change Requests for Phase H
Phase H: Architecture Change Management Governance
Phase H governs how changes to the architecture are evaluated and processed after implementation begins. Governance in Phase H involves:
- Change classification: Categorise change requests as simplification (no ADM re-cycle needed), incremental (minor ADM phases revisited), or strategic (full ADM re-cycle triggered)
- Board change approval: The Architecture Board approves or rejects change requests based on business value, strategic alignment, and risk
- Architecture updates: Approved changes are incorporated into the Architecture Landscape and the Standards Information Base
- ADM re-trigger decision: If the change is significant enough to warrant a new architecture development cycle, Phase H triggers a return to Phase A or the appropriate phase
Phase G governs ongoing implementation — it keeps delivery projects on track against the agreed architecture. Phase H governs changes to the architecture itself — it responds to new requirements, technology changes, or business events that require the architecture to evolve. A common Part 2 trap: a scenario describes a new business requirement emerging during build. The answer involves Phase H (raise a Change Request) rather than Phase G (conduct a compliance review). Compliance reviews check conformance against the current architecture; Phase H decides if the architecture itself should change.
Section 8: Part 2 Governance Scenarios
Part 2 of the OGEA-103 exam presents complex, realistic scenarios where you must apply governance knowledge to make best-fit decisions. The following worked scenarios cover the three most commonly tested governance situations.
Situation: A large retail bank is implementing a new mobile banking application. The project team has found that the chosen third-party mobile platform does not support the enterprise's mandated API authentication standard (OAuth 2.0 with enterprise-specific extensions). The vendor has confirmed this limitation will not be resolved for at least 18 months. The mobile application is a strategic priority with a board-mandated launch in 6 months.
What should the Architecture Board do?
Best-fit answer: Grant a time-bounded dispensation allowing the project to use the vendor's proprietary authentication scheme for the initial launch, subject to conditions: (1) the project must implement compensating security controls that achieve equivalent risk mitigation; (2) the dispensation expires at the next major release following the vendor's OAuth 2.0 support; (3) the project team must produce a migration roadmap to full conformance by month 18; (4) the dispensation is recorded in the Governance Log with all conditions. Do not reject the project — the business case is valid and the constraint is genuine. Do not approve without conditions — unconstrained deviations undermine governance credibility.
What not to do: Do not simply approve or reject. A blanket approval ignores the architecture non-conformance. A rejection blocks a strategic business priority without valid architectural justification. A dispensation with conditions is the correct balanced response.
Situation: During a Phase G compliance review of a new claims processing system, the Architecture Review Board discovers that the project has used a proprietary database engine that is not on the Standards Information Base, without any prior discussion with the architecture team. The project is 70% complete and replacing the database would set the project back by at least 8 months. The project has also exceeded its approved architecture scope by integrating directly with two external systems not covered by its Architecture Contract.
What should the Architecture Board do?
Best-fit answer: The Architecture Board should take the following actions: (1) Immediately record the non-conformances in the Governance Log as open actions. (2) Require the project to formally request a dispensation for the database, with a risk assessment, compensating controls, and a plan to migrate to a standards-compliant database in the next major release. (3) Require the project to amend its Architecture Contract to cover the additional external integrations, and conduct a mini-compliance review for those integrations. (4) Issue a formal caution or process improvement notice, as the project deviated without engaging governance — strengthen the governance framework to prevent recurrence. (5) Monitor the project at monthly intervals until conformance is re-established.
Key principle: The goal of governance is conformance and risk management — not punishment. The Board should find the path to the best achievable outcome (conditional dispensation + amended contract) rather than forcing an outcome that would cause greater harm to the enterprise (project cancellation at 70% completion).
Situation: The CFO has argued that the Architecture Board meets too infrequently (monthly) and too few business representatives are present (currently only the CTO and two IT domain leads). Business stakeholders feel they have no voice in architecture decisions that are causing project delays. The Head of Enterprise Architecture has responded that adding more business members will dilute technical authority and slow decision-making.
What should the Architecture Board recommend?
Best-fit answer: Both concerns are valid. TOGAF guidance supports a Board that includes business sponsors alongside architecture and IT representatives — the purpose is to ensure architecture decisions are aligned with business strategy, which requires business authority in the room. Recommended changes: (1) Add two senior business sponsors (representing major business domains) to the Board membership, with voting rights on business-impact decisions. (2) Establish a fast-track review process (e.g. email-vote with 5-day deadline) for urgent or low-risk decisions that do not require a full Board meeting. (3) Consider creating a standing sub-committee (Architecture Review Board) for operational compliance reviews, so the main Board can focus on strategic governance. (4) Review meeting cadence — consider bi-monthly for strategic decisions and on-demand for compliance escalations.
Key principle: Architecture governance works only when it has genuine authority and buy-in from both business and IT. A Board that is perceived as an IT-only body will be bypassed or ignored by business-led projects.
Common Mistakes in Governance Questions
- Confusing Architecture Board with Architecture Review Board: The Architecture Board is the strategic governance authority; the ARB is the operational review body. They have different memberships, powers, and outputs.
- Treating dispensations as approvals: A dispensation approves a deviation, not the architecture itself. The non-conformance is still recorded — it is simply controlled rather than open-ended.
- Confusing Phase G and Phase H: Phase G governs implementation conformance to the approved architecture. Phase H governs changes to the architecture itself. If the scenario involves a new requirement, think Phase H.
- "Fully Compliant" is not a TOGAF term: Use Conformant for the highest positive compliance state. This is a favourite distractor in Part 1 questions.
- Architecture Contracts are not optional: Many candidates treat contracts as nice-to-have. In TOGAF, they are the binding mechanism of Phase G governance — without one, compliance reviews have no agreed baseline.
- Governance Log is not the same as the Repository: The Governance Log is a component within the Architecture Repository. Do not confuse the whole with one of its parts.
Chapter 14 Revision Summary
- Architecture Governance is the system of controls over all architectural components — it answers "Is the right architecture being built?" (governance) vs. "Is it being built right?" (management)
- The four governance levels are: Enterprise, Portfolio, Project, and Operational — each with different scope, authority, and governance bodies
- The Architecture Board is the primary governance authority: it approves, rejects, grants dispensations, and escalates. It differs from the Architecture Review Board (operational compliance reviewer)
- Architecture Contracts are formal, binding agreements between the architecture team and implementation partners — they must be in place at Phase G before any build activity begins
- Architecture Contracts come in two types: with development projects (internal) and with external suppliers — both have the same essential content: deliverables, quality measures, acceptance criteria, dispensations
- Compliance Reviews are conducted at multiple project milestones in Phase G, not just at project end. They can be formal (full ARB) or informal (Lead Architect)
- The compliance spectrum runs: Irrelevant → Consistent → Compliant → Conformant (highest positive). Non-Compliant is resolved via dispensation or remediation — "Fully Compliant" is not a TOGAF term
- A dispensation is a time-bounded, conditioned, formally approved deviation from architecture standards — it is recorded in the Governance Log with conditions and expiry
- The six repository components that support governance: Metamodel, Capability, Architecture Landscape, Standards Information Base, Reference Library, and Governance Log
- The Governance Log records four types of entries: decisions, dispensations, compliance results, and actions/follow-ups
- Phase G governs implementation conformance to the approved architecture; Phase H governs changes to the architecture itself — triggered by new requirements, business events, or technology changes
- In Part 2 scenarios, always use the formal TOGAF mechanism: dispensation (not waiver/exception), Architecture Board (not steering committee), Governance Log (not meeting minutes)
Practice Questions
Click each question to reveal the model answer. Use these to test your recall before moving on.
B. Grant a time-bounded dispensation allowing the mainframe to use its existing encryption approach for up to 24 months, with conditions that include compensating security controls and a firm migration commitment.
This is the correct TOGAF governance response because: (1) the constraint is genuine and externally imposed (legacy mainframe limitation), (2) the duration is defined and bounded (24 months = mainframe replacement), (3) a dispensation provides formal, conditioned approval rather than an uncontrolled deviation. Rejecting the project entirely would be disproportionate — the constraint is temporary. Approving without conditions would leave the non-conformance unmanaged. The dispensation must be recorded in the Governance Log with the expiry date, conditions (compensating controls), and the owner responsible for monitoring conformance.
C. A joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture, providing the formal mechanism by which implementation projects commit to architectural conformance.
This is the TOGAF definition of an Architecture Contract. Key exam points: it is a joint agreement (not a unilateral mandate), it covers deliverables, quality measures, and acceptance criteria, and it is the primary mechanism binding implementation teams to architectural standards in Phase G. The Statement of Architecture Work (Phase A) is often confused with the Architecture Contract — the SAW governs the architecture development effort; the Architecture Contract governs the implementation project's compliance obligations. They are established at different phases and serve different purposes.
A. Consistent
The compliance spectrum, from lowest to highest positive state, is: Irrelevant → Consistent → Compliant → Conformant. "Consistent" means the project aligns with the intent and direction of the architecture but does not explicitly meet all formal requirements — exactly the scenario described. "Compliant" means it meets most requirements; "Conformant" means it meets all requirements fully. "Non-Compliant" means it fails and requires remediation or dispensation. Note that "Fully Compliant" is not a TOGAF term — a common distractor. The appropriate Board action for a "Consistent" finding is typically to note the alignment while requesting the project either adopt an approved standard or submit a proposal to add the technology to the SIB.
D. Phase H — Architecture Change Management
Phase H governs changes to the architecture itself in response to business events, regulatory changes, or technology shifts. The new regulation represents a business driver that requires the enterprise architecture (specifically the Data Architecture and related principles) to be updated. Phase H would: (1) receive and assess the Change Request triggered by the regulation; (2) determine whether a new ADM cycle is required or whether targeted updates to the Data Architecture suffice; (3) update the Architecture Landscape and Standards Information Base with the new data retention requirements; (4) communicate the changes to implementation projects via the Architecture Board. Phase G compliance reviews would then assess projects against the updated architecture — but Phase H must first update the architecture before Phase G can enforce it.
B. The Governance Log
The Governance Log is the repository component that records all formal governance decisions, including dispensations granted by the Architecture Board. A dispensation record in the Governance Log includes: the standard deviated from, the project that received the dispensation, the business justification, the conditions attached, the expiry date, and the date of the Board decision. The Standards Information Base (SIB) contains the list of approved standards — not dispensation records. The Reference Library contains approved patterns and guidelines. The Architecture Landscape contains architectural artefacts and models. Only the Governance Log serves as the immutable audit trail of governance decisions, making it the correct answer and the definitive source for locating historical dispensations.