Lesson 6: Data Integration and Interoperability

Many system integration projects fail not because applications cannot connect, but because their data does not match. Two systems may use different field names, different identifiers, different validation rules, or different meanings for the same label.

For example, one system may store course, another program. One may use Student No., another Learner_ID. One system may record province names in full, another may use abbreviations. If these are merged carelessly, reports become inaccurate.

Data integration usually involves three important tasks:

• Mapping – deciding which fields correspond to each other
• Transformation – converting structure, type, or format
• Validation – checking completeness, correctness, and consistency

In practice, data integration is where architecture becomes very concrete. If the team does not define data ownership, unique identifiers, and quality rules, the integrated environment will behave unpredictably.

Interoperability means systems can exchange and correctly use information. It is not enough that a message is received; the receiving system must also understand it correctly.

Common interoperability concerns include:

• Syntactic interoperability – Do the systems use compatible formats such as CSV, JSON, or XML?
• Semantic interoperability – Do they mean the same thing by the same field?
• Technical interoperability – Can systems exchange data over compatible protocols and platforms?

A useful example is health or education data. Two systems may both send a field called status, but one means active/inactive while the other means enrolled/graduated. That is a semantic problem, not a transport problem.

Because of this, integration teams often create canonical data models, shared dictionaries, or mapping tables. These do not remove differences, but they give the team a controlled way to manage them.