Principles as a Weapon Against Three Country GMs
A retail bank is consolidating four CRM systems into one. The EA team has a target architecture approved in Phase D and compliance reviews booked for Phase G. Three country general managers, who hold local budgets, have funded their own CRM extensions and are lobbying to keep them. Branch staff unions are hostile, citing past failed rollouts. The CIO suggests issuing a new architecture principle - 'all customer data shall be mastered in the enterprise Customer Data Model' - and enforcing it at the compliance reviews. The lead architect is asked whether that will work and what else should be done before the reviews.
1. Evaluate the CIO's proposal to issue and enforce this principle.
Read the worked answer
It will not produce compliance, and it misuses the instrument.
- Wrong level of abstraction. An architecture principle is a general, enduring rule that guides decision-making across many decisions. 'All customer data shall be mastered in the CDM' is a specific target-architecture decision dressed as a principle. The principle level is something like 'customer data is a shared enterprise asset: captured once, mastered once, shared by all' - with the CDM appearing as a standard that implements it. Getting this wrong means the principle will be amended or ignored the first time a genuine exception arises.
- Missing definition elements. A usable principle carries a name, statement, rationale, and implications. Nobody has asked what the CDM commitment costs each country in migration, training, and local reporting. Without implications, the principle has no credibility with the people who must fund it.
- Wrong authority. Principles are ratified by the Architecture Board, not issued by the CIO alone. An unratified principle will be contested at exactly the moment it matters.
- Wrong enforcement point. Enforcing at a Phase G compliance review means enforcing after the GMs have spent the money. At that point the realistic options are flagging non-compliance or granting a dispensation - both of which are worse outcomes than a conversation held during Phase A and B.
What would work better: fewer, well-formed principles ratified by the Board; the CDM expressed as a standard with a roadmap; the GMs engaged as stakeholders while the target can still be shaped.
2. Which ADM guidelines and techniques would you apply before the Phase G reviews, and why those?
Read the worked answer
The choice of technique should follow the diagnosis: the problem is political and readiness-related, not analytical.
- Stakeholder Management. Map power versus interest. The country GMs are high power, high interest - they must be engaged and their requirements brought inside the architecture, not instructed. The unions are high interest, low power, but they can slow or stop rollout at branch level; they need genuine involvement and honest communication about what changes for staff. The current plan treats both groups as obstacles, which guarantees resistance.
- Business Scenarios. Use these with the GMs to make explicit what business outcome each local extension serves. Two possible results, both useful: the outcome is genuinely local and regulatory (it becomes a real requirement in the Architecture Requirements Specification), or it is habit (it becomes a retirement item in the roadmap).
- Business Transformation Readiness Assessment. Readiness factors - leadership commitment, funding alignment, branch operational capacity, union relations, skills, past change track record - are rated for maturity with actions attached. The reference to past failed rollouts is a readiness data point, not an anecdote; it should drive the sequencing.
- Gap analysis and consolidation between the four current CRM landscapes, to size the change honestly and expose duplication the GMs may not know they are funding.
Run these in parallel in the next few weeks; they are cheap compared with a contested Phase G.
3. How should the three GMs and their funded extensions be handled?
Read the worked answer
Bring them inside the architecture rather than positioning them as violations.
- Assess, don't classify. For each extension, establish what business or regulatory requirement it serves and what it costs to maintain. An architecture that assumes away three markets' requirements will simply be bypassed - that is the predictable outcome of ignoring funded reality.
- Split genuine need from local preference. Genuine, defensible requirements must be reflected in the Architecture Requirements Specification and, if necessary, in the target architecture itself (for example, defined configuration points or an approved local extension pattern). If the target cannot accommodate real requirements, the target is wrong and it is cheaper to correct it now than at implementation.
- Where the extension is preference, retire it through the roadmap, not through confrontation. A Transition Architecture showing when each extension is withdrawn, and what replaces it, gives the GM a defensible answer to their own stakeholders.
- Use the Board for arbitration, not the architect. The Board is the body with authority to grant bounded dispensations and to rule on conformance.
- Contract with the budget holders. Because the GMs control funding, an Architecture Contract with them - not only with IT delivery - is what makes the decision stick.