TOGAF's ADM has both Phase G (Implementation Governance) and Phase H (Architecture Change Management) after the migration plan is finalized. What does each phase actually govern, and how does an issue found by Phase G differ from a trigger handled by Phase H?

## Two governance phases at the tail Phase G and Phase H are the two governance-flavored phases at the tail of the ADM, and it's tempting to lump them together as 'the phases that make sure things stay on track after planning,' but they govern fundamentally different things and operate on different timescales, which is why TOGAF keeps them distinct. ## Phase G — governing delivery Phase G, Implementation Governance, is scoped to the delivery projects that Phase F's Implementation and Migration Plan spawned. Its central artifact is the **Architecture Contract**: a formal, typically signed agreement between the architecture function and the team delivering a given work package, stating what architectural constraints, standards, and target-state requirements that delivery must conform to. With Architecture Contracts in place, Phase G's ongoing job is **compliance review** — periodically checking the actual solution being built against the approved Architecture Definition Document and the contract's terms, and flagging deviations. A deviation might be: - **benign** — a documented waiver for a better implementation detail; - **a real compliance failure** — a team quietly chose a different database technology than the approved Target Technology Architecture specified, because it was faster to build with what the team already knew. Phase G's authority is to catch and adjudicate exactly this kind of drift between 'what was approved' and 'what is actually being delivered,' while the approved architecture itself is treated as the fixed reference point. ## Phase H — governing the architecture itself Phase H, Architecture Change Management, does the opposite kind of work: it treats the approved architecture as potentially wrong or stale, and watches the environment for evidence that it needs to change. Its inputs are external to any single delivery project: - a new regulatory requirement; - a technology becoming obsolete; - a merger or business-strategy pivot; - or even a pattern of Requests for Change accumulating from multiple Phase G compliance reviews that all point at the same architectural assumption being wrong in practice. Phase H's job is to classify the significance of these changes — is this a simple, low-risk change handled by a minor update, or is it significant enough that the organization needs to re-enter the ADM at the Preliminary Phase or Phase A — and to manage the process of deciding and formally triggering that re-entry when warranted. ## Telling them apart The clean way to keep them apart: | Phase | The question it asks | What's fixed, what's in question | |---|---|---| | **Phase G** | 'is delivery conforming to the architecture we approved?' | the architecture held fixed as the reference | | **Phase H** | 'is the architecture we approved still the right one, given what's changed in the world?' | delivery held out of scope, and the architecture itself as the thing under question | A single finding can legitimately feed both, but for different reasons — if Phase G repeatedly finds teams deviating from a particular Target Architecture element in the same way, that's a compliance signal for Phase G but also a Request for Change signal that should reach Phase H, since the architecture itself may need revisiting. ## The trade-offs on both sides - The trade-off of keeping **Phase G's project-level policing rigorous** is delivery friction: teams under deadline pressure resent compliance reviews that block a shipped feature over an architecture technicality, and heavy-handed Phase G governance without a fast waiver/exception path drives shadow-IT behavior — teams quietly building outside the governed process, which defeats the whole purpose of having governance. - The trade-off of keeping **Phase H's environment-monitoring genuinely active** is cost and organizational attention: someone has to actually watch for regulatory and technology changes and periodically ask 'is our Target Architecture still valid,' and organizations that treat Phase H as a formality end up with architectures that quietly go stale — technically 'approved' documents that nobody has checked against reality in years. ## What goes wrong in practice A concrete failure mode illustrating both phases failing together: an organization's Phase G approves an Architecture Contract requiring a specific message-queue technology; eighteen months later, that vendor announces end-of-life. Because Phase H isn't actively monitoring the technology landscape, nobody flags this as a trigger, so the 'approved' Target Technology Architecture keeps requiring new projects to build against a dying platform — Phase G is doing its job perfectly, but Phase H's absence means what's approved has become wrong, and Phase G's rigor is now actively enforcing a mistake. ## Where it shows up A worked example: a bank's Phase G compliance reviews repeatedly find delivery teams requesting waivers to bypass an approved data-encryption-at-rest standard because a newly-adopted cloud platform handles encryption differently than the standard assumed. Individually, each waiver is a Phase G decision; but the pattern — the same waiver requested by four different teams — is exactly the kind of signal Phase H is meant to catch and escalate into a Request for Change, triggering a targeted re-entry into Phase D to update the Target Technology Architecture's encryption standard to match how the new cloud platform actually works, rather than continuing to grant one-off waivers indefinitely.