Applied Data · Module 3
Interoperability and standards
Interoperability means systems understand each other.
Previously
Data governance and stewardship
Governance is agreeing how data is handled so people can work quickly without being reckless.
This module
Interoperability and standards
Interoperability means systems understand each other.
Next
Data analysis and insight generation
Analysis is asking good questions of data and checking that the answers hold up.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
A join works only if the key represents the same thing on both sides.
What you will be able to do
- 1 Explain interoperability and standards in your own words and apply it to a realistic scenario.
- 2 Standards reduce translation work by creating stable interfaces and shared meaning.
- 3 Check the assumption "Terms are mapped" and explain what changes if it is false.
- 4 Check the assumption "Interfaces are stable" and explain what changes if it is false.
Before you begin
- Foundations-level vocabulary and concepts
- Confidence with basic diagrams and section terminology
Common ways people get this wrong
- Translation drift. Mappings rot over time. Without review, the standard becomes a myth.
- Standards as theatre. A PDF standard no system follows does not create interoperability.
Main idea at a glance
Diagram
Stage 1
Start join
Begin by asking if foundations are aligned.
I think starting with meaning instead of mechanics saves weeks of debugging.
Interoperability means systems understand each other. It is shared meaning, not just shared pipes. Standards help through common formats, schemas, and naming. A schema is the agreed structure and data types. When systems misalign, data lands in the wrong fields, numbers become strings, or meaning gets lost.
Formats like JSON or CSV carry data, but standards and contracts explain what each field means. An API (application programming interface) without a contract is guesswork. A file without a schema requires detective work.
Small mismatches cause big effects. Dates in different orders, currencies missing, names split differently. Aligning schemas early saves hours of cleanup and prevents silent errors.
Worked example. Join keys are mathematics, not vibes
Worked example. Join keys are mathematics, not vibes
A join works only if the key represents the same thing on both sides. That sounds obvious until you meet real data.
One system uses customer_id as “account holder”. Another uses it as “billing contact”. Both are “customer”, until you try to reconcile charges.
My opinion: schema alignment is not a technical chore. It is a meaning negotiation. You need the business definition written down, not just the column name.
Foundations. One-to-one, one-to-many, many-to-many
Cardinality describes how many records relate to how many records.
Cardinality patterns
Know these patterns before writing joins on production data.
-
One-to-one
Each record matches at most one record on the other side.
-
One-to-many
One record can match multiple records on the other side.
-
Many-to-many
Multiple records match multiple records and can multiply row counts quickly.
Undergraduate. Why many-to-many joins can blow up row counts
If a key value appears times in table A and times in table B, then an inner join produces rows for that key. Total join rows across all keys is:
This is why “duplicated keys” are not a small detail. They can change both correctness and performance.
Verification. What you check before you trust a join
Join trust checklist
Do this before sharing any joined metric.
-
Confirm key meaning
Validate business definition match, not just data type match.
-
Check uniqueness and expected duplication
Where keys are non-unique, define whether multiplicative joins are acceptable.
-
Compare row-count deltas
Explain row-count changes from pre-join to post-join before publishing.
Mental model
Interoperability boundary
Standards reduce translation work by creating stable interfaces and shared meaning.
-
1
System A
-
2
Shared standard
-
3
System B
Assumptions to keep in mind
- Terms are mapped. A standard needs a mapping from local meaning to shared meaning. That mapping must be maintained.
- Interfaces are stable. Stability is what gives teams confidence to build. Version changes deliberately.
Failure modes to notice
- Translation drift. Mappings rot over time. Without review, the standard becomes a myth.
- Standards as theatre. A PDF standard no system follows does not create interoperability.
Check yourself
Quick check. Interoperability and standards
0 of 6 opened
What is interoperability
Systems sharing data with the same meaning.
What is a schema
An agreed structure and types for data.
Scenario. Two systems both have a field called `date` but one means local time and one means UTC. What should you do
Write the meaning explicitly in the contract, convert at the boundary, and add validation. Same name does not mean same meaning.
How do standards help
They reduce guesswork and make systems predictable.
What happens when schemas mismatch
Fields break, meaning is lost, and errors spread.
Why do contracts matter for APIs
They tell clients exactly what to send and expect.
Artefact and reflection
Artefact
A one-page decision note with assumption, evidence, and chosen action
Reflection
Where in your work would explain interoperability and standards in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
Align two simple schemas and see what breaks when fields do not match.