Appearance
Unified customer architecture — the strategy
| Source | client-resources/unified-customer-architecture.pdf |
| Type | PDF, 25 pages, presentation-style long-form |
| Origin | Canada Segment Enterprise Architecture |
| Dated | 2026-06-13 · marked for review |
| Classification | Manulife internal |
What it is
The most complete statement of a target state in anything we have been given. It is a strategy document, not a solution design: it defines the layers, the ownership boundaries between them, and the discipline that keeps those boundaries honest. Its opening claim sets the tone — "the goal is not modernization, it is determinism" — and it returns to that repeatedly: identity is verified, never inferred; schema is approved, not invented; where uncertainty exists the architecture suppresses rather than guesses.
The starting position it describes
Nine secure portals. Five mobile apps. Fourteen discrete experiences. Between three and twelve manual steps to link a product. Zero unified customer identifiers at runtime.
Today identity is created at the product or business-unit level rather than as an enterprise relationship; product relationships resolve independently inside BU systems and never centrally; profile and preference data is duplicated with no single current view; consent lives in compliance artifacts rather than runtime decisions; and operational customer context does not exist, so channels either query mastering systems directly or render canned data.
The four layers
The architecture is layered, and the document is emphatic that each layer does one job:
- Experience composes.
- Access and authorization govern.
- Operational profile serves.
- Enterprise data (MDM) masters.
"Mastering does not serve UI. Serving does not master." The read side and the write side are two stores with two jobs: MDM is a property graph of nodes and typed edges optimised for resolution, survivorship, lineage and ontology evolution; the operational profile is a denormalised document keyed by relationship id, optimised for low-latency reads by channels, BFFs, widgets and agents. The projection between them is event-driven, idempotent, replayable and keyed on (rel_id, ontology_version, event_id).
The named components
| Concern | Component named |
|---|---|
| Identity provider | ForgeRock CIAM (already operated) |
| Mastered relationship graph | MDM, elevated to governed ontology graph |
| Consent system of record | OneTrust, with authenticated user context |
| Policy decision point | PingAuthorize (formerly Symphonic), PEP in the BFF tier |
| Runtime customer context | Operational profile, projected from MDM |
Identity and authorization deliberately stay inside a single Ping support boundary. Every policy decision is logged with a full attribute trace.
Visibility and action are separate decisions
The section that most directly shapes the portal: "what the customer sees is not what the customer can do." The PDP consumes relationship, product, consent, entitlement and jurisdiction inputs and emits two answers per request — can the customer see this, and can the customer act on it — with stricter thresholds on the second. A product may be owned, and ready, and still not actionable.
Identity resolution
A five-stage pipeline, deterministic at the boundaries and probabilistic only in the middle (K-means sits in stage three). Verification is mandatory where ambiguity exists. Recovery must not mint a new identity when an existing one should have been recovered.
The seven workstreams
The document decomposes delivery into seven independently shippable workstreams across three phases — and explicitly notes that the landing-page MVP already follows this pattern, with interim correlation keys swapped for enterprise relationship ids over time.
| # | Workstream | Owner | Phase |
|---|---|---|---|
| 01 | Canonical ontology and contracts | MDM | 1 |
| 02 | Match/merge and mastered graph | MDM | 1 |
| 03 | Product auto-association | MDM + BU | 2 |
| 04 | Consent management integration | OneTrust | 2 |
| 05 | Operational profile and runtime APIs | Platform | 1 |
| 06 | Policy and entitlement (PDP) | Identity | 2 |
| 07 | Experience integration | Channels | 1 |
Phase 1 is backbone and shell; Phase 2 is auto-link and consent-aware; Phase 3 is AI-assisted reasoning over the governed graph — candidate-only, written through governed flows.
It also traces a single login end to end: twenty-one numbered interactions across eight participants in four phases (bootstrap, authenticate, compose, render), with two failure variants that fork inside a phase and rejoin at the next boundary. Group Benefits gets its own ontology section, because a member holds a reference to a sponsor's policy rather than owning one — which generalises to every future audience.
Why it matters here
This is the document the SOW means by "the existing target state vision and architecture direction". Our WS 2 target state architecture has to either build on it, extend it, or argue against it — and say which. Three things make that non-trivial:
- It is dated June 2026, before the ADS and before both critical reviews. Nothing tells us whether it is still the segment's position.
- Its Phase 2 content — ECID, MDM, consent, PDP/UES entitlements — is precisely what the GARB ADS excludes from MVP1. So the MVP is Phase 1 of this plan, or it is something else, and the material does not say which.
- Workstream 07 assumes "forward-compatible contracts so identity-key swaps are non-breaking." Whether the MVP's contracts actually have that property is an architectural question we can answer, and it is worth answering early.
Open questions raised
- Is this still the endorsed Canada Segment target state as of today, and who owns it?
- Is the MVP being built as Phase 1 of this architecture, or independently of it?
- Are PingAuthorize, OneTrust and the operational profile funded and staffed, or aspirational?
- Are the MVP's BFF and Integration API contracts forward-compatible with an ECID swap?