Data Integration and Interoperability
Data integration moves and combines data across systems; interoperability ensures those exchanges are understood and usable. The exam tests integration patterns, contracts, latency, error handling, and canonical data design.
Core rules
- Choose the pattern from the requirement: batch ETL/ELT for volume and transformation, change data capture for low-impact near-real-time, APIs for request-response, messaging for events, virtualization for federated access.
- Define an interface contract: schema, semantics, keys, nullability, version, owner, SLA, and error behavior.
- Design for idempotency, replay, ordering, and dead-letter handling; integration failures are normal, not exceptional.
- Use a canonical model for many-to-many system exchanges, with explicit mapping and transformation rules.
- Monitor freshness, completeness, and volume; latency is not a quality measure by itself.
Worked example
CRM and ERP both hold customer records. A point-to-point feed would create two mappings and no shared definition. Instead the team defines a canonical Customer contract with party ID, legal name, tax ID, and status. CRM maps to it; ERP maps from it. The integration layer deduplicates on tax ID, applies survivorship rules, and writes a reconciliation report. The reasoning: the canonical layer reduces mappings from n(n−1) to 2n and gives one place to govern semantics.
Traps
- Building point-to-point sprawl that no one can maintain.
- Exchanging files without a schema or semantic contract.
- Assuming lower latency means higher quality.
- No replay or dead-letter path, so failures require manual rebuilds.