Integrated Capstone — Acquisition-Created Shared-Data Disorder
Scenario
A company built through acquisitions has: - five customer systems; - three product systems; - inconsistent country/status codes; - duplicate Party records and conflicting identifiers; - no agreed stewardship ownership; - a warehouse that independently builds what it calls “golden records.”
Design the Chapter 10 response in order.
Strong response
1. Define drivers, requirements, domains, and consumers
Separate Reference Data problems (country/status controlled values, mappings, hierarchy) from Master Data problems (Customer/Product entity identity, attributes, identifiers, relationships).
2. Assess sources and authority
For each domain identify: - Systems of Record; - semantics/definitions and granularity; - Data Quality; - latency/update behavior; - existing identifiers and code sets; - consumers and current integration.
Do not make the warehouse “golden” merely because it has a broad view.
3. Choose architecture by domain
Name: - source write authority; - System(s) of Reference; - Registry / Transaction Hub / Consolidated pattern where relevant; - publication/sharing services; - latency and source-disruption trade-offs.
4. Model shared semantics
Define enterprise Master entities/attributes and Reference domains, crosswalks, hierarchies, definitions, versions, and mappings.
5. Build controlled processing
For Master Data: - validate/standardize/enrich; - resolve identity; - manage Global IDs and Source-ID X-Refs; - preserve reversible match history; - use survivorship rules for merges.
For Reference Data: - manage authoritative sets; - crosswalk alternative representations; - control hierarchy/structural changes; - preserve versions/history as required.
6. Establish stewardship and sharing
Define: - exception queues and match review; - Reference change ownership; - survivorship/trust rules; - publication/maintenance processes; - Data Sharing Agreements and SLAs; - issue/escalation/root-cause processes.
7. Establish governance
Govern: - enterprise source authority and adoption; - DQ and conditions-of-use rules; - monitoring and approval gates; - privacy/security/retention requirements; - local exceptions; - accountability.
8. Measure outcomes
Track: - DQ/compliance; - change activity; - ingestion/consumption; - SLA adherence; - steward coverage; - TCO; - sharing volume/usage.
Weak answers and why they lose
“Buy an MDM tool.” Tool-first skips requirements, authority, governance, Reference-vs-Master separation, and adoption.
“Merge all duplicates.” Similar records may be different entities; workflow strength must follow evidence and risk.
“Make the warehouse the golden source.” Consumer completeness does not automatically grant write authority or perfect-truth status.
Changed-fact challenge
If the organization decides all future Customer changes must occur centrally, the customer architecture shifts toward Transaction Hub. If local systems must retain writes while analytics needs one stored copy, Consolidated is stronger. If source disruption must remain minimal and consumers can tolerate index-based source access, Registry becomes a stronger candidate.
Source: Chapter 10, pp. 329–359.