In the TOGAF Architecture Development Method (ADM), Phase H: Architecture Change Management is the final phase of the cycle, but it is not the end of the architecture’s life. Instead, it marks the transition from architecture delivery to ongoing evolution.
Once an architecture has been implemented (Phase G), the business environment, technology landscape, and user needs will inevitably change. Phase H ensures that these changes are managed in a controlled, deliberate, and value-driven manner. It acts as the “watchtower” that monitors the live architecture, decides how to handle requested changes, and determines when a completely new architecture cycle is required.
Phase H has three primary goals:
Maintain the Architecture Lifecycle: Keep the architecture aligned with business goals over time, rather than letting it become outdated.
Execute Architecture Governance: Ensure that the established governance framework continues to oversee changes, maintain compliance, and protect architectural integrity.
Sustain Architecture Capability: Verify that the organization’s architecture practice (tools, skills, processes, repositories) continues to meet current and future requirements.
During this phase, the architecture team performs four core activities:
Continual Monitoring: Track the performance, usage, and business relevance of the deployed architecture.
Change Management Process: Receive, evaluate, and route architecture change requests through a structured workflow.
Cohesive Change Handling: Ensure modifications are applied in a way that doesn’t break existing integrations or violate principles.
Business & Capacity Monitoring: Watch for shifts in business growth, market conditions, or IT capacity that could impact the architecture’s viability.
The central question Phase H answers is: “Does this change threaten or enhance the original business value we aimed for?”
Phase H establishes clear rules for:
When and how the live architecture can be modified after deployment.
When a change is so significant that it requires starting a new ADM cycle to design a fresh architecture.
To make these decisions, Phase H evaluates all incoming changes against three categories of architectural change:
| Change Type | What It Means | Business Driver | Typical Handling |
|---|---|---|---|
| Simplification Change | Reducing complexity or cost in the current architecture. Need to reduce investment. | Budget cuts, consolidation, decommissioning legacy systems. | Handled via standard change management techniques. No new ADM cycle needed. |
| Incremental Change | Enhancing or extending existing capabilities. Need to derive additional value from current investment. | New regulatory requirements, technology upgrades, minor feature expansions. | May be handled via change management, OR may require partial re-architecting. |
| Re-architecting Change | Fundamental transformation of how the business operates or delivers value. Need to increase investment to create new value. | Market disruption, major strategic pivot, complete digital transformation. | Requires restarting the full ADM cycle (Issue a new Request for Architecture Work). |
Not every change request requires a full redesign. Phase H uses practical guidelines to route changes efficiently:
| Scenario | Recommended Path |
|---|---|
| Change impacts two or more stakeholders/business units | Likely requires Architecture Redesign (re-enter ADM) |
| Change impacts only one stakeholder or department | Likely suitable for Change Management |
| Change can be approved via a dispensation (temporary exception) | Likely suitable for Change Management |
| Change significantly impacts overall business strategy | Re-architecting (full ADM cycle) |
| Change involves new technology/standards (e.g., cloud migration, new data privacy law) | Incremental (refresh specific architecture domain) |
| Change is at the infrastructure level (e.g., consolidating 10 servers into 1) | Simplification (handle via change management) |
Phase H doesn’t just react to random requests. It looks for systemic shifts that indicate the current architecture foundation is no longer fit for purpose. A Refreshment Cycle (partial or complete re-entry into the ADM) is triggered when:
The Foundation Architecture (core principles, reference models) no longer aligns with business strategy.
Substantial changes are needed to deployment components, guidelines, or standards.
Major regulatory or industry standard changes occur that significantly impact end-users or compliance posture.
If a refreshment is required, the architecture team issues a new Request for Architecture Work, formally kicking off a new iteration of the ADM cycle.
Scenario: A mid-sized retail company recently deployed a new e-commerce platform (the Target Architecture) following TOGAF Phases A–G. The platform is live, and Phase H begins.
Month 3: The IT operations team requests to decommission three old inventory databases and migrate their data into the new central system to save licensing costs.
Phase H Classification: Simplification Change (driven by cost reduction)
Action: Handled through standard change management. Architecture Board approves, governance logs the change, and the team implements it without restarting the ADM.
Month 7: A new government privacy regulation requires all customer data to be encrypted at rest and in transit, with strict consent tracking.
Phase H Classification: Incremental Change (driven by compliance & extracting additional value from existing data assets)
Action: Architecture team updates the Data and Technology Architecture models, issues an incremental change plan, and applies it via controlled deployment. Governance ensures compliance.
Month 12: The CEO announces a strategic pivot: the company will shift from selling products to offering a subscription-based “product-as-a-service” model with AI-driven personalization.
Phase H Classification: Re-architecting Change (driven by new business value creation & strategic shift)
Action: Phase H determines the current architecture cannot support this pivot. A new Request for Architecture Work is issued, and the enterprise begins a fresh ADM cycle starting with Phase A.
Phase H is continuous: Architecture doesn’t end at deployment; it enters a lifecycle of controlled evolution.
Change is categorized, not chaotic: Every request is evaluated as Simplification, Incremental, or Re-architecting to ensure proportional response.
Governance is central: The Architecture Board and governance framework ensure changes don’t compromise security, compliance, or long-term vision.
Know when to restart: Phase H protects the organization from forcing old architectures to solve new strategic problems. When business strategy fundamentally shifts, the ADM cycle begins again.
Business value is the compass: All decisions in Phase H tie back to preserving or enhancing the original business outcomes the architecture was designed to deliver.
By mastering Phase H, organizations avoid architecture decay, reduce technical debt, and ensure their IT landscape remains a strategic enabler rather than a legacy bottleneck.
