Why Your Business Systems Don't Talk (And How to Fix It)

April 6, 2026

Key takeaways

The average enterprise runs roughly 897 applications but integrates only about 29 per cent, per summaries of the 2025 MuleSoft Connectivity Benchmark Report.
Silos show up as three recurring symptoms: re-keying, reconciliation and shadow spreadsheets, each a hidden, ongoing cost.
Point-to-point connections grow as n(n-1)/2; a central hub cuts that to n connections, but avoid point-to-point beyond about five systems (Exalate).
For most mid-market firms, iPaaS is the practical default integration layer; add event-driven patterns only for flows that must be near-instant.
Fix data ownership and quality alongside integration, otherwise you simply spread existing errors faster.

If your finance team re-keys order numbers from the CRM into the accounting system, if month-end starts with someone reconciling two reports that should already agree, or if the real source of truth is a spreadsheet that lives on one person’s laptop, you already have an integration problem. The systems work; they just do not talk to each other.

This is not unusual, and it is not a sign of a badly run business. It is the ordinary result of buying good tools at different times for different reasons. The question is not whether your systems are siloed, but how much that silo is costing you and which of several integration approaches is the right one to fix it without creating a worse problem.

The scale of the gap

The disconnection is more widespread than most leaders assume. The 2025 MuleSoft Connectivity Benchmark Report, based on a survey of over 1,050 IT leaders, found that the average enterprise runs roughly 897 applications but has only about 29 per cent of them integrated, as reported in summaries of that report (note this is a secondary citation; MuleSoft’s own page was not directly accessible). Even allowing for the fact that a mid-market firm runs far fewer than 897 applications, the ratio is telling: most of the software a business owns is not connected to the rest.

That same report, per an independent analysis by SalesforceDevops.net, found that 80 per cent of organisations cite data silos as the single biggest barrier to their automation and AI goals, and that integration challenges cost organisations an average of 6.8 million US dollars a year in lost productivity and delayed projects. Whatever your own number is, it is rarely zero.

What silos actually cost

The cost of disconnected systems is mostly invisible because it is spread across many small acts of manual work. It shows up in three recurring symptoms.

First, re-keying: the same data is typed into two or three systems by hand, which is slow and quietly introduces errors. Second, reconciliation: because the same fact lives in several places, someone has to periodically check that the versions agree, and chase down the differences when they do not. Third, shadow spreadsheets: when the official systems cannot answer a question together, people build their own spreadsheets to bridge the gap, and those spreadsheets become an unmanaged, unaudited source of truth.

These symptoms have a price. IDC research is widely cited, including by the advisory firm Cherry Bekaert, as finding that companies lose 20 to 30 per cent of revenue annually to inefficiencies caused by data silos. That figure is repeated across many reputable outlets, but the original IDC report could not be located, so treat it as a widely-repeated industry estimate rather than a precise measurement. Separately, Gartner research has found that poor data quality costs organisations at least 12.9 million US dollars per year on average; that figure dates to around 2020 but still appears on Gartner’s current data-quality topic page. Poor data quality and disconnected systems are close cousins, because re-keying and reconciliation are exactly how bad data enters a business.

There is also a trend worth noting. As cited by Cherry Bekaert, DATAVERSITY’s 2024 data-management survey found 68 per cent of organisations naming data silos as their top concern, up seven percentage points on the prior year, while Salesforce’s 2024 Connectivity Benchmark Report found 72 per cent of IT leaders describing their infrastructure as overly interdependent. The problem is widely felt and, by these measures, growing rather than shrinking.

Why silos form in the first place

Silos are rarely a decision; they are an accumulation. A firm buys an accounting package, then a CRM, then a payroll tool, then an inventory system, each chosen on its own merits at the time. Each is excellent at its own job and indifferent to the others. Departments own their own tools and their own data, and nobody owns the spaces between them.

Understanding this matters because it tells you what to fix. The goal is not to replace good systems with one monolithic platform. It is to build the connective tissue between systems you have sensible reasons to keep.

The integration approaches, and their trade-offs

There are five broad ways to connect systems. They are not strictly better or worse than one another; they suit different sizes and needs, and most mature setups use more than one.

Point-to-point

The simplest approach is to wire each system directly to each other system that needs its data. For two or three systems this is perfectly reasonable, and it is sometimes the only option for an old system with a limited interface or for a connection that must be very fast.

The trouble is the arithmetic. As the integration vendor Exalate explains, the number of direct connections grows as n(n-1)/2, where n is the number of systems. Five systems need 10 connections; ten systems need 45; twenty systems need 190. Each connection is something to build, monitor and repair, and the result becomes the familiar tangle often called spaghetti architecture. Exalate’s guidance is to avoid point-to-point beyond roughly five systems.

Middleware and the enterprise service bus (ESB)

Instead of connecting every system to every other, you connect each system once to a central hub that handles routing and translation between them. This changes the arithmetic decisively: as Exalate notes, the hub model reduces the count from n(n-1)/2 to just n connections, so ten systems drop from 45 connections to 10, a reduction of over 75 per cent.

The enterprise service bus is the classic version of this hub. According to Celigo, an ESB is typically deployed on-premises on dedicated hardware, with upgrades and scaling handled in-house, and is focused on message-level routing and transformation. Its weakness is that the hub becomes a single point of failure: as the integration writer Digital Selwyn observes, because every message passes through the bus, when the bus fails all integrations stop. It can also become a performance bottleneck under load.

Integration platform as a service (iPaaS)

iPaaS is, in effect, the hub model delivered as a cloud subscription. Per Celigo, it is cloud-hosted and fully managed, priced by subscription or usage, scales without infrastructure changes, and typically offers more than message routing alone: data integration, API management, event-driven patterns and workflow automation, often with a library of pre-built connectors for common applications.

The trade-offs are real. As Exalate describes, iPaaS platforms handle roughly 80 to 90 per cent of integration scenarios well, but unusual transformation logic, odd interfaces, or systems with no pre-built connector can push a platform to its limits. Costs can rise as usage grows, and you take on a dependence on the vendor’s connector library. The category is sizeable and growing: Gartner figures quoted in an Informatica press release put iPaaS market revenue above 9 billion US dollars in 2024, up from 7.8 billion in 2023 and 5.9 billion in 2022, with a forecast above 17 billion by 2028. Gartner evaluated 16 vendors in its 2025 Magic Quadrant for iPaaS, published on 19 May 2025; Boomi notes it has been named a Leader in every edition of that Magic Quadrant since the category began, eleven times as of 2025.

APIs, webhooks and event-driven integration

Underneath all of the above sit two mechanisms worth naming. An API is the published doorway a system offers so other software can read or write its data in a controlled way; an API-led strategy treats those doorways as reusable building blocks rather than one-off connections. Per the SalesforceDevops.net analysis of the 2025 MuleSoft report, 58 per cent of IT leaders have adopted an API-led integration strategy.

Event-driven integration flips the direction. Instead of one system repeatedly asking another whether anything has changed, the system that changes announces it, often via a webhook, and interested systems react. This suits high-frequency or low-latency needs, where waiting for the next scheduled sync is too slow, such as updating stock the moment an order is placed.

A pragmatic path for a mid-market business

You do not need to choose one approach for everything. A sensible sequence for a mid-market firm looks like this.

Map before you build. List your systems, the data each one owns, and every place that data is currently re-keyed or reconciled by hand. The map usually reveals that a handful of connections cause most of the pain.
Fix the worst few first. If only two or three systems are involved, a direct connection may be entirely adequate; do not buy a platform to solve a two-system problem.
Adopt a central layer before the tangle forms. Once you are connecting more than about five systems, move to a hub rather than adding more point-to-point links. For most mid-market firms an iPaaS is the practical default, because it avoids running your own hardware and arrives with connectors for common tools.
Add event-driven patterns only where you need them. Use webhooks and event streaming for the specific cases that must be near-instant, and let the scheduled iPaaS flows handle the rest.
Treat data quality as part of the project, not an afterthought. Integration moves data faster; if the data is wrong, you simply spread the errors faster. Agree which system owns each field before you connect anything.

The bottom line

Disconnected systems are normal, but the re-keying, reconciliation and shadow spreadsheets they produce are a steady, mostly hidden tax on a business. The fix is rarely a single grand platform. It is a deliberate sequence: map the pain, fix the worst connections directly, adopt a central layer (usually iPaaS) before the point-to-point tangle sets in, and reserve event-driven patterns for the few flows that truly need to be instant.

At Zenith Tech Works we tend to start with the map rather than the platform, because the right integration approach falls out of what the data is actually doing, not the other way round. Whichever tools you choose, the discipline is the same: decide who owns each fact, connect deliberately, and stop paying the silo tax one keystroke at a time.

System integration: why your tools don’t talk, and how to fix it