Study guide
8.1 Enterprise Data Architecture & Zachman Framework
DAMA Certified Data Management Professional CDMP
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & DMBoK Framework
1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles
2 Chapter 2: Data Governance (Part A)
2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures
3 Chapter 2: Data Governance (Part B)
2.4 Data Stewardship 2.5 Governance Metrics & Implementation
4 Chapter 3: Data Modeling and Design (Part A)
Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization
5 Chapter 3: Data Modeling and Design (Part B)
3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices
6 Chapter 4: Data Quality (Part A)
Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle
7 Chapter 4: Data Quality (Part B)
4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting
8 Chapter 5: Metadata Management (Part A)
5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures
9 Chapter 5: Metadata Management (Part B)
5.4 Standards and Semantics 5.5 Metadata Governance & Integration
10 Chapter 6: Master and Reference Data Management
6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards
11 Chapter 7: Data Warehousing and Business Intelligence
7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses
12 Chapter 8: Data Architecture
8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards
13 Chapter 9: Document and Content Management
9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies
14 Chapter 10: Data Integration and Interoperability
Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards
15 Chapter 11: Data Security
Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards
16 Chapter 12: Data Storage and Operations
Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations
17 Chapter 13: Big Data and Data Science
13.1 Big Data V's & Technologies
18 Chapter 14: Data Ethics
14.1 DMBoK Data Ethics Framework
19 Chapter 15: Data Management Process and Maturity
15.1 Maturity Assessment Frameworks
8.1 Enterprise Data Architecture & Zachman Framework
Key Takeaways Explain This Topic AI
The Zachman Framework is an enterprise ontology consisting of a 6x6 matrix, mapping six stakeholders (rows) against six interrogatives (columns).
Column 1 (What) represents the data aspect, progressing from the Subject Area Model (Row 1) to active database instances (Row 6).
An Enterprise Data Model (EDM) is a holistically integrated model that aligns data concepts across the entire enterprise, independent of technical constraints.
Row 4 represents the Technology Model (Builder's physical schema view), whereas Row 5 represents Detailed Representations (Subcontractor's DDL/scripts).
Last updated: July 2026
Introduction to Data Architecture
Data Architecture is defined by the DAMA Certified Data Management Professional (CDMP) curriculum and DAMA-DMBOK2 as the master plan containing blueprints, models, standards, and integration designs that define how data is collected, stored, integrated, and used across the organization. It acts as the bridge between business strategy and IT systems, translating business goals into concrete technical structures.
Enterprise Data Architecture (EDA) is a subset of Enterprise Architecture (EA) . EDA focuses on designing and managing the structure of data assets across the entire organization. It establishes standard models, definitions, and integration patterns to break down data silos, reduce redundant storage, improve data quality, and support business intelligence and analytics. The primary goals of EDA include:
Establishing a single version of the truth by reducing redundant data and silos.
Enhancing integration and data quality across disparate systems.
Reducing operational costs through data standardization and system consolidation.
Enabling business intelligence and analytics by providing a clear, governed data foundation.
The Zachman Framework for Enterprise Architecture
The Zachman Framework , created by John Zachman in 1987, is an ontology used to classify and organize enterprise architecture artifacts. It is represented as a 6x6 matrix. The rows represent the viewpoints of different stakeholders in the design and construction process, while the columns represent the basic interrogative questions: What, How, Where, Who, When, and Why.
The Columns (Aspects)
Each column focuses on a specific aspect of the enterprise:
Column 1: What (Data) - This is the primary domain of the Data Architect. It deals with material inventories, which translate to business entities, data structures, tables, and files in information systems.
Column 2: How (Process) - Focuses on business processes and software transformations. It details how input data is processed into outputs.
Column 3: Where (Network) - Concerns geographical distribution, locations, nodes, and network connections.
Column 4: Who (People) - Focuses on organizational units, human resources, roles, security access, and data ownership/stewardship.
Column 5: When (Time) - Deals with temporal events, business schedules, processing cycles, and triggers.
Column 6: Why (Motivation) - Focuses on business drivers, corporate goals, policies, and business rules.
The Rows (Perspectives)
The rows define the abstraction level and the stakeholder perspective:
Row 1: Executive Summary (Contextual) - Planner Perspective : Defines the list of business items that are relevant to the enterprise. In Column 1, this represents the Subject Area Model (SAM), listing the high-level domains (e.g., Customer, Product, Finance).
Row 2: Business Concepts (Conceptual) - Owner Perspective : Defines the semantic models of the business. In Column 1, this corresponds to the Conceptual Data Model (CDM), showing business entities and their relationships using business terminology.
Row 3: System Model (Logical) - Designer Perspective : Translates business concepts into systematic structures. In Column 1, this is the Logical Data Model (LDM), containing normalized entities, attributes, primary keys, and relationships, independent of technology.
Row 4: Technology Model (Physical) - Builder Perspective : Adapts the logical design to physical constraints. In Column 1, this is the Physical Data Model (PDM), showing database-specific tables, columns, indexes, data types, and constraints.
Row 5: Detailed Representations (Out-of-Context) - Subcontractor Perspective : Focuses on implementation components. In Column 1, this translates to Data Definition Language (DDL) scripts, database deployment schemas, or XML/JSON schemas.
Row 6: Functioning Enterprise (Actual) - User Perspective : The active, operational system. In Column 1, this represents the actual production databases , operational data, and transactional instances.
The Intersection of Data (Column 1) and the Rows
- Row / Perspective Data Aspect (Column 1) Deliverable / Artifact
- Row 1: Planner (Contextual) List of Business Things Subject Area Model (SAM)
- Row 2: Owner (Conceptual) Business Entity Relations Conceptual Data Model (CDM)
- Row 3: Designer (Logical) Entity-Attribute-Key Schema Logical Data Model (LDM)
- Row 4: Builder (Physical) Tables and Columns Schema Physical Data Model (PDM)
- Row 5: Subcontractor (Detailed) Database Scripts & Files Data Definition Language (DDL)
- Row 6: User (Actual) Active Production Instances Live Databases & Transactions
- Enterprise Data Models (EDM)
An Enterprise Data Model (EDM) is an integrated, holistic model defining the data across the entire enterprise. It is a critical component of EDA. The EDM provides a common business vocabulary, aligns data structures with business processes, and serves as a master blueprint for all system-specific models.
An EDM is typically constructed top-down:
Subject Area Model : High-level groupings of related concepts (e.g., Customer, Product, Asset, Location, Agreement, Event, Financial).
Conceptual Data Model : Formalizes the subject areas into distinct business entities with definitions and relationships, ignoring attributes and keys.
Enterprise Logical Data Model : Combines all conceptual models into a fully normalized, detailed schema that serves as the source of truth for design.
Purpose and Benefits of EDM:
Reduces Data Redundancy : Identifies duplicate data stores, reducing integration complexity.
Enforces Data Quality : Promotes clear ownership and metadata definitions.
Speeds Up Project Delivery : New projects can reuse existing EDM structures rather than starting from scratch.
Facilitates Master Data Management (MDM) : Identifies master data entities and their relationships.
Worked Example: Banking Customer Lifecycle in the Zachman Framework
To understand how these concepts apply to a real-world enterprise, consider a retail bank mapping its customer data through the Zachman Framework:
Row 1 (Planner/Contextual) : The bank's executive committee outlines its business boundaries. They identify "Customer", "Account", and "Transaction" as core subject areas in the bank's Subject Area Model.
Row 2 (Owner/Conceptual) : The business domain experts define "Customer" as a legal entity that holds an account, and "Account" as a financial contract. This is documented in the Conceptual Data Model showing a many-to-many relationship (a customer can have multiple accounts, and an account can have multiple customers).
Row 3 (Designer/Logical) : The data architect designs the Logical Data Model, resolving the many-to-many relationship with an associative entity "Account Ownership" and defining attributes like Customer ID, Social Security Number, Account Open Date, and Account Balance.
Row 4 (Builder/Physical) : The database architect maps this to a Physical Data Model for an Oracle Database, defining table names like TBL_CUST_INFO , datatypes like VARCHAR2(50) , indexes on SSN , and foreign key constraints.
Row 5 (Subcontractor/Detailed) : The DBA writes a DDL SQL script containing CREATE TABLE TBL_CUST_INFO (...) statements and stores them in a repository.
Row 6 (User/Actual) : The production database contains actual rows of active bank customer data (e.g., Jane Doe, Account Number 987654321).
Exam Trap: Zachman Rows vs. Deliverables
A common exam error is confusing Row 4 (Builder/Physical Model) with Row 5 (Subcontractor/Detailed DDL scripts). The Builder perspective focuses on database design (tables, columns, indexes), while the Subcontractor perspective focuses on the actual code and scripts used to instantiate that design (DDL, database files). Remember that the columns are orthogonal, meaning Column 1 (What/Data) is independent of Column 2 (How/Process), but they must align at the same row perspective.