TOGAF Phase G and H: Implementation Governance and Change Management

All of the careful design work done in Phases A through D, and all of the planning done in Phases E and F, comes down to this: does what actually gets built match what was designed? Phase G answers that question by actively governing the implementation. Phase H then ensures the architecture remains fit for purpose as business conditions inevitably change.

Together, Phases G and H close the ADM cycle and set the organization up for the next one. They are the phases most often overlooked in organizations that treat architecture as a design-only function and leave implementation entirely to project teams. That approach is where architectural integrity gets lost.

Phase G: Implementation Governance

What Phase G Does

Phase G provides the architectural oversight of the implementation projects that deliver the agreed Architecture Roadmap. It is where the architecture team transitions from designers and planners to active overseers of delivery.

This does not mean architects manage the projects. Programme and project managers do that. What architects do in Phase G is ensure that what is being built conforms to the architecture, catch deviations early before they become expensive problems, and help delivery teams resolve genuine technical conflicts between the architecture and implementation reality.

The Key Objectives of Phase G

Ensure conformance with the Target Architecture during implementation
Perform Architecture Compliance Reviews at agreed milestones
Handle requests for changes to the agreed architecture
Update the Architecture Repository as implementation proceeds and decisions are made
Provide architecture guidance to implementation teams when needed
Ensure that compliance with the architecture is assessed in both project-level and enterprise-level governance

Architecture Compliance Reviews in Phase G

The primary governance tool in Phase G is the Architecture Compliance Review. These are formal checkpoints where the architecture team examines the current state of a project's design and delivery against the agreed architecture.

A well-run compliance review programme includes:

Defined review schedule: Reviews are planned at specific milestones in each project, not triggered ad-hoc
Clear scope: Each review examines a specific set of architecture requirements relevant to the project stage
Structured assessment: Using the compliance levels defined by TOGAF (Conformant, Accommodated, Delineated, Non-Conformant)
Escalation path: Non-conformant findings trigger a structured resolution process, escalating to the Architecture Board where needed
Documented outcomes: All review findings and decisions are recorded in the Architecture Repository

Phase G Is the Most Commonly Skipped Phase

In many organizations, the architecture practice focuses on producing architecture blueprints and hands them to delivery teams without any follow-through governance. This is the single most common reason why implemented systems diverge from their architecture designs. Phase G exists specifically to prevent this.

Architecture Contracts in Phase G

Architecture Contracts, first established in Phase A, are actively managed in Phase G. As implementation progresses, contractors and delivery teams are held to the contracts they signed. Any proposed deviation from the contract must be formally assessed.

The Architecture Contract governance process in Phase G works as follows:

A delivery team identifies a deviation: something they cannot build as designed, or something they want to change
The team raises a formal change request with the architecture team
The architecture team assesses the impact of the proposed change on the rest of the architecture
Minor changes within agreed tolerances are approved by the lead architect
Major changes that affect the Architecture Definition are escalated to the Architecture Board for decision
The outcome is documented in the Governance Log in the Architecture Repository

This process protects the integrity of the architecture without being inflexible. Real implementations always encounter surprises. The goal is to handle those surprises in a controlled, recorded way rather than by undocumented workarounds.

Updating the Architecture Repository in Phase G

As implementation decisions are made, they generate information that must be captured. Phase G keeps the Architecture Repository up to date by:

Recording all compliance review outcomes in the Governance Log
Updating Solution Building Blocks as the actual products and configurations chosen by implementation teams are confirmed
Capturing lessons learned from implementation challenges for future architecture work
Updating the Architecture Landscape to reflect the evolving current state as work packages are completed

A live, accurate Architecture Repository is one of the most valuable assets an enterprise architecture practice can have. Phase G is one of the primary mechanisms that keeps it current.

Phase H: Architecture Change Management

What Phase H Does

Phase H ensures that the architecture lifecycle continues to operate effectively once a Target Architecture has been implemented. It monitors the business and technology environment for changes that would require the architecture to be updated, and manages the process of making those updates in a controlled way.

The world does not stand still once an architecture is delivered. Regulations change. Market conditions shift. New technologies emerge. Competitor actions require strategic responses. Phase H is the mechanism that keeps the enterprise architecture responsive to these dynamics.

The Key Objectives of Phase H

Ensure that the architecture lifecycle is actively maintained
Ensure that the governance framework remains effective and respected
Monitor changes in the technology environment for architecture relevance
Monitor changes in the business environment for architecture relevance
Assess the performance of the architecture against the Key Performance Indicators defined in Phase A
Manage requests for changes to the architecture that arise from business or technology drivers
Activate the ADM cycle again when a change of sufficient magnitude warrants a new architecture development effort

Change Triggers in Phase H

Phase H actively monitors for events that would trigger an architecture review or a new ADM cycle. These triggers fall into two broad categories.

Technology-Driven Triggers

A platform or product reaching end of life and requiring replacement
A new technology emerging that could significantly improve business outcomes (for example, a new AI platform or a new cloud service category)
A security vulnerability discovered in a component of the current architecture
Changes in vendor licensing, pricing, or support arrangements that affect platform viability

Business-Driven Triggers

A change in business strategy that alters which capabilities are strategically important
A regulatory change requiring new data governance or reporting capabilities
A merger or acquisition that brings new systems and organizations into scope
A significant shift in customer behaviour or market conditions requiring new business services

Not Every Change Requires a New ADM Cycle

Phase H distinguishes between incremental changes (managed within existing governance processes without a new ADM cycle) and strategic changes (which require triggering a full new ADM cycle from Phase A). Part of the Phase H skill is correctly categorizing incoming change requests so that the response is proportionate.

The Change Management Process in Phase H

When a change request arrives, Phase H processes it through a structured assessment:

Receive and log: The request is formally received and logged in the Governance Log
Assess impact: What parts of the current architecture are affected? What risks arise from the change? What risks arise from not making the change?
Classify the change: Is this an incremental correction, an enhancement, or a strategic shift?
Determine the response: For incremental changes, update the relevant architecture documents and update the Repository. For strategic changes, initiate a new ADM cycle
Communicate: Inform affected stakeholders of the change and its implications
Update the Repository: Record the change and its decisions in the Architecture Repository

Architecture Performance Measurement

Phase H is also responsible for measuring whether the architecture is delivering the business outcomes promised in Phase A's Architecture Vision.

Key Performance Indicators are defined during Phase A against the business goals. Phase H monitors these KPIs over time and reports on them:

Is the architecture enabling the business capabilities that were identified as strategically important?
Are the cost efficiencies forecast in the business case being realized?
Are the operational quality targets (availability, performance, security) being met?
Is technical debt being reduced as planned?
Are the intended regulatory compliance improvements achieved?

Poor performance against these KPIs is itself a trigger for architecture change. If the delivered architecture is not producing the expected benefits, Phase H drives the review and correction process.

How Phases G and H Connect to the Full ADM Cycle

The ADM is a cycle, not a linear sequence. After Phase H concludes its change management activity for a given architecture generation, the decision may be made to re-enter the cycle at Phase A with a new Architecture Vision for the next generation.

This cyclical nature is fundamental to TOGAF's value. Business and technology are perpetually changing. An architecture practice that completes one cycle and then stops is one that will quickly find its architecture out of date. Phases G and H are designed specifically to keep the cycle alive and the architecture relevant.

Real-World Example: Retail Bank Post-Implementation

Following the completion of a cloud migration programme, a retail bank's architecture team enters Phase G and H operations:

Phase G compliance review: A review of the new online banking application finds a deviation: the team used a non-approved third-party authentication library instead of the enterprise-standard IAM platform. This is assessed as non-conformant and an escalation plan is agreed to replace the library within 60 days
Phase H trigger (regulatory): A new PSD3 regulation is announced requiring enhanced transaction monitoring. This qualifies as a strategic change requiring a new ADM cycle for the payments architecture
Phase H trigger (technology): The message broker used in the cloud integration platform approaches end of life. This triggers an incremental change: a technology replacement work package is added to the existing roadmap
KPI monitoring: Branch footfall has reduced by 32% following the digital banking launch, matching the target. Digital transaction volume is 18% above forecast. The architecture is declared successful against its Phase A KPIs

Summary

Phases G and H complete the ADM cycle by ensuring the architecture is implemented as designed and maintained as the world changes.

Phase G provides implementation governance through:

Architecture Compliance Reviews at key project milestones
Architecture Contract management and change control
Continuous updates to the Architecture Repository

Phase H ensures long-term architecture relevance through:

Monitoring business and technology change triggers
Classifying and processing change requests
Measuring architecture performance against Phase A KPIs
Activating the next ADM cycle when warranted

The final ADM process we have not yet addressed is Requirements Management — the central, cross-cutting process that runs through every phase. That is the subject of our next post: Requirements Management: The Cross-Phase ADM Process.

For the full series and all ADM phase posts, begin with What is TOGAF 9.2? and follow the reading order from there.