Systems integration is connecting separate business applications so they share data and trigger each other's processes, replacing manual re-entry and reconciliation with an agreed contract between systems.
Systems integration is connecting separate business applications so they share data and trigger each other's processes, replacing manual re-entry and reconciliation with an agreed contract between systems.
The technical connection is rarely the hard part. What decides whether an integration landscape stays manageable is a small number of architectural choices made early, usually without anyone realising they were choices.
The natural way to integrate is directly: connect the webshop to the ERP, then the ERP to the WMS, then the webshop to the shipping platform. Each connection is sensible on its own.
The problem is combinatorial. Connecting n systems point-to-point can require up to n(n−1)/2 connections — four systems is six, six systems is fifteen, and every one of them is a thing that can break and must be maintained through both sides' upgrades.
This is why integration landscapes feel fine for two years and then feel unmanageable. Nothing went wrong; the arithmetic simply arrived.
The alternative is routing through a central layer — middleware, an integration platform, an iPaaS — so each system connects once, to the hub. That converts n(n−1)/2 connections into n.
It is not free. A hub adds a component that must itself be operated, monitored and paid for, and it becomes a single point of failure with real operational weight. The honest threshold is around four to six systems with genuinely bidirectional flows. Below that, point-to-point is usually cheaper and simpler, and choosing a platform early is a common way to buy licence cost before you have the problem it solves.
The question that causes the most operational pain is not technical. When a field changes, who is responsible for telling whom?
An integration is a contract, and contracts need owners on both sides. In practice the failure looks like this: an upstream system adds a field in a minor release, nobody informs the downstream owner, and the integration keeps running while quietly writing incomplete data for three weeks.
What to establish explicitly: a named owner per integration, a documented expectation that schema changes are announced, and monitoring that detects volume anomalies rather than only errors. A silent integration is not necessarily a working one.
A synchronous call waits for an answer — simple to reason about, and it couples the two systems' availability: if the other side is down, your process stops. An asynchronous flow puts the message on a queue and continues, which survives the other side being unavailable but requires you to handle the answer arriving later, or not at all.
The rule of thumb: use synchronous where the user is waiting for the result and the operation is fast; use asynchronous for anything bulk, slow, or where the other system's uptime is not something you control. Most production landscapes need both, and the mistake is choosing one style everywhere for consistency.
A single well-documented integration is days to a couple of weeks. What multiplies it: legacy systems without real APIs, bidirectional sync (which needs conflict rules — a business decision, not a technical one), and anything touching money or stock where error handling dominates.
At Crux Digits: a €2,500 audit maps the landscape, the volumes and the failure cases and says whether you need a hub yet. A €20,000 proof of concept covers genuinely uncertain flows, and production starts from €50,000.
Roughly from four to six systems with bidirectional flows. Below that, direct connections are usually cheaper and easier to reason about.
An API is the interface a system exposes. Integration is everything built on top of it for a specific purpose — mapping, scheduling, authentication, error handling and reconciliation.
Usually a change on the other side, or volume that was never tested — and the dangerous failures are the silent ones.
Want this applied in your business? See how we take it to production:
We build this AI in production — at fixed prices, with one named expert. Start with a free consultation.
Book a free consultation →