Phase H: Architecture Change Management
Keeping the architecture alive
Phase H establishes and runs the architecture change management process. It monitors technology, business and regulatory drivers, assesses change requests, decides how to respond, and maintains the Architecture Repository so the architecture reflects reality. It also drives value realisation and triggers re-entry into the ADM.
Change categories: simplification (cost reduction with no business change), incremental (adds value without altering the core architecture), and re-architecting (a major change to the architecture itself, which returns you to the Preliminary Phase or Phase A). Small changes may be handled through requirements management and project change control; significant ones need the Architecture Board.
Traps
- Phase H is not project change control; that belongs to Phase G and the project's own change process.
- Not every change request warrants a new ADM cycle; classification determines the response.
- The Board decides whether a change is significant; the architect detects and proposes.
- Value realisation and monitoring tools belong to Phase H, not to Phase G deployment governance.
Worked rule of thumb
Ask three questions in order. Does it change the core of the architecture? That is re-architecting. Does it add capability without changing the core? That is incremental. Is it purely cost or simplification? That is simplification. Then route to the matching governance path; if re-architecting, return to Phase A with a new Request for Architecture Work.