Suggested answer

This is a master data management problem, and the technology is the last part of the answer:

1. Agree the domain and scope: Which entity are we mastering, which attributes are in scope, and which system is authoritative for each attribute. Authority is attribute-level: the ERP may own billing address while the marketing platform owns consent and email preference.
2. Choose an implementation style: Registry (keys only, resolved on the fly), consolidation (aggregate for reporting, no write-back), centralised (the hub is the system of record), or coexistence (hub masters, sources keep authoring, bidirectional sync). The choice follows how much change the existing applications can absorb.
3. Define matching: Deterministic matching on strong identifiers such as a tax id or a customer number, plus probabilistic or fuzzy matching on name and normalised address for the rest. Set thresholds for auto-merge versus route-to-steward.
4. Define survivorship: Per attribute: source trust ranking, then recency, then completeness, then validation status such as address standardisation. Write these down as rules with weightings, because they will be disputed.
5. Preserve lineage: Store the source system identifier, source name, and last-synchronised timestamp alongside the consolidated values so any attribute can be traced back and reprocessed if the rules change.
6. Staff the stewardship: Someone must work the exception queue for records that fall between the auto-merge and reject thresholds. An MDM programme with no steward capacity degrades within months.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.