7.1 Phase H: Architecture Change Management
Key Takeaways
- Phase H objectives are to ensure the architecture lifecycle is maintained, the Architecture Governance Framework is executed, and the Enterprise Architecture Capability meets current requirements.
- A simplification change can normally be handled via change management techniques and is often driven by a requirement to reduce investment.
- An incremental change may be handled by change management or may require partial re-architecting, depending on the nature of the change.
- A re-architecting change requires putting the whole architecture through the architecture development cycle again.
- If a change impacts two or more stakeholders it likely needs architecture redesign and ADM re-entry; one stakeholder or a dispensation suggests change management.
7.1 Phase H: Architecture Change Management
Phase H establishes procedures for managing change to the new architecture. The Foundation syllabus asks you to briefly explain the purpose of Phase H and describe its objectives. Phase H keeps the architecture fit for purpose after implementation and decides, for each change, whether it can be handled as maintenance or needs a new architecture development cycle.
Objectives of Phase H
- Ensure that the architecture lifecycle is maintained
- Ensure that the Architecture Governance Framework is executed
- Ensure that the Enterprise Architecture Capability meets current requirements
The goal is to make sure the architecture continues to achieve its original target business value, and that the organization responds to change in a controlled way.
Steps of Phase H
- Establish Value Realization Process — influence business projects to exploit the enterprise architecture for value realization
- Deploy Monitoring Tools — monitor technology changes, business changes, enterprise architecture capability maturity, asset management, QoS performance, and business continuity requirements
- Manage Risks — manage enterprise architecture risks and provide recommendations for IT strategy
- Provide Analysis for Architecture Change Management — analyze performance and conduct enterprise architecture performance reviews with service management, assess Change Requests and reporting
- Develop Change Requirements to Meet Performance Targets
- Manage Governance Process — arrange a meeting of the Architecture Board or other governing council to decide on handling changes
- Activate the Process to Implement Change — produce a new Request for Architecture Work and request for investment, and ensure changes are captured in the Architecture Repository
Drivers for Change
TOGAF recognizes that change can be strategic and top-down (to enhance or create new capability), bottom-up (to rectify or enhance capabilities in operation and maintenance), or driven by experience with previously delivered project increments that are now in operations but still connected to ongoing projects.
| Technology-related drivers | Business drivers |
|---|---|
| New technology reports | Business-as-usual developments |
| Asset management cost reductions | Business exceptions |
| Technology withdrawal | Business innovations |
| Standards initiatives | Business technology innovations |
| Strategic change |
The Enterprise Architecture Change Management Process
The change management process decides how each change is handled. To determine whether a change is a simplification, incremental, or re-architecting change, TOGAF describes activities such as:
- Registration of all events that may impact the architecture
- Resource allocation and management for architecture tasks
- Assessment by the process or role responsible for architecture resources of what should be done
- Evaluation of impacts
The Three Classes of Change
| Class of change | How it is handled | Typical underlying requirement |
|---|---|---|
| Simplification change | Can normally be handled via change management techniques | Often driven by a requirement to reduce investment |
| Incremental change | May be handled via change management techniques, or may require partial re-architecting, depending on the nature of the change | Driven by a requirement to derive additional value from existing investment |
| Re-architecting change | Requires putting the whole architecture through the architecture development cycle again | Driven by a requirement to increase investment in order to create new value for exploitation |
Guidelines for Maintenance Versus Architecture Redesign
TOGAF gives a rule of thumb:
- If the change impacts two stakeholders or more, it is likely to require an architecture redesign and re-entry to the ADM.
- If the change impacts only one stakeholder, it is more likely to be a candidate for change management.
- If the change can be allowed under a dispensation, it is more likely to be a candidate for change management.
When re-entry to the ADM is needed, Phase H activates the process by producing a new Request for Architecture Work, which starts a new cycle at Phase A (and the Preliminary Phase can be revisited if the capability itself must change).
Examples
| Situation | Likely classification and handling |
|---|---|
| Retire a duplicate reporting tool to cut license costs, with one business owner affected | Simplification change — handled via change management |
| Add a new payment method to an existing e-commerce platform, affecting only the online sales team | Incremental change — likely change management, possibly partial re-architecting if integration impacts spread |
| Merge two companies' customer service operations and systems, affecting many stakeholders | Re-architecting change — new Request for Architecture Work and a new ADM cycle |
| A system cannot meet a new standard yet, and a time-limited dispensation is acceptable | Candidate for change management under a dispensation |
Outputs of Phase H
| Output | When it is produced |
|---|---|
| Architecture updates | For maintenance changes |
| Changes to architecture framework and principles | For maintenance changes |
| New Request for Architecture Work | To move to another ADM cycle for major changes |
| Statement of Architecture Work (updated) | If necessary |
| Architecture Contract (updated) | If necessary |
| Compliance Assessments (updated) | If necessary |
Common Exam Pitfalls
- Using "Simplicity change." The TOGAF term is simplification change.
- Assuming incremental change always needs re-architecting. It may be handled by change management or by partial re-architecting.
- Forgetting the stakeholder rule of thumb. Two or more stakeholders affected suggests redesign and ADM re-entry; one stakeholder or a dispensation suggests change management.
- Confusing Phase H with Phase G. Phase G governs implementation; Phase H manages ongoing change to the architecture and its capability.
Which statement is an objective of Phase H: Architecture Change Management?
According to TOGAF, how is a re-architecting change handled?
A proposed change affects three different stakeholder groups across the enterprise. What does the TOGAF rule of thumb suggest?
Which class of change is described as typically driven by a requirement to derive additional value from existing investment?