In the lifecycle of the TOGAF Architecture Development Method (ADM), Phase H: Architecture Change Management is often the most misunderstood. While previous phases focus on building the architecture, Phase H focuses on sustaining it. It ensures that the investment made in creating the Target Architecture continues to deliver value as business needs, technologies, and regulations evolve.
Phase H is not a "one-and-done" activity; it is a continuous governance loop. Its primary goal is to determine whether a change requires a full re-entry into the ADM cycle or can be handled through simpler change management processes.
This guide zooms in exclusively on Phase H, detailing its four key deliverables with practical examples, decision criteria, and best practices.
Phase H is triggered by:
New Business Requirements: e.g., a merger, new product line, or market expansion.
Technological Shifts: e.g., emergence of AI, new cloud providers, or end-of-life legacy systems.
Regulatory Changes: e.g., new data privacy laws or financial compliance rules.
Performance Issues: e.g., the current architecture fails to meet SLAs.
The output of Phase H determines the path forward:
Simple Change: Update documentation only.
Significant Change: Initiate a new Request for Architecture Work (re-enter Phase A).
Architecture Updates are the revised versions of existing architecture artifacts and documents that reflect approved changes. These are not new creations but modifications to the baseline, target, or transition architectures defined in earlier phases.
To ensure the Architecture Repository remains the "single source of truth." If the live system changes but the documentation does not, the architecture becomes obsolete and useless for future planning.
Revised Architecture Definition Documents (ADD): Updating the Baseline and Target descriptions.
Updated Artifacts: Modifying ArchiMate diagrams, data models, or application portfolios.
Version Control: Clear labeling of version numbers (e.g., v1.0 to v1.1) and change logs.
Scenario: GlobalFin launches a new "Crypto Wallet" feature post-launch.
Action:
The Application Architecture Diagram is updated to include the new "Crypto Service Microservice."
The Data Model is updated to include new tables for wallet addresses and transaction hashes.
The Technology Architecture is updated to show the integration with a third-party blockchain node provider.
Output: GlobalFin_ADD_v2.1.pdf with a change log noting the addition of Crypto capabilities.
Automate Where Possible: Use tools that sync code repositories with architecture models to reduce manual update errors.
Incremental Updates: Do not wait for a major release to update docs. Update them as part of the sprint completion criteria.
A Change Request (CR) is a formal proposal to modify the architecture. In Phase H, CRs are the mechanism by which stakeholders propose changes. They are not just IT tickets; they are business-case-driven requests that assess impact on the enterprise architecture.
To provide a structured way to capture, evaluate, and approve/reject changes. It prevents "scope creep" and ensures that every change is aligned with architectural principles.
Requestor Details: Who is asking for the change?
Description of Change: What is being proposed?
Business Justification: Why is this needed? (ROI, compliance, risk reduction).
Impact Assessment: Preliminary analysis of cost, time, and technical complexity.
Priority: Critical, High, Medium, Low.
Scenario: The Marketing Department wants to integrate a new AI-driven customer chatbot.
Change Request Document:
ID: CR-2026-045
Requestor: Head of Digital Marketing
Justification: Reduce customer support costs by 30% and improve 24/7 availability.
Impact: Requires new API endpoints in the Customer Service Module; potential data privacy concerns regarding customer conversation logs.
Recommendation: Approve for further analysis in Phase A.
Standardize Templates: Use a consistent CR form across the organization.
Link to Strategy: Every CR must reference a strategic goal or principle. If it doesn’t align, reject it early.
The Architecture Contract is an agreement between the architecture function and other stakeholders (development teams, vendors, business units). In Phase H, these contracts are updated to reflect new realities, such as changed SLAs, new compliance requirements, or revised governance rules.
To enforce accountability. It ensures that those implementing or using the architecture adhere to the agreed-upon standards and constraints.
Scope of Agreement: What parts of the architecture are covered?
Compliance Requirements: Specific standards that must be met (e.g., security protocols, coding standards).
Service Level Agreements (SLAs): Performance, availability, and support expectations.
Governance Mechanisms: How compliance will be checked (e.g., automated scans, manual reviews).
Sign-offs: Formal acceptance by all parties.
Scenario: Due to new regulatory requirements, data residency rules have tightened.
Updated Contract Clause:
Previous: "All customer data must be encrypted."
Updated: "All EU customer data must be stored exclusively in AWS Frankfurt Region (eu-central-1). Any cross-border data transfer requires explicit legal approval."
Sign-off: CTO, Chief Compliance Officer, and Lead Cloud Architect sign the updated contract.
Make it Living: Don’t lock contracts in PDFs. Use collaborative platforms where terms can be tracked and audited.
Regular Reviews: Schedule quarterly reviews of architecture contracts to ensure they remain relevant.
A Request for Architecture Work (RAW) is the formal trigger to start a new ADM cycle. In Phase H, if a change is deemed too complex for simple updates, a new RAW is generated. This effectively closes the current phase and hands off to Phase A of a new project.
To distinguish between minor tweaks and major transformations. It ensures that significant changes receive the full rigor of the ADM, including stakeholder analysis, visioning, and detailed design.
Problem Statement: What is the business issue?
Scope: What parts of the enterprise are affected?
Constraints: Budget, time, technology limits.
Stakeholders: Who needs to be involved?
Success Criteria: How will we know the new architecture is successful?
Scenario: GlobalFin decides to acquire a smaller fintech company. This is not a simple feature add; it requires integrating two entire IT landscapes.
New Request for Architecture Work:
Title: "Post-Merger Integration Architecture"
Scope: Full integration of AcmeFintech’s core banking system with GlobalFin’s platform.
Objective: Achieve single view of customer within 12 months.
Budget: $2M allocated for architecture and initial integration.
Outcome: This RAW triggers a new ADM cycle, starting again at Phase A: Architecture Vision.
Clear Thresholds: Define clear criteria for when a CR becomes a RAW. For example, any change costing >$100k or impacting >3 business units requires a new RAW.
Executive Sponsorship: Ensure the new RAW has high-level backing before initiating the full ADM cycle.
Not every change follows the same path. Use this matrix to decide how to process inputs in Phase H:
| Change Type | Complexity | Impact | Action | Deliverable Focus |
|---|---|---|---|---|
| Correction | Low | Low | Fix error in implementation | Architecture Updates |
| Enhancement | Medium | Medium | Add minor feature | Change Request + Architecture Updates |
| Adaptation | High | High | Respond to major market/regulatory shift | Request for Architecture Work (New Cycle) |
Documentation Drift: Failing to update Architecture Updates leads to a repository that no one trusts.
Ignoring Change Requests: Treating CRs as mere IT tickets rather than architectural decisions leads to siloed solutions.
Over-Governing: Requiring a full ADM cycle for trivial changes slows down innovation. Use the decision matrix to balance rigor and agility.
Weak Contracts: Without updated Architecture Contracts, there is no enforcement mechanism for compliance.
Phase H is the bridge between architecture design and long-term business value. It transforms the static outputs of Phases A-G into a dynamic, living framework that adapts to change.
By meticulously managing Architecture Updates, processing Change Requests with discipline, enforcing Architecture Contracts, and knowing when to trigger a new Request for Architecture Work, organizations ensure their enterprise architecture remains a strategic asset rather than a historical artifact.
In the fast-paced digital economy, the ability to manage change effectively is not just an architectural skill—it is a competitive advantage. Phase H provides the structure to make that possible.
