Lesson 3 — EDM, Data Flow & Model Linkage
Source focus: DMBOK Chapter 4, pp. 106–110.
1. Enterprise Data Architecture needs two master views
Chapter 4 pairs two specification families:
- Enterprise Data Model (EDM) — what the enterprise data means and how concepts relate.
- Data Flow Design — where data originates, moves, is stored, transformed, and used in business/technical context.
A complete architecture needs both.
The quickest discriminator
EDM asks WHAT. Flow asks WHERE/HOW.
- “What is Customer? How does Customer relate to Order and Account?” → EDM.
- “Where is Customer created? Which systems copy it? Where is it transformed?” → Data Flow Design.
A detailed flow without shared semantics can show perfect arrows around inconsistent meanings. A rich EDM without flow knowledge cannot reveal where the real enterprise creates, duplicates, transforms, or consumes the data.
2. Enterprise Data Model is a linked family, not one giant ER diagram
The EDM is a holistic, enterprise-level, implementation-independent conceptual/logical view. In practice it can be a coordinated family of: - enterprise conceptual views, - Subject Area models, - enterprise logical models, - project logical models, - physical implementation models, - definitions, - mappings, - business rules and specifications.
The power comes from linkage.
Vertical linkage = model lineage across abstraction levels
Example:
Physical CUSTOMER table → project logical Customer → enterprise logical Party/Customer → Subject Area concept → enterprise conceptual view
Moving down adds implementation detail. Moving up recovers shared enterprise meaning.
Horizontal linkage = relationships at the same level
A Product Part can participate in Product Management, Sales Order, Inventory, and Marketing models at the same general abstraction level. Horizontal mappings preserve those peer relationships across subject areas/models.
Memory hook: vertical changes altitude; horizontal stays on the floor.
3. Architecture vs Data Modeling & Design
These disciplines cooperate but are not interchangeable.
| Data Architecture | Data Modeling & Design |
|---|---|
| Enterprise needs and master blueprints. | Detailed representation/design of data requirements. |
| Cross-project alignment and model relationships. | Conceptual/logical/physical model construction techniques. |
| Target states, standards, integration, roadmap. | Normalization, keys, database structures, implementation design. |
A physical data model can be important to architecture lineage, but Chapter 4 explicitly places physical modeling in Data Modeling & Design.
4. Subject Areas make enterprise semantics manageable
A Subject Area is a semantic region of the enterprise model.
Key source rules: - each entity should reside in one Subject Area, - relationships can cross Subject Area boundaries, - top-down starts with Subject Areas and populates them, - bottom-up derives Subject Area structure from existing models, - a combined approach is often practical, - the discriminator should be consistent across the enterprise.
Chapter 4 lists possible organizing principles such as systems/funding, governance ownership, value-chain processes, business capabilities, and normalization. It says normalization is usually most effective for Data Architecture work because it groups data around inherent semantic relationships rather than temporary organizational structures.
5. Data Flow Design is lineage with business and technical context
End-to-end flows document: - origin, - storage/use, - movement, - processing/transformation, - applications, - business processes, - network segments, - locations, - CRUD roles, - technical components.
Flows can be drawn at Subject Area, entity, or attribute level depending on the decision being supported.
Example
Customer Address is captured in CRM by a call-center process, validated against Reference Data, published through an integration service, persisted in MDM, copied to Billing, and transformed into a warehouse dimension.
A useful architecture flow can show: - who creates/updates it, - where it becomes authoritative, - what transformations occur, - which consumers depend on it.
That is why flows support impact analysis.
6. Matrix vs directional flow diagram
A directional flow diagram is best when sequence/movement is the question.
A process-by-data / CRUD matrix can be better when many processes interact with many data entities. It makes create/read/update/delete responsibility and acquisition dependencies visible at once.
Neither visual is universally superior; select the representation that fits the relationship being analyzed.
Diagram discipline matters
A diagram is an architecture artifact only if readers can interpret it reliably. Chapter 4 emphasizes: - consistent legends, - symbols that match the legend, - consistent direction, - crossing lines that do not look like joins, - color/size/line weight only when they carry meaning, - clear rows/columns/symmetry.
Stop and check
A physical CUSTOMER table maps upward to enterprise concepts. What linkage?
Vertical mapping/model lineage.
A diagram shows CRM → integration hub → Billing → Analytics with transformations. EDM or Flow?
Data Flow Design.
Several processes create/update the same entities and acquisition responsibility is unclear. Which visual may be most helpful?
A process/data matrix because the relationships are many-to-many.