The central judgement in Phase H is how large a response a change deserves.
Criteria and the Board’s challenge
The governance body must set criteria that separate changes needing only an update to the architecture from those needing a fresh ADM cycle. Two principles guide them: favour changes tied directly to business value, and avoid “creeping elegance” (change for its own sake). The criteria are hard to fix in advance because enterprises accept risk differently, and they improve as governance matures.
- The Architecture Compliance report says whether a proposed change complies. If not, an exemption may be granted where the rationale is valid; where the impact is high, a strategy to manage it is needed.
- The Architecture Board reviews and approves Requests for Change. Its key question is whether to approve now or whether a project already planned in a Transition Architecture will deal with the issue anyway. An innovative solution or request can itself drive architecture change.
- A filtering function decides which phases a change affects; a change that only touches migration, for instance, does not concern the development phases. Existing methods such as PRINCE2, ITIL and Catalyst should be adapted rather than replaced.
Three categories of change
| Category | Normal handling | Typical driver |
|---|---|---|
| Simplification | Change management techniques | Cutting investment |
| Incremental | Change management, or partial re-architecting | Getting more value from investment already made |
| Re-architecting | The whole architecture goes round the cycle again | Increasing investment to create new value |
Categorising a change depends on logging every event that might affect the architecture, resourcing architecture tasks, assessment by whoever is responsible for those resources, and an impact evaluation.
Maintenance or redesign: the stakeholder guideline
| If the change… | It is more likely to be handled by… |
|---|---|
| affects two or more stakeholders | architecture redesign and re-entry to the ADM |
| affects only one stakeholder | change management |
| can be allowed under a dispensation | change management |
| Example from the Standard | Category and response |
|---|---|
| Significant impact on business strategy | Re-architecting: redo the whole Enterprise Architecture |
| A new technology or standard | Incremental: refresh only the Technology Architecture |
| Ten infrastructure systems consolidated into one | Simplification via change management: nothing above the physical layer changes, but the Technology Baseline description does |
A refreshment cycle (partial or complete re-architecting) is needed when the Foundation Architecture must be brought back into line with business strategy, when components and deployment guidelines change substantially, or when important product standards change in ways that significantly affect end users (regulatory change, for example). Every refreshment cycle requires a new Request for Architecture Work. Figure 13.1 brings these checks together as one decision path.
Common trap: Every Change Request should go back to Phase A - simplification and many incremental changes are handled through change management; a new cycle is for multi-stakeholder, strategic or major standards change.