Mixed Scenarios — Resolution Key 01–06
1 — Three Revenue Numbers
Primary problem: no authoritative business definition/decision, not primarily bad SQL.
Leading KA: Data Governance.
Supporting: Metadata Management; DW/BI; Data Quality.
Roles: governance decision body, Data Owner/Business Steward, BI/warehouse implementers.
Best action: resolve/approve the official Net Revenue definition and decision rights; capture it in the Business Glossary; then implement/test the governed definition in analytical mappings/measures.
Weaker: patch dashboard SQL first—this may choose a definition without authority and leave other consumers inconsistent.
Changed fact: if the official definition is already governed and consistently published but the ETL/semantic layer applies it incorrectly, DW/BI / Data Management implementation becomes leading.
Sources: Ch3 Governance; Ch12 Glossary; Ch11 analytical implementation. See Confusion entry 1 and entry 6.
2 — One Customer, Three IDs, Two Country Codes
Primary: two different shared-data problems are hidden inside “one clean Customer”: entity identity + controlled code translation.
Leading KA: Reference & Master Data, with MDM leading because persistent Customer identity is the central object.
Supporting: RDM for country-code mappings; Data Quality; Governance; Metadata.
Roles: MDM/RDM stewards, Data Owner, source owners, DQ analyst.
Best action: model/assess sources and authority; reconcile Customer identity with identifiers/X-Refs and governed matching; separately govern country-code set/mappings; preserve lineage/history.
Weaker: create one country-code crosswalk and call the Customer problem solved—code translation does not resolve duplicate identity.
Changed fact: if Customer IDs already resolve one entity correctly and the only inconsistency is US/USA/840, RDM becomes leading.
Source: Reference vs Master.
3 — Merger Blueprint vs Project Schema
Primary: two levels of design are being conflated.
Leading KA: Data Architecture for the enterprise target/reuse problem.
Supporting: Data Modeling & Design for the project model; Governance for adoption/standards.
Roles: Data Architect, Data Modeler, governance/ARB, project teams.
Best action: establish enterprise target subject areas/concepts/alignment and roadmap; then require scoped models to conform/mapping back to that direction while modelers resolve cardinality/keys/normalization.
Weaker: let the project’s detailed physical model become the enterprise architecture by default.
Changed fact: if the enterprise target is already set and the remaining question is only Customer–Order cardinality/keys, Data Modeling & Design becomes leading.
Source: Architecture vs Modeling.
4 — The ETL Fixes It Every Night
Primary: recurring source defect is being hidden by downstream correction/transformation.
Leading KA: Data Quality.
Supporting: DW/BI; Reference Data; Governance/process ownership.
Roles: DQ Analyst, Data Steward, source process/system owner, integration specialist.
Best action: identify/root-cause and remediate the source process, add prevention where appropriate, govern valid status values, and correct historical defects as needed; keep warehouse transformation transparent rather than using it as permanent camouflage.
Weaker: make the ETL conversion more sophisticated—reports stay clean while defect production continues.
Changed fact: if US is already a valid governed source value and target convention intentionally requires 840, DW/BI transformation becomes the appropriate lead for that conversion rather than DQ remediation.
Sources: Prevention/Correction/RCA and Mapping/Remediation/Transformation.
5 — We Found the Table, But What Does It Mean?
Primary: discovery has been solved, but business meaning and element structure have not.
Leading KA: Metadata Management.
Supporting: Governance/Stewardship; Data Quality.
Roles: Business Steward, Metadata Specialist, technical SMEs/data modelers.
Best action: link the catalog discovery record to an approved Business Glossary definition/valid-value meaning and Data Dictionary structural properties such as datatype/nullability.
Weaker: demand that “the catalog” be treated as one undifferentiated artifact; platform integration does not erase conceptual roles.
Changed fact: if meaning/structure/location are known but multiple Customer records must be reconciled into one identity, MDM becomes leading.
Source: Glossary vs Dictionary vs Catalog.
6 — Current Data vs Historical Record
Primary: one architectural role is being asked to satisfy incompatible time-horizon/volatility purposes.
Leading KA: DW/BI.
Supporting: Data Architecture; Integration & Interoperability; Governance/retention.
Roles: DW/BI Architect, Data Architect, integration/operations teams.
Best action: distinguish an ODS for integrated current/near-current lower-latency use from a durable historical Data Warehouse; design flows/retention accordingly.
Weaker: label the 30-day volatile store “warehouse” and assume the name satisfies audit history.
Changed fact: if the store is only a temporary area used while data is cleansed before the next load, Staging becomes the closer role.
Source: Staging vs ODS vs DW vs Mart.