Unified Digital Experience — MDM use cases and capability ownership

Source	client-resources/unified-digital-use-cases-capability (1).docx
Type	DOCX, four sections
Origin	Manulife architecture — individual authors not stated
Dated	Not stated · received 2026-10-06
Classification	Internal

What it is

A desired-state inventory written to assess Informatica MDM as both the system of record and the Enterprise Relationship Registry (ERR), including its real-time capabilities. It defines eleven use cases, indicative channel NFRs, seven questions for Informatica and a proposed ownership map across nine capability domains.

The assignments are explicitly proposals under review, not evidence that the capabilities exist. The document says several are only partly built or in design, some have no implementation, and blank owners remain unresolved.

It aligns with our concern, but does not prove an Informatica shortcoming

The document asks the same architectural question as our review: can a mastering platform become an operational service without making channels depend directly on it? It does not answer that question. Its hardest requirements remain questions for Informatica:

• real-time registry reads and updates while on the onboarding and authorization path;
• event intake, runtime APIs and deployment across two Canadian regions;
• ordering and idempotency through merge → unmerge → merge;
• worst-case unmerge propagation;
• API-driven licensing and gaps in the current MDM setup; and
• support for MDM as a write-side event publisher with a downstream projection serving runtime reads.

That last question is the key point of alignment. The document also requires customer reads to remain available during an MDM outage. Both statements imply that MDM can be the mastered write authority without being the synchronous channel-serving dependency.

The ownership map preserves boundaries that a “central system of record” must not erase

The proposed map does not make MDM authoritative for every customer-related fact:

• BU administration systems remain the legal systems of record for policies, accounts and plans.
• MDM is proposed for ECID, matching, survivorship, golden party attributes and identity cross-references.
• The ERR records product relationships, roles, status and effective dates; whether Informatica MDM physically implements that logical role is what the assessment must prove.
• PingAuthorize or another PDP makes access decisions; MDM supplies facts, not authorization.
• Consent and preferences retain separate authorities.
• The profile read API has no assigned owner, while projection builders and the event backbone sit with platform teams.

“MDM as core system of record” is therefore defensible only when scoped to mastered party identity, cross-references and accepted relationship state. It does not make MDM the legal product record, the policy decision point or the runtime profile API.

Where it agrees with the target architecture

The target architecture draft uses the same command/query split: Informatica MDM is the sole issuer of rel_id and publishes changes, while an event-fed Cosmos DB profile serves the dashboard with no MDM or BU call on login. The new inventory makes that split an explicit vendor question and adds the requirement that reads survive an MDM outage.

It also adopts the mechanism our product-ownership recommendation argued for: BU systems publish ownership changes. The authority differs — the draft and this inventory route those events through MDM, while R1.3 proposed a separate relationship registry — but the source fact is now converging. Manulife has since ruled for this inventory's assignment: MDM is the ERR, and ECID is rel_id (ADR-0006). MDM can accept and master a BU-authored relationship; it cannot originate the legal fact that a policy or account was created.

Official product documentation: capability exists, guarantees remain open

The product family can support the proposed shape at a feature level:

• Multidomain MDM 10.5 Business Entity Services documents REST operations for search, match, merge and unmerge in its API reference.
• MDM SaaS supports hierarchical and non-hierarchical relationships with configured relationship attributes; a record can participate in multiple hierarchies.
• The licensed Business 360 Events Connector can publish create, update, delete, merge, unmerge and restore events from MDM SaaS to Kafka and other targets in real time or batches.
• Informatica's cloud metering documentation includes daily or monthly incoming API requests and MDM streaming-ingestion volume as potential licence meters.

Those documents do not establish the required p95/p99 latency, 1,200 requests per second, per-customer ordering, idempotency, replay, worst-case unmerge propagation or Canadian dual-region RPO/RTO. The event connector exposes an event ID and time-window parameters, but its public documentation does not promise exactly-once delivery or downstream idempotency.

Deployment model changes the answer. For on-premises Multidomain MDM 10.5, Informatica's infrastructure guidance recommends standalone application-server instances with external load balancers for real-time API calls, while stating that batch jobs do not fail over. Its documented two-system zero-downtime pattern uses Oracle GoldenGate and identical Operational Reference Store structures and key values. These are reasons to establish Manulife's exact edition and topology first, not evidence that the target is impossible.

Gaps the Informatica session must close

The installed product is unknown. No edition, version, deployment model, topology, licensed modules, owner or current workload is identified. General product capability is not evidence that Manulife's configuration can meet the target.

The latency target is a channel target, not yet an MDM commitment. The profile API must achieve p95 under 150 ms and p99 under 400 ms at 1,200 requests per second, but its owner is blank. If a projection serves the API, Informatica must commit to the write and publication path rather than be benchmarked as the read store.

Freshness starts too late. The p99 under 30-second measure starts at MDM publish. The target architecture admits product ownership remains batch until BUs emit events. The business SLO must run from the authoritative BU commit through MDM to the profile, or upstream delay disappears from the measurement.

Real-time matching is a first-access gate. The target architecture gives a customer no dashboard until MDM assigns rel_id. The UCL current-state evidence records Group Benefits, the pilot, as the only BU with no match-and-merge capability and with product data unmapped across applications. Match latency, ambiguity, outage and stewardship are therefore customer-journey requirements, not only data-quality concerns.

Event semantics are requirements, not demonstrated capabilities. Every create, update, merge and unmerge must be published; two regions must consume independently without losing per-customer order; repeats must be safe; and unmerge must have a bounded propagation window. The document correctly asks Informatica to state the guarantees.

Position for the meeting

Informatica MDM is now the mastered write authority and the ERR (ADR-0006). The product-fit gate remains, and it now decides what MDM's delivery must change rather than whether MDM holds the role. Preserve the event-fed operational profile for channel reads, keep product facts in BU systems of record, and keep authorization in PingAuthorize and the BU. Go-live waits until the exact Manulife product and topology demonstrate the latency, throughput, event, multi-region, recovery and lifecycle requirements.

The meeting one-pager is Informatica MDM as customer system of record.