Informatica MDM as the Customer System of Record — Meeting Brief

Audience	Informatica and Manulife MDM technical leads
Purpose	Test whether the installed platform can carry the proposed operational role
Position	MDM is the mastered write authority and enterprise relationship registry (ADR-0006); keep runtime reads in an event-fed profile
Status	Working-session position. The role is decided; the product fit is not

Accept the direction, with a boundary and a proof gate

Informatica MDM is the core system of record for mastered customer identity, cross-references and accepted relationship state. It should not become the synchronous profile read path or the authority for every customer-related fact. Manulife made MDM the enterprise relationship registry on 2026-10-12 (ADR-0006). This session tests whether the installed platform can carry that role.

Use the pattern Manulife's own material already describes:

BU facts and profile changes → MDM mastering → ordered change events → operational profile → channels

• BU systems remain the legal record for policies, accounts, plans and relationship start or end.
• MDM matches, merges, applies survivorship, issues the enterprise relationship ID and records the accepted cross-reference and relationship.
• The operational profile serves web, mobile and other channels; login makes no MDM or BU call.
• PingAuthorize decides enterprise visibility, and each BU retains action and record authorization.
• Consent and preferences retain their own systems of record.

This supports the VP's direction without turning a mastering outage or stewardship queue into a channel outage. The trade-off is an eventually consistent read model and an additional projection to operate. In return, channels get predictable latency and availability, and MDM can optimize for identity quality, governance and write integrity.

The new Manulife document confirms the concern

The MDM use-case and ownership inventory positions MDM as system of record and ERR, but explicitly asks Informatica whether a write-side, event-publishing MDM with a downstream runtime projection is a supported pattern. It also requires customer reads to remain available during an MDM outage.

The target architecture draft already uses that split: MDM is the sole issuer of rel_id, while an event-fed Cosmos DB profile serves the dashboard with no MDM or BU call on login. Its v2 also concedes that product ownership remains batch until BUs publish ownership events.

Informatica's public documentation establishes baseline capability, not target fit: Multidomain MDM 10.5 has match, merge and unmerge APIs, and MDM SaaS can publish those lifecycle events. It does not publish the ordering, replay, latency or two-region guarantees required here; its on-premises HA guidance also says batch jobs do not fail over. The shortcomings below are proposition gaps, not claims that the features are absent.

Five shortcomings in the current proposition

1 · The product configuration is unnamed. No edition, version, hosting model, licensed modules, topology, current workload or service owner is recorded. A general product capability is not proof that Manulife's deployment can use it.

2 · The channel NFRs are not MDM commitments. The proposed Profile API must sustain 1,200 requests per second at p95 under 150 ms, p99 under 400 ms and 99.95% availability. Its owner is blank, while reads must survive MDM failure. Those facts favour a projection; Informatica must prove the ingest and publish path, not claim the channel read target.

3 · Freshness is measured after the hidden delay. The p99 under 30-second target starts at MDM publish. The customer outcome starts when a BU creates or changes a product. Without a BU-authored event, the target architecture says ownership remains batch, however quickly MDM later publishes it.

4 · Matching is on the first-access critical path. No rel_id means onboarding status rather than a dashboard. Group Benefits, the pilot, is the only BU the UCL evidence records with no match-and-merge and with product data unmapped across applications. Match latency, no-match, ambiguity, outage and stewardship therefore affect customer access directly.

5 · Event and multi-region guarantees are requested, not demonstrated. Informatica documents event publication, but not the ordering, duplicate, replay, propagation or two-region guarantees required here. Unmerge needs a bounded worst-case propagation time, and dual publication to two brokers is not proof that MDM itself is active-active.

Questions that close the gaps

1. What exactly are we assessing? Name the product, edition, version, deployment model, current topology, licensed modules, support horizon, production workload and API-driven cost model.
2. Is the proposed boundary a supported reference pattern? Show the supported topology for MDM as write authority and event publisher, with an independent operational projection serving runtime reads.
3. What performance has been proven? Provide production-like results for matching, relationship updates, merges, reconciliation and publication at the proposed peak. Commit to freshness from the authoritative BU write to profile visibility, not only from MDM publish.
4. What are the event contracts and guarantees? Cover create, update, merge, unmerge and relationship termination; ordering key, duplicate handling, replay, schema evolution, retention, gap recovery and the worst-case unmerge window.
5. How does two-region failure work? Clarify supported topology, write ownership, conflict handling, Canadian residency, failover and demonstrated RPO/RTO. Show that registrations queue safely and channel reads remain available through MDM failure and recovery.
6. How does onboarding fail safely? State match thresholds, false-link controls, ambiguous and no-match flows, manual approval, reversibility and queue/backpressure limits.
7. Where does MDM's authority stop? Confirm that BU systems author legal product facts, PingAuthorize and BUs authorize access, and the operational profile serves channels. rel_id and ECID are one identifier, named rel_id.

Decision criterion

The role is decided, so this gate no longer chooses between MDM and another registry. It decides what MDM's delivery must change, whether edition, topology or configuration, before the exact Manulife deployment can demonstrate the write, event, lifecycle and recovery requirements under production-like load. Keep the Manulife-owned API and event contracts independent of Informatica, and keep the operational profile as the channel read boundary.