Nobody ever approved an integration strategy. Integration arrived one application at a time, and by 2011 it had become one of the largest permanent costs in the enterprise technology budget — without ever appearing as a line item anyone had agreed to fund. The arithmetic is unforgiving and it is why this happened. Two systems require one connection. Five systems, if everything talks to everything, require ten. Ten systems require forty-five. The organizations that adopted a CRM, an expense tool, a recruiting system, a marketing platform and a helpdesk over three years did not add five applications. They added several dozen potential connections, of which they built perhaps fifteen, each one a small project nobody costed as part of the original decision. And unlike a licence, an integration does not stay bought. It has to keep working.
Why SaaS Made This Structural
On-premise estates had integration problems too, but the shape was different. Systems were fewer, change was slower, and the organization controlled when anything moved. SaaS reversed all three. Buying became decentralised. Marketing bought marketing tools, HR bought HR tools, finance bought finance tools. Each purchase was individually justified and none of them included the cost of connecting to everything else. IT discovered the integration requirement after the contract was signed, which is the worst possible moment. Vendors controlled the release schedule. An on-premise upgrade happened when you decided. A SaaS API changed when the vendor decided, on their timeline, with notice periods that assumed you had engineering capacity available. Every connection became a standing obligation to respond to someone else's roadmap. APIs varied wildly in quality. Some vendors offered well-documented, versioned, rate-limited-but-generous interfaces. Others offered a partial API, an export file, or a partner who would build something. Integration effort was determined by the weakest interface in the chain, not the average. Data models did not agree. Customer in the CRM, account in the billing system, and entity in the ERP overlap without matching. Every integration encoded a set of mapping decisions, and those decisions — which system is authoritative, what happens on conflict, how deletes propagate — were usually made by whoever wrote the code, at the time they wrote it, undocumented.
The Costs Nobody Budgeted
Building an integration is the cheap part. The expensive parts arrive later. Maintenance is continuous. Every connected system changes, and each change is a potential break. A portfolio of thirty integrations generates a steady stream of failures, most small, all requiring attention from someone who understands both ends. Monitoring is usually absent. Integrations fail silently more often than loudly. A nightly sync that stops running is frequently discovered days later by a user noticing missing data, and by then the reconciliation is worse than the outage. Knowledge concentrates dangerously. Integrations are built by individuals, often quickly, often without documentation. Two or three people typically understand how the estate actually connects, and their departure is a genuine operational risk that appears on no register. And the compound effect is the one that eventually forces a decision: every new application gets more expensive to adopt, because it must connect to a larger estate. The organization slows down, and the cause is invisible in any single business case.
Middleware Was the Answer, With Conditions
The response — enterprise service buses, then integration platforms delivered as a service — was architecturally correct. Point-to-point connections scale quadratically; a hub scales linearly. Centralising transformation, error handling, monitoring and retry logic in one place is obviously better than reimplementing it thirty times. Middleware programmes still failed regularly, for reasons that had nothing to do with the architecture. They were treated as projects rather than functions. A platform was procured, a team assembled, connections migrated, and the programme declared complete. Integration is not a project; it is an operating capability, and capabilities need permanent ownership and permanent funding. They did not stop the point-to-point building. Teams under delivery pressure continued writing direct connections because the platform's intake process was slower. The organization then paid for a hub and kept the mesh. And they underestimated the canonical data model. Defining a shared vocabulary — what a customer is, which system owns it, how records reconcile — is the hard part of integration, and it is organizational rather than technical. Platforms that arrived without that agreement became expensive routers of contested data.
Running Integration as a Function
- Cost integration inside every application business case. Build effort, ongoing maintenance, and monitoring, estimated before signature. This changes some buying decisions, which is the point.
- Maintain a live integration inventory. What connects to what, in which direction, how often, who owns it, and what breaks if it stops. Most organizations cannot produce this, and cannot plan without it.
- Declare a system of record per data domain. Customer, product, employee, vendor. One authoritative source each, with everything else consuming. Ambiguity here is what turns integration into reconciliation.
- Monitor every interface and alert on silence. Absence of data is the most common failure mode and the least likely to be noticed. Alert on the sync that did not run, not only on the one that errored.
- Evaluate API quality during vendor selection. Documentation, versioning policy, deprecation notice periods, rate limits, sandbox availability and webhook support. A cheaper product with a poor API is frequently more expensive within two years.
- Standardise the platform and enforce it. A hub only pays back if new connections go through it. Make the supported path faster than the unsupported one, or it will be bypassed.
- Document the mapping decisions, not just the code. Which field maps where, what happens on conflict, how deletes propagate. This is the knowledge that leaves with people.
- Review and retire. Integrations outlive the processes that justified them. An annual review of what is still needed prevents the estate from accumulating indefinitely.
The Position Now
Integration platforms became a mature category, API-first design became a competitive requirement, and standards improved enough that connecting two well-built SaaS products is genuinely easier than it was in 2011. The underlying dynamic did not change. Application counts rose faster than integration capability improved. Most mid-sized organizations now run hundreds of applications, a significant proportion adopted by departments without IT involvement, and the integration estate connecting them is still largely undocumented. AI is applying fresh pressure at exactly the weakest point. Assistants and agents are only as useful as the data they can reach, which means every AI deployment immediately becomes an integration programme — and one with a new characteristic. Traditional integrations move data between systems that will reject malformed input. AI systems consume whatever they are given and produce confident output regardless of whether the underlying data was current, complete or authoritative. So the discipline that was optional for reporting becomes load-bearing for AI. Knowing which system owns which data, whether the sync ran, and how conflicts resolve is no longer back-office hygiene. It determines whether the answers your organization now generates automatically are true.
Common Questions
Why did integration costs grow so quickly with SaaS adoption?
Because connections scale faster than applications — ten systems can require dozens of interfaces — while decentralised buying meant integration cost was excluded from the business case, and vendor-controlled API changes turned every connection into an ongoing maintenance obligation.
What is the difference between point-to-point and middleware integration?
Point-to-point connects each system directly to each other system, growing quadratically with the number of applications. Middleware routes through a central hub, so each system connects once, growing linearly and centralising transformation, monitoring and error handling.
Why do middleware programmes fail?
Usually because they are run as finite projects rather than permanent capabilities, because teams keep building point-to-point connections around the platform, and because the organization never agrees a canonical data model defining which system owns which data.
How does AI change integration requirements?
AI assistants are limited by the data they can reach, so every deployment becomes an integration programme. Unlike traditional interfaces, AI systems consume whatever data they are given and produce confident output regardless of accuracy, making data ownership and sync reliability directly consequential.
Integration Strategy Assessment — Outpace maps what actually connects to what in your estate, fixes the interfaces failing silently, and builds the integration capability your AI plans are about to depend on.