Skip to content

Lesson 1 — Mental Model: Integration vs Interoperability

Data Integration is movement and consolidation of data within and between data stores, applications, and organizations. Data can be copied, transformed, combined, migrated, archived, routed, or virtually presented.

Data Interoperability is the ability of multiple systems to communicate successfully through compatible interaction mechanisms.

The concepts overlap but are not synonyms. Two systems can communicate successfully and still exchange semantically inconsistent data. Likewise, a mapping can be correct on paper while the systems cannot reliably exchange it.

Example

A retailer’s new order platform can call the enterprise Customer API. Technical interoperability exists. But the platform sends CUSTOMER_STATUS = 0/1/2/3, while the enterprise hub uses ACTIVE / INACTIVE / PROSPECT / CLOSED. The unresolved problem is integration: the representation and business meaning must be mapped consistently.

Why DII touches so many Knowledge Areas

DII depends on:

  • Data Architecture for enterprise and solution patterns;
  • Data Modeling & Design for persistent and transient structures;
  • Metadata Management for meanings, mappings, schedules, history and lineage;
  • Data Governance for ownership and approval of transformation rules;
  • Data Security for data in motion, virtual access and shared services;
  • Data Storage & Operations for the physical operating environment.

It enables DW/BI, MDM, Reference Data, Big Data, migration, vendor-package integration, external-data ingestion, distribution, archiving, operational intelligence and many other use cases.

The real business problem: uncontrolled complexity

A single direct interface can be simple. Hundreds of applications can create an explosion of pairwise connections, technologies, transformations, support skills and troubleshooting paths. Chapter 8 therefore favors an enterprise design perspective while still allowing incremental delivery.

The goal is not centralization for its own sake. It is to reduce unnecessary interface and semantic complexity while keeping the solution extensible and supportable.

Business accountability

Technical teams implement transformations, but a transformation can change business meaning. If a source status becomes a different enterprise category, business experts and Data Stewards must participate in defining and changing the rule.

Decision rule: technical execution does not remove business ownership of semantics.

Stop and check

Two systems exchange messages successfully but use incompatible definitions of Customer Status. The best answer is Integration, because communication works while semantic consistency does not.

Source: pp. 257–260.

← Guide · Lesson 2 →