Learn Architecture

Source · TOGAF Standard, 10th Edition — ADM: Phase H

Why this matters

ADM — Phase H

Architectures don't stand still — technology, business and requirements change. Phase H — Architecture Change Management keeps the delivered architecture relevant and decides whether a change is small (handled by governance) or big enough to trigger a new ADM cycle.

The concept

Phase H §Objectives

Phase H establishes a change management process for the new enterprise architecture, monitors changes (technology, business, capability), and assesses their impact. It classifies changes as simplification, incremental, or re-architecting — the last of which starts a new ADM iteration.

Change classification

Phase H §Steps

Simplification change — handled via change management. Incremental change — handled via architecture amendment/governance. Re-architecting change — significant; requires putting the whole architecture through a new ADM cycle. Phase H decides which, based on impact.

How it connects

ADM flow

Phase H closes the loop back to the top of the ADM: a re-architecting change generates a new Request for Architecture Work and re-enters at Phase A (or Preliminary if capability itself must change). It works closely with Requirements Management and governance (Phase G).

Common traps

Phase H manages change to the deployed architecture — not the original build (that's G).
Three change types: simplification, incremental, re-architecting; only re-architecting triggers a new ADM cycle.
Phase H can loop back to Phase A (or Preliminary) via a new Request for Architecture Work.

Key takeaways

Phase H manages changes to the deployed architecture to keep it relevant.
Classifies change as simplification / incremental / re-architecting.
Re-architecting changes trigger a new ADM cycle.