7.2 Data Architecture Domain: Data Entities, Storage & Data Management

7.2 Data Architecture Domain: Data Entities, Storage & Data Management

Data Architecture constitutes a critical component of Phase C (Information Systems Architectures) in the TOGAF ADM. It defines the structure, governance, storage, movement, and lifecycle of an enterprise's logical and physical data assets and data management resources. Because data outlives individual software applications, establishing a rigorous Data Architecture ensures that enterprise data remains accurate, accessible, secure, and aligned with strategic business capabilities.

Data Architecture provides the blueprint for transforming raw operational transactions into trusted analytical insights and strategic decision-making assets across the enterprise.

---

The Three Abstraction Levels of Data Models

TOGAF structures Data Architecture artifacts across three distinct levels of modeling abstraction: Conceptual Data Models, Logical Data Models, and Physical Data Models. Each level targets a specific stakeholder audience and serves a unique architectural purpose.

---

1. Conceptual Data Model: Business Semantics

The Conceptual Data Model captures high-level business data concepts (Data Entities) and their primary interrelationships. It establishes a common business vocabulary (Business Glossary) to eliminate ambiguity across business domains.

• Key Constructs: High-level entities such as Customer, Account, Product, Order, and Supplier.
• Scope: Covers broad enterprise subject areas without detailing attributes, data types, or database technicalities.

2. Logical Data Model: Structural Rigor & Normalization

The Logical Data Model expands the conceptual model by defining specific attributes, relationships, cardinalities (e.g., 1-to-Many, Many-to-Many), and data integrity rules. Logical models typically adhere to database normalization standards (e.g., Third Normal Form - 3NF) to eliminate redundant data attributes and prevent update anomalies.

• Key Constructs: Entity attributes (e.g., Customer_Tax_ID, Order_Placement_Timestamp), relationship cardinalities, domain constraints, and candidate keys.
• Neutrality: Remains independent of whether data will eventually be stored in a relational RDBMS, document database, or graph store.

3. Physical Data Model: DBMS Execution & Storage

The Physical Data Model translates the logical model into concrete technical implementations optimized for specific storage engines and performance requirements. Physical modeling balances normalization with controlled denormalization to achieve target query latency, throughput, and storage efficiency.

• Key Constructs: Physical table schemas, column data types (e.g., VARCHAR(255), UUID), primary key indexes, B-tree/LSM indexes, table partitioning schemes, and sharding keys.
• Storage Paradigms: Encompasses relational databases (OLTP), columnar analytical data warehouses (OLAP), document stores, key-value caches, and distributed object storage.

+---------------------------------------------------------------------------------+
| CONCEPTUAL MODEL: [Customer] -------- (Places) --------> [Order]                 |
+---------------------------------------------------------------------------------+
                                       |
                                       v
+---------------------------------------------------------------------------------+
| LOGICAL MODEL:    Customer (ID, Name, Email) 1---* Order (ID, CustID, Date, Amt)|
+---------------------------------------------------------------------------------+
                                       |
                                       v
+---------------------------------------------------------------------------------+
| PHYSICAL MODEL:   CREATE TABLE tbl_customer (cust_id UUID PRIMARY KEY, ...)    |
|                   CREATE TABLE tbl_order (order_id BIGINT, cust_id UUID, ...)   |
+---------------------------------------------------------------------------------+

---

Logical vs. Physical Data Components

In TOGAF, Data Architecture categorizes data repositories into Data Components:

• Logical Data Components: Boundary definitions that group logically related data entities serving specific business capabilities (e.g., Customer Master Data Component, Financial Ledger Data Component).
• Physical Data Components: Actual physical software systems, database instances, or storage clusters hosting the data (e.g., PostgreSQL Customer DB Cluster, AWS S3 Analytics Data Lake, Snowflake Financial Warehouse).

---

Core Data Management & Governance Principles

Data Architecture must define explicit operational principles governing data ownership, consistency, and compliance across the enterprise lifecycle:

1. System of Record (SoR) & Golden Source

For every enterprise data entity, Data Architecture must designate a single System of Record (SoR). The System of Record is the authoritative, canonical source responsible for creating and updating that entity. All other downstream applications, data marts, and caches consume read-only replicas or synchronized feeds from the System of Record, preventing conflicting data edits across systems.

2. CRUD Matrix (Create, Read, Update, Delete)

A CRUD Matrix maps Application Components to Data Entities, explicitly declaring which application holds authority to Create, Read, Update, or Delete specific data entities. Enforcing strict CRUD boundaries prevents unauthorized applications from directly modifying underlying database tables.

+-----------------------+------------------+------------------+------------------+
| Application / Entity  | Customer Entity  | Order Entity     | Product Catalog  |
+-----------------------+------------------+------------------+------------------+
| CRM Portal            |  CREATE / UPDATE |       READ       |       READ       |
| Order Engine          |       READ       |  CREATE / UPDATE |       READ       |
| Inventory System      |    NO ACCESS     |       READ       |  CREATE / UPDATE |
| Billing Gateway       |       READ       |      UPDATE      |    NO ACCESS     |
+-----------------------+------------------+------------------+------------------+

3. Data Privacy and Regulatory Compliance

Modern Data Architecture must bake regulatory compliance directly into data storage and flow models. Architectures must address:

• Data Classification: Categorizing data into Public, Internal, Confidential, and Restricted (PII / PHI).
• Regulatory Frameworks: Enforcing GDPR (Right to be Forgotten, Data Minimization), CCPA, and HIPAA requirements.
• Security Controls: Implementing field-level encryption at rest (AES-256), TLS encryption in transit, data masking, pseudonymization, and role-based access control (RBAC).

---

Key Data Architecture Deliverables in TOGAF

During Phase C, the data architecture team produces standardized architectural deliverables stored in the Enterprise Architecture Repository:

1. Data Entity Catalog: Master inventory of all enterprise data entities, definitions, owners, and classification levels.
2. Data Entity / Data Component Matrix: Matrix mapping logical data entities to physical storage systems.
3. Data Dissemination Diagram: Visual mapping showing how data flows between source systems, integration hubs, and destination data stores.
4. Data Lifecycle Diagram: Diagram depicting the lifecycle stages of critical data entities from creation, ingestion, transformation, storage, archiving, to purge/deletion.