5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements

5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability

Phase C Data Architecture translates strategic business models into rigorous structural blueprints. To accomplish this, enterprise architects use the catalogs, matrices, and diagrams defined in the TOGAF Content Framework. Mastering the construction and interpretation of these artifacts, executing gap analysis, and designing interoperability contracts are central competencies tested on the TOGAF Enterprise Architecture Practitioner examination.

---

Essential Phase C Data Architecture Artifacts

The TOGAF Content Framework classifies Phase C data artifacts into catalogs (Data Entity/Data Component catalog), matrices (Data Entity/Business Function and Application/Data), and diagrams (Conceptual Data, Logical Data, Data Dissemination, Data Security, Data Migration, and Data Lifecycle). The most frequently used are:

1. Catalogs (Inventories)

• Data Entity/Data Component Catalog: A structured inventory listing all logical data entities (e.g., Customer, Policy, Invoice, Order) and the physical data components that implement them (e.g., Customer Master PostgreSQL Database, Policy Document S3 Store). It captures entity descriptions, classification levels, data owners, and lifecycle states.

2. Matrices (Relationship Cross-Mappings)

• Data Entity/Business Function Matrix: Maps business functions (from Phase B) to data entities, identifying which business capabilities create, read, update, or delete enterprise data.
• Application/Data Matrix: Maps software applications to data entities, illustrating which applications maintain, transform, or consume specific data assets.

3. Diagrams (Visual Views)

• Data Dissemination Diagram: Depicts the physical and logical flow of data entities across application components, databases, and network boundaries. It highlights protocols, message formats, and security zones.
• Data Security Diagram: Illustrates security classification zones, encryption barriers, tokenization gateways, and role-based access boundaries across the enterprise data landscape.
• Data Migration Diagram: Outlines the staging, extraction, cleansing, transformation, and loading pipelines required to migrate data from legacy baseline systems into target architectures.

---

The Data Entity/Business Function Matrix (CRUD Analysis)

The Data Entity/Business Function Matrix is one of the most powerful analytical tools in enterprise architecture. It establishes the operational link between Phase B (Business Architecture) and Phase C (Data Architecture) by documenting how business functions interact with data entities using CRUD actions:

• C (Create): The business function has the formal authority to instantiate a new record of the data entity.
• R (Read): The business function queries, extracts, or views the data entity to perform operational activities or analytical assessments.
• U (Update): The business function modifies existing attributes or changes the state of the data entity during operational processing.
• D (Delete / Deactivate): The business function archives, de-identifies, or deletes the data entity in accordance with data retention schedules.

Critical Architectural Rules Governing CRUD Analysis

TOGAF does not prescribe CRUD rules, but enterprise architects commonly check CRUD matrices against three practical heuristics:

Rule 1: The Single Creator Rule (System of Record Authority)

Every data entity must have exactly one primary business function (and, in Application Architecture, one corresponding application) with the authority to Create (C) that entity. If multiple independent business functions have "Create" authority over the same data entity, a severe architectural defect exists: disparate systems will generate conflicting master records, identity keys will diverge, and the enterprise will lose a single authoritative System of Record.

Rule 2: The No-Orphan Rule (Completeness and Cleanliness)

• Read/Update Without Create: If an entity is Read (R) or Updated (U) by business functions but has no function that Creates (C) it, an architectural blind spot exists. Data is entering the enterprise through ungoverned channels, shadow spreadsheets, or undocumented external feeds.
• Create Without Read: If an entity is Created (C) by a business function but is never Read (R) or consumed by any downstream function, it represents "dark data"—operational overhead and storage expenditure that delivers zero measurable business value.

Rule 3: Governed Deletion and Lifecycle Integrity

Every entity containing sensitive, financial, or regulated data must have a designated business function responsible for its Deletion or Archival (D) to guarantee compliance with legal retention policies (such as GDPR erasure or tax audit retention rules).

---

Worked Example: Insurance Enterprise CRUD Matrix

The following matrix illustrates an operational CRUD analysis for an enterprise insurance provider:

Architectural Insights from the Worked Matrix

1. Single Creator Adherence: Each data entity has exactly one business function marked with C: Customer Onboarding creates Customer Profile, Underwriting creates Risk Dossier, Policy Administration creates Insurance Policy, Claims Processing creates Claim Dossier, and Financial Accounting creates General Ledger Record. System of Record integrity is preserved.
2. Information Lineage: Underwriting consumes Customer Profile (R) to generate Risk Dossier (C). Policy Administration consumes both to issue the Insurance Policy (C). Claims Processing reads the Insurance Policy (R) before creating a Claim Dossier (C). The flow mirrors the end-to-end customer value stream.
3. Audit and Compliance: Regulated entities (Insurance Policy, Claim Dossier, and General Ledger Record) have explicit Deletion/Archival (D) authorities assigned to ensure compliance with insurance regulatory retention rules.

---

The Application/Data Matrix

While the CRUD matrix maps business functions, the Application/Data Matrix maps software applications to data entities. It reveals the physical health of the IT portfolio by identifying:

• Data Store Redundancy: Multiple disparate applications independently persisting local copies of Customer Profile, leading to reconciliation failures.
• Database Monoliths: A single legacy database directly accessed by 30 different applications through raw SQL queries, creating high coupling that blocks cloud modernization.
• Shadow IT Data Stores: Business-critical entities maintained in local desktop spreadsheets or unmanaged departmental servers.

---

Data Architecture Gap Analysis

During Phase C, enterprise architects conduct a formal Gap Analysis to identify differences between the Baseline (current state) and Target (future state) data architectures. The gap analysis technique evaluates:

---

The TOGAF Interoperability Requirements Technique

TOGAF defines interoperability as "the ability to share information and services". Its Interoperability Requirements technique defines the degree to which information and services are to be shared, which is an especially useful requirement in a complex organization or extended enterprise.

Interoperability Across the ADM

Interoperability is determined throughout the ADM:

Categories and Degrees

Many organizations categorize interoperability as Operational or Business (how business processes are shared), Information (how information is shared), and Technical (how technical services are shared or connect). From an IT perspective, TOGAF also describes presentation, information, application, and technical integration.

To make requirements measurable, TOGAF gives the Degrees of Interoperability used by the Canadian Department of National Defence and NATO:

1. Degree 1, Unstructured Data Exchange: human-interpretable free text, such as reports and papers.
2. Degree 2, Structured Data Exchange: human-interpretable structured data that still needs manual compilation, receipt, or dispatch.
3. Degree 3, Seamless Sharing of Data: automated data sharing among systems based on a common exchange model. It can be refined into 3A Formal Message Exchange, 3B Common Data Exchange, 3C Complete Data Exchange, and 3D Real-time Data Exchange.
4. Degree 4, Seamless Sharing of Information: universal interpretation of information through cooperating applications.

Interoperability standards must be SMART, and the degree required need not be symmetrical between two parties. A Business Information Interoperability Matrix started in Phase B records which degree each stakeholder needs with each other stakeholder. It is refined in Phase C into an Information Systems Interoperability Matrix between specific systems, for example Degree 3A rather than just Degree 3.

Operating Model and Conflicts

The enterprise's operating model, meaning the level of business process integration and standardization it needs, indicates the right interoperability approach. It should be determined in Phase A if not Phase B, and definitely by Phase E. When reused building blocks, COTS products, or service providers impose conflicting requirements, TOGAF gives two basic approaches: create a building block that transforms or translates between the conflicting ones, or change the specification of the conflicting building blocks. Business interoperability is usually the hardest issue, because COTS products embed their own processes; any change to business interoperability requirements must be signed off by the business architects and sponsors in a revised Statement of Architecture Work.

Practical Mechanisms

Canonical data models and contract-first APIs are common ways to implement Degree 3 and Degree 4 exchanges. A canonical model avoids the $N \times (N - 1)$ point-to-point translations between $N$ systems by having each system map once to a shared model.

Common Exam Traps & Pitfalls

• Trap 1: Tolerating Multiple Systems of Record: Scenario questions often describe a business where the Sales team creates customer accounts in CRM while the Billing team independently creates customer accounts in ERP. Distracter options suggest synchronizing them with batch scripts. The stronger answer designates one authoritative system of record and governed service interfaces, rather than synchronizing duplicates.
• Trap 2: Ignoring Deletion/Archival in CRUD: Candidates often focus exclusively on Create and Read operations. On the exam, questions on regulatory compliance (e.g., GDPR Right to Erasure, financial records audit) require explicit identification of the Delete / Deactivate (D) function.
• Trap 3: Confusing Data Dissemination with Infrastructure Diagrams: A Data Dissemination diagram models the movement of data entities and message contracts across application components and logical trust boundaries. Distracters will describe it as a diagram showing physical IP subnets, Ethernet switches, or virtual machine hypervisors (which belong to Phase D Technology Architecture).