ExamFinch.com My Study

Study guide

Section 10.1: Integration Patterns & Technologies

Practice this exam

DAMA Certified Data Management Professional CDMP

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & DMBoK Framework

1.1 CDMP Exam Details & Strategy 1.2 The DMBoK Framework 1.3 Data Management Organization & Roles

2 Chapter 2: Data Governance (Part A)

2.1 Data Governance Principles & Drivers 2.2 Operating Models & Structures 2.3 Policies, Standards, and Procedures

3 Chapter 2: Data Governance (Part B)

2.4 Data Stewardship 2.5 Governance Metrics & Implementation

4 Chapter 3: Data Modeling and Design (Part A)

Section 3.1: Conceptual, Logical, and Physical Models Section 3.2: ERD Notations & Relational Modeling Section 3.3: Normalization

5 Chapter 3: Data Modeling and Design (Part B)

3.4 Dimensional Modeling 3.5 Naming Standards & Modeling Best Practices

6 Chapter 4: Data Quality (Part A)

Section 4.1: Data Quality Dimensions Section 4.2: Data Quality Policy & Rules Section 4.3: DMAIC & DQ Improvement Lifecycle

7 Chapter 4: Data Quality (Part B)

4.4 Root-Cause Analysis & Remediation 4.5 DQ Metrics, Tools, and Reporting

8 Chapter 5: Metadata Management (Part A)

5.1 Business, Technical, and Operational Metadata 5.2 Metadata Lineage & Impact Analysis 5.3 Repository Architectures

9 Chapter 5: Metadata Management (Part B)

5.4 Standards and Semantics 5.5 Metadata Governance & Integration

10 Chapter 6: Master and Reference Data Management

6.1 Master vs Reference Data 6.2 MDM Repository Architectures 6.3 Match-Merge & Identity Resolution 6.4 Reference Data Governance & Standards

11 Chapter 7: Data Warehousing and Business Intelligence

7.1 DW Architectures: Inmon vs Kimball 7.2 Data Warehousing Storage & Load Patterns 7.3 BI Delivery & OLAP 7.4 Data Marts & Enterprise Data Warehouses

12 Chapter 8: Data Architecture

8.1 Enterprise Data Architecture & Zachman Framework 8.2 Data Flow Diagrams & Value Chains 8.3 Architecture Frameworks & Standards

13 Chapter 9: Document and Content Management

9.1 Records Management & ECM 9.2 Retention, Disposal, and E-Discovery 9.3 ARMA GARP Principles & Taxonomies

14 Chapter 10: Data Integration and Interoperability

Section 10.1: Integration Patterns & Technologies Section 10.2: Replication & Virtualization Section 10.3: Canonical Models & Integration Standards

15 Chapter 11: Data Security

Section 11.1: Security Principles: CIA Triad & Privacy Section 11.2: Access Control & Encryption Section 11.3: Security Regulations & Standards

16 Chapter 12: Data Storage and Operations

Section 12.1: Database Technologies & DBA Roles Section 12.2: Backup, Recovery, and High Availability Section 12.3: Performance Tuning & Operations

17 Chapter 13: Big Data and Data Science

13.1 Big Data V's & Technologies

18 Chapter 14: Data Ethics

14.1 DMBoK Data Ethics Framework

19 Chapter 15: Data Management Process and Maturity

15.1 Maturity Assessment Frameworks

Section 10.1: Integration Patterns & Technologies

Key Takeaways Explain This Topic AI

Extract, Transform, Load (ETL) is optimized for traditional data warehouses, shifting transformations to a dedicated middle-tier integration engine before loading to reduce destination processing requirements.

Extract, Load, Transform (ELT) leverages the processing power of modern cloud data platforms, loading raw data directly into the target database where transformations are executed via SQL or push-down optimization.

Change Data Capture (CDC) minimizes database resource consumption by tracking and extracting only modified data (inserts, updates, deletes) from source database transaction logs.

Enterprise Service Bus (ESB) provides a service-oriented, centralized middleware architecture that acts as a router, translator, and orchestrator between disparate applications.

Publish-Subscribe (Pub-Sub) systems decouple message senders (publishers) from receivers (subscribers) through message brokers or topics, facilitating asynchronous, event-driven data integration.

Last updated: July 2026

Data Integration and Interoperability (DII) Fundamentals

According to the DAMA DMBoK2 , Data Integration and Interoperability (DII) encompasses the processes, technologies, and architectures required to move, consolidate, and share data across applications, databases, and organizations. The primary objective is to maintain a consistent state of data throughout the enterprise, enabling business processes to run on accurate, unified information. While data integration focuses on combining data from multiple sources into a single, cohesive datastore (such as a data warehouse or data lake), data interoperability emphasizes the capability of distinct systems to communicate, exchange data, and interpret that data in real-time, often using standardized services and protocols.

Without an effective DII strategy, enterprises suffer from data fragmentation, high application maintenance costs, and poor decision-making due to inconsistent data views. Achieving high interoperability requires organizations to move beyond ad-hoc, point-to-point connections toward structured, repeatable architectural patterns.

Batch Integration: ETL vs. ELT

Batch integration remains a core pattern for bulk data movement. The two dominant paradigms are Extract, Transform, Load (ETL) and Extract, Load, Transform (ELT) . The choice between them impacts database performance, network bandwidth, and the design of the target storage system.

Extract, Transform, Load (ETL) : In a traditional ETL flow, data is extracted from source systems, moved to a dedicated middle-tier staging server (or ETL engine), transformed, and finally loaded into the target data warehouse. The transformation phase includes cleansing, validation, reformatting, denormalization, and applying business logic. Because transformations occur prior to loading, only clean, structured data enters the target database. This minimizes the compute overhead on the target system and prevents dirty or sensitive data from being stored in the data warehouse. However, ETL requires a specialized middleware engine and can create performance bottlenecks during the transformation phase if memory or disk limits are reached on the middle-tier server.

Extract, Load, Transform (ELT) : With the rise of highly scalable, cloud-based data storage and query platforms, ELT has become the preferred choice for modern architectures. In ELT, data is extracted from sources and loaded directly into the target database in its raw format. The transformation of the data is then executed inside the target system using its own compute engine, typically via SQL queries or push-down optimization . ELT offers faster load times because there is no intermediary staging server, and it provides higher flexibility as data analysts can access raw history to create new views on demand. However, it requires highly performant target engines and can lead to increased cloud compute costs if transformations are inefficient.

  • Attribute Extract, Transform, Load (ETL) Extract, Load, Transform (ELT)
  • Transformation Engine Dedicated Middle-tier Server Target Database/Data Warehouse Engine
  • Data Preservation Only transformed/cleaned data is loaded Raw source data is preserved in target
  • Latency Higher load latency due to transformation Lower load latency; raw data is available quickly
  • Scalability Limited by middle-tier server capacity Highly scalable (leverages cloud compute)

Security/Privacy High (sensitive data can be masked before load) Moderate (raw data must be protected in target)

  • Main Use Case Legacy databases, sensitive security scrubbing Cloud data warehouses, big data analytics
  • Real-Time Integration: Change Data Capture (CDC)

Change Data Capture (CDC) is a critical technology for keeping databases in sync with minimal impact on operational sources. Instead of extracting entire tables periodically, CDC tracks and extracts only the data that has changed (INSERTs, UPDATEs, DELETEs) since the last extraction. DAMA identifies three main methods of CDC:

Log-Based CDC : This is the gold standard for database integration. Database engines write every transaction to a binary transaction log (e.g., Oracle Redo log, SQL Server transaction log) for recovery purposes. Log-based CDC software reads these logs directly, extracting changes asynchronously without querying the active database tables. It has virtually zero performance overhead on the source database, does not require schema changes, and captures hard deletes. However, it requires database-specific log readers and elevated admin privileges.

Trigger-Based CDC : This method utilizes database triggers that automatically fire on write operations, inserting the change details into a dedicated shadow/audit table. The integration tool then pulls data from the shadow table. While trigger-based CDC is database-independent and easy to configure, it incurs a significant performance penalty on source transactional systems because triggers execute synchronously as part of the primary write transaction.

Query-Based (Timestamp/Status) CDC : In this approach, the integration engine queries source tables looking for records where last_updated_timestamp is greater than the previous extraction run. This method is simple and requires no database-level configuration, but it places a heavy query load on the source database, fails to capture hard deletes (where records are physically deleted from the table), and relies on developers consistently updating the timestamp column on every write operation.

Middleware Patterns: ESB and Message Queuing/Pub-Sub

For application-to-application (A2A) integration, middleware technologies facilitate communication and message routing between disparate systems.

Enterprise Service Bus (ESB) : An ESB is a centralized, service-oriented middleware architecture that enables applications to communicate through a shared bus. It acts as a router, translator, and orchestrator. For example, if Application A sends a message in XML format via SOAP, the ESB can translate it to JSON and route it to Application B via REST. The ESB enforces routing rules, handles security, and coordinates multi-step business transactions. While powerful, ESBs can become monolithic single points of failure and performance bottlenecks if overloaded with complex business logic.

Message Queuing and Publish-Subscribe (Pub-Sub) : To decouple systems, organizations utilize message-oriented middleware. In a point-to-point message queuing model, a sender places a message in a specific queue, and a single receiver consumes it. In contrast, the Publish-Subscribe (Pub-Sub) pattern decouples publishers and subscribers through topics . A publisher sends a message to a topic, and the message broker broadcasts it to all subscribers registered to that topic. This allows asynchronous, event-driven data integration where systems do not need to wait for a response, increasing overall system resilience and horizontal scalability.