ExamFinch.com My Study

Study guide

4.4 Data and Application Integration, Migration & Interoperability

Practice this exam

TOGAF Enterprise Architecture Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction to TOGAF & Enterprise Architecture Concepts

1.1 Overview of TOGAF Standard 10th Edition & Enterprise Architecture Concepts 1.2 The Structure of the TOGAF Standard (Easily Navigated Body of Knowledge) 1.3 Core Concepts: Enterprise, Architecture, Deliverables, Artifacts, and Building Blocks 1.4 TOGAF Certification Paths & the OGEA-101 Exam Plan

2 Chapter 2: ADM Foundation & Preliminary Phase

2.1 The Architecture Development Method (ADM) Cycle & Requirements Management 2.2 Preliminary Phase: Scope, Principles, and Architecture Capability Setup 2.3 Tailoring the ADM & Applying Iteration / Architecture Levels 2.4 Applying the ADM: The TOGAF Library, Purpose-Based Architecture Projects & the Digital Enterprise

3 Chapter 3: ADM Architecture Vision & Business Architecture

3.1 Phase A: Architecture Vision, Stakeholder Management & Value Proposition 3.2 Business Architecture Scope, Strategy & Capability Mapping 3.3 Phase B: Business Architecture Inputs, Steps, Outputs & Artifacts 3.4 Business Scenarios & Value Stream Modeling

4 Chapter 4: ADM Information Systems Architectures (Phase C)

4.1 Information Systems Architectures Overview & Phase C Strategy 4.2 Phase C Data Architecture: Principles, Data Models & Governance 4.3 Phase C Application Architecture: Logical Components, Services & Interfaces 4.4 Data and Application Integration, Migration & Interoperability

5 Chapter 5: ADM Technology Architecture & Solution Realization (Phases D, E, F)

5.1 Phase D: Technology Architecture, Platform Services & Infrastructure 5.2 Phase E: Opportunities and Solutions & Initial Implementation Strategy 5.3 Phase F: Migration Planning, Roadmap Development & Portfolio Prioritization 5.4 Transition Architectures & Implementation Dependencies

6 Chapter 6: ADM Governance, Change & Requirements Management (Phases G, H)

6.1 Phase G: Implementation Governance & Architecture Compliance 6.2 Phase H: Architecture Change Management & Driver Monitoring 6.3 Requirements Management: Central Flow, Impact Analysis & Traceability 6.4 Architecture Contracts, Dispensations & Compliance Reviews

7 Chapter 7: BDAT Architecture Domains Deep-Dive

7.1 Business Architecture Domain: Functions, Processes & Value Streams 7.2 Data Architecture Domain: Data Entities, Storage & Data Management 7.3 Application Architecture Domain: Application Services, Systems & Integration Patterns 7.4 Technology Architecture Domain: Hardware, Software, Cloud & Network Platforms

8 Chapter 8: Architecture Content — Content Framework, Enterprise Metamodel & Artifacts

8.1 Architecture Content Framework Overview & Deliverables vs Artifacts vs Building Blocks 8.2 Architecture Building Blocks (ABBs) vs Solution Building Blocks (SBBs) 8.3 The Enterprise Metamodel: Core Concepts, Entities & Attributes 8.4 Architecture Catalogs, Matrices & Diagrams (Visual Representation) 8.5 Stakeholders, Concerns, Architecture Views & Viewpoints

9 Chapter 9: Architecture Governance, Capability & Maturity

9.1 Architecture Governance Framework & The Role of the Architecture Board 9.2 Establishing an Architecture Capability & Organizational Structure 9.3 Architecture Skills Framework, Roles & Competency Levels 9.4 Architecture Maturity Models & Capability Assessments

10 Chapter 10: Enterprise Continuum, Reference Models & Key Techniques

10.1 Enterprise Continuum, Architecture Repository & Landscape Partitioning 10.2 Technical Reference Model (TRM) & Integrated Information Infrastructure Reference Model (III-RM) 10.3 Core EA Techniques: Gap Analysis, Interoperability, Risk, Capability-Based Planning & Architecture Patterns

4.4 Data and Application Integration, Migration & Interoperability

Key Takeaways Explain This Topic AI

Phase C concludes by harmonizing Data Architecture and Application Architecture through cross-domain integration matrices.

The Application / Data Matrix maps software applications to logical data entities, explicitly identifying data CRUD rights and System of Record (SoR) ownership.

Interoperability must be evaluated across organizational, semantic, syntactic, and behavioral layers to ensure seamless cross-system data exchange.

Legacy data migration strategies incorporate data profiling, data cleansing, ETL pipelines, dual-write synchronization, and archival pipelines.

Consolidated Phase C gap analysis deliverables yield candidate work packages feeding directly into Phase D and Phase E.

Last updated: August 2026

4.4 Data and Application Integration, Migration & Interoperability

Key Takeaway: Phase C concludes by integrating Data and Application Architectures into a cohesive Information Systems architecture. Using cross-domain artifacts like the Application / Data Matrix, establishing multi-layered interoperability standards, and planning legacy data migrations ensure smooth execution into Phase D and Phase E.

The final section of Phase C addresses the synthesis of Data Architecture and Application Architecture into a unified Information Systems blueprint. Neither data structures nor software applications exist in isolation; their alignment must be explicitly modeled, validated, and governed. Section 4.4 details cross-domain integration matrices, interoperability frameworks, legacy data migration strategies, and the consolidation of Phase C gap analysis deliverables.

Cross-Domain Integration: Harmonizing Data and Applications

The primary objective of cross-domain integration in Phase C is to verify complete coverage and operational harmony between application components and enterprise data entities. Every logical data entity must have a designated software system of record responsible for its lifecycle, and every application must operate within defined data boundaries.

The Application / Data Matrix

The Application / Data Matrix is the definitive cross-domain artifact in TOGAF Phase C. It maps application components (rows) against logical data entities (columns), detailing the precise operational relationship using CRUD (Create, Read, Update, Delete) designations and identifying the System of Record (SoR) :

  • Application Component Customer Entity Order Entity Product Entity Inventory Entity
  • Salesforce CRM (PAC) C / R / U (SoR) C / R R —
  • SAP ERP Billing (PAC) R U (SoR) R R
  • PIM Master Product Catalog — — C / R / U (SoR) —
  • WMS Warehouse System — R R C / R / U (SoR)
  • Architectural Value of the Application / Data Matrix

System of Record (SoR) Clarity: Ensures that exactly one physical application component serves as the authoritative creator and updater (SoR) for each core data entity, eliminating dual-mastering conflicts.

Orphan Data Entity Detection: Highlights data entities that no application creates, updates, or reads.

Unused Application Identification: Identifies applications that consume data but perform no business function or CRUD operations.

Additional Cross-Domain Matrices

System User / Location Matrix: Maps application deployments and data stores to user locations and business departments. Identifies network bandwidth bottlenecks, latency limitations, and geographic data residency compliance constraints (e.g., GDPR data localization in Europe).

Application Organization Matrix: Correlates software applications with business organizational structures to ensure accountability and business ownership.

Interoperability Requirements Analysis

Interoperability is defined in TOGAF as the ability of two or more systems, applications, or components to exchange information and mutually utilize the exchanged information effectively. During Phase C, architects analyze interoperability requirements across four distinct operational layers: ┌────────────────────────────────────────────────────────────────────────┐

  • │ 1. ORGANIZATIONAL / OPERATIONAL INTEROPERABILITY │
  • │ Alignment of business processes, organizational roles, and policies │
  • └───────────────────────────────────┬────────────────────────────────────┘
  • │
  • ▼
  • ┌────────────────────────────────────────────────────────────────────────┐
  • │ 2. SEMANTIC DATA INTEROPERABILITY │
  • │ Shared business definitions, canonical data models, & common ontologies │
  • └───────────────────────────────────┬────────────────────────────────────┘
  • │
  • ▼
  • ┌────────────────────────────────────────────────────────────────────────┐
  • │ 3. SYNTACTIC / TECHNICAL INTEROPERABILITY │
  • │ Common message formats (JSON, XML, Avro) & protocols (REST, gRPC, AMQP)│
  • └───────────────────────────────────┬────────────────────────────────────┘
  • │
  • ▼
  • ┌────────────────────────────────────────────────────────────────────────┐
  • │ 4. BEHAVIORAL / DYNAMIC INTEROPERABILITY │
  • │ Transactional consistency, state management, & error recovery rules │
  • └────────────────────────────────────────────────────────────────────────┘
  • 1. Organizational / Operational Interoperability

Ensures that business processes, governance policies, and operating workflows between collaborating organizations or divisions are aligned so that shared information produces meaningful business outcomes.

2. Semantic Data Interoperability

Ensures that exchanged data carries precise, unambiguous business meaning across system boundaries. Achieved by mapping local application data formats to enterprise Canonical Data Models (CDM) and business glossaries (e.g., ensuring both systems define Total_Revenue using identical tax and currency rules).

3. Syntactic / Technical Interoperability

Focuses on data format structure and transport protocols. Ensures systems agree on encoding syntax (JSON, XML, Protocol Buffers) and communication transport standards (HTTPS REST, gRPC, Kafka, WebSphere MQ).

4. Behavioral / Dynamic Interoperability

Governs execution behavior, transaction processing, state synchronization, and error handling across distributed application components (e.g., saga pattern execution, multi-system ACID vs. eventual consistency guarantees).

Legacy Data and Application Migration Planning

Transitioning from Baseline Information Systems to Target Information Systems represents one of the highest-risk endeavors in enterprise architecture. Phase C requires explicit planning for Legacy Data Migration .

  • Key Data Migration Lifecycle Phases ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
  • │ Data │ │ Data │ │ ETL / ELT │ │ Cutover & │
  • │ Profiling │───► │ Cleansing │───► │ Pipeline │───► │ Dual-Write │
  • │ & Audit │ │ & Transform │ │ Execution │ │ Validation │
  • └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘

Data Profiling & Quality Audit: Analyzing legacy databases to quantify data corruption, duplicate records, missing attributes, and unconstrained fields.

Data Cleansing & Transformation: Designing automated rules to scrub legacy data, standardize addresses, re-key identifiers, and map legacy structures into target canonical data schemas.

ETL / ELT Pipeline Design: Building Extract-Transform-Load (ETL) or real-time event-streaming pipelines capable of handling bulk data migration without operational downtime.

Execution Strategy Selection:

Big Bang Cutover: Instantaneous cutover over a weekend; high risk, suitable only for low-complexity systems.

Phased Parallel Run / Dual-Write: Running legacy and target systems concurrently with bi-directional synchronization until target system stability is proven; lower risk, higher operational complexity.

Archival & System Retirement: Migrating historical legacy records to immutable cold storage for regulatory compliance, followed by complete physical decommissioning of legacy hardware and software licenses.

Consolidating Phase C Deliverables and Transitioning to Phase D & E

At the conclusion of Phase C, the architecture team consolidates all findings into a unified Phase C Architecture Deliverables Package :

Consolidated Data and Application Architecture Description Document: Complete baseline and target documentation for both domains.

Consolidated Gap Analysis Report: Synthesized matrix linking data gaps, application gaps, and integration dependencies.

Updated Architecture Requirements Specification: Refined functional and non-functional requirements (performance, security, interoperability, data retention).

Candidate Architecture Roadmap Components: Discrete, structured work packages (e.g., Project Alpha: Customer MDM Hub , Project Beta: Core ERP Migration , Project Gamma: Legacy Monolith Retirement ) passed into Phase E (Opportunities & Solutions) .

Seamless Transition to Phase D (Technology Architecture)

Target Data and Application Architectures provide the direct functional input for Phase D (Technology Architecture) . Phase D translates the software application components, API throughput targets, and data storage volumes defined in Phase C into physical IT infrastructure blueprints—including cloud compute instances, container orchestrators (Kubernetes), network topologies, storage SANs, and security firewalls.