Study guide
5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
TOGAF Enterprise Architecture Practitioner OGEA-103
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Mechanics & Foundation Overview
1.1 OGEA-103 Exam Structure, Gradient Scoring & Open-Book Strategy 1.2 The TOGAF Standard 10th Edition Structure & Core Concepts 1.3 Enterprise Architecture in Practice: Context, Scope, and Architecture Domains 1.4 The Context for Enterprise Architecture: Purpose, Capability, Security, and the Digital Enterprise
2 Chapter 2: Preliminary Phase & Establishing the EA Capability
2.1 Preliminary Phase Objectives, Inputs, and Activities 2.2 Scope of the Enterprise and Defining the Architecture Footprint 2.3 Establishing Architecture Governance, Frameworks, and Tools
3 Chapter 3: Architecture Vision & Stakeholder Management (Phase A)
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition 3.2 Stakeholder Management: Identification, Classification, the Power/Interest Grid, and the Stakeholder Map 3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation 3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
4 Chapter 4: Business Architecture (Phase B)
4.1 Phase B Objectives, Steps, and Business Modeling Approaches 4.2 Business Capabilities, Capability Mapping, and Assessment 4.3 Value Streams, Value Stream Mapping, and Capability Cross-Mapping 4.4 Business Architecture Artifacts, Gap Analysis, and Architecture Definition Document Updates
5 Chapter 5: Information Systems Architectures — Data Architecture (Phase C)
5.1 Phase C Data Architecture Objectives, Approach, and Data Principles 5.2 Conceptual, Logical, and Physical Data Models and Data Management 5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
6 Chapter 6: Information Systems Architectures — Application Architecture (Phase C)
6.1 Phase C Application Architecture Objectives, Approach, and Baseline vs. Target First 6.2 Application Portfolio Rationalization, Component Modeling, and Application Integration 6.3 Application/Organization Matrix, Application Gap Analysis, and Boundary Definitions
7 Chapter 7: Technology Architecture (Phase D)
7.1 Phase D Objectives, Cloud & Modern Platforms, and Technology Principles 7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling 7.3 Technology Gap Analysis, Non-Functional Requirements, and Reference Models
8 Chapter 8: Opportunities and Solutions (Phase E)
8.1 Phase E Objectives, Consolidated Gap Analysis, and Work Package Formulation 8.2 Architecture Building Blocks (ABBs) to Solution Building Blocks (SBBs) Transition 8.3 Transition Architectures, Incremental Delivery, and Dependency Analysis 8.4 Architecture Roadmap Development and Trade-Off Analysis 8.5 Business Transformation Readiness Assessment and Risk Management
9 Chapter 9: Migration Planning (Phase F)
9.1 Phase F Objectives, Stakeholder Collaboration, and Governance Alignment 9.2 Business Value Assessment, Cost-Benefit Analysis, and Risk/Feasibility Scoring 9.3 Implementation and Migration Plan Deliverable, Resource Allocation, and Transition Roadmaps
10 Chapter 10: Implementation Governance (Phase G)
10.1 Phase G Objectives, Implementation Governance Structure, and Project Architecture Hand-off 10.2 Architecture Contracts: Purpose, Types, Timing, and Stakeholder Commitments 10.3 Architecture Compliance Reviews: Conformance Levels, Process, Timing, and Checklists
11 Chapter 11: Architecture Change Management (Phase H) & Requirements Management
11.1 Phase H Objectives, Drivers of Architecture Change, and Value Monitoring 11.2 Change Classification: Simplification, Incremental, and Re-Architecting Changes 11.3 Ongoing Governance, Retirement of Solutions, and Maintenance vs. New ADM Cycle 11.4 Requirements Management: Central Role, Traceability, Mid-Phase Discovery, and Scope Conflict
12 Chapter 12: Architecture Governance, Boards, and Dispensations
12.1 Architecture Governance Framework, Organizational Roles, and RACI Matrix 12.2 Architecture Board Structure, Federation, Responsibilities, and Meeting Operations 12.3 Compliance Assessment, Dispensation Process, Expiration, and Remediation Tracking 12.4 Architecture Principles, the Decision Log, and Resolving Principle Conflicts
13 Chapter 13: Architecture Content Framework & Architecture Repository
13.1 The TOGAF Content Framework and Enterprise Metamodel 13.2 Deliverables, Artifacts (Catalogs, Matrices, Diagrams), and Building Blocks (ABBs vs SBBs) 13.3 Architectural Views, Viewpoints, Stakeholder Concerns, and ISO/IEC/IEEE 42010 13.4 The Enterprise Continuum and the TOGAF 10 Architecture Repository
14 Chapter 14: EA Capability, Tailoring, and Iteration
14.1 Tailoring the ADM: Enterprise Context, Process Weight, and Agile Integration 14.2 ADM Iteration Cycles, Levels, and Classes of Architecture Engagement 14.3 Architecture Maturity Models, Capability Assessment, and EA Performance Measures 14.4 Supporting the ADM Work: The TOGAF Library, Series Guides, Patterns, and Security
5.3 Data Entity/Business Function Matrix, Data Architecture Gap Analysis, and Interoperability Requirements
Key Takeaways Explain This Topic AI
The Data Entity/Business Function matrix links Phase B functions to Phase C data entities; CRUD marking is a common way to show which function creates, reads, updates, or deletes each entity.
Practical CRUD heuristics check that each entity has one authoritative creator and that no entity is orphaned; they are good practice rather than TOGAF rules.
The Application/Data matrix shows which applications use which data entities, exposing duplicate data stores and integration hotspots.
TOGAF defines interoperability as the ability to share information and services, and uses four Degrees of Interoperability: Unstructured Data Exchange, Structured Data Exchange, Seamless Sharing of Data, and Seamless Sharing of Information.
Interoperability conflicts are resolved by adding a building block that transforms or translates, or by changing the specification of the conflicting building blocks.
Last updated: October 2026
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:
- Business Function (Phase B) Customer Profile Risk Dossier Insurance Policy Claim Dossier General Ledger Record
- Customer Onboarding C , R, U — — — —
- Underwriting & Risk Analysis R C , R, U — — —
- Policy Administration R R C , R, U, D R —
- Claims Processing R R R C , R, U, D —
- Financial Accounting & Reporting — — R R C , R, U, D
- Architectural Insights from the Worked Matrix
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.
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.
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:
Gap Category Definition & Architectural Impact Remediation Strategy in Phase E/F
Missing Data Entities Target business capabilities require new data entities not present in baseline systems (e.g., Customer Consent Ledger for privacy compliance, Carbon Offset Metrics ). Create new Architecture Building Blocks (ABBs) and define new data management services.
Redundant / Duplicate Entities Multiple baseline databases store overlapping entities under different names (e.g., Client in CRM vs. Subscriber in Billing). Rationalize into a unified canonical entity managed via Master Data Management (MDM).
Orphaned / Obsolete Entities Data entities lingering in legacy databases that are no longer created, updated, or read by any active business capability. Securely decommission, extract historical records for legal archival, and purge storage.
Governance & Quality Gaps Data entities that exist but lack designated Data Owners, data quality validation rules, or automated metadata tagging. Establish formal stewardship contracts, implement data catalogs, and deploy automated data quality monitors.
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:
- Phase Interoperability work
- A Business scenarios first reveal the nature and security considerations of information and service exchanges
- B Exchanges are defined in business terms
- C (Data) The content of the exchanges is detailed using the corporate data or information exchange model
- C (Application) How applications will share information and services is specified
- D The technical mechanisms that permit the exchanges are specified
E Actual solutions (for example, COTS packages) are selected, and interoperability requirements are consolidated and reconciled
- F Interoperability is logically implemented
- 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:
Degree 1, Unstructured Data Exchange : human-interpretable free text, such as reports and papers.
Degree 2, Structured Data Exchange : human-interpretable structured data that still needs manual compilation, receipt, or dispatch.
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.
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 × ( N − 1 ) N \times (N - 1) N × ( N − 1 ) point-to-point translations between N N 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).