Interoperability

Interoperability Does Not Begin With the Connection

Two systems can be technically connected to each other.

For example:

System A
   ↓
 HTTPS
   ↓
System B

Initially, this only tells us that a technical communication path exists.
Whether the systems can actually work together meaningfully is a different question.
For that, additional properties must be compatible with each other.

Transmitting Data Is Not Yet Enough

Suppose System A sends:

{
  "customer": 4711,
  "status": "active"
}

System B receives exactly the same data.
The transmission was error-free.

Even then, the following has not yet been clarified:

What does customer mean?
What does 4711 mean?
What does active mean?
What other states are possible?
What effect should the value have in System B?

Technically successful data transmission is therefore only a prerequisite for Interoperability.
The systems involved must also understand the exchanged information sufficiently consistently.

Multiple Levels Must Align

Interoperability can be considered at different levels.

A simplified representation is:

technical connection
        ↓
common protocol
        ↓
compatible data format
        ↓
compatible data model
        ↓
shared understanding
        ↓
compatible processes and responses

Not every use case requires the same depth at every level.
For a simple file transfer, a relatively small common basis may already be sufficient.
For complex business processes, by contrast, additional coordination may be necessary.

Technical Interoperability

At the technical level, communication must first be possible.

This can include, for example:

• network protocols
• transport protocols
• authentication
• interfaces
• message formats
• character encodings

If System A exclusively uses protocol X and System B only understands protocol Y, the two cannot communicate directly without additional mediation.
This level is necessary.
But it is not yet sufficient.

Syntactic Interoperability

The systems involved must be able to understand the structure of the exchanged data.

For example, both systems can use JSON:

{
  "quantity": 12
}

They then know the syntactic structure.

They know:

There is a field quantity.
Its value is 12.

What is not yet known, however, is:

12 what?

That is exactly where the next level begins.

Semantic Interoperability

Semantic Interoperability concerns the meaning of the exchanged information.

A field:

stock = 12

can, for example, mean:

12 physically available units

or:

12 units available for sale

or:

12 units including goods already reserved

or:

inventory at the time of the last synchronization

The syntax can be completely identical.
The domain meaning is nevertheless different.
If these differences are not taken into account, formally correct data can lead to incorrect behavior.

Same Value, Different Meaning

Suppose two systems use:

status = active

System A understands this as:

Customer account has not been deleted.

System B understands this as:

Customer currently has an active contract.

The value can be transmitted without any technical problems.
If System B adopts it without translation, incorrect decisions may result.
Interoperability therefore requires more than shared values.
It requires a sufficiently shared understanding of their meaning.

Processes Are Also Part of It

Some systems exchange more than individual pieces of information.
Together, they form a process.

For example:

Order
    ↓
Inventory management
    ↓
Shipping
    ↓
Invoice

In that case, it may not be sufficient for all systems to be able to read the same order.
Process states must also align.

For example:

When is an order considered accepted?
When may it be changed?
When is inventory reserved?
What happens with partial quantities?
When is an invoice generated?
How is an error reported back?

Interoperability thus also concerns behavior and timing.

Interfaces Support Interoperability

A documented interface can describe:

Which operations exist?
What data is expected?
What responses are possible?
What errors can occur?

This creates a basis for collaboration.
An interface alone, however, does not yet guarantee Interoperability.
The documentation may be incomplete.
Two implementations may interpret the same specification differently.
Or a relevant domain relationship may not have been described at all.

Therefore:

interface exists
        ≠
Interoperability proven

Open Data Formats Can Help

Open Data Formats facilitate Interoperability because their structure and rules can be documented independently of a single application.
Multiple systems can thereby implement the same technical basis.

But here too:

open data format
        ≠
automatically interoperable

Two programs can, for example, support the same standard but use different optional features.
Or both can store the same values with different domain meanings.
Open formats create possibilities.
The actual collaboration must still be tested.

Standards Can Create Shared Expectations

Standards can define, for example:

• data structures
• protocols
• value ranges
• units
• semantics
• process rules
• error handling

This means the systems involved do not have to reinvent every agreement.

But a statement such as:

We support standard X.

alone is not yet a complete statement about Interoperability.

Relevant factors include:

Which version?
Which parts?
Which optional features?
Which extensions?
Which profiles?

The subset of a standard actually used can be decisive.

Interoperability Is Context-Dependent

Two systems do not have to be compatible in every conceivable property.
They must be sufficiently compatible for the required collaboration.

For example, System A may only need the following data from System B:

article number
description
price

If this information can be exchanged reliably, sufficient Interoperability may exist for this specific use case.
The fact that other functions of System B are not supported may be irrelevant.

The question is therefore not:

“Are these systems interoperable?”

but, more precisely:

“Are these systems sufficiently interoperable for this exchange and this purpose?”

Interoperability Requires Agreements

The more complex an exchange becomes, the more important explicit agreements can become.

For example:

Format:
JSON

Character encoding:
UTF-8

API version:
v2

Date:
ISO 8601

Currency:
EUR

Price:
gross amount in cents

Status:
active = active contract

This makes assumptions visible that might otherwise exist only implicitly in the implementations.
Such agreements can be part of interface documentation, schemas, standards, or other technical specifications.

Interoperability Can Be Tested

Whether two implementations actually work together should not be inferred only from their documentation.

A test could, for example, check:

System A generates message
        ↓
System B reads message
        ↓
System B interprets data
        ↓
compare expected result

This does not only test whether a file is syntactically valid.
The actual processing can also be examined.

For more complex systems, additional tests can cover:

• boundary values
• optional fields
• unknown values
• different versions
• error situations
• retries
• timeouts
• order of events

Interoperability is therefore also a property for which real evidence can be generated.

Failure Cases Are Part of the Collaboration

Interoperability is not demonstrated only in the success case.
Suppose System B cannot process a message.

What happens then?

Is an error returned?
What does this error mean?
Is the message retried?
Can it be processed twice?
Who then holds the valid state?

If the systems involved have different assumptions about this, the integration may fail precisely when a problem occurs.
Error behavior is therefore also part of the relevant interface properties.

Versions Change Interoperability

Systems evolve.

From:

API v1

comes:

API v2

A data format gains new fields.
A status value acquires a new meaning.
An optional field becomes mandatory.
An integration that previously worked can thereby lose its Interoperability.
Version management and compatibility rules can therefore play an essential role.

For example:

Can v2 still read data from v1?
Does v1 ignore unknown new fields?
When will v1 no longer be supported?

Interoperability is not a state that remains guaranteed forever after the first successful integration.

An Adapter Can Establish Interoperability

Two systems do not have to use the same internal data model.

An adapter can translate between them:

System A
   ↓
Format A
   ↓
Adapter
   ↓
Format B
   ↓
System B

The adapter can, for example:

• map field names
• convert values
• convert units
• map states
• translate versions

The adapter can thereby enable interoperable collaboration between otherwise incompatible systems.
However, the adapter itself then becomes part of the integration and creates its own maintenance and testing requirements.

Too Many Translations Can Be a Warning Sign

Suppose a process requires:

System A
   ↓
Adapter 1
   ↓
Intermediate format
   ↓
Adapter 2
   ↓
Middleware
   ↓
Adapter 3
   ↓
System B

This can be technically necessary.
But it can also indicate that several historically incompatible systems have been connected to one another.
Each translation can create additional sources of error and loss of meaning.

During Systems Analysis, it can therefore be useful to ask:

Which of these translations do we actually still need?

Interoperability and System Integration

System Integration describes the process and technical task of connecting different components into a collaborating system.
Interoperability describes an important property for this.

Simplified:

System Integration:
How do we connect the systems?

Interoperability:
Can the connected systems work together meaningfully?

An integration can technically exist and still have poor Interoperability.
This may result in many special cases, manual corrections, or information loss.

Interoperability and Digital Sovereignty

Interoperability can support Digital Sovereignty.
If a system can work with only one specific product, a strong technical dependency arises.
If, by contrast, it can work with multiple implementations through documented interfaces and formats, additional options for action arise.

This makes it easier, for example, to:

replace components
change providers
develop your own tools
modernize systems incrementally

Interoperability does not eliminate dependencies.
But it can improve their changeability.

Interoperability and Legacy Systems

Legacy Systems often have established interfaces whose actual meaning has grown over years.

Formally, an interface may contain only:

customer_id
amount
date

In actual operation, however, additional rules may exist:

customer_id 0 has a special meaning
negative amounts are processed differently
empty date means current posting date

These properties may not appear in any current documentation.
A modernization must therefore not only adopt the visible format.
It must understand the actual semantics relevant to the process.
Interoperability with a Legacy System is therefore often also a task of Systems Analysis.

Interoperability and Low-Tech

Interoperability can help make technical systems smaller and more replaceable.
If components work together through simple, clearly documented interfaces, individual parts may be replaceable independently.
This does not necessarily require introducing a complex integration platform.
For a simple use case, a well-defined file format may already be sufficient.
The appropriate form of Interoperability depends on the actual need.

Why Interoperability Has Practical Effects

• Systems can work together meaningfully: Not only transmission, but also the use of information is considered.
• Semantic errors become visible: Identical data structures do not automatically mean the same thing.
• Standards can create common foundations: Agreements do not have to be developed completely from scratch for every integration.
• Open Data Formats can realize their potential: Independent implementations can work together on a shared documented basis.
• Systems can be replaced more easily: Well-defined boundaries reduce certain dependencies.
• Legacy Modernization becomes easier: Old and new systems can be coupled incrementally.
• Error behavior becomes part of the interface: Collaboration must work not only in the success case.
• Interoperability can be tested: Real implementations can be tested against each other.
• Digital Sovereignty can increase: Multiple compatible implementations create additional options for action.

Typical Example

An inventory management system supplies inventory levels to an online shop.

The interface transmits:

{
  "article": "A-4711",
  "stock": 12
}

Technically, the connection works without errors.

The inventory management system defines stock as:

physically available quantity

The shop interprets the value as:

immediately sellable quantity

Of the twelve articles physically present, however, five have already been reserved for other orders.
The shop therefore offers twelve articles for sale even though only seven are available.
The interface works.
The syntax works.
The data transmission works.
The Interoperability is nevertheless insufficient.

After clarification, the data model is extended:

{
  "article": "A-4711",
  "physical_stock": 12,
  "reserved_stock": 5,
  "available_stock": 7
}

In addition, the meaning of the fields is documented.
Only then do both systems have a sufficient common basis for the intended process.

Distinction

• Interoperability refers to the ability of different systems to exchange information and use it meaningfully for a specific purpose.
• Interface refers to a defined transition between systems or system components at which relevant properties, interactions, or relationships are specified. An Interface can enable Interoperability, but does not guarantee it.
• System Integration refers to connecting different components or systems into a collaborating whole. Interoperability is a relevant property of this collaboration.
• Open Data Format describes a sufficiently publicly documented data format that enables independent implementations. It can support Interoperability, but does not guarantee it.
• Compatibility generally describes the compatibility of components or systems. Interoperability specifically considers their ability to collaborate and meaningfully exchange information.
• Digital Sovereignty describes the ability to remain capable of making decisions and taking action in the presence of digital dependencies. Interoperability can increase replaceability and thus available options for action.

Further Reading

Related Concepts

→ Interface
→ System Integration
→ Open Data Format
→ Digital Sovereignty
→ System Architecture
→ Legacy Modernization
→ Low-Tech