Phase H: Architecture Change Management

Objective | Approach | Inputs | Steps | Outputs

This chapter looks at establishing procedures for managing change to the new architecture.

Figure: Phase H: Architecture Change Management


The objective of Phase H is to establish an architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G. This process will typically provide for the continual monitoring of such things as new developments in technology and changes in the business environment, and for determining whether to formally initiate a new architecture evolution cycle.

Phase H also provides for changes to the framework and principles set up in the Preliminary Phase.


The goal of an architecture change management process is to ensure that changes to the architecture are managed in a cohesive and architected way, and to establish and support the implemented enterprise architecture as a dynamic architecture; that is, one having the flexibility to evolve rapidly in response to changes in the technology and business environment.

The change management process once established will determine:

The architecture change management process is very closely related to the architecture governance processes of the enterprise, and to the management of the Architecture Contract (see Architecture Contracts) between the architecture function and the business users of the enterprise.

In Phase H it is critical that the governance body establish criteria to judge whether a change request warrants just an architecture update or whether it warrants starting a new cycle of the Architecture Development Method (ADM). It is especially important to avoid "creeping elegance", and the governance body must continue to look for changes that relate directly to business value.

Guidelines for establishing these criteria are difficult to prescribe, as many companies accept risk differently, but as the ADM is exercised, the maturity level of the governance body will improve, and criteria will become clear for specific needs.

The Drivers for Change

There are many technology-related drivers for architecture change requests. For example:

This type of change request is normally manageable primarily through an enterprise's change management and architecture governance processes.

In addition there are business drivers for architecture change, including:

This type of change request often results in a complete re-development of the architecture, or at least in an iteration of a part of the architecture development cycle, as explained below.

The Change Management Process

The change management process needs to determine how changes are to be managed, what techniques are to be applied, and what methodologies used. The process also needs a filtering function that determines which phases of the architecture development process are impacted by requirements. For example, changes that affect only migration may be of no interest in the architecture development phases.

There are many valid approaches to change management, and various management techniques and methodologies that can be used to manage change; for example, project management methods such as PRINCE 2, service management methods such as ITIL, management consultancy methods such as Catalyst, and many others. An enterprise that already has a change management process in place in a field other than architecture (for example, in systems development or project management) may well be able to adapt it for use in relation to architecture.

The following describes an approach to change management, aimed particularly at the support of a dynamic enterprise architecture, which may be considered for use if no similar process currently exists.

The approach is based on classifying required architectural changes into one of three categories:

  1. Simplification change: A simplification change can normally be handled via change management techniques.
  2. Incremental change: An incremental change may be capable of being handled via change management techniques, or it may require partial re-architecting, depending on the nature of the change. See Guidelines for Maintenance versus Architecture Redesign for guidelines.
  3. Re-architecting change: A re-architecting change requires putting the whole architecture through the architecture development cycle again.

Another way of looking at these three choices is to say that a simplification change to an architecture is often driven by a requirement to reduce investment; an incremental change, by a requirement to derive additional value from existing investment; and a re-architecting change, by a requirement to increase investment in order to create new value for exploitation.

To determine whether a change is simplification, incremental, or re-architecting, the following activities are undertaken:

  1. Registration of all events that may impact the architecture
  2. Resource allocation and management for architecture tasks
  3. The process or role responsible for architecture resources has to make assessment of what should be done
  4. Evaluation of impacts

Guidelines for Maintenance versus Architecture Redesign

A good rule-of-thumb is:

For example:

In particular, a refreshment cycle (partial or complete re-architecting) may be required if:

If there is a need for a refreshment cycle, then a new Request for Architecture Work must be issued (to move to another cycle).


Inputs to Phase H are:


Key steps in Phase H include:

  1. Monitor Technology Changes
  2. Monitor Business Changes
  3. Assess Changes and Development of Position to Act
  4. Arrange Meeting of Architecture Board (or other governing council)

    The aim of the meeting is to decide on handling changes (technology and business).


The outputs of Phase H are:

return to top of page


The TOGAF document set is designed for use with frames. To navigate around the document:

return to top of page


Downloads of the TOGAF documentation, are available under license from the TOGAF information web site. The license is free to any organization wishing to use TOGAF entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A hardcopy book is also available from The Open Group Bookstore as document G063.

Copyright © 1999-2006 The Open Group, All Rights Reserved
TOGAF is a trademark of The Open Group