The Post-Go-Live Field Request
Eight months after a new CRM go-live, the sales director requests a customer-tier field and a real-time integration to a partner's loyalty platform. Separately, the CRM vendor announces end-of-support for the underlying database in 14 months. The architecture contract requires all changes to pass through a change request. The approved target architecture assumed batch integration only, and the partner has not been through security review. The EA team can complete one impact assessment this quarter; the sales director wants the field live in four weeks.
1. How should the architect classify and route the two changes?
Read the worked answer
Split the two changes. The field plus partner integration is an incremental change: it extends the current architecture but changes an external interface and security posture, so it needs impact assessment and likely security review, not automatic approval. The database end-of-support is a technology lifecycle trigger that probably requires re-entry to the ADM at Phase D, and possibly Phase E/F for migration, because it may invalidate the technology architecture and roadmap. Both should enter through the change request process, but they should not be treated as one queue item. The four-week field request can be fast-tracked only if the impact assessment shows low risk and the partner passes security review.
2. What should the impact assessment cover, and which artefacts are updated?
Read the worked answer
The impact assessment should cover affected architecture domains, the data model and field ownership, interface and partner security, non-functional requirements, architecture contract obligations, cost and risk, and the 14-month database deadline. Update the architecture repository: baseline and target descriptions, interface catalog, roadmap, architecture requirements, governance log and change register. If the change is minor, update the Architecture Definition Document and proceed under Phase G/H governance; if major, create a new Statement of Architecture Work or re-enter the ADM. Record the decision and rationale so the next change is not assessed from scratch.
3. What triggers full ADM re-entry versus a minor update?
Read the worked answer
Re-enter the ADM when the change alters architecture principles, scope, a cross-domain dependency, a technology standard at end-of-life, or a regulatory or safety obligation. A new field with a local report is usually a minor update; a real-time partner integration that changes the target integration style is more than cosmetic; a database end-of-support is a clear trigger. Use the change classification to decide, but let the impact assessment provide the evidence. The Architecture Board should confirm the route, and the governance log should show why the chosen route was proportionate.