Most IT leaders can name their most fragile integration. Ask how many integrations are running in total and the number arrives with a qualifier. Ask which of them a business process would stop without, and the qualifier gets longer. Ask who owns the one that broke last quarter, and the room goes quiet.
That gap is the first measurable symptom of integration complexity. Organisations grow into it one reasonable integration at a time, which is why almost none of them see it happening. It is like watching your own hair grow. What they do notice are the effects: projects that slip, incidents that take too long to explain, and a team that is always restoring something. Assessing the complexity underneath is how you find the root cause of what you already feel, before it turns into business risk you are paying for without knowing it.
Key takeaways
- Integration complexity grows without anyone deciding it should. In ONEiO's own research, 54% of companies struggle with integrations that fail silently, with data sync errors going undetected.
- Complexity is not just the number of integrations. It is the product of how many parties are involved, how interdependent the data flows are, how varied the requirements are, and how fast the connected systems change.
- Point-to-point connections grow quadratically. Ten systems need up to 45 connections; twenty systems need up to 190.
- Complexity and change multiply rather than add. A moderately complex estate connected to fast-moving systems is harder to run than a very complex estate connected to stable ones.
- Adding headcount buys time and makes the underlying problem worse, because every additional person increases the coordination cost of the estate they were hired to manage.
- The assessment below takes about 20 minutes, and together with five questions on what is at stake, tells you which of three responses your estate actually needs.
The operating discipline behind this. The Integration Ops book sets out how integration estates are planned, operated and measured at scale under a Managed Integration Service. Download the book.
What is integration complexity?
Integration complexity is the operational difficulty of keeping a set of integrations working, determined by how many systems and organisations are connected, how tightly those connections depend on each other, how much the requirements differ across them, and how frequently the connected systems change. It is a property of the environment, not of any individual integration.
The distinction is practical. Building one integration between two systems can take real engineering skill, and once it works it tends to keep working. Forty simple integrations across nine organisations, each upgrading its systems on its own schedule, take little skill to build and constant attention to keep running. Organisations prepare for the first kind of difficulty and are worn down by the second. That is the argument we make at length in enterprise software integration as an operations problem. Visa at Paulig described the starting condition in a sentence:
"It was very, very fragmented and complex... four or five different integration approaches." -- Visa Oksa, Paulig
Four or five approaches is not a technology problem. It is what an estate looks like when each integration was solved correctly and separately.
The challenge of quadratic growth
When systems are connected directly with custom point-to-point links, the number of possible connections grows quadratically, not linearly. For n systems, the maximum number of connections is n x (n - 1) / 2.
A small environment of 5 systems needs up to 10 connections. At 10 systems that becomes 45, and a moderately sized estate of 20 systems needs up to 190. Each system added connects to more systems than the one before it, so the effort of keeping data flowing securely between them grows faster than the estate itself.
The result is an architecture where changing one application breaks several others in ways nobody predicted. Without a standard connection pattern to replace those point-to-point links, short-term workarounds and unmanaged exceptions keep adding to the complexity, and the estate becomes harder to change every year.
Why integration complexity is a business risk
Nobody decides to build a complex estate. Every integration was added for a good reason, by people who did the job well, and nobody writes a business case that assumes it will break. So the complexity is never budgeted for, and the cost of it arrives as a surprise.
"If integrations fail, hell breaks loose." -- Hanna Pursiainen, DNV
When integrations in a complex estate fail, the damage reaches well beyond IT. Processes stop and manual work replaces them. Decisions are made on data that is late or wrong. Service levels are breached and penalties follow. Orders that cannot complete are lost, and invoices that go out wrong turn into disputes and later payment. We traced how this plays out in retail in the true cost of integration failure and the fix that holds.
The second cost is the spending that goes into containing it: extra people, external experts brought in at short notice, and projects delayed while the team restores what already exists. Organisations with high complexity spend more than they need to on mitigation, because they are treating the symptoms one at a time. Knowing your complexity is what tells you whether that spending is solving the problem or only keeping pace with it.
The two axes of integration complexity
Two variables explain most of the difference between estates that run calmly and estates that consume a team.
Complexity is the static picture: how much is connected, and how entangled it is.
Change is the dynamic picture, meaning how often that picture stops being accurate.
An estate is easy to run when both are low, manageable when one is high, and hostile when both are. Most organisations assess the first and never assess the second, which is why an estate that passed an architecture review can become unmanageable without anything in the architecture having changed.
The complexity axis: four factors
Number of connected systems
The obvious factor and the least informative one on its own. Diversity matters more than the count. 30 integrations across three well-understood platforms is a different estate from 30 across 14 platforms, half of which belong to somebody else.
Number of parties
An integration inside your own four walls is a technical dependency. An integration that crosses an organisational boundary is a technical dependency plus a relationship, a release calendar you do not control, and an escalation path that has to be negotiated before it can be used.
Each additional party adds a coordination cost that does not appear anywhere in an architecture diagram, which is the problem service integration and management (SIAM) exists to structure. Michael at MHP named the effect exactly:
"Before, 100%, it was very complex... every time you add a customer, there's another environment to go into." -- Michael, Jasniak MHP
Interdependence
How many flows depend on the same mapping, the same reference data or the same authentication? Interdependence is what turns a single failure into an incident. It is also what makes change expensive, because a modification that looks local is not. Integration architecture for IT service management explains why data flow predicts this better than data structure does.
"If you change something, you can shoot up the customer before, because of dependencies." -- Michael, Jasniak MHP
Requirement diversity
If every connected party wants the same fields in the same format at the same cadence, the estate is repeatable. If each one has its own contractual data requirements, its own retention rules and its own idea of what a ticket is, the estate is bespoke, and bespoke does not scale without adding people.
The change axis: frequency and scope
Change has two dimensions and organisations track neither.
Frequency is how often a connected system changes in a way that affects an integration. Count the last 12 months: platform version upgrades, API deprecations, schema changes, authentication changes, partner-side re-platforming, mergers that bring a new system into scope.
Scope is how much of the estate a single change touches. A change contained to one flow is an afternoon. A change to a shared mapping or a shared identity model is a project.
The Integration Ops book calls change the most reliable constant in integration work. An estate designed for a fixed picture will spend the rest of its life being corrected.
Why complexity and change multiply
The two axes are not additive, and this is the part that catches otherwise well-run organisations. In a low-change environment, complexity is absorbable. The estate is intricate, but it holds still long enough for people to learn it. Tribal knowledge works because the thing being known stays the same.
Raise the change rate and the tribal knowledge decays faster than it accumulates. Every change invalidates part of what the team understood, and in an interdependent estate a single change invalidates more than one part. The team is no longer running integrations. They are re-learning their own estate, permanently, while being measured on delivery.
That is the point where the organisation starts routing around IT, because the estate became unpredictable enough that the business stopped trusting a date. In ONEiO's own research, 68% of companies report integration projects delayed by two to six months because of resource constraints. Delays of that length across a portfolio are a board-level number, and integration dependencies are one of the things underneath them. Nobody sets out to become the bottleneck. The operating model produces one.
How to do your integration complexity assessment
Score each factor from 1 to 5, where 1 is the benign case and 5 is the hostile one. If you want a narrower starting point, our system integration checklist covers the nine questions to answer before a single build. Twenty minutes with the people who actually run the estate will get you an honest answer. Twenty minutes with an architecture diagram will not.
Complexity subtotal is factors 1 to 4. Change subtotal is factors 5 and 6. Operational maturity is factors 7 and 8, and it is the multiplier: weak ownership and stale documentation make every other score worse.
What is at stake when things break
The score tells you how hard your estate is to run. It does not tell you how urgent that is. Answer these five questions alongside it to get a view of what the complexity puts at risk:
- Which business processes stop if your three most critical integrations stop, and who notices first: your team, the business or your customer?
- How long can each of those processes run on manual workarounds before revenue is lost, a service level is missed or an invoice goes out wrong?
- Which integrations carry a contractual or regulatory commitment, such as a customer service level, financial reporting or an audit trail?
- When did an integration failure last reach a customer, and what did it take to recover the relationship?
- If the person who knows your most critical integration left tomorrow, how long would the next recovery take?
If most answers point to customers, revenue or contracts, treat the result one band higher than your score suggests.
How to read the results of your assessment
Complexity 4-8, change 2-4. A stable estate. In-house operation is appropriate. Invest in documentation and named ownership before anything else, because those are what protect you if either axis moves.
Complexity 9-14, change 5-7. The estate is outgrowing informal operation. This is the band where organisations add a person and buy 12 months. Spend the 12 months standardising patterns and establishing ownership. Absorbing the backlog buys nothing.
Complexity 15-20, or change 8-10 at any complexity. The estate can no longer be held in a team's collective memory. Effort is going into re-learning the estate, and the business has probably already noticed. This band needs an operating-model decision, not a resourcing decision.
Ownership and documentation scoring 8 or above. Fix this first regardless of the other scores. An estate nobody owns and nobody has documented is expensive at any complexity, because every change begins with an investigation.
The response that does not work
The instinctive answer to a growing estate is a growing team. It is also the answer that produces the sentence most integration leaders say out loud sooner or later:
"20,000 tickets per month... I can't go with 50 people. Everybody is getting crazy." -- a managed service provider running 20,000 tickets a month
We have written separately on scaling IT service operations without adding headcount. Headcount works arithmetically and fails structurally. Each additional person raises the coordination cost of the estate, adding handovers, context to transfer, and further chances for two people to hold different versions of the truth about the same mapping. In an interdependent estate the coordination cost rises faster than the capacity added.
There is a second problem, and it is the one that shows up in retention. People hired to run integrations spend their time restoring them. Talent held in firefighting stops developing, and eventually leaves, taking the tribal knowledge that was holding the estate together.
The response that does
Three things change the economics, and none of them is a platform choice. All three are available to an in-house team and none of them is quick.
Standardise the pattern, not the platform. A single connection pattern that reaches any endpoint, whatever technology sits at either end, is structurally different from a set of point-to-point builds, because the estate stops compounding as parties are added. This is the single largest lever on the complexity axis.
Design for the next change. Decoupling, versioning and change-aware monitoring turn a connected system's upgrade from an incident into a scheduled task. The Integration Ops book treats this as a design requirement.
Assign accountability that survives an incident. Named ownership of each integration, current documentation, and a defined answer to who restores service when the failure sits between two vendors. Where this sits organisationally is covered in how to build a service management office.
Organisations do this in-house, and it works when integration capability is something they want to build and keep. Where the estate is high on both axes and integration is not the product, the alternative is to move the operation to a provider who runs it under a service level.
That is what ONEiO does as a Managed Integration Service. We run your integrations, you deliver your services: any-to-any connectivity without point-to-point work, 24/7 operational management, and accountability for keeping the estate running as your connected systems change. The assessment above is the honest test of whether that is the right answer for your environment or an expensive answer to a problem you do not have.
Bottom line on managing integration complexity
Complexity is not a number of integrations and it is not a technology problem. It is the combination of how much is connected, how entangled it is, and how fast the ground underneath moves.
Score the estate honestly and weigh what is at stake before deciding what to do about it. The result tells you whether you have a documentation problem, a resourcing problem, or an operating-model problem, and those three have completely different fixes. Most organisations reach for the second when they have the third.
Scaling integrations should not require scaling chaos.
Run the assessment with someone who does this for a living. Schedule a 30-minute conversation and walk through your scores with an integration specialist.
