Scenarios 06–10
6 — Possible Duplicate, High Risk
Practice: Records are similar, but legal risk makes an automatic merge unsafe.
Decision key: problem = uncertain identity with high false-positive cost; leading KA = Reference & Master Data; supporting = stewardship, governance, thresholds, reversibility; roles = Steward, MDM specialist, risk/business owner. Best: duplicate identification + steward review. Weaker: automatic match-merge on similarity. Changed: high confidence and source content should stay unchanged → match-link.
Source: pp. 343–346.
7 — Need Unified Record
Practice: Three source records clearly represent one customer; business needs one reconciled profile.
Decision key: problem = reconciliation of confirmed same-entity records; supporting = survivorship, DQ, IDs, stewardship. Best: match-merge with explicit survivorship/trust rules, Global ID, X-Ref history, reversible audit evidence. Weaker: match-link does not satisfy unified-profile requirement. Changed: only identity linkage needed → match-link.
Source: pp. 345–347.
8 — Rule-Based Matcher Fails Edge Cases
Practice: Fixed patterns miss variations not anticipated by developers.
Decision key: problem = matching-method limitations, possibly upstream preparation. Roles = MDM/DQ specialist + Steward. Best: first verify adequate standardization; then consider probabilistic techniques or tune deterministic rules from observed cases. Weaker: change hub architecture; Registry/Hub/Consolidated does not repair similarity logic. Changed: inconsistent phone representation → standardization first.
Source: pp. 343–345.
9 — Enterprise Identity
Practice: Each Source ID changes independently; downstream consumers need one stable enterprise identifier.
Decision key: problem = enterprise identifier stability; supporting = entity resolution, X-Ref history, governance. Best: one authorized solution generates/maintains Global ID and preserves source-to-global mappings. Weaker: replace all Source IDs; local IDs can remain useful. Changed: translating ISO/FIPS codes → Reference cross-reference, not Master identity X-Ref.
Source: pp. 346–347.
10 — Complex Organization Relationships
Practice: Company A owns B, and employees can work at multiple affiliates.
Decision key: problem = flexible relationships among Master entities; supporting = identity, hierarchy, stewardship. Best: typed affiliations, deriving hierarchies as needed. Weaker: force every relationship into one rigid tree. Changed: business truly requires one stable hierarchy only → parent-child may be sufficient.
Source: pp. 346–349.