Section 1: Phase H Overview
Phase H — Architecture Change Management — is the final phase of an ADM cycle and the bridge to the next. Its core purpose is to ensure the architecture remains fit for purpose as the business and technology environment evolve after implementation. While Phase G (Implementation Governance) oversees the deployment of architecture in projects, Phase H manages the ongoing operational architecture once deployment is complete.
The ADM phase that establishes and operates an architecture change management process to monitor change drivers, manage change requests, assess impact, and determine whether a new ADM cycle is required. Phase H ensures the architecture lifecycle is continuous, not a one-off exercise.
Phase H Inputs and Outputs
| Inputs | Outputs |
|---|---|
| Requests for Architecture Change (from Phase G or stakeholders) | Architecture Updates (minor changes applied within current cycle) |
| Performance metrics against the Architecture Contract | Changes to the Architecture Framework and Principles |
| New technology reports and technology watch findings | New Statement of Architecture Work (if re-architecting change approved) |
| Business strategy changes and new requirements | Updated Architecture Repository (all classes refreshed) |
| Lessons learned from Phase G governance | Architecture Governance Log updated; Dispensation reviews closed |
Part 1 frequently tests Phase H purpose with distractors that sound like Phase G. Remember: Phase G governs implementation of projects; Phase H manages change to the architecture after implementation. If a question involves monitoring the running architecture, assessing change requests, or deciding whether to re-cycle the ADM, the answer is Phase H.
Section 2: Types of Architecture Change
TOGAF defines three types of architecture change, each requiring a different response. Correctly classifying a change is the architect's first task when a Request for Architecture Change arrives — the classification determines the governance path, the decision-makers, and whether a new ADM cycle is needed.
| Type | Description | Response | Who Decides | New ADM Cycle? |
|---|---|---|---|---|
| Simplification | Reduces complexity without altering the baseline scope or changing approved target architecture. Examples: removing a redundant server, consolidating duplicated application functions. | Handled within ongoing EA operations; Architecture Repository updated; no formal re-approval needed. | Architecture team (no Board approval required) | No |
| Incremental | Small, planned adjustments to the architecture that remain within the scope and objectives of the current ADM cycle. Examples: adding a new API integration, updating a technology standard. | Change assessed by Architecture Board; if approved, integrated into current architecture without re-starting ADM. Architecture Roadmap may be updated. | Architecture Board | No — continue current cycle |
| Re-architecting | Significant business or technology disruption requiring a fundamental rethink of the architecture. Examples: merger/acquisition, disruptive technology (AI platform replacement), major regulatory overhaul, business model pivot. | Architecture Board escalates to sponsor. New Statement of Architecture Work issued. New ADM cycle triggered from Phase A or Preliminary. | Architecture Board + Sponsor (executive decision) | Yes — new ADM cycle |
Part 2 scenarios often present a change and ask which type it is and what the correct response should be. Key heuristic: if the change alters the approved target architecture or business objectives, it is at minimum incremental. If it questions the validity of the entire architecture or strategy, it is re-architecting. Simplification never changes the target — it only removes unnecessary complexity from the baseline.
Section 3: Change Request Process
Any stakeholder — project team, business unit, technology team, or external party — can raise a Request for Architecture Change. The process ensures every change is formally assessed before being applied, preventing uncontrolled drift from the approved architecture.
| Step | Activity | Responsible |
|---|---|---|
| 1 | Stakeholder raises a Request for Architecture Change, documenting the driver, scope, urgency, and proposed resolution. | Requesting stakeholder |
| 2 | Architecture team performs initial impact assessment: which architectural building blocks are affected, what is the risk of change vs. risk of inaction. | Enterprise Architect |
| 3 | Architecture Board reviews the impact assessment and classifies the change as simplification, incremental, or re-architecting. | Architecture Board |
| 4 | Decision is made: Accept (implement within current cycle), Reject (document rationale), Defer (revisit at next governance window), or Escalate (to sponsor for re-architecting changes). | Architecture Board / Sponsor |
| 5 | Architecture Repository updated: Architecture Definition Document, Standards Information Base, and Governance Log all reflect the approved change. | Architecture team |
| 6 | Requesting stakeholder notified of decision and any resulting constraints or new architecture guidance. | Architecture Board |
Section 4: Architecture Board in Phase H
The Architecture Board's role does not end when implementation is complete. In Phase H, the Board shifts from approving architectures (its Phase A–G role) to stewarding the architecture over time. This is one of the most commonly misunderstood aspects of TOGAF governance.
- Technology watch function: The Board actively monitors the external technology landscape for disruptive developments that may invalidate architecture decisions. Reports are fed into the Phase H assessment process.
- Lessons-learned integration: The Board collects lessons from Phase G governance activity and from post-implementation reviews. These lessons improve the next ADM cycle and update the Architecture Principles where needed.
- Dispensation reviews: Any dispensations granted during Phase G (deviations from the approved architecture) are reviewed in Phase H. If a dispensation has become the norm, it may be formalised as a standards update.
- Governance log maintenance: The Board keeps the Architecture Governance Log current, recording all change requests, decisions, and their rationale — creating an auditable architecture history.
Exam scenarios will describe an ongoing operational situation and ask who is responsible for managing architecture change. The Architecture Board is always the correct governance body for change management decisions in Phase H. Do not confuse with project governance bodies, which operate within Phase G. The Board's ongoing role is: monitor, assess, decide, record.
Section 5: Triggers for a New ADM Cycle
Phase H must determine whether incoming change is manageable within the current architecture or requires a completely new ADM cycle. TOGAF identifies six common trigger categories that typically necessitate a re-architecting decision and new cycle.
| Trigger Category | Example | Likely Change Type |
|---|---|---|
| Business strategy change | Company pivots from product sales to subscription model; a merger requires integrating two enterprise architectures | Re-architecting |
| Disruptive technology | Adoption of generative AI invalidates the existing data and application architectures; migration to sovereign cloud | Re-architecting |
| Regulatory / compliance change | New data sovereignty regulation requires fundamental restructuring of data flows and storage locations | Re-architecting |
| Lessons learned from implementation | Phase G reveals that the target architecture assumptions were flawed; multiple dispensations were granted | Incremental or Re-architecting |
| New capability requirement | Board mandates a new enterprise-wide digital customer experience capability not covered in the current target | Incremental (if additive) or Re-architecting |
| Technology end-of-life | A core platform in the target architecture is discontinued by the vendor; replacement requires broad architecture rethink | Re-architecting |
The decision criterion is straightforward: if the change can be absorbed within the existing approved target architecture, it remains in Phase H as an incremental update. If the change invalidates the target architecture itself, a new ADM cycle must begin — typically from Phase A (Architecture Vision) to re-establish the vision, scope, and stakeholder alignment, or from the Preliminary Phase if the framework itself needs revision.
Section 6: Architecture Repository Maintenance
A critical Phase H responsibility is keeping the Architecture Repository current. As the architecture evolves, the Repository must reflect the actual state of the enterprise — not a snapshot from the last ADM cycle. Stale repositories are a major source of governance failure.
| Repository Class | Phase H Action |
|---|---|
| Architecture Metamodel | Update if the tailored framework has changed; reflect any new artefact types approved by the Board |
| Architecture Capability | Record new skills, tools, or processes developed during this ADM cycle |
| Architecture Landscape | Promote implemented Transition Architectures to the new baseline; archive superseded architectures |
| Standards Information Base (SIB) | Add newly adopted technology standards; retire deprecated ones; update technology lifecycle status |
| Reference Library | Add lessons learned, updated patterns, and new reference models discovered during implementation |
| Governance Log | Record all Phase H decisions, dispensation resolutions, and change request outcomes |
Archiving deprecated architectures is as important as adding new ones. Retired baselines and superseded transition architectures must be preserved (not deleted) for audit, regulatory, and lessons-learned purposes. TOGAF recommends a formal archive policy defining retention periods and access controls.
Section 7: Technology Watch
Technology Watch is the proactive scanning of the external environment for emerging technologies, standards, and industry trends that could affect the architecture. It is a formal Phase H activity in TOGAF and feeds directly into the change assessment process.
- Scope of monitoring: Vendor roadmaps and product end-of-life dates; emerging open standards (e.g., new API protocols, cloud-native patterns); industry analyst assessments (Gartner Hype Cycle, Forrester); regulatory horizon scanning for technology-relevant legislation.
- Assessment process: For each monitored technology, the architect assesses: (a) current relevance to the architecture, (b) maturity level, (c) potential impact if adopted or if a current technology becomes obsolete, and (d) time horizon for action.
- TOGAF's approach to innovation: TOGAF does not prescribe specific technologies — it provides governance mechanisms to evaluate and absorb new technology in a controlled way. Technology Watch ensures the Architecture Board has advance notice of disruptive changes rather than reacting to them after they have already occurred.
Technology Watch outputs feed into the Architecture Repository's Standards Information Base and into Phase H change assessments. If an exam question asks which Phase H activity is responsible for proactively monitoring the technology landscape, the answer is Technology Watch — not Requirements Management (which is passive) and not the Compliance Assessment (which is Phase G).
Section 8: Phase H and Continuous Architecture
Modern organisations rarely complete one ADM cycle and then wait for the next. Agile EA, DevOps, and continuous delivery models mean that architecture must evolve continuously alongside product and service delivery. Phase H is the TOGAF mechanism that accommodates this reality.
Agile EA and continuous change management: In an Agile enterprise, Phase H operates as an ongoing function rather than a discrete phase with a defined end. The Architecture Board holds regular (e.g., bi-weekly or monthly) change review cadences. Incremental changes are batched and processed within a governance sprint, keeping the architecture aligned with evolving delivery without creating bottlenecks.
Relationship to DevOps and CI/CD: DevOps pipelines generate frequent changes to the application and technology layers. Phase H provides the governance wrapper: architecture guardrails are defined in Phase A–G and enforced via automated conformance checks in CI/CD pipelines; any change that exceeds pre-defined thresholds (e.g., a new data storage technology not in the SIB) automatically raises a Request for Architecture Change, triggering the Phase H assessment process. This integration ensures agility without sacrificing architectural integrity.
Candidates often treat Phase H as the termination of the ADM lifecycle. In TOGAF, Phase H is explicitly not an ending — it is the mechanism that determines what comes next. The ADM is a cycle, and Phase H is the decision gate that either continues managing the current architecture or initiates a new cycle. Never describe Phase H as "closing out" the architecture.
Revision Summary — Chapter 10
- Phase H ensures the architecture remains fit for purpose after implementation by monitoring change drivers and managing change requests throughout the operational lifecycle.
- Three change types: Simplification (no new ADM cycle; architecture team handles); Incremental (Architecture Board approves; current cycle continues); Re-architecting (sponsor decision; new ADM cycle from Phase A).
- The Change Request process has six steps: raise → impact assess → Board review → decide (accept/reject/defer/escalate) → update Repository → notify stakeholder.
- The Architecture Board's Phase H role is to monitor, assess change requests, review dispensations, and maintain the Governance Log — not to approve new architectures (that is Phases A–D).
- Six re-architecting triggers: business strategy change, disruptive technology, regulatory change, lessons learned revealing flawed assumptions, new enterprise capability requirement, technology end-of-life.
- All six Architecture Repository classes must be kept current in Phase H; the Architecture Landscape is updated to reflect the new baseline; deprecated architectures are archived (not deleted).
- Technology Watch proactively scans the external environment; findings update the Standards Information Base and feed Phase H change assessments.
- In Agile EA and DevOps contexts, Phase H operates as a continuous governance function; CI/CD pipeline thresholds can automatically trigger Change Requests, integrating architecture governance into delivery workflows.
Practice Questions
Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.
A. To oversee the implementation of architecture projects and ensure conformance to the Architecture Contract
B. To develop the Target Architecture across the Business, Data, Application, and Technology domains
C. To ensure the architecture remains fit for purpose by monitoring change drivers and managing change requests after implementation
D. To finalise the Architecture Roadmap and prioritise work packages for delivery
Explanation: Option C is correct. Phase H manages the architecture after it is implemented, ensuring it stays relevant as business and technology conditions evolve. Option A describes Phase G (Implementation Governance). Option B describes Phases B, C, and D. Option D describes Phase F (Migration Planning). A common trap is confusing Phase G and Phase H — Phase G governs during implementation; Phase H governs after implementation.
A. Simplification change — the architecture team should remove redundant components and update the Repository
B. Incremental change — the Architecture Board should approve the change and integrate it into the current ADM cycle
C. Simplification change — no Board approval required; update the Standards Information Base
D. Re-architecting change — the Architecture Board escalates to the sponsor; a new Statement of Architecture Work is issued and a new ADM cycle is triggered
Explanation: Option D is correct. A merger requiring integration of two incompatible enterprise architectures is a classic re-architecting scenario — it fundamentally invalidates the existing target architecture and business scope. Re-architecting changes require executive (sponsor) approval, a new Statement of Architecture Work, and a new ADM cycle. Options A and C are incorrect because simplification never involves strategic disruption. Option B is incorrect because incremental changes are absorbed within the current cycle without questioning the target architecture itself.
A. Revoke all dispensations and require projects to comply with the original architecture standards
B. Review the dispensations and formalise them as updates to the architecture standards in the Architecture Repository
C. Escalate the situation to the sponsor as a re-architecting change and trigger a new ADM cycle immediately
D. Leave the dispensations in place and document them only in the Governance Log without further action
Explanation: Option B is correct. When dispensations become standard practice, TOGAF guidance is to formalise them — they represent the reality of how the enterprise operates, and the architecture standards should reflect reality. This is a dispensation review activity within the ongoing Phase H Board responsibilities. Option A is disruptive and ignores the fact that the standards have effectively changed. Option C may be premature — if the dispensations represent incremental evolution rather than strategic disruption, a full re-architecting cycle is not warranted. Option D is insufficient — leaving the gap between standards and practice unaddressed undermines governance integrity.
A. Architecture Metamodel
B. Architecture Landscape
C. Standards Information Base
D. Architecture Capability
Explanation: Option C is correct. The Standards Information Base (SIB) is the repository class that holds approved technology standards, product lifecycles, and technology reference information. Technology Watch findings — new technologies to adopt, technologies approaching end-of-life, revised open standards — directly update the SIB. The Architecture Landscape (B) holds the current and transition architectures. The Architecture Metamodel (A) holds the framework structure. The Architecture Capability (D) records the organisation's EA practice skills and processes. None of these are primary targets of Technology Watch outputs.
A. Continuous architecture change management, where automated conformance thresholds in CI/CD pipelines trigger Requests for Architecture Change when violated
B. Transition Architecture iteration, where each sprint produces a new transition architecture reviewed by the Architecture Board
C. Architecture Contract enforcement, where the CI/CD pipeline must obtain a signed contract for each deployment
D. Gap Analysis automation, where the pipeline compares baseline and target architectures in every build
Explanation: Option A is correct. Phase H accommodates continuous delivery environments by operating as an ongoing governance function. Pre-defined architecture guardrails (standards, approved technologies, interface patterns) can be implemented as automated pipeline gates; a violation automatically raises a Request for Architecture Change, which enters the Phase H assessment process. This integrates architecture governance into delivery without slowing down the pipeline for routine changes. Option B describes a Phase E/F concept, not Phase H. Option C is a Phase G mechanism (Architecture Contracts are signed before implementation, not per deployment). Option D is a Phase B/C/D activity, not a pipeline integration.