Skip to content

Cross-Domain Case Studies — Resolution Key 01–02

Case 01 — Post-Merger Customer 360

1. Business objective and symptoms

The objective is a trusted shared Customer identity plus comparable enterprise reporting. Symptoms include semantic disagreement, duplicate identity, uncontrolled reference codes, uncertain authority, Data Quality defects, missing lineage and jurisdictional control differences.

2. Leading Knowledge Area

Reference & Master Data, with MDM leading the entity-identity solution. The central “one Customer” problem is persistent identity reconciliation, not simply code standardization or warehouse design.

3. Supporting Knowledge Areas

  • Data Governance: authoritative Customer definition, source authority, stewardship, survivorship policy, exceptions.
  • Reference Data: country/status values and crosswalks.
  • Data Architecture: enterprise Customer target, source/target/transition relationships.
  • Data Modeling & Design: Party/Organization/Person structure, relationships, keys and detailed models.
  • Data Quality: profiling, rules, baseline assessment, correction/root-cause work.
  • Metadata: glossary, catalog, lineage, mappings, ownership.
  • Integration: mappings, orchestration, latency/CDC where needed.
  • DW/BI: conformed analytical Customer dimension and fact-grain consistency.
  • Security/Privacy: internal restrictions plus all applicable jurisdictional obligations.
  • Organization/Change: stewardship roles, local-business engagement, adoption.

4. Roles

Data Owner(s), Business Stewards, MDM/RDM stewards, Data Architect, Data Modeler, DQ Analyst, integration specialists, DW/BI architect, security/privacy roles, governance decision body and executive sponsor.

5. Governance decisions before merging

  1. approve enterprise Customer/Party semantics and scope;
  2. define source authority by attribute/domain—not “most complete row wins”;
  3. assign Data Owner/Stewards and issue/escalation rights;
  4. approve survivorship/trust rules and acceptable match-risk thresholds;
  5. govern Reference Data code sets/mappings;
  6. approve sharing/privacy/retention/access conditions and exceptions.

Key rule: Governance decides authority/rules; MDM and other Data Management capabilities implement them.

6. Architecture/design decisions

  • establish enterprise Customer/Party model and person/organization relationships;
  • map source models/IDs to target semantics;
  • choose MDM hub/authority architecture based on desired write/read authority;
  • design Global ID + source-ID/X-Ref history;
  • define reference-code structures/crosswalks separately;
  • define analytical Customer dimension as conformed only when its governed descriptive meaning is reused consistently across fact areas/marts.

7. Ordered management execution

  1. inventory sources, consumers, current authority and lineage;
  2. discover/profile source Customer data and quantify DQ/duplicate patterns;
  3. establish enterprise semantic/model baseline;
  4. govern Reference Data sets/mappings;
  5. standardize/enrich as appropriate;
  6. identify match candidates, resolve identity, generate Global IDs and preserve X-Refs;
  7. apply survivorship/trust rules and maintain reversible merge history;
  8. remediate important recurring source defects rather than hiding them in the hub/warehouse;
  9. implement mappings/orchestration/CDC with lineage;
  10. publish trusted master data and build the conformed analytical Customer dimension/history;
  11. enforce privacy/security controls and monitor adoption/quality.

8. Evidence and metrics

Duplicate/false-positive/false-negative rates; DQ compliance; steward coverage; Reference Data adoption; lineage completeness; source-to-global ID coverage; merge reversibility/audit evidence; downstream use; SLA/latency; cross-report consistency; access-control exceptions.

9. Tempting shortcut

Concatenate tables and choose the most complete row. It bypasses entity resolution, attribute-level authority, survivorship, Reference Data governance, reversible history and business accountability.

10. Changed-fact branch

If Customer identity is already reconciled with trusted Global IDs and X-Refs, but reports disagree only because US/USA/840 and status codes differ, Reference Data Management becomes the leading remaining problem.

Sources

Case 02 — Enterprise Revenue Trust Crisis

1. Business objective and symptoms

The objective is one governed, reproducible Net Revenue KPI trusted across Finance, Sales and executives. Symptoms span conflicting business meaning, incompatible fact grain, inconsistent Product dimensions, late refunds, undocumented transformations and weak lineage.

2. Leading Knowledge Area

Data Governance leads first because the official business definition/accountability is unresolved. DW/BI cannot create legitimate authority by selecting a SQL formula.

3. Supporting Knowledge Areas

Metadata; DW/BI; Data Modeling & Design; Data Quality; Integration; Reference/Master as needed for Product/Customer conformance; Organizational Change for sustained adoption.

4. Roles

Revenue Data Owner, Business Steward(s), governance decision body, Finance/Sales SMEs, BI/DW Architect, Data Modeler, DQ Analyst, Metadata Specialist and integration engineers.

5. Governance decisions

  1. name the accountable owner/stewards;
  2. approve the Net Revenue business definition, inclusions/exclusions and effective date;
  3. define conflict/escalation and change-control process;
  4. approve authoritative sources/rules for refunds/cancellations;
  5. govern shared Product definitions if used across marts.

6. Architecture/design decisions

  • capture approved meaning in the Business Glossary;
  • define structural/technical fields in dictionaries;
  • choose fact grain explicitly before comparing/aggregating measures;
  • standardize the measure and conformed dimensions where analytics must compare across marts;
  • document mapping/transformation rules and lineage from source transactions to KPI.

7. Ordered management execution

  1. freeze ad-hoc semantic changes while governance resolves the metric;
  2. inventory current definitions/calculations/consumers;
  3. trace lineage and profile the sources/feeds;
  4. approve semantic definition and ownership;
  5. resolve fact grain and source-to-target model/mappings;
  6. separate late-arriving/timeliness effects from semantic or accuracy defects;
  7. remediate source/process defects where appropriate; implement valid transformations where intentional;
  8. conform Product/other shared dimensions and rebuild calculations;
  9. reconcile results to authoritative evidence and establish ongoing monitoring;
  10. publish the governed definition/lineage and communicate the change to users.

8. Evidence and metrics

Definition adoption; lineage completeness; reconciliation variance; late-arriving-data latency; DQ rule compliance; cross-mart Product consistency; number of unofficial KPI variants; user confidence/usage; time to resolve metric disputes.

9. Tempting shortcut

Assign the BI developer as owner and patch SQL. Implementation proximity does not create business accountability; a technically consistent formula can still be the wrong enterprise definition.

10. Changed-fact branch

If the Net Revenue definition, owner, grain and Product semantics are already governed and documented, but the executive KPI alone calculates the approved formula incorrectly, DW/BI implementation becomes the leading issue.

Sources

← Case 02 Prompt · Resolution 03–04 →