Data Integration

Definition

Data integration is the set of methods, technologies, and governance practices used to consolidate data that originates in disparate systems — CRM, ERP, core banking platforms, claims systems, spreadsheets, external data feeds — into a coherent, trustworthy whole. In practice this spans a spectrum: from real-time integration via APIs and event streams, to batch ETL/ELT pipelines feeding a data warehouse or lake, to virtualization layers that federate queries across sources without physically moving the data. The common thread is that integration resolves structural differences (schemas, formats, identifiers) and semantic differences (what does 'customer' or 'active policy' actually mean) so downstream consumers get one answer, not five conflicting ones. In a business architecture context, data integration is distinct from data architecture itself. Data architecture defines what data entities exist, how they relate, and who owns them conceptually. Data integration is the execution layer — the plumbing and rules that make those entities actually flow and reconcile across the technology landscape. Architects use capability maps and information maps to identify where integration is structurally required: wherever a capability (say, 'Customer Onboarding') depends on data that is created or maintained by a different capability or system of record ('Party Management', 'Product Catalog'). This is why data integration decisions cannot be made purely at the IT level; they follow directly from how the business is organized to deliver value. It is also bounded conceptually from master data management (MDM) and data governance. MDM defines the authoritative version of a data entity; governance defines the rules and accountability for data quality and stewardship. Data integration is the mechanism that enforces both — moving, transforming, and synchronizing data according to the master definitions and governance rules architects and data stewards have agreed upon.

Origin & Context

The term emerged from database and information systems research in the 1980s and 1990s, as enterprises accumulated multiple incompatible systems and needed formal approaches to reconcile them — giving rise to ETL tooling, data warehousing, and later enterprise application integration (EAI). Within enterprise architecture, frameworks such as TOGAF's Data Architecture domain and the Zachman Framework's data column formalized data integration as a discipline connected to, but distinct from, application and technology architecture. The Business Architecture Guild's BIZBOK further ties data integration back to capabilities and value streams, framing it as a business enabler rather than a purely technical concern.

Why It Matters

CIOs and enterprise architects care about data integration because poor integration is one of the most persistent sources of operational cost, compliance exposure, and customer-facing errors — duplicate customer records, mismatched balances, and delayed regulatory reporting all trace back to integration gaps. Business architects care because capability rationalization, M&A integration, and digital transformation initiatives all stall when the underlying data cannot be reliably connected across the systems supporting those capabilities. Getting integration right materially shortens time-to-value for new digital products and reduces the manual reconciliation work that quietly drains operations teams. It is also foundational to trustworthy analytics and AI initiatives, which are only as good as the integrated data feeding them.

Common Misconceptions

Myth: Data integration is purely an IT/technical concern handled by data engineers.

Reality: Integration requirements are driven by business capability and value stream dependencies. Architects must define which capabilities need which data, at what latency, and with what accuracy before engineers can design the technical pipelines — otherwise teams build integrations that are technically sound but business-irrelevant.

Myth: Buying an integration platform (iPaaS, ESB, or similar) solves the data integration problem.

Reality: Tools move and transform data; they don't resolve semantic disagreements about what a data element means across business units. Without a governed business glossary and data ownership model, platforms simply automate inconsistency faster.

Myth: Real-time integration is always better than batch.

Reality: The right approach depends on the capability's actual need. A regulatory reporting capability may require validated, reconciled batch data, while a customer-facing capability may require real-time synchronization. Architects should map integration patterns to capability requirements, not default to the newest technology.

Practical Example

A regional insurer's business architecture team was mapping the Claims Processing capability and discovered that adjusters were pulling policy data from three different systems, each with a slightly different view of coverage limits. The business architect worked with the data architect to trace this back to the value stream: policy data was created in the underwriting system, modified in a legacy administration platform, and cached in a claims portal that was never refreshed on schedule. Rather than commissioning a new integration project outright, the team first produced a capability-to-data cross-map showing exactly where the discrepancy originated. This reframed the initiative from 'fix the claims portal' to 'establish policy administration as the authoritative source and integrate downstream systems accordingly' — a decision that avoided a costly, narrowly scoped rebuild and instead targeted the actual root cause.

Industry Applications

Financial Services

Integrating core banking, lending, and CRM systems to produce a single customer view for regulatory reporting (e.g., BCBS 239) and cross-sell decisioning.

Healthcare

Combining electronic health record, claims, and lab systems to support accurate patient records and interoperability mandates such as HL7 FHIR-based exchange.

Retail & Consumer Goods

Synchronizing inventory, point-of-sale, and e-commerce platforms in near real time to enable accurate omnichannel fulfillment and pricing.

Related Terms

• Data Architecture: The broader discipline that defines data entities and structure; data integration executes their movement and reconciliation