4.2 Phase C Data Architecture: Principles, Data Models & Governance

4.2 Phase C Data Architecture: Principles, Data Models & Governance

Key Takeaway: Phase C Data Architecture establishes how enterprise data assets are structured, modeled, governed, and secured. By structuring data modeling across conceptual, logical, and physical tiers and utilizing key artifacts like the Data Entity / Business Function Matrix, architects create a sustainable baseline and target data blueprint.

Data Architecture is the first of two domains within TOGAF ADM Phase C. Its overarching objective is to define the target data assets, data management structures, and data governance policies required to support the business capabilities articulated in Phase B. Effective Data Architecture ensures that enterprise information is accurate, accessible, secure, and consistently interpreted across all business units and software applications.

---

Establishing Data Architecture Principles

Before defining specific data entities or database schemas, the architecture team establishes or refines Data Architecture Principles. These principles serve as enduring guidelines for all subsequent data engineering, database procurement, and integration decisions.

Standard TOGAF data principles include:

• Data is an Enterprise Asset: Data belongs to the enterprise as a whole, not to individual business units or software projects. It must be managed with appropriate stewardship and protection.
• Data is Shared: Timely access to accurate data must be provided across organizational boundaries to support cross-functional business processes, eliminating data silos.
• Common Vocabulary and Data Definitions: Data terms, entity names, and data attributes must be defined consistently across the enterprise using an enterprise data dictionary or business glossary.
• Data Security and Privacy Compliance: Data must be protected against unauthorized access, exposure, or modification in compliance with legal, regulatory, and corporate privacy mandates.

---

The Three Tiers of Data Modeling

TOGAF emphasizes a structured, tiered approach to data modeling. Progressing through conceptual, logical, and physical tiers ensures that data requirements remain tied to business meaning rather than being prematurely constrained by specific database technologies.

┌────────────────────────────────────────────────────────────────────────┐
│ 1. CONCEPTUAL DATA MODEL                                              │
│ - High-level business concepts, subject areas, & major relationships  │
│ - Audience: Business executives, domain experts, business architects   │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 2. LOGICAL DATA MODEL                                                 │
│ - Detailed data entities, attributes, primary/foreign keys, rules      │
│ - Technology-agnostic, normalized structures                          │
│ - Audience: Enterprise data architects, data modelers, analysts       │
└───────────────────────────────────┬────────────────────────────────────┘
                                    │
                                    ▼
┌────────────────────────────────────────────────────────────────────────┐
│ 3. PHYSICAL DATA MODEL                                                │
│ - DBMS-specific schemas (SQL DDL, NoSQL JSON schemas, Graph structures)│
│ - Indexing strategies, partitioning, replication, storage optimization │
│ - Audience: Database administrators (DBAs), data engineers             │
└────────────────────────────────────────────────────────────────────────┘

Conceptual Data Model

The Conceptual Data Model captures high-level business subject areas and core business entities without technical details. It defines key concepts such as Customer, Account, Product, Policy, and Order and their fundamental business relationships (e.g., "A Customer places one or more Orders"). This model provides a common language bridging business stakeholders and technical teams.

Logical Data Model

The Logical Data Model expands conceptual entities into detailed, technology-independent structures. It specifies data attributes (e.g., Customer_Tax_ID, Order_Placement_Timestamp), primary keys, foreign key relationships, normalization (typically Third Normal Form / 3NF for operational domains), and business validation rules. The logical data model remains agnostic of whether the ultimate storage mechanism is a relational SQL database, a document-oriented NoSQL store, or a columnar analytics warehouse.

Physical Data Model

The Physical Data Model translates logical data designs into concrete storage implementations tailored to specific Database Management Systems (DBMS). It incorporates technology-specific details such as data types (VARCHAR, TIMESTAMP WITH TIMEZONE), table partitioning strategies, indexing structures (B-Tree, Bitmap), storage clustering, data encryption parameters, and replication topologies.

Tiered Modeling Comparison

---

Core Data Architecture Artifacts

TOGAF Phase C specifies key architectural artifacts—catalogs, matrices, and diagrams—that document baseline and target data environments.

1. Data Entity / Business Function Matrix

The Data Entity / Business Function Matrix maps logical data entities to core business functions. It uses CRUD (Create, Read, Update, Delete) designations to define how business functions interact with enterprise data:

• Architectural Value: Highlights data ownership, identifies missing CRUD operations (e.g., an entity created without an update mechanism), and exposes redundant data creation across departments.

2. Conceptual Data Diagram

Visualizes core data entities, subject areas, and entity relationship cardinalities (one-to-one, one-to-many, many-to-many) to illustrate enterprise information scope.

3. Data Dissemination Diagram

Depicts how data entities flow between databases, application systems, physical hosting sites, and external third-party partners. It details data transfer mechanisms, ETL frequencies (real-time stream vs. nightly batch), and data transformation points.

4. Data Security Diagram

Maps data classification tiers (Public, Internal, Confidential, Restricted/PII) to storage repositories, access controls, tokenization policies, and encryption requirements (at-rest and in-transit).

5. Data Migration Diagram

Outlines the transition path for transferring legacy data structures to target databases. It specifies extraction rules, data cleansing procedures, schema transformations, and validation checkpoints.

---

Governance, MDM, and Data Lifecycle Management

Master Data Management (MDM)

A foundational responsibility of Data Architecture is establishing Master Data Management (MDM) frameworks. Master data represents the non-transactional, foundational reference entities shared across the enterprise (e.g., Customer, Employee, Vendor, Product). MDM establishes a Golden Record or Single Source of Truth (SSOT), mitigating data fragmentation where multiple systems maintain conflicting customer records.

Data Lifecycle Management (DLM)

Data Architecture defines governance policies across all five phases of the Data Lifecycle:

1. Creation / Ingestion: Capturing data at source with input validation and schema enforcement.
2. Storage & Maintenance: Securing data repositories with encryption, backup, and redundancy.
3. Usage & Sharing: Provisioning API access and analytics views governed by role-based access control (RBAC).
4. Archiving: Migrating aged operational data to low-cost immutable cold storage.
5. Purging / Destruction: Permanently purging expired data in accordance with regulatory retention policies and privacy mandates (e.g., "Right to be Forgotten").

---

Conducting Data Architecture Gap Analysis

Phase C Data Architecture concludes with a systematic Gap Analysis comparing the Baseline Data Architecture against the Target Data Architecture. Architects construct a Gap Analysis Matrix to identify:

• Intentionally Eliminated Entities: Obsolete, redundant, or shadow data stores targeted for retirement.
• Newly Created Entities: New data entities required to support new business capabilities (e.g., Customer Sentiment Score, IoT Telemetry Record).
• Modified / Enhanced Entities: Baseline entities requiring schema expansion, normalization, or MDM integration.

All identified gaps are documented in the Architecture Requirements Specification and converted into candidate work packages for Phase E.