Deep Battle Cards A–E
Use these when two or more answers sound plausible.
A — Data Governance vs Data Management vs IT Governance
| Dimension | DG | Data Management | IT Governance |
|---|---|---|---|
| Object | Data-asset decision rights/behavior | Specialized work that manages data | Technology investments/portfolios/architecture |
| Purpose | Intentional accountable data decisions | Execute management capabilities | Align/control technology investment |
| Typical outputs | policies, standards, decisions, issue resolutions, scorecards | models, databases, integrations, quality, Metadata, operations | portfolio/technology decisions |
| Deciding clue | rule/authority/escalation | execution | technology investment/application/project portfolio |
Scenario: approve enterprise Customer definition → DG; implement approved mapping → Data Management; fund application platform → IT Governance.
Trap: data work uses technology, but that does not erase the object distinction.
B — Steering vs DGC vs DGO vs Stewardship Team
| Layer | Core job | Strong clue |
|---|---|---|
| Steering | highest authority/sponsorship/funding | release funding |
| DGC | governance decisions, policy/metrics, issues/escalations | decide escalated conflict |
| DGO | ongoing program coordination | maintain role/definition/standards workflow |
| Stewardship | domain/project working collaboration | resolve Customer-definition issue locally |
Memory: Sponsor → Decide → Coordinate → Work.
C — Data Owner vs Business Steward vs Technical Steward
Owner: final business-domain accountability.
Business Steward: business semantics/rules/subset control.
Technical Steward: technical KA implementation/support.
Inputs/outputs: Owner consumes strategy/risk and produces accountable business decisions; Business Steward consumes stakeholder meaning and produces definitions/rules; Technical Steward consumes approved requirements and produces/maintains technical implementation/Metadata/support.
Trap: technical expertise does not make the technical steward the business owner.
D — Centralized vs Replicated vs Federated
Scope: distribution/coordination of governance — not storage architecture and not maturity.
- One enterprise center → Centralized.
- Same playbook independently repeated → Replicated.
- Enterprise coordination + distributed local participation → Federated.
Design inputs: organization structure, culture, data value, regulation and business model.
Trap: “large/global” does not automatically mean Federated; the coordination pattern must be present.
E — Principle vs Policy vs Standard vs Procedure
| Artifact | Purpose | Example |
|---|---|---|
| Principle | foundational belief | Data is an enterprise asset. |
| Policy | enterprise directive | Restricted data must not go to unapproved recipients. |
| Standard | measurable mandatory conformance rule | Date = YYYY-MM-DD. |
| Procedure | repeatable steps/method | Request → review → approve → publish. |
Memory: Believe → Direct → Measure → Do.
Source anchors: Chapter 3 pp. 69–92.