Systems Integration

How Systems Integration Works

In Systems Integration, the systems involved and their boundaries must first be considered.
It must first be clarified what is to be exchanged or shared between these systems.

This can include, for example:

• data
• functions
• events
• states
• files
• messages
• control information
• technical resources

Suitable interfaces and methods for this exchange must then be found or created.
Technically, integration can take place, for example, through APIs, network protocols, message queues, files, shared databases, or specially developed adapters.
The technical connection, however, is only one part of integration.

Systems Must Be Able to Do More Than Reach Each Other

Two systems can communicate technically perfectly and still be poorly integrated.
One system can, for example, interpret inventory as immediately available stock, while another includes goods that have already been reserved.
Both systems can then transmit the same number without error and still mean different things by it.

Similar problems arise from:

• different data models
• different units of measurement or formats
• different points in time and update intervals
• conflicting states
• different responsibilities for the same data
• different assumptions about failure cases
• different life cycles of the systems involved

Systems Integration therefore also concerns meaning and behavior at the boundaries between systems.

Who Determines the State?

An important question in integrated systems is which component is authoritative for particular information or a particular state.
If, for example, two systems store customer data, it must be clear which system determines changes and how those changes reach the other system.

Without such a definition, competing truths can arise:

System A says something different from System B—and both consider their own state correct.

In simple integrations, this responsibility can be defined unambiguously. In more complex systems, states can be distributed or emerge only through the interaction of several components.
The technical connection alone does not solve this problem.

Integration Also Includes Failures

An integrated system must not function only under normal conditions.
A participating system can fail. A message can arrive late. Data can be incomplete. The behavior of an interface can change, or an external service can temporarily be unavailable.

Integration therefore also includes questions such as:

• What happens if a participating system is unavailable?
• Can operations be continued later?
• Can messages be processed twice?
• How are conflicting states detected?
• Which errors can be handled automatically?
• Which deviations require human decision?
• How does it become visible that parts of the overall system no longer have the expected state?

It is often at precisely such boundaries that it becomes apparent whether multiple connected components actually function as a robust overall system.

Why Systems Integration Has Practical Effects

• Existing systems can continue to be used: Not every new requirement requires the complete replacement of existing components.
• Data can flow between systems: Different applications can share information.
• Functions can be combined: Specialized systems can jointly perform a larger task.
• Dependencies become visible: Integration makes clear which systems are relevant to other systems.
• Migrations can take place gradually: Old and new components can be operated together temporarily.
• Failure boundaries become recognizable: Failures and conflicting states can be handled deliberately.
• Responsibilities can be clarified: It can be defined which system is authoritative for particular data or states.

Typical Example

A company operates an online shop and introduces a new inventory management system.
The shop continues to accept orders. The inventory management system manages inventory and shipping.
An initial technical integration could consist of transferring orders from the shop to the inventory system through an API and reporting inventory levels back.
This, however, raises further questions.
What happens to an order if the inventory system is temporarily unavailable?
When is an order considered successfully transferred?
Can the same order accidentally be processed twice?
Which system holds the authoritative inventory state?
What happens if inventory changes while data exchange is interrupted?
A functioning Systems Integration must therefore not only enable data exchange, but also take such states and deviations into account.

Distinction

• Systems Integration is not the same as Systems Architecture. Systems Architecture describes fundamental elements, relationships, and structures of a system. Integration concerns bringing different components or systems together so that they function jointly.
• Solution Architecture considers a concrete solution to a problem. The integration of multiple systems can be a component of that Solution Architecture.
• An Interface is also not equivalent to integration. An interface defines a boundary or a means of communication between systems. Integration additionally includes the behavior and interaction of the systems involved. Systems Integration is ultimately not automatically successful merely because data can technically be transmitted. What matters is whether the systems involved jointly enable the desired function and expected behavior of the overall system.

Further Reading

Related Concepts

→ Systems Analysis
→ Systems Architecture
→ Solution Architecture
→ Interface
→ Verification and Validation
→ Legacy System
→ Legacy Modernization
→ Fault Tolerance
→ Resilience