Deep Battle Cards A–D
Deep Card A — Data Architecture vs Data Modeling & Design
Definition
Data Architecture identifies enterprise data needs and maintains master blueprints/alignment. Data Modeling & Design discovers/represents detailed requirements and designs data structures.
Purpose
Architecture keeps enterprise direction coherent; Modeling & Design turns requirements into precise conceptual/logical/physical structures.
Scope
- Architecture: enterprise requirements, target states, roadmaps, integration, standards, cross-project alignment.
- Modeling & Design: model construction, normalization, keys, logical/physical database design.
Typical outputs
- Architecture: EDM/flows, roadmaps, standards, enterprise specifications.
- Modeling & Design: CDM/LDM/PDM and implementation designs.
Deciding distinction
Enterprise blueprint/alignment vs precise model/design execution.
Scenario switch
“Which Customer definition should every project reuse?” → Architecture.
“How should Customer and Address be normalized?” → Modeling & Design.
Exam trap: one highly detailed physical schema is not the enterprise Data Architecture.
Memory hook: Architecture sets the map; Modeling draws the structures on it.
Source: pp. 99–103, 106–109.
Deep Card B — Enterprise Data Model vs Data Flow Design
Definition
EDM provides enterprise concepts, relationships, rules, and critical attributes. Flow Design describes movement, storage, processing, transformation, and contextual relationships.
Purpose
EDM stabilizes meaning; Flow stabilizes movement/traceability.
Inputs
- EDM: definitions, enterprise concepts, business rules.
- Flow: sources, targets, interfaces, CRUD responsibility, processes, locations.
Outputs
- EDM: conceptual/logical enterprise models and mappings.
- Flow: lineage/flow maps and process/data relationships.
Deciding distinction
Meaning/relationship vs movement/processing.
Scenario switch
Customer → Order relationship → EDM.
CRM → API → hub → warehouse, including transformations → Flow.
Exam trap: EDM alone does not answer lineage.
Memory hook: EDM says WHAT; Flow says WHERE/HOW.
Source: pp. 106–110.
Deep Card C — Current vs Target vs Transition State
Definition
Current = as-is landscape. Target = intended future. Transition = intermediate architecture during change.
Purpose
Together they make change realistic and governable.
Deciding questions
- What exists? → Current.
- Where are we ultimately going? → Target.
- What architecture exists during migration? → Transition.
Scenario switch
Legacy CRM + new Customer hub coexist for 12 months → Transition, even though it is future-dated.
Exam trap: a target picture without current-state validation and transition planning is incomplete.
Memory hook: Current = here; Target = there; Transition = bridge.
Source: pp. 99–100, 106, 112–115.
Deep Card D — Framework vs Roadmap
Definition
Framework organizes architecture viewpoints/artifact categories. Roadmap sequences architecture development and implementation over time.
Purpose
Framework structures thinking and communication; roadmap structures change.
Inputs
- Framework: architecture concerns, stakeholder viewpoints.
- Roadmap: current state, target state, priorities, dependencies, resources, costs.
Outputs
- Framework: organized classification/taxonomy.
- Roadmap: roughly 3–5 year implementation path.
Deciding distinction
Structure for thinking vs sequence for evolution.
Scenario switch
What/How/Where/Who/When/Why matrix → framework.
Year-by-year modernization milestones → roadmap.
Exam trap: Zachman does not become a roadmap because rows and columns appear ordered.
Memory hook: Framework = shelves; Roadmap = route.
Source: pp. 104–105, 112–113.