Confusion Cluster — Architecture, Modeling & Metadata
4. Data Architecture vs Data Modeling & Design
Plain language
Architecture sets the enterprise map and direction; Modeling & Design specifies the detailed structures that fit on that map.
Formal distinction
- Data Architecture: identifies enterprise data needs and maintains master blueprints, target-state alignment, roadmaps, flows/standards and cross-project coherence.
- Data Modeling & Design: discovers and represents detailed requirements and constructs conceptual, logical and physical structures/designs.
Similarities
Models can be architecture artifacts; both describe data structure/relationships and both influence implementation.
Differences
Enterprise alignment/blueprint vs precise scoped representation/design.
Deciding clue
Enterprise target/alignment/reusable blueprint → Architecture.
Cardinality/keys/normalization/CDM-LDM-PDM detail → Modeling & Design.
Common trap
A detailed physical schema is not the whole enterprise Data Architecture.
Mini scenario
“Define the enterprise subject-area target and reusable Customer concept across projects” → Architecture.
“Resolve Customer–Order cardinality and primary/foreign keys” → Modeling & Design.
Counterexample
A model can legitimately appear inside architecture work; classify by the dominant task, not merely by the presence of a diagram.
Retrieval check
❓ The stem asks how Customer and Address should be normalized. Which Knowledge Area leads?
✅ Answer: Data Modeling & Design.
🧠 Why: normalization is precise data-structure design rather than enterprise blueprint/alignment.
📖 Sources: Chapter 4 pp. 99–103, 106–109; Chapter 5 current source. See Ch4 Deep Card A and Ch5 Deep Card A.
5. Data Model vs Metamodel
Plain language
A data model models the business/data world. A metamodel models the kinds of Metadata objects and relationships used to describe that world and its systems.
Formal distinction
- Data Model: represents business/data concepts, attributes and relationships.
- Metamodel: represents Metadata entities, attributes and relationships in the Metadata environment.
Similarities
Both are models, both use entities/relationships, and a data model itself can be managed as Metadata.
Differences
They operate at different abstraction targets.
Deciding clue
Ask: What do the modeled entities represent?
Customer/Order/Product → Data Model.
System/Table/Column/Mapping/Steward → Metamodel.
Common trap
Thinking “meta” means the model is simply more conceptual. The distinction is what is being modeled, not how abstract the diagram looks.
Mini scenario
A repository design represents System → Table → Column → Business Term → Steward relationships. → Metamodel.
Counterexample
An enterprise conceptual model with Customer, Product and Location is still a data model, even if it is high-level.
Retrieval check
❓ A diagram shows System, Table, Column, Mapping, and Steward. Data model or metamodel?
✅ Answer: Metamodel.
🧠 Why: the entities are Metadata objects describing data/systems/management context rather than the business entities themselves.
📖 Source: Chapter 12 pp. 413–414. See Ch12 Deep Card F.
6. Business Glossary vs Data Dictionary vs Data Catalog/Directory
Plain language
Glossary tells you what a business term means; Dictionary tells you structural properties of a data element; Catalog/Directory helps you find where data or sources are.
Formal distinction
- Business Glossary: business concepts, terms and approved definitions.
- Data Dictionary: dataset/element structural properties and technical detail.
- Directory/Catalog: searchable source/system/location inventory for discovery.
Similarities
Modern Metadata platforms can expose all three through one interface and cross-link them.
Differences
Meaning vs structure vs discovery/location.
Deciding clue
“What does it mean?” → Glossary.
“What are this field’s properties?” → Dictionary.
“Where can I find it?” → Catalog/Directory.
Common trap
Letting a vendor product name erase the DMBOK conceptual distinctions.
Mini scenario
- Net Revenue approved definition → Glossary.
CUSTOMER_IDdatatype, nullability and uniqueness → Dictionary.- Which system contains Customer history → Catalog/Directory.
Counterexample
A catalog search result may display a glossary definition and dictionary attributes together; the integrated UI does not make those information types identical.
Retrieval check
❓ “Which systems contain customer-history data?” Which artifact is the closest match?
✅ Answer: Data Catalog/Directory.
🧠 Why: the deciding need is discovery/location, not definition or element structure.
📖 Source: Chapter 12 pp. 403–407. See Ch12 Deep Card B.