Confusion Cluster — Governance, Management & Roles
1. Data Governance vs Data Management
Plain language
Governance decides the rules, authority and accountability. Data Management performs the specialized work that manages data under that direction.
Formal distinction
- Data Governance: intentional decision rights, policy/standards, accountability, issue/escalation and oversight around the data asset.
- Data Management: implementation and operation of modeling, databases, integration, Metadata, quality, master/reference, security and other management capabilities.
What makes them similar
Both exist to improve how data is managed and must work together. Either may appear in the same initiative, committee structure or organizational reporting model.
What makes them different
The object of the question differs: direction/authority vs execution/operation.
Deciding clue
Who should decide/approve/set accountability? → Governance.
Who should implement/run the approved capability? → Data Management.
Common trap
A technical or operational activity may support a governance goal, but that does not make the activity itself Governance.
Mini scenario
Enterprise leaders approve a stewardship policy and escalation rule; the DMO then configures Metadata and Data Quality workflows to operate it.
Governance: approve the policy/escalation model.
Management: run the workflows/capabilities.
Counterexample
“Which cloud platform should receive investment?” is not automatically Data Governance simply because the platform stores data; the dominant object may be IT Governance / technology investment.
Retrieval check
❓ A committee resolves an escalated conflict over the official Customer definition. Governance or Management?
✅ Answer: Data Governance.
🧠 Why: the decisive act is an authoritative data-definition decision/escalation resolution, not implementation of the definition in systems.
📖 Sources: Chapter 3 pp. 69–92; Chapter 16 pp. 534–535. See Ch3 Deep Card A and Ch16 Deep Card H.
2. Data Owner vs Business Steward vs Technical Steward
Plain language
- Owner: ultimately accountable for the business data domain.
- Business Steward: turns business meaning into definitions, rules and day-to-day stewardship decisions.
- Technical Steward: supports/implements the technical side of the approved requirements.
Formal distinction
The Chapter 3 role model separates final business-domain accountability, business semantic/rule stewardship, and technical Knowledge Area implementation/support.
Similarities
All can care deeply about the same data and may collaborate on the same issue.
Differences
Their authority and work products are different.
Deciding clue
- final accountable business decision → Owner;
- definition/valid value/business rule/subset control → Business Steward;
- technical implementation/Metadata/support → Technical Steward.
Common trap
Technical expertise does not turn a Technical Steward into the business Owner.
Mini scenario
A Customer Status definition is disputed. The Business Steward develops the business definition and valid values; the Owner resolves a final business-accountability conflict; the Technical Steward helps implement the approved rule in systems/Metadata.
Counterexample
A Data Quality Analyst who analyzes recurring defect patterns is not automatically the Business Steward merely because the defects are in the steward’s domain.
Retrieval check
❓ Who is the better answer when the stem says “final business-domain accountability” rather than “maintains definitions”?
✅ Answer: Data Owner.
🧠 Why: the Owner’s deciding feature is final accountability, while the Business Steward is the business SME working on semantics/rules and stewardship execution.
📖 Source: Chapter 3 pp. 69–92. See Ch3 Deep Card C.
3. Data Steward vs Data Quality Analyst
Plain language
The Steward says what good/valid data should mean for the business; the DQ Analyst measures and diagnoses how the data is actually performing.
Formal distinction
- Data Steward: business SME accountable for Metadata/Data Quality expectations for assigned data, including terms, valid values, rules and issue decisions.
- Data Quality Analyst: hybrid role that determines fitness for use, monitors condition, analyzes defects/root causes and identifies business/technical improvements.
Similarities
Both collaborate on Data Quality and may work on the same defect or rule.
Differences
Expectation/accountability vs condition analysis/root-cause diagnosis.
Deciding clue
Define expectations → Steward. Diagnose fitness/causes → DQ Analyst.
Common trap
Choosing “Analyst” whenever the stem contains a data problem even when the task is defining the business rule.
Mini scenario
“Customer Status must be Active, Inactive or Pending” → Steward.
“Why did invalid Customer Status defects triple after the release?” → DQ Analyst.
Counterexample
If the question asks who should change the source business process that creates defects, the best answer may be a process/system owner, not either role acting alone.
Retrieval check
❓ A person profiles invalid status trends and performs root-cause analysis. Steward or DQ Analyst?
✅ Answer: Data Quality Analyst.
🧠 Why: monitoring fitness and analyzing causes are the Analyst’s defining responsibilities; stewardship supplies/owns the business expectations used to judge the data.
📖 Sources: Chapter 16 pp. 538–539; Chapter 13 pp. 428, 443–459. See Ch16 Deep Card I.