Scenarios 11–15
11 — Minimal Source Changes
Practice: Global firm has many SORs and wants enterprise identity with minimal disruption.
Decision key: problem = architecture under minimal-change constraint; supporting = governance, integration, latency, distributed authority; roles = architect, governance, MDM, source owners. Best: evaluate Registry—enterprise identity/index while Master Data remains in SORs; document distributed assembly complexity. Weaker: Transaction Hub requires major centralization. Changed: hub must own all updates → Transaction Hub.
Source: pp. 349–351, 355–356.
12 — Central Write Authority
Practice: Applications should stop maintaining Master Data independently; one hub owns updates.
Decision key: problem = central Master maintenance; supporting = architecture, governance, integration. Best: Transaction Hub with central stewardship/rules; hub = SOR. Weaker: Registry leaves writes in sources. Changed: sources keep writes but hub stores reconciled consumer copies → Consolidated.
Source: pp. 349–351.
13 — Enterprise Read View
Practice: Business units keep local SORs; analytics wants one reconciled stored repository.
Decision key: problem = stored enterprise consumer view while sources retain writes; supporting = replication, latency, integration, DQ. Best: Consolidated; source systems = SORs, hub = System of Reference; monitor synchronization. Weaker: Registry may require assembling distributed data. Changed: index-based retrieval from source-held records → Registry.
Source: pp. 349–351.
14 — New MDM Program Too Broad
Practice: Team proposes mastering Customer, Product, Location, Account, and hundreds of attributes at once.
Decision key: problem = scope/roadmap risk; supporting = governance, architecture, requirements, DQ, change. Roles = sponsor, governance, program manager, stewards, architects. Best: prioritize by need, start manageable domain/attribute set under enterprise roadmap, expand with value/learning. Weaker: big-bang mastery magnifies unresolved semantics and ownership. Changed: mature program may support larger releases, still justified by roadmap/requirements.
Source: pp. 340–341, 355–356.
15 — Reference Set Too Detailed
Practice: Casual users choose from 500 fine-grained status values and make frequent mistakes.
Decision key: problem = Reference granularity/usability causing DQ errors; supporting = DQ, stewardship, governance, consumer requirements. Best: fit-for-purpose related governed lists/taxonomies with mappings and definitions. Weaker: force all consumers to use the 500-value list because it is “enterprise.” Changed: multiple standards for same concept → cross-reference mapping.
Source: pp. 334–338.