8.1 Enterprise Data Architecture & Zachman Framework

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:

1. 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.
2. Column 2: How (Process) - Focuses on business processes and software transformations. It details how input data is processed into outputs.
3. Column 3: Where (Network) - Concerns geographical distribution, locations, nodes, and network connections.
4. Column 4: Who (People) - Focuses on organizational units, human resources, roles, security access, and data ownership/stewardship.
5. Column 5: When (Time) - Deals with temporal events, business schedules, processing cycles, and triggers.
6. 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:

1. 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).
2. 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.
3. 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.
4. 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.
5. 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.
6. 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

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:

1. Subject Area Model: High-level groupings of related concepts (e.g., Customer, Product, Asset, Location, Agreement, Event, Financial).
2. Conceptual Data Model: Formalizes the subject areas into distinct business entities with definitions and relationships, ignoring attributes and keys.
3. 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.