Unified customer experience target architecture — executive briefing

Source	client-resources/Unified_Customer_Exec_Briefing_v3.pdf — the same 14 slides as Unified_Customer_Exec_Briefing_v3.pptx, committed in e8bbb04; the slide text is character-for-character identical
Type	Slide deck, 14 slides. The PPTX was generated with PptxGenJS (revision 34); the PDF is a Keynote export
Origin	Canada Segment Enterprise Architecture. The PPTX properties name Gopi Balasingam, Chief Architect, as creator and last editor
Dated	Cover October 2026 · Draft for review · PPTX created 2026-10-06 · PDF exported 2026-10-07 · received 2026-10-07
Classification	Internal
Purpose	The client's first draft of the executive presentation for next week's readout, sent as a reference for curating ours

What it is

The executive cut of the target architecture draft, UC-ARCH-002 v2. It adds no architecture. The fifteen decisions, fifteen validation items, service levels, failure table, token hops and seven future-state capabilities are the DOCX's, reduced to one idea per slide: summary, customer lens, the stack on one page, three principles, the future state, three decisions to make now, resilience, security, failure behaviour, service levels, technology register and what must hold true before build.

Its ask is on slide 2: "Owners for 15 validation items, and business sign-off on service levels and identity proofing." Nothing in it asks for money, a date or a scope decision on the MVP.

The cover line, "One identity. One relationship. One truth.", and the principles on slide 5 are the vocabulary the room will hear: mastered once, projected twice; seeing is not doing; fail visibly, never open.

What the briefing changes from the draft

Product-ownership events moved from the future list into the decisions to make now. In the DOCX, BU ownership events were card 6 of the future state, with product ownership "limited to batch" without them. Slide 8 makes "One business event contract" — every BU publishing purchase, ownership and status events when they happen — one of three decisions to make now, and slide 6 tags commerce and cross-sell DECIDE NOW. That is R1.3's mechanism, and it is what O4 asked us to argue: move the ownership event into the foundation. The authority still differs — events go to MDM, not a separate registry — but the client now puts the fact we said the dashboard depends on into the foundation.

Search before create is also a decision to make now. Card 1, real-time identity, is tagged DECIDE NOW, and slide 8's first decision, "MDM resolves first," frames it as matching at origination rather than reconciliation after the fact. It does not address the back book, or Group Benefits, which the UCL deck records as the only BU with no match and merge.

The profile is declared a read model. Decision 3 — "Journey state, decisioning and preferences get their own services" — protects MDM and the Customer Profile Store from becoming a general customer database. It is consistent with the MDM meeting brief. It does not move the journey-status store or the cross-BU Process APIs out of MuleSoft; slide 7 still draws both inside the integration layer, tagged LAYER ON, so R6.3's disagreement stands.

Validation items have owning groups. Every V-item in the DOCX read "to assign." Slide 14 maps all fifteen to a team: business owners (V-09), each BU with Fraud and Identity (V-15), each BU's API team (V-13), Identity (V-04, V-12), MDM (V-03, V-11), Legal, Privacy and Records (V-07), Platform, Network and Integration (V-01, 02, 05, 10), Security and Procurement (V-06), and Observability with Architecture (V-08, V-14). The ask on slide 2 is therefore for named individuals inside those groups. V-14 — rewriting the ADS authentication table — sits with Architecture, not with the delivery team that owns the ADS.

Where the briefing claims more than the draft

These are wording problems, not design changes. Each is the kind an executive will quote back or an ARB reviewer will catch, and each is better raised with the author before the meeting than in it.

• "Settled" against "to validate". Slide 2 lists "15 architecture decisions" under What is settled. Slide 13 lists nine components still to validate before build, and they are the ones most decisions rest on: MDM, MuleSoft, PingAuthorize, Cosmos DB, messaging, audit, CI/CD, observability and token exchange. The DOCX's own framing is decided unless the check fails.
• "IN PLACE". Slide 6 tags the enterprise profile — "MDM is the truth; the Customer Profile Store serves every channel" — IN PLACE. It means in the foundation design. Nothing is deployed, and the DOCX's status box says it does not claim any integration is. An executive will hear built.
• Three descriptions of replication. Slide 4 says MDM "publishes once per change"; slide 5 says it "publishes each change to both regions" (the DOCX's dual-publish, D-10); slide 9 says the Customer Profile Store is "kept in sync across both regions; writes accepted in either" (Cosmos multi-region write). The DOCX's model is the second, with each region projecting independently.
• The "today" panel. Slide 10 draws today as Browser → BFF → MuleSoft → BU Data API on service credentials. In that position the ADS has an Integration API over Azure APIM, and the experience map has di-dashboard-services; neither is MuleSoft. The panel is the only place the MVP appears in the deck, unnamed and redrawn on the target's platform.
• Canada East's zones. Slide 9 gives Canada Central "3 availability zones" and Canada East "Paired region." The DOCX is explicit that Canada East has none, so after a Canada Central loss the whole load runs on a single-zone stamp. "100% of peak traffic carried by either region alone" still has no peak figure behind it (open question 24).
• 99.95% "login to dashboard". Slide 12 measures availability from login. Slide 11 says CIAM down means "No new logins," and CIAM sits outside both regional stamps. The target cannot exceed CIAM's own availability and is not derived from it (R2.2).
• The register's counts. Slide 13's "9 decided here" names six components. The other two categories name all of theirs.
• "Service continues" when MDM is down. True for existing customers. A new customer gets a pending state and no dashboard, which slide 3 presents as "Honest by default." For a Group Benefits pilot without match and merge, pending is the common case, not the exception.

What it leaves out

Everything the DOCX left out, plus the DOCX's own caveats on classification, Redis keys and resilience asymmetry. For our deck the omissions that matter are the ones SOW D2.2 requires:

• Per-line-of-business considerations. Three BUs appear — GB, Affinity, GWAM — and only as owners of V-13. D2.2 requires considerations for each participating line of business; the UCL deck has six and the ADS seven BU Data APIs (open question 49).
• Business benefits. Slide 8's "Unlocks …" lines are the only benefit statements, and they are capabilities, not outcomes.
• The path from the MVP to the target. No phase, date, release or sequencing; the GARB ADS is absent except through V-14 (open question 44). The capability roadmap's horizons do not appear.
• The rest of the estate and the portal. Azure APIM, the API Mediation proposal, gb-core-authx, micro-frontend loading, the design system, content and staff-channel authorization — all absent, as in the DOCX.
• Cost. None, and no ask for funding.

What it means for our presentation

Theirs owns the vision and the components; ours should own what theirs does not. Restating its stack, principles, failure table or service levels in a Konrad deck puts two versions of the same facts in the room. The SOW's D2.2 elements their deck does not carry are the per-BU considerations, the business and technology benefits, and — with WS 3 — the sequence from the October MVP to this target. Those are where our slides earn their place, along with the gaps above that no client document has filled: portal and micro-frontend architecture, the design system, staff and advisor access, and gateway coexistence.

Speak its vocabulary. Customer ID or rel_id, not ECID; Customer Profile Store, not D3; seeing is not doing; Token A and Token B; decide now and layer on. Our recommendations still say ECID and relationship registry, and until open question 48 is answered that reads as a different architecture rather than a different word.

Match its shape. One claim per slide, a headline that states it, a customer lens before the stack, and a closing slide of owners and asks. Our diagram exports already carry the Manulife skin.

Take a side on its three decisions. Back decision 2 outright — it is R1.3's ownership event, and backing it costs us nothing. Back decision 3. Support decision 1 with its condition attached: search before create needs match and merge in the pilot BU, and Group Benefits does not have it. Argue R6.3 on card 2 before the meeting rather than in it; a recommendation does not close a question in front of the client's executives.

Clear the overclaims with the author first. The list above is a conversation with Gopi Balasingam, not material for our slides. If his deck still says settled and in place on the day, our slides should use decided pending validation and designed without commenting on the difference.

Open questions raised

• What does the briefing ask executives to endorse — the fifteen decisions, the three decide-now choices, or owners for the fifteen validation items — and does the readout present one deck or two? Open question 3 and open question 52.
• Is the MVP the first increment of this target? The deck's only reference to it is the unlabelled today panel. Open question 44.