6.1 Phase G: Implementation Governance & Architecture Compliance

6.1 Phase G: Implementation Governance & Architecture Compliance

Phase G: Implementation Governance is the operational bridge in the TOGAF Architecture Development Method (ADM) where architectural concepts, blueprints, and roadmaps transition into concrete physical implementations. While Phases A through F focus on defining architecture vision, target business/systems architectures, candidate solutions, and transition plans, Phase G establishes rigorous architectural oversight over the actual implementation projects. The primary objective of Phase G is to ensure that solution delivery teams conform to the agreed-on Target Architecture, adhere to architectural principles, and realize the intended business outcomes.

Implementation without architectural governance frequently leads to "architectural drift"—a scenario where development teams make localized technical compromises, bypass established standards, or introduce shadow technologies under schedule pressure. Phase G mitigates this risk by instituting formal governance mechanisms, executing continuous compliance reviews, formulating binding Architecture Contracts, and aligning project delivery with enterprise governance frameworks.

---

Core Objectives of Phase G

The fundamental goals of ADM Phase G encompass the following primary objectives:

1. Establish Implementation Governance: Formulate and operationalize a robust governance structure for all solution implementation projects forming part of the architecture roadmap.
2. Ensure Architecture Conformance: Perform systematic architectural oversight across the implementation project lifecycle to ensure compliance with the Target Architecture and Architecture Contracts.
3. Manage Architecture Contracts: Formulate, negotiate, sign, and monitor Architecture Contracts executed between the Enterprise Architecture (EA) organization and internal or external implementation partners.
4. Execute Architecture Compliance Reviews: Conduct formal compliance audits at defined project milestones to evaluate compliance levels and identify architectural deviations early.
5. Guide Solution Implementation: Provide ongoing architectural guidance, interpretation, and design clarification to delivery teams, solution architects, and engineering leads.
6. Issue Governance Decisions: Coordinate with the Architecture Board to evaluate non-compliance findings, review dispensation requests, and determine appropriate remediation paths.

---

Establishing the Implementation Governance Framework

Implementation governance in Phase G does not replace project management or software delivery methodologies (such as Agile, Scrum, or Waterfall); rather, it overlays an architectural governance wrapper around them. The EA team collaborates with Project Management Offices (PMO), Solution Delivery Leads, and Quality Assurance (QA) teams to integrate architectural checkpoints directly into project delivery gates.

+-------------------------------------------------------------------------+
|                        ARCHITECTURE BOARD                               |
|   - Sets Standards    - Reviews Compliance    - Grants Dispensations    |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|                   ENTERPRISE ARCHITECTURE TEAM                          |
|   - Drafts Contracts  - Conducts Audits       - Provides Guidance       |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|                  IMPLEMENTATION / DELIVERY TEAMS                        |
|   - Builds Solution   - Adheres to Baseline   - Reports Deviations      |
+-------------------------------------------------------------------------+

The governance framework establishes clear accountabilities, escalation channels, and review cadences. Central to this model is the Architecture Board, which exercises ultimate authority over architecture compliance, standards enforcement, and contractual dispensations.

---

Formulating Architecture Contracts

An Architecture Contract is a legally or operationally binding agreement that governs the architectural characteristics, constraints, standards, and deliverables of an implementation project. It defines the explicit relationship between the architecture organization (supplier of architectural requirements) and the implementation team (builder of the solution).

Key Components of an Architecture Contract

• Target & Scope Definition: Explicit statement of the business capabilities, application services, and technology infrastructure within scope.
• Architectural Requirements & Constraints: Specific non-functional requirements (NFRs), security controls, performance SLAs, and technology standards that must be satisfied.
• Deliverables & Milestones: List of architectural artifacts, code assets, and documentation required at each project phase gate.
• Standards Baseline: Reference to specific enterprise standards, guidelines, and Architecture Building Blocks (ABBs) that must be utilized.
• Conformance Metrics & Audit Schedule: Frequency, criteria, and governance gates for Architecture Compliance Reviews.
• Signatories: Formal sign-off by the Chief Architect, Program Director, Lead Solution Architect, and Implementation Partner Lead.

---

Conducting Architecture Compliance Reviews

An Architecture Compliance Review is a formal audit of an implementation project against enterprise architecture standards, principles, and the specific Architecture Contract. Conducted by designated EA staff or independent architecture reviewers, compliance reviews ensure early detection of architectural deviations before solutions reach production deployment.

The 6 Levels of Architecture Compliance in TOGAF

TOGAF defines six precise levels of compliance. Every definition turns on exactly two questions: are all of the specification's features implemented? and does the implementation add features the specification does not cover? Learn them as that 2x2 rather than as vague degrees of "how compliant" a project is — that is the single most common trap on this topic.

Two consequences follow directly from these definitions and are worth memorizing:

• Non-conformant is not the bottom of a ladder. It is a cross-cutting verdict: as soon as any specified feature is built the wrong way, the implementation is Non-conformant regardless of how much else lines up.
• "In accordance with" has a precise TOGAF meaning: the implementation supports the stated strategy and future directions, adheres to the stated standards (including syntax and semantic rules), provides the stated functionality, and adheres to the stated principles.

Note that "Compliant with dispensation" is a governance outcome recorded in the Governance Log, not one of the six conformance levels.

---

Role of the Architecture Board During Execution

The Architecture Board operates as the steering committee during Phase G. When compliance reviews uncover Non-conformant elements, the project team must present its case to the Architecture Board. The Board has three primary options:

1. Mandate Remediation: Require the implementation team to modify the design or code to achieve compliance at their own expense.
2. Grant a Formal Dispensation: Temporarily or permanently grant an exemption allowing non-compliant delivery under strict risk mitigation controls and expiration timelines.
3. Amend the Architecture: If the non-conformance represents a superior technical innovation or unbudgeted business reality, the Board may elect to trigger an Architecture Change Request to update the baseline architecture.

---

Phase G Inputs, Steps, and Outputs

Key Inputs

• Architecture Vision & Statement of Architecture Work
• Target Architecture Definitions (Business, Data, Application, Technology)
• Architecture Requirements Specification & Requirements Traceability Matrix
• Transition Architecture & Architecture Roadmap
• Enterprise Architecture Repository & Governance Models

Key Steps

1. Confirm scope and priority deployment with development teams.
2. Formulate, negotiate, and execute Architecture Contracts.
3. Establish implementation governance integration with PMO/DevOps pipelines.
4. Execute formal Architecture Compliance Reviews at predefined gates.
5. Review non-compliance findings and process dispensation requests with the Architecture Board.
6. Publish Compliance Assessments and update the Architecture Repository.

Key Outputs

• Architecture Contracts: Signed governance agreements for implementation projects.
• Compliance Assessments: Formal audit reports detailing compliance levels across projects.
• Change Requests: Architecture change proposals resulting from implementation feedback.
• Architecture-Compliant Solutions: Verified building blocks and deployed capabilities ready for operational handover.