Deep Battle Cards H–M
Deep Card H — Data Governance vs Data Management
Definition: Governance establishes strategy/policy/standards/accountability; management implements and operates. Purpose: prevent confusion between direction and execution. Owners/users: DG bodies and DMO. Outputs: guidance/mandate vs executed capabilities. Nearest confusion: either may report to the other depending enterprise emphasis. Deciding distinction: doing the right things vs doing things right. Scenario pair: DG approves stewardship policy → Governance; DMO runs metadata/DQ process → Management. Memory hook: Rules and air cover vs execution. Source: pp. 534–535.
Deep Card I — Data Steward vs Data Quality Analyst
Definition: Steward is business SME/accountable for metadata/DQ expectations; DQ Analyst monitors fitness, analyzes causes, and identifies business/technical improvement. Purpose: distinguish business accountability from hybrid analytical capability. Inputs: terms/valid values/rules vs profiles/issues/condition data. Outputs: definitions/rules/accountability vs condition/root-cause analysis. Nearest confusion: both collaborate on Data Quality. Deciding distinction: account for data vs analyze its fitness. Scenario pair: define valid Customer Status values → Steward; analyze defect trend/root cause → DQ Analyst. Memory hook: Steward defines expectations; Analyst diagnoses condition. Source: pp. 538–539.
Deep Card J — Data Architect vs Data Modeler
Definition: Architect owns broader architecture/integration direction; Modeler captures detailed requirements, definitions, rules, and logical/physical models. Purpose: separate blueprint direction from detailed representation. Outputs: architecture/integration direction vs models/requirements. Nearest confusion: a data model can be an architecture artifact, but the role emphasis is different. Deciding distinction: blueprint vs detailed representation. Scenario pair: choose enterprise integration pattern → Architect; create logical Customer model → Modeler. Memory hook: Architect shapes landscape; Modeler shapes representation. Source: p. 538.
Deep Card K — Data Integration Architect vs Specialist
Definition: Architect designs integration technology; Specialist implements replication/ETL/near-real-time systems. Purpose: separate design from implementation. Outputs: integration design vs built integration flows/systems. Nearest confusion: complex technical implementation is not automatically architecture ownership. Deciding distinction: design vs build. Scenario pair: select enterprise integration approach → Architect; implement ETL job → Specialist. Memory hook: Architect designs; Specialist delivers. Source: p. 538.
Deep Card L — Enterprise Architecture / ARB vs DMO
Definition: EA owns enterprise architecture disciplines and ARB standards review; DMO owns broader Data Management capability and execution. Purpose: recognize shared Data Architecture without organizational confusion. Outputs: blueprint/standards approval vs DM operations. Nearest confusion: Data Architects can sit in either organization with coordination to the other. Deciding distinction: architecture standards vs Data Management operations. Scenario pair: ARB approves project architecture → EA/ARB; DMO runs stewardship/DQ/metadata → DMO. Memory hook: Different homes, shared Data Architecture. Source: pp. 535–536.
Deep Card M — Organizational Role vs Individual Role
Definition: organizational role = function/team/service; individual role = responsibilities assigned to a person. Purpose: avoid confusing capability placement with job description. Inputs: operating model, service structure, role inventory. Outputs: unit-level capability vs person-level responsibility. Nearest confusion: a centralized DBA service does not dictate every company's exact reporting arrangement for individual DBAs. Deciding distinction: function vs person. Scenario pair: create centralized Metadata service → Organizational; assign Metadata Specialist → Individual. Memory hook: Where capability lives vs who performs it. Source: pp. 537–539.
Final discrimination check
- Distributed DMO adds RACI but no reporting changes → Network.
- COE+BU teams later gains regional DMO layers → Hybrid moves toward Federated.
- Powerful sponsor exists but leaders send conflicting messages → Leadership alignment.
- Person defines business terms and valid values → Data Steward.
- Group approves projects against architecture standards → Architecture Review Board.