Data Integration & Interoperability (KA 6)

Data Integration & Interoperability (KA 6)

Batch, micro-batch, streaming, change-data-capture, API — and the contracts between them.

Why it matters

Most enterprise pain lives in integration: the brittle nightly jobs, the ‘mystery 9 a.m. break’, the silent CDC slot. DMBOK organises this KA around patterns + contracts rather than tools.

Going deeper

Integration patterns and the latency / coupling trade:

Pattern	Latency	Coupling	Failure mode
Nightly batch ETL/ELT	Hours	Loose	Stale data; cron misses; backfill pain
Micro-batch (5–15 min)	Minutes	Loose	Hidden lag amplification
CDC (log-based)	Seconds	Tight to source	Slot lag; replication storms
Event streaming (Kafka)	Sub-second	Loose	Schema-evolution discipline required
Synchronous API call	Real-time	Very tight	Cascading failure if upstream blips

The discipline DMBOK adds: every integration is governed by a contract (schema + SLA + ownership). Without contracts, the pattern is irrelevant — it'll break.

Integration patterns are the difference between letters, daily delivery, courier and phone calls.

A letter is cheap, slow, asynchronous, decouples you from the recipient's schedule (batch). A daily delivery service is faster but you still bundle (micro-batch). A courier is near-real-time and works file-by-file (streaming). A phone call is real-time and only works if the other person picks up — and the call drops if they don't (synchronous API).

Every integration choice is choosing one of these. The mistake is using a phone call where a letter would do (over-coupled architectures) or sending a letter where you needed a phone call (stale dashboards).