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

16.1 Objectives

The objectives of Phase H are:

• To ensure that baseline architectures continue to be fit-for-purpose
• To assess the performance of the architecture and make recommendations for change
• To assess changes to the framework and principles set up in previous phases
• To establish an architecture change management process for the new enterprise architecture baseline that is achieved with completion of Phase G
• To maximize the business value from the architecture and ongoing operations
• To operate the Governance Framework

16.2 Approach

The goal of an architecture change management process is to ensure that the architecture achieves its original target business value. This includes managing changes to the architecture in a cohesive and architected way.

This process will typically provide for the continual monitoring of such things as governance requests, new developments in technology, and changes in the business environment. When changes are identified, change management will determine whether to formally initiate a new architecture evolution cycle.

Additionally, the architecture change management process aims 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.

Monitoring business growth and decline is a critical aspect of this phase. Usage of the enterprise architecture is the most important part of the architecture development cycle. All too often the business has been left with an enterprise architecture that works for the organization of yesterday but may not give back sufficient capability to meet the needs of the enterprise of today and tomorrow.

In many cases the architecture continues to fit, but the solutions underlying them may not, and some changes are required. The enterprise architect needs to be aware of these change requirements and considers this an essential part of constant renewal of the architecture.

Capacity measurement and recommendations for planning is a key aspect of this phase. While the architecture has been built to deliver a steady state Business Architecture with agreed capacity during the lifecycle of this enterprise architecture, the growth or decline in usage needs to be continually assessed to ensure that maximum business value is achieved.

For example, some Solution Architectures may not lend themselves to be scalable by a large factor - say 10 - or alternative solutions may be more economic when scaled up. While the architecture specifications may not change, the solutions or their operational context may change.

If the performance management and reporting has been built into the work products through previous phases, then this phase is about ensuring the effectiveness of these. If there needs to be additional monitoring or reporting, then this phase will handle the changes.

The value and change management process, once established, will determine:

• The circumstances under which the enterprise architecture, or parts of it, will be permitted to change after deployment, and the process by which that will happen
• The circumstances under which the architecture development cycle will be initiated again to develop a new architecture

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 Part VII, 49. 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.

An Architecture Compliance report should state whether the change is compliant to the current architecture. If it is non-compliant, an exemption may be granted with valid rationale. If the change has high impact on the architecture, then a strategy to manage its impact should be defined.

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.

16.2.1 Drivers for Change

The main purpose for the development of the enterprise architecture so far has been strategic direction and top-down architecture and project generation to achieve corporate capabilities. However, enterprise architecture does not operate in a vacuum. There is usually an existing infrastructure and business which is already providing value.

There are also probably drivers for change which are often bottom-up, based upon modifying the existing infrastructure to enhance functionality. Enterprise architecture changes this paradigm by a strategic top-down approach to a degree, although the delivery of increments makes the equation more complex.

There are three ways to change the existing infrastructure that have to be integrated:

• Strategic, top-down directed change to enhance or create new capability (capital)
• Bottom-up changes to correct or enhance capability (operations and maintenance) for infrastructure under operations management
• Experiences with the previously delivered project increments in the care of operations management, but still being delivered by ongoing projects

Governance will have to handle the co-ordination of these Requests for Change, plus there needs to be a lessons learned process to allow for problems with the recently delivered increments to be resolved and changes made to the Target Architectures being designed and planned.

A lessons learned process ensures that mistakes are made once and not repeated. They can come from anywhere and anyone and cover any aspect of the enterprise architecture at any level (strategic, enterprise architecture definition, transition, or project). Often an enterprise architecture-related lesson may be an indirect outcome of a lesson learned elsewhere in the organization.

The Architecture Board (see Part VII, 47. Architecture Board) assesses and approves Requests for Change (RFC). An RFC is typically in response to known problems but can also include improvements. A challenge for the Architecture Board when handling an RFC is to determine whether it should be approved or whether a project in a Transition Architecture will resolve the issue.

When assessing project or solution fit into the architecture, there may also be the case when an innovative solution or RFC drives a change in the architecture.

In addition, there are many technology-related drivers for architecture Change Requests. For example:

• New technology reports
• Asset management cost reductions
• Technology withdrawal
• Standards initiatives

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:

• Business-as-usual developments
• Business exceptions
• Business innovations
• Business technology innovations
• Strategic change

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.

16.2.2 Enterprise Architecture Change Management Process

The enterprise architecture 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 PRINCE2, 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:

• Simplification change: A simplification change can normally be handled via change management techniques.
• 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 16.2.3 Guidelines for Maintenance versus Architecture Redesign for guidelines).
• 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 is driven by a requirement to derive additional value from existing investment; and a re-architecting change is driven 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

16.2.3 Guidelines for Maintenance versus Architecture Redesign

A good rule-of-thumb is:

• If the change impacts two stakeholders or more, then it is likely to require an architecture redesign and re-entry to the ADM.
• If the change impacts only one stakeholder, then it is more likely to be a candidate for change management.
• If the change can be allowed under a dispensation, then it is more likely to be a candidate for change management.

For example:

• If the impact is significant for the business strategy, then there may be a need to redo the whole enterprise architecture - thus a re-architecting approach.
• If a new technology or standards emerge, then there may be a need to refresh the Technology Architecture, but not the whole enterprise architecture - thus an incremental change.
• If the change is at an infrastructure level - for example, ten systems reduced or changed to one system - this may not change the architecture above the physical layer, but it will change the Baseline Description of the Technology Architecture. This would be a simplification change handled via change management techniques.

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

• The Foundation Architecture needs to be re-aligned with the business strategy.
• Substantial change is required to components and guidelines for use in deployment of the architecture.
• Significant standards used in the product architecture are changed which have significant end-user impact; e.g., regulatory changes.

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

16.3 Inputs

This section defines the inputs to Phase H.

16.3.1 Reference Materials External to the Enterprise

• Architecture reference materials (see Part IV, 36.2.5 Architecture Repository)

16.3.2 Non-Architectural Inputs

• Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work) identified during Phases E and F

16.3.3 Architectural Inputs

• Organizational Model for Enterprise Architecture (see Part IV, 36.2.16 Organizational Model for Enterprise Architecture), including:
  • Scope of organizations impacted
  • Maturity assessment, gaps, and resolution approach
  • Roles and responsibilities for architecture team(s)
  • Constraints on architecture work
  • Budget requirements
  • Governance and support strategy
• Tailored Architecture Framework (see Part IV, 36.2.21 Tailored Architecture Framework), including:
  • Tailored architecture method
  • Tailored architecture content (deliverables and artifacts)
  • Configured and deployed tools
• Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work)
• Architecture Vision (see Part IV, 36.2.8 Architecture Vision)
• Architecture Repository (see Part IV, 36.2.5 Architecture Repository), including:
  • Re-usable building blocks
  • Publicly available reference models
  • Organization-specific reference models
  • Organization standards
• Architecture Definition Document (see Part IV, 36.2.3 Architecture Definition Document)
• Architecture Requirements Specification (see Part IV, 36.2.6 Architecture Requirements Specification), including:
  • Gap analysis results (from Business, Data, Application, and Technology Architectures)
  • Architectural requirements
• Architecture Roadmap (see Part IV, 36.2.7 Architecture Roadmap)
• Change Request (see Part IV, 36.2.11 Change Request), - technology changes:
  • New technology reports
  • Asset management cost reduction initiatives
  • Technology withdrawal reports
  • Standards initiatives
• Change Request (see Part IV, 36.2.11 Change Request), - business changes:
  • Business developments
  • Business exceptions
  • Business innovations
  • Business technology innovations
  • Strategic change developments
• Change Request (see Part IV, 36.2.11 Change Request), - from lessons learned
• Transition Architecture (see Part IV, 36.2.22 Transition Architecture)
• Implementation Governance Model (see Part IV, 36.2.15 Implementation Governance Model)
• Architecture Contract (signed) (see Part VII, 49. Architecture Contracts)
• Compliance Assessments (see Part IV, 36.2.13 Compliance Assessment)
• Implementation and Migration Plan (see Part IV, 36.2.14 Implementation and Migration Plan)

16.4 Steps

The level of detail addressed in Phase H will depend on the scope and goals of the overall architecture effort.

The order of the steps in Phase H (see below) as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established architecture governance.

The steps in Phase H are as follows:

• 16.4.1 Establish Value Realization Process
• 16.4.2 Deploy Monitoring Tools
• 16.4.3 Manage Risks
• 16.4.4 Provide Analysis for Architecture Change Management
• 16.4.5 Develop Change Requirements to Meet Performance Targets
• 16.4.6 Manage Governance Process
• 16.4.7 Activate the Process to Implement Change

16.4.1 Establish Value Realization Process

Influence business projects to exploit the enterprise architecture for value realization (outcomes).

16.4.2 Deploy Monitoring Tools

Ensure monitoring tools are deployed and applied to enable the following:

• Monitor technology changes which could impact the Baseline Architecture
• Monitor business changes which could impact the Baseline Architecture
• Business value tracking; e.g., investment appraisal method to determine value metrics for the business objectives
• Monitor enterprise architecture capability maturity
• Track and assess asset management programs
• Track the QoS performances and usage
• Determine and track business continuity requirements

16.4.3 Manage Risks

Manage enterprise architecture risks and provide recommendations for IT strategy.

16.4.4 Provide Analysis for Architecture Change Management

Provide analysis for architecture change management:

• Analyze performance
• Conduct enterprise architecture performance reviews with service management
• Assess Change Requests and reporting to ensure that the expected value realization and Service Level Agreement (SLA) expectations of the customers are met
• Undertake a gap analysis of the performance of the enterprise architecture
• Ensure change management requests adhere to the enterprise architecture governance and framework

16.4.5 Develop Change Requirements to Meet Performance Targets

Make recommendations on change requirements to meet performance targets and development of position to act.

16.4.6 Manage Governance Process

Manage governance process and framework for architecture:

• Arrange meeting of Architecture Board (or other Governing Council)
• Hold meeting of the Architecture Board with the aim of the meeting to decide on handling changes (technology and business and dispensations)

16.4.7 Activate the Process to Implement Change

Activate the architecture process to implement change:

• Produce a new Request for Architecture Work and request for investment
• Ensure any changes implemented in this phase are captured and documented in the Architecture Repository

16.5 Outputs

The outputs of Phase H are:

• Architecture updates (for maintenance changes)
• Changes to architecture framework and principles (for maintenance changes)
• New Request for Architecture Work (see Part IV, 36.2.17 Request for Architecture Work), to move to another cycle (for major changes)
• Statement of Architecture Work (see Part IV, 36.2.20 Statement of Architecture Work), updated if necessary
• Architecture Contract (see Part IV, 49. Architecture Contracts ), updated if necessary
• Compliance Assessments (see Part IV, 36.2.13 Compliance Assessment), updated if necessary

return to top of page