Approach

TL;DR

Phase H manages architecture change in a cohesive and architected way. It defines when the architecture can change after implementation, when a new ADM cycle should begin, and how change requests are classified.

General approach

The approach in Phase H is to manage changes to the architecture in a cohesive and architected way.

Architecture change management determines two things.

1. The circumstances under which the enterprise architecture, or part of it, can change after implementation.
2. The circumstances under which a new ADM cycle should be started to develop new architecture.

This prevents architecture change from becoming ad hoc.

Decision criteria

Phase H should establish criteria for judging Change Requests.

The core question is:

Does this change warrant an architecture update, or does it warrant starting a new ADM cycle?

The answer should be judged against business value.

This connects back to the purpose of Phase H: managing change to the new architecture while ensuring the architecture continues to deliver value.

Change request structure

Part of the Phase H procedure is defining the structure of a change request.

TOGAF suggests describing a change request with three main attributes.

Attribute	What it explains
Description	what change is being proposed
Rationale	why the change is needed
Impact assessment	what the change affects and how significant the effect is

The impact assessment helps determine whether the change is small enough to handle through normal change management or significant enough to require architecture work.

Change classification

TOGAF recommends three broad change types.

Change type	Meaning	Typical handling
Simplification change	a change that can be handled through available change management techniques	manage through normal change management
Incremental change	a change that may require partial re-architecting	create a new Request for Architecture Work if architecture work is needed
Re-architecting change	a change that requires a new architecture development cycle	create a new Request for Architecture Work and start a new ADM cycle

ADM trigger

For incremental and re-architecting changes, the Enterprise Architect may need to create a new Request for Architecture Work.

That request can kick off a new ADM cycle.

The point is not that every change restarts ADM.

The point is that Phase H provides the governance logic for deciding which changes can be handled operationally and which changes require architecture development.

Exam note

• Phase H manages architecture change in a cohesive and architected way.
• The change management process defines when the architecture can change after implementation.
• It also defines when a new ADM cycle should be initiated.
• Change requests should be judged using criteria, especially business value.
• A change request is described by description, rationale, and impact assessment.
• TOGAF classifies changes as simplification, incremental, or re-architecting changes.
• Simplification changes can be handled through available change management techniques.
• Incremental changes may require partial re-architecting.
• Re-architecting changes require a new architecture development cycle.
• Incremental and re-architecting changes may require a new Request for Architecture Work.