Unified Client Experience — business capabilities and HLD deep dive
| Source | client-resources/Enterprise Customer Experience_UCL_v2.0 copy.pdf |
| Type | PDF, 26 slides — v2.0 |
| Origin | Core Architecture — authored by Obe Gopalan |
| Cover date | 7 May 2026 · exported 2026-09-17 |
| Classification | Manulife internal |
What it is
The layer between the June 2026 strategy and a solution design: a conceptual high-level design with a named business-capability taxonomy under it, per-capability BU discovery questionnaires, and a staged path to a first deliverable with the people assigned to each stage. It is the first artifact we hold that is explicitly organised as business capabilities rather than components, and the first that names client individuals against work.
It is also the first artifact to use the phrase "Priority Business Capabilities (North Star)" in a document authored by Core Architecture — which bears directly on open question 8.
The conceptual HLD
Four layers, the same four the June strategy names, with the capabilities that sit in each:
| Layer | Component | Capabilities named on the slide |
|---|---|---|
| Customer experience | Unified Customer Experience | Unified enrolment · aggregated portfolio view · unified profile management · seamless application routing |
| Access and authorization | Customer Authentication | Universal authentication · SSO and token minting · session management · identity federation |
| Access and authorization | Enterprise Entitlement Service | Coarse-grained authorization · policy governance (PDP) · B2B relationship traversal · event-driven lifecycle |
| Operational data | Customer Profile Management | Unified customer profile · customer identifiers · real-time BU sync · common capabilities · operational data contract |
| Enterprise data | MDM & Entity Resolution | Golden record · entity resolution engine · survivorship rules · batch stitching · analytical data |
Arrows are runtime data flow top-down and MDM feed bottom-up. Five business capabilities are tagged across those layers: Customer Experience Management, Customer Profile Management, Customer Identity Management, Customer Authorization Management, Customer Product Management.
This is the June strategy's "experience composes, access governs, profile serves, MDM masters" restated as a capability map. Nothing contradicts it. What is new is the seam it draws inside the access layer — authentication and entitlement as two components, not one.
"Enterprise coarse, BU fine"
The single most consequential sentence in the deck, on the Enterprise Entitlement slide:
Enterprise coarse, BU fine — enterprise decides 'can access product'; BU decides 'can do action'
The enterprise entitlement service makes coarse-grained product-access decisions — can this customer reach GB, can they see Insurance — and fine-grained authorization stays with the business unit. Supporting principles on the same slide: deny by default, consent as a mandatory PDP input, externalized authorization, relationship-derived entitlements from B2B traversal, eventual consistency via events, and full replay for regulatory review.
This is Manulife's own position on the question R1.2 argues and open question 17 tracks. It does not settle R1.1 — coarse-grained access control says nothing about which identity arrives at the Data API — but it means the display-versus-servicing split the segment assessment argues for in B-01 is already enterprise architecture's stated model. The disagreement is with the ADS, not with the client.
The layer specifications
Slides 11–14 give each layer a description, architectural principles, technical enablers, the data that belongs there, and the roles needed to reach a technical solution. Positions that constrain our recommendations:
Authentication. "Graceful degradation — if CIAM is down, BU local auth continues with reduced scope." Progressive trust: base auth for browsing, step-up only for sensitive actions. BU autonomy preserved — the enterprise federates identity, BUs keep app-level sessions. Stateless propagation via signed tokens, no shared server-side sessions.
Operational data. "Availability over consistency — serve stale data rather than fail; eventual consistency is OK." Also: "No direct BU-to-BU data sharing — all cross-BU data flows through the operational layer", "Profile is a projection, not a copy", "Contracts are APIs", and "Consent is a runtime filter — not a static permission; checked on every access." The Operational Data Contract is described as a formal API between each BU and the enterprise, with latency, throughput and freshness targets per contract.
MDM. Explicitly not the real-time layer. "BU systems are sources, not consumers — BUs feed data in, not query MDM directly." Consent is mastered here — type, version, channel, timestamp, status — and PIPEDA compliance depends on its audit trail. Records cannot be merged without customer consent.
Roles needed. Each layer lists the roles required to get from HLD to technical solution: security architect and CIAM specialist for authentication; those plus a B2B relationship modeler, legal and compliance analyst and policy analyst for entitlement; integration architect, per-BU integration lead, API architect and a data contract owner for operational data; enterprise data architect, privacy specialist, MDM specialist, data quality architect and per-BU data stewards for MDM. This is a staffing model stated as an architecture input, and it is useful evidence for D3.2.
The architecture principles, and a defect in them
Ten principles are named: Least Privilege, Loose Coupling, Idempotency, Separation of Concerns, Zero Trust, Observability, Single Source of Truth, Scalability by Design, Immutability. Four of them — Idempotency, Observability, Scalability by Design and Immutability — carry the identical body text as Least Privilege, verbatim: "Customer access is restricted to only what is necessary, for the shortest duration required…"
That is a copy-paste defect, not a position. It matters because these are the closest thing we have to a client-authored answer to D2.1's guiding principles section, and a principle with no definition cannot be applied to a design review. Worth raising directly with the author — it is a two-line fix on their side and it saves us inventing four definitions and attributing them.
The executive summary and first deliverable
Programme vision, quoted, because nothing else in the corpus states one this plainly:
A unified digital experience brings everything together in one experience to empower customers and advisors to manage health, wealth, and business needs in one place, with clarity, confidence, and ease.
Priority business capabilities (North Star), 2026 — two, not fourteen:
- Customer identity and profile — one customer, one relationship, across products
- Unified secure experience layer — a single post-login homepage and navigation organized around the customer
First deliverable — the GB/GR scenario: establish new customers as a single customer relationship; streamline onboarding, enrolment, MID setup and automatic product linking and delinking; a unified homepage showing everything the customer owns.
The path to solution design, with names
Three stages, each with activities, deliverables and a named team. Only the first deliverable is marked complete — North Star Identity and Profile Business Capabilities.
| Stage | Deliverables |
|---|---|
| North Star Conceptual HLD | North Star identity and profile business capabilities ✅ · North Star experience business capabilities · North Star conceptual HLD |
| North Star High-Level Logical Solution | North Star OKRs and high-level requirements · North Star high-level logical solution design |
| First Deliverable Detailed Logical Solution | First deliverable OKRs and requirements · first deliverable detailed logical solution design |
Each stage validates with BU Digital Product, Legal and Compliance first, then BU IT architects, VPs and CIOs. Named participants across the three stages: Core Business — Cigi, Estelle, Nadia, Patrick. Core Architecture — Obe, Bianca, Rishi, Oana. CIAM — Sanjeev, Josh. MDM — Theo, Jen, Mike, Naveed, Taqui. EA — Bianca, Mazhar, Sanjeev, Ilker. CSDO — Mehmet. WSDO — TBD. GB — Gary. CR — Andrei. Bank — Tom. Wealth — Rishi. Plus BU digital product owners, BU data stewards, IT security and risk, and "IIC/Affinity — Confluence documentation" in place of a person.
This is the closest thing to an answer to CR-25 that exists, and it should be used as the starting list rather than asking the question cold.
The BU discovery questionnaires
Slides 4–8 give five capabilities the same four-part treatment: customer irritant, enterprise requirements, key activities, and a BU requirement analysis split into integration, dependencies and risks. The questions are specific — "what is the earliest system-confirmed signal that a product is owned, and can you emit it?", "can the BU consume profile from a central source without local persistence, and if not, why?", "where could we accidentally show a product as ready when it is not?"
This is a ready-made agenda for the WS 2 alignment sessions, written by the client, in the client's vocabulary. Using it rather than our own is cheaper and lands better — see WS 2 tasks.
The appendix — new current-state evidence
Technology current state PoV (slide 21) is the first per-BU current-state matrix we hold, RAG rated across six lines of business:
| Capability · component | GB | Bank | Insurance | Affinity | Wealth | Retirement |
|---|---|---|---|---|---|---|
| Identity and authentication | ✅ CIAM CAN · ⚠️ SSO with employer | ✅ CIAM CAN | ✅ CIAM CAN · ⚠️ Seg funds and Vitality on Salesforce | ✅ CIAM CAN | ✅ CIAM CAN | ✅ CIAM CAN |
| Session continuity and context propagation | ✅ CIAM synched to BU | ✅ | ✅ | ✅ | ✅ | ✅ |
| Onboarding and provisioning orchestration | 🔴 Policy and membership based | 🔴 CIF based | 🔴 Policy based | 🔴 Policy based | 🔴 Vendor specific | 🔴 Local based on entitlement |
| Product data | ❌ In multiple applications, not mapped | ✅ Mostly centralized on core banking | DMO (retail) · ⚠️ Salesforce (seg funds, Vitality) | MDM | EDL and vendor system | MPS/SLX system |
| Operational customer context | ❌ No match and merge | ✅ Match and merge | ✅ | ✅ | ✅ | ✅ |
| Third-party integration | To be validated | Credit card via CIAM federation SSO | To be validated | To be validated | FCC via CIAM federation SSO | To be validated |
Three readings matter. Identity is the healthy row — CIAM CAN across all six, which is a second independent client source for R5.2. Onboarding and provisioning orchestration is red in every column — six different mechanisms, no shared one. GB is the exception on data, with no match and merge and product data unmapped across multiple applications — and GB is also the primary pilot.
The slide's own caveat: "Deeper analysis and validation is required prior to design or implementation. Seeking support to continue analysis." And slide 19's note records that the current state hypothesis is based on discovery across Bank, GB, GWAM and CR only — Insurance and Affinity discovery is pending.
The three-phase roadmap and the pilot comparison
Foundation → Pilot → Scale (slide 23): "establish the core and resolve legacy fragmentation", then "activate the connection, prove the identity-first and real-time business case", then "mandate the platform, decommission legacy silos and extend to the enterprise." Each of the five business capabilities gets activities in each phase.
Pilot comparison (slides 24–25): MVP1 is GB + GRS — largest customer base, highest convergence, already targeted for 2026, risk rated HIGH. MVP1A is a parallel track on a lower-lift BU (CR, Affinity, Bank or IIC), risk MODERATE, with much of the BU still marked TBC. GB dependencies: MDM participation, CIAM resolution for sponsor-managed authentication, sponsor contractual obligations. The recommendation is to start GB match and merge in MDM in parallel, since it is the larger problem.
Why it matters here
It changes the North Star finding. Observation 1 has been that no agreed North Star exists and both sides say so. That is now more precise rather than wrong: a North Star statement exists, dated, authored by Core Architecture, with two 2026 priority capabilities and a named validation path — and its own path-to-solution slide shows the validation with BU IT VPs and CIOs as not yet done. The gap is endorsement, not authorship.
It gives the target state a capability spine. D2.1 has to map onto something the client recognises. Five business capabilities across four layers is that thing, and it is theirs.
It is the client's own answer on entitlement. Enterprise coarse, BU fine is a position, it is written down, and it is compatible with R1.2. Our recommendation gets stronger by citing it rather than by arguing around it.
It is in tension with the MVP on sequencing. The first deliverable here is GB/GR identity, enrolment and automatic product linking. The MVP under review builds a dashboard that explicitly excludes ECID, MDM, consent and centralized authorization. Both cannot be the first deliverable, and nothing we hold reconciles them.
And it does not describe the thing being built. The words BFF, micro-frontend, Integration API, Next.js, Redis and APIM appear nowhere in 26 slides. The experience layer is named as an outcome — unified secure landing page, unified homepage — with no component architecture under it. That is consistent with a conceptual HLD and it is also the gap D2.1 exists to close: this deck stops exactly where the portal architecture, application and platform architecture and integration architecture sections begin.
Open questions raised
- Is the 7 May 2026 cover date current for v2.0? The deck was exported the day it reached us and the version is 2.0, so the cover may be stale from v1. Which version and date are of record matters because the June 2026 strategy would otherwise be the later document.
- Has the North Star conceptual HLD been validated with BU IT architects, VPs and CIOs — stage 1 activity 4 — and what came back?
- Which is the first deliverable: this deck's GB/GR identity and enrolment scenario, or the ADS's dashboard MVP? If both, what is the dependency between them?
- Four of the ten architecture principles carry Least Privilege's definition. What are their intended definitions?
- Does "Enterprise coarse, BU fine" have an owner and a target platform, and is it the same PingAuthorize PDP the June 2026 strategy names?
- Slide 22 records the target entitlement layer as "ABAC/Policy Data Point" — is that the Policy Decision Point, or a separate Policy Information Point concept?
- Insurance and Affinity current-state discovery is pending. When, and does anything in the GB/GR first deliverable depend on it?
- Is the "central customer management layer" — described on slide 20 as "not MDM" — the same component as the June strategy's operational profile?