Scenario Lab — 1–5
1 — The duplicate-customer program
A retailer launches MDM because duplicate customers disrupt service, but leaders treat it as technology-only.
Best: tie DG to the business problem; establish decision rights, stewardship, definitions, DQ rules and issue paths before/alongside MDM technology.
Leading KA: Data Governance. Support: Reference/Master Data, DQ, Metadata, Architecture/Integration.
Weaker: buy matching/merging software and let it decide what Customer means.
Changed fact: if definitions/owners/rules/issues are already governed and only entity matching remains, Reference/Master Data becomes primary execution.
Source: p. 72; pp. 74–75.
2 — The all-powerful council
A DGC approves every database change and runs remediation jobs.
Problem: oversight/execution collapsed.
Best: DGC approves/oversees rules and appropriate escalations; technical teams execute controlled changes.
Weaker: centralize operations in DGC to “strengthen governance.”
Changed fact: deciding a policy exception/escalated cross-domain conflict is appropriate DGC governance.
Source: pp. 74–75.
3 — The three business units
Corporate wants common definitions; units need local autonomy.
Best starting classification: Federated — central coordination + distributed local participation.
Roles: enterprise DGC/DGO + local governance/stewards.
Weaker: Centralized only because corporate wants consistency.
Changed fact: same playbook independently adopted with no central coordinating function → Replicated.
Source: p. 77; Figure 17.
4 — The identical regional playbook
Three units independently implement the same DG model/standards; no central coordinating body.
Answer: Replicated.
Weaker: Federated merely because several units exist.
Changed fact: enterprise DG actively coordinates shared definitions/standards while units keep local governance → Federated.
Source: p. 77.
5 — Who owns the decision?
Technical steward maintains access Metadata; a business leader must decide whether new Customer-data use is allowed.
Answer: Data Owner is accountable for domain decision. Business/Technical Stewards provide semantic/technical expertise.
Weaker: let Technical Steward decide because data sits in a system.
Changed fact: defining a Customer attribute/business rule inside approved policy boundary → Business Data Steward leads working task.
Source: p. 79.