04 — Comparison & Battle Cards
← Visual Atlas · Chapter 1 Home · Next: Scenario Lab →
Purpose: learn the deciding difference, not two isolated definitions.
For each card, cover the Deciding distinction, classify the scenarios yourself, then uncover the answer.
1. Data vs Information
Data: represented facts/concepts/events that require context.
Information: data interpreted/prepared for a particular use.
Deciding distinction: Use the distinction to communicate purpose and use, but do not treat data and information as permanently separate stages. DMBOK treats them as intertwined and often interchangeable.
Data scenario: transaction rows are being validated before a quarterly report.
Information scenario: the report summarizes those rows for executives; later its results become inputs to another analysis.
Trap: assuming information is always separate from data or that data exists before knowledge/design.
Memory hook: relationship, not rigid ladder.
Source: Section 2.2, p. 22.
2. Data vs Metadata
Data: business/world facts, content, events, entities, transactions, documents or images.
Metadata: definitions, structure, origin, lineage, rules, ownership, classification and other context needed to understand/manage data.
Deciding distinction: Is the item primarily the business/content value itself, or does it describe meaning, structure, origin, movement, rules or management of other data?
Data scenario: a customer shipping ZIP code in an order table.
Metadata scenario: a catalog entry explains where shipping_zip is captured and who stewards it.
Trap: treating Metadata as only technical schema.
Memory hook: Metadata makes invisible data understandable.
Source: Sections 2.1, 2.4, 2.5.5; pp. 20–24, 29–30.
3. Data Management vs IT Management
Data Management: manages the data/information asset—meaning, value, quality, protection, access, lifecycle, risk and use.
IT Management: manages technology infrastructure, platforms, systems and services.
Deciding distinction: Ask whether the stem is about what the data must mean/do/protect/support or how to run/manage the technology platform itself.
Data Management scenario: determine retention, lineage and restricted-use requirements for customer history.
IT Management scenario: patch a database server and monitor CPU utilization.
Trap: “most data is electronic” does not mean Data Management is just technology management.
Memory hook: manage the asset first; technology serves it.
Source: Sections 1, 2.4, 2.5.12; pp. 19, 25, 33.
4. Data Management vs Data Governance
Data Management: broad discipline covering multiple Knowledge Areas and lifecycle functions.
Data Governance: direction, oversight, decision rights, policy, stewardship and consistency.
Deciding distinction: Governance tells the organization how data decisions are made and overseen; Data Management is the broader set of functions that perform the work.
Management scenario: engineers implement lineage capture and analysts monitor Data Quality rules.
Governance scenario: a council approves an enterprise customer-definition policy and stewardship decision rights.
Trap: calling Governance a synonym for all Data Management.
Memory hook: Governance directs; Management executes the broader system.
Source: Sections 2.4, 2.5.7, 3.3, 4; pp. 24–25, 29–30, 37–48.
5. Data Lifecycle vs Data Lineage
Lifecycle: stages/events and management requirements across data's life.
Lineage: origin, movement, transformations and uses of a specific data set or element.
Deciding distinction: lifecycle = what happens over the data's life; lineage = route and transformations of this data.
Lifecycle scenario: design retention controls from creation through disposal.
Lineage scenario: trace Revenue from ERP transactions through ETL rules to a dashboard.
Memory hook: life = stages; line = path.
Source: Section 2.5.9; pp. 30–32.
6. Data Lifecycle vs SDLC
Data lifecycle: follows the data asset across its life.
Systems Development Lifecycle: follows analysis, design, build, test, preparation and deployment of a system/solution.
Deciding distinction: What object is being followed—data itself or a system being built/changed?
Data lifecycle scenario: define how sensor readings are retained, transformed, used and destroyed.
SDLC scenario: design, build, test and deploy a new data-entry application.
Memory hook: data life vs system build.
Source: Sections 2.5.9 and 3.3; pp. 30–32, 39–40.
7. Data Strategy vs Data Management Program Strategy
Data Strategy: begins with business strategy and describes the data the enterprise needs and how it supports business goals.
Program Strategy: establishes the management capabilities, roles, quality, integrity, access, security, risk work and priorities needed to enable that direction.
Deciding distinction: business-use direction vs management-enablement plan.
Data Strategy scenario: retailer decides it needs behavior data to personalize offers and reduce churn.
Program Strategy scenario: CDO defines roles, quality/security objectives, governance support, initiatives and roadmap for managing that data.
Memory hook: use vs enable.
Source: Section 2.6; pp. 34–35.
8. Charter vs Scope Statement vs Implementation Roadmap
- Charter: mandate, vision, business case, goals, principles, success measures, risks, operating model.
- Scope Statement: goals/objectives for a planning horizon plus accountable roles, organizations and leaders.
- Roadmap: programs, projects, tasks, assignments and delivery milestones.
Deciding distinction: mandate/why → Charter; what/who/horizon → Scope; how/when → Roadmap.
Trap: picking Roadmap whenever the stem contains the word “strategy.”
Source: Section 2.6; pp. 34–35.
9. SAM vs AIM
SAM: four broad domains—Business Strategy, IT Strategy, Organizational Infrastructure/Processes, IT Infrastructure/Processes.
AIM: 9-cell Business, Information and IT across Strategy, Tactics/Structure and Operations.
Deciding distinction: SAM = four broad alignment domains; AIM = explicit Information layer plus three organizational levels.
Memory hook: four-domain SAM; nine-cell AIM.
Source: Sections 3.1–3.2; pp. 36–37.
10. DAMA Wheel vs Environmental Factors Hexagon vs Context Diagram
- Wheel: what Knowledge Areas exist; Governance central.
- Hexagon: recurring factors surrounding work around Goals & Principles.
- Context Diagram: detailed operating flow of one KA—Inputs/Suppliers, P-C-D-O Activities, Participants, Deliverables/Consumers, Tools, Techniques and Metrics.
Deciding distinction: Wheel names; Hexagon frames; Context flows.
Source: Section 3.3; pp. 37–41.
11. Suppliers vs Participants vs Consumers
- Supplier: provides or enables access to inputs.
- Participant: performs, manages or approves activities.
- Consumer: directly benefits from the primary deliverables.
Deciding distinction: classify by relationship to the activity—supplies input, performs/approves work, or consumes output.
Memory hook: Supply → Participate → Consume.
Source: Section 3.3; pp. 39–41.
12. Plan vs Control vs Develop vs Operate
- Plan: set strategic/tactical direction.
- Control: assure ongoing quality, integrity, reliability and security.
- Develop: analyze/design/build/test/prepare/deploy.
- Operate: support use, maintenance and enhancement.
Deciding distinction: setting direction vs assuring conditions vs building/changing vs running/supporting.
Memory hook: P = direction; C = assurance; D = build/change; O = run/support.
Source: Section 3.3, p. 40.
Master discrimination drill
Complete each stem before revealing the model completion:
-
Data Management is broader than Data Governance because…
Governance provides direction, oversight and decision rights while Data Management includes the full set of governed data functions. -
Metadata differs from business data because…
business data represents facts/content while Metadata describes meaning, structure, origin, movement, rules and context used to understand/manage data. -
Lifecycle differs from lineage because…
lifecycle describes stages/events across data's life while lineage traces a particular data path. -
Lineage differs from SDLC because…
lineage follows data; SDLC follows development of a system/solution. -
Data Strategy differs from Program Strategy because…
Data Strategy is business-use direction while Program Strategy is the capability plan that enables it. -
A Charter differs from a Roadmap because…
Charter establishes mandate/intent; Roadmap defines implementation work and milestones. -
SAM differs from AIM because…
SAM uses four broad alignment domains; AIM uses a 3×3 structure with an explicit Information layer. -
The DAMA Wheel differs from the Context Diagram because…
Wheel maps the Knowledge Areas; Context Diagram explains how one Knowledge Area operates. -
A Supplier differs from a Participant because…
Supplier provides/enables input; Participant performs/manages/approves the activity. -
Control differs from Operate because…
Control assures required ongoing conditions; Operate runs/supports/maintains ongoing services or processes.
Current-standard completion layer
For each card, be able to state not only the definitions but also purpose, typical user, inputs, outputs/artifacts and when used. The recurring rule is to identify the object, decision or relationship the stem is testing rather than match vocabulary superficially.