Skip to content

Chapter 4 — Data Architecture

Quick Study Navigation

🏠 Study Home · 📖 Chapter Library · 📘 Learn · 🎯 Exam Map · 🧠 Visuals · ⚔️ Battle Cards · 🧩 Scenarios · 📝 Questions · 🔄 Recall · 📕 Source PDF · 🗂️ Formatted Originals

Fundamentals weight: 6%
Primary source: DAMA-DMBOK2 Revised, Chapter 4 — Data Architecture, printed pp. 99–122.

Source boundary: This fresh GitHub reading build is derived from the current Chapter 4 Mastery Lab package in Google Drive. DAMA terminology and distinctions control. No outside architecture framework is silently substituted for the source.

Chapter mental model

Business strategy → Data Architecture → technology/project execution

Data Architecture identifies enterprise data needs and designs and maintains the master blueprints needed to meet them. Those blueprints guide integration, help control data assets, and align data investments with business strategy. The chapter is not teaching “how to draw one data model.” It teaches an enterprise management discipline built from artifacts, activities, and behavior.

A locally successful project can still damage enterprise architecture if it creates a new Customer definition, another uncontrolled copy, a one-off integration pattern, or an implementation that makes the long-term target harder to reach. Architecture keeps those local decisions connected to enterprise intent.

High-risk exam traps

  • Data Architecture ≠ one physical data model. Physical models participate in the architecture lineage but are products of Data Modeling & Design.
  • EDM ≠ Data Flow Design. EDM explains meaning and relationships; flow explains movement, storage, transformation, and context.
  • Zachman = ontology/classification, not methodology. It helps classify what architecture descriptions exist; it does not prescribe the work sequence.
  • Target state ≠ roadmap. The target is the destination; the roadmap is the sequenced path, including transition states and dependencies.
  • Agile ≠ no architecture. Iterative delivery still needs enterprise intent, data specifications, standards, and close architect/developer collaboration.
  • Emerging ≠ Preferred. A pilot is not automatically the recommended default for new work.
  • Artifact volume ≠ business value. Diagram counts do not prove compliance, implementation progress, or enterprise benefit.

Study this chapter through the Mastery Lab loop

LEARN → RECALL → COMPARE → APPLY → TEST → DIAGNOSE → REVISIT

  1. Guided Learning — learn the chapter as one enterprise story.
  2. Exam Map — isolate what must be known cold and what must be distinguished.
  3. Visual Memory Map — redraw the architecture models from memory.
  4. Battle Cards — discriminate concepts that share vocabulary.
  5. Scenario Lab — apply architecture reasoning to projects, roadmaps, lifecycle, and governance.
  6. Question Bank — work the 56-item source-bound bank and diagnose misses.
  7. Teach-Back — retrieve and reconstruct without recognition cues.

One-sentence professional rule

Architecture is valuable when trusted enterprise blueprints, flows, standards, roadmaps, project practices, governance, and stakeholder behavior reinforce one another so business strategy can be implemented coherently over time.

← Chapter 3 · All Chapters · Chapter 5 →