Skip to main content

The Integration Complexity Ceiling

Every system you add makes the next integration harder. The compounding cost of connections that nobody budgets for.
25 March 2022·6 min read
John Li
John Li
Chief Technology Officer
engineeringstrategy
There's a number that nobody tracks in enterprise IT. It's the total number of connections between systems. Not the number of systems, the number of connections. The difference matters more than most people realise.

What You Need to Know

  • Integration complexity grows exponentially, not linearly. Five systems can need up to ten connections. Ten systems can need up to forty-five
  • Most organisations hit a complexity ceiling around seven to nine integrated systems, where adding the next one becomes disproportionately expensive
  • Point-to-point integrations are the main cause. Each new system needs to talk to multiple existing ones
  • Middleware and integration platforms help, but they need to be introduced before you hit the ceiling, not after

The Maths Nobody Does

When you have three systems that need to share data, that's three possible connections. Manageable. When you add a fourth, the possible connections jump to six. A fifth system: ten. By the time you have eight systems, you're looking at twenty-eight possible connections.
The formula is simple: n(n-1)/2, where n is the number of systems. It's the same maths that makes network effects powerful. Except in this case, each connection isn't an asset. It's a maintenance obligation.
28
possible point-to-point connections between just 8 integrated systems
Source: Combinatorial mathematics
Not every system needs to talk to every other system. In practice, most organisations maintain about 60-70% of the theoretical maximum. But even at 60%, eight systems means seventeen active integrations, each one with its own data mapping, error handling, authentication, and maintenance requirements.

Where It Gets Expensive

The first five integrations are usually straightforward. Well-documented APIs, clear data mappings, standard authentication. The team has capacity to build and maintain them.
Somewhere around integration six or seven, things change. The team is now spending a meaningful portion of their time maintaining existing integrations. API changes, schema updates, authentication token renewals, debugging data sync failures. New integration work competes with maintenance of the existing ones.
This is the complexity ceiling. It's not that the next integration is technically harder. It's that the cumulative maintenance burden has consumed the capacity you'd use to build it.
I've watched teams spend three weeks debugging why two systems stopped syncing, only to discover that a third system's API update broke the middleware that connected the first two. That's the kind of cascading failure you get at the ceiling.
John Li
Chief Technology Officer

The Point-to-Point Trap

Most organisations build integrations one at a time. System A needs to talk to System B, so you build a connection. Later, System C needs data from both A and B, so you build two more connections. Each one makes sense in isolation.
The result is a web of point-to-point integrations. Every system knows about every other system it connects to. Change one, and you need to check all its connections. Replace one, and you need to rebuild all its integrations.
This is the pattern that creates the ceiling. And it's the default pattern because it's the path of least resistance for each individual project.

Breaking Through

There are two ways to address the ceiling. One is architectural, the other is organisational.

The architectural approach

Move from point-to-point to hub-and-spoke. An integration platform or middleware layer sits in the middle. Each system connects to the hub once. The hub handles the routing, transformation, and error management.
This doesn't eliminate complexity, but it centralises it. Instead of twenty-eight connections between eight systems, you have eight connections to the hub. The hub is more complex, but it's one thing to maintain rather than twenty-eight.
Tools like MuleSoft, Boomi, and Azure Integration Services do this well for large organisations. For smaller setups, a well-built API gateway with some transformation logic can serve the same purpose.
The catch is timing. If you introduce middleware after you've already built fifteen point-to-point integrations, the migration is a project in itself. The best time to introduce an integration layer is around four to five systems, before the ceiling hits.

The organisational approach

Treat integration as a capability, not a side effect of projects. Assign someone, or a team, to own the integration architecture. Not as a project, but permanently. Their job is to maintain the connections, evaluate new tools against the existing architecture, and push back when a new system would add unsustainable complexity.
Most organisations don't do this. Integration work gets split across project teams. Nobody has the full picture. By the time someone does, the ceiling has already arrived.

Practical Steps

If you're reading this and recognising your own situation:
  1. Count your connections. Not your systems, your active integrations. If the number surprises you, that's information.
  2. Assess your maintenance burden. What percentage of your development team's time goes to integration maintenance vs new capability? If it's over 30%, you're at or near the ceiling.
  3. Evaluate a hub model. Even a simple one. The cost of introducing middleware now is almost always less than the compounding cost of more point-to-point connections.
  4. Make integration visible. Put it on the architecture diagram. Include it in project estimates. Make sure leadership understands that every new system has a connection cost.
The ceiling is real. But if you see it coming, you can plan for it.