In this guide 6 sections
Direct links suit two or three systems. Each pair needs its own mapping, so the count grows fast: five systems can need ten links, and each one breaks when either side changes its API. Past four or five systems, a middleware layer holds one mapping per system and absorbs changes in a single place.
How the number of links grows
A direct link joins one system to one other. Billing to CRM is one link. Add the warehouse tool and you need two more, warehouse to billing and warehouse to CRM, each with its own mapping and its own login.
The formula is plain. For n systems that all talk to each other, you may need n times n minus one, divided by two, links. Four systems need six links. Ten systems need forty five links.
Each link carries its own field mapping, its own login, its own retry logic and its own set of failures, so fifteen links means fifteen things to monitor. One person remembers how three work.
- Two systems: one link, easy to hold in your head
- Four systems: six links, still manageable with notes
- Six systems: fifteen links, mappings start to contradict each other
- Ten systems: forty five links, nobody owns the whole picture
What middleware changes
Middleware sits between the systems, so each one connects once to the middle layer, and the layer passes every message onward to whichever systems need it. Six systems need six connections, not fifteen.
The layer also holds one agreed shape for each business object, so a customer, an order and an invoice each get a single internal format. The CRM’s customer record is translated into that format on the way in, then translated again for the accounts package on the way out.
That translation step is the real gain, because a field name fixed once is fixed for every system that reads it, with no second edit anywhere. It is the whole point.
What happens when one side changes its API
Say your payment provider retires version two of its API and moves to version three, then every direct link that touches it must be found, edited and retested. Billing, ERP and sheet all call it. That is three repairs.
With middleware, one connector is rewritten while the other systems keep sending the same internal message and never learn that anything changed. Test it once, release it once.
The reverse also holds. Replace your CRM and you rebuild one connector instead of one per partner system, which is why a vendor switch stops feeling like a project.
- Direct links: edit every pair that touches the changed API
- Middleware: rewrite one connector and rerun its tests
- Direct links: each repair is a chance to break something nearby
- Middleware: the change is isolated behind one door
When direct links are still the right answer
Middleware is not free. It is one more service to host, patch, back up and watch, so for two systems that rarely change, a direct link is cheaper and easier to explain.
Stay direct when the pair is stable, the data is small, the volumes are steady and no third system is likely to join within the next two planning cycles. A shop floor tablet app that posts finished counts into one ERP is a fair example, because nothing else needs those numbers.
Move when a third system wants the same data, when a vendor announces an API retirement or when failed syncs reach you as phone calls. Then add the layer.
A simple way to decide
Draw every system as a box and every data flow as an arrow, and label each arrow with the object it carries and the direction. Count the arrows. Then count the boxes each arrow touches.
If two arrows carry the same object, such as a customer record leaving the CRM for two places, that is a sign the mapping is being repeated. Repeated mappings are where drift starts.
Bring that drawing to your next planning session and mark every arrow that would break if a vendor changed its API tomorrow.
System links map
A one page worksheet. The left column lists each system with its owner, vendor, API version and the date its vendor last announced a change. The middle block is a grid of systems against systems, where you mark each existing link and the object it carries. The right column records who gets the alert when that link fails and how the change notice from each vendor reaches you.
Open a blank worksheet to printQuestions owners ask
How many systems is too many for direct links?
There is no fixed number. Four or five is where teams feel it. Count links and incidents: if a single vendor update means more than two repairs, the layer in the middle has probably earned its place.
Is middleware the same as an integration platform?
Close, but not identical. An integration platform is a bought product that does the middle job, while custom middleware is built to your own objects and rules. Both hold the mappings in one spot.
Can we move from direct links to middleware gradually?
Yes. Start with the system that changes most often or feeds the most others, because its direct links cost you the most repairs. Route its traffic through the new layer, retire the old direct links one at a time, then move the next system.
Does middleware add a single point of failure?
It can. Run it with a queue so messages wait during an outage, add health alerts, and keep a restore routine that someone has actually rehearsed on a quiet afternoon. It also covers maintenance windows.