Opinion · Architecture · The enterprise stack

Integration hell: how best-of-breed became a liability

Best-of-breed was sold as a virtue. In production, it became a tax.
Every line in your stack is a contract, a breakpoint, and an egress path.

An Appice Perspective

Ask any CIO how many tools sit in their customer technology stack. The answer is rarely under fifty. Now ask how many of them actually talk to each other, and how many are actually used. The picture changes.

Scott Brinker's 2026 Marketing Technology Landscape catalogues 15,505 products, the first year in fifteen that the count has effectively stopped growing, even as 1,488 new products were added and 1,367 removed beneath the surface. Inside enterprises, his stack analysis puts the average at around 90 MarTech tools per organisation. Gartner's CMO Marketing Technology Survey then asks what proportion of those bought tools are actually used. Utilisation has slid from 58 per cent in 2020 to 33 per cent in 2023, recovering only to 49 per cent in 2025. The average enterprise marketer is using less than half of the stack already paid for.

Best-of-breed was sold to a generation of buyers as a virtue. In production it became a tax, paid in engineering hours, broken integrations, and customer journeys that fail in the seams between tools rather than inside them.

How we got here

The logic was sound at the time. For any single function there was a specialist tool that did it better than the all-in-one suite, so enterprises unbundled. Pick the best email platform, the best CDP, the best analytics layer, the best decisioning point solution, and assemble them. Best-of-breed became gospel, and procurement was organised around it: evaluate each category on its own merits, against its own shortlist, on its own contract. One sensible purchase at a time, the stack grew into a dozen or more specialist tools that each excel in isolation and must somehow be made to work as one.

Making them work as one is the part nobody bought, and the part everybody pays for.

The hidden tax

The problem is not the boxes. The problem is what every line between them quietly carries. Procurement signs off on the licence fee. The rest of the bill arrives later, in pieces, paid for from different budgets, and visible only when something goes wrong.

Exhibit 1
One integration, exploded. What a single line between two of your tools actually carries.
System A e.g. CDP System B e.g. campaign tool 1 INTEGRATION what this single line actually carries BUILD & MAINTAIN Engineering time to wire it up & keep it alive through every release. A NEW BREAKPOINT A schema change on one side silently breaks the flow on the other. DATA EGRESS Customer data crosses another boundary, another jurisdiction, another vendor. ADDED LATENCY Time lost at every handoff, in a discipline where the window is the value. ACCOUNTABILITY GAP When the journey breaks, no single party owns the result. You do, by default. × the number of lines in your stack
The licence fee is what shows up in procurement. The five layers underneath show up across engineering, security, operations, customer service, and the apology cycle. Multiply by the number of lines, not the number of tools: a dozen tools is not twelve relationships, it is dozens of integrations, each carrying every layer above.
Exhibit 2
The same five costs, in plain terms — and the question each one demands.
The hidden costWhat it means in practiceThe question to ask
Build & maintainEngineering time to connect the two systems, and to keep the connection alive through every release on either side.Who maintains this integration when either side ships a release?
A new breakpointA schema change or deprecated API on one side breaks the flow on the other, often silently, discovered only when a customer journey fails.How would we know if this connection silently failed?
Data egressCustomer data crosses another boundary at every hop, out of a jurisdiction or environment you control into one you may not.Where does the data go, and whose jurisdiction does it cross?
Added latencyEvery handoff adds delay, in a discipline where the value of acting is measured in the window before the moment passes.How much time does this handoff add to the customer experience?
The accountability gapWhen a journey breaks across five vendors, each can credibly point at the others. No single party owns the outcome.When this connection breaks, who owns the outcome?
Five hidden costs, present in every connection. Five questions, rarely asked at procurement. The five answers tell you more about your real operating risk than any feature comparison.

The accountability gap

The most expensive liability has no line item. When a customer journey breaks across five vendors, every one can point, accurately, at one of the others. The data was fine when it left us. The API returned what it was asked. The message was delivered as instructed. Everyone is right; the journey is still broken; the enterprise owns the result by default, because no one else can. Best-of-breed distributed the capability and, with it, the accountability, until none was left in any one place.

A dozen tools is not twelve relationships. It is the dozens of integrations between them, and every one is something to build, to break, and to blame.

The intent was always there. The reality kept catching up.

It would be wrong to suggest the industry has not tried. Every decade has produced its own framework for making the lattice tractable, and the intent behind each has been genuine. The 1990s offered EDI and point-to-point standards. The 2000s reached for SOAP, the Enterprise Service Bus, and Service-Oriented Architecture, with governance and middleware in the middle. The 2010s simplified to REST, JSON and OpenAPI, then layered iPaaS platforms, MuleSoft and Boomi and Workato, to consolidate the connectors. The 2020s added event streams, GraphQL, and data-mesh architectures, each promising the right abstraction. Architects worked on these in earnest, and each wave delivered real, useful capability.

Then reality caught up. Standards work when the participants stay in their lanes. Software vendors are not built that way. Every vendor faces relentless pressure to grow, to deepen what it does for its customers, and to extend into adjacent territory the standard was not designed to cover. The CDP becomes a campaign tool. The campaign tool becomes a CDP. The analytics platform adds personalisation. The personalisation platform adds analytics. Each is rational from inside one company, and collectively it means no standard ever fully holds, because no one can mandate the lane that every vendor has a commercial reason to leave.

The result is consistent across waves. A new protocol arrives, the industry adopts it, vendors converge on it, then extend it, then differentiate within it. The standard solves syntax. The market quietly reintroduces the same lock-in at the next layer up. After three decades of standards work, the average enterprise still runs ninety disconnected tools and uses fewer than half.

The pattern has a name. It was famously labelled embrace, extend, extinguish in the antitrust hearings of the late 1990s, and in milder forms it has repeated across every protocol wave since. The first two Es are constants. Every vendor embraces the standard. Every vendor extends it. The third E is the variable. In some waves it has hardened into extinguish, where the standard or the competitor disappears. In others it has settled into exploit, where the customer is locked into the extension and rents access back to it. The interesting question for the agent era is whether the third E might, finally, become empower, where the customer keeps control of the seam, and the substrate beneath the agents is the thing they own, not the thing they rent.

The latest entrants are MCP (Model Context Protocol) and A2A (Agent-to-Agent), protocols designed for AI agents to discover and call tools, and each other, dynamically. The intent is again genuine. The same commercial forces will, in time, act on them. Two signals are worth watching: whether MCP and A2A actually reduce the integrations an enterprise has to maintain, or simply add a layer above them; and whether ownership of the seam moves with the protocol, or stays where it has across every prior wave — nowhere.

But the agent era changes the stakes. For thirty years, every integration ultimately had a human somewhere in the loop — an engineer wiring it up, an analyst checking the output, an operator approving the flow. Agent-to-agent traffic will not. Integrations will increasingly happen at machine speed and in machine volume, between systems that discover each other dynamically and act without anyone reviewing the handshake. The plumbing that used to be inspected integration by integration becomes a flow no human is fast enough to supervise.

The protocol decides what agents say to each other. The substrate decides what happens on the way through.

That is why the substrate underneath matters more, not less, in this era. When agents are the ones doing the connecting, the only thing that can govern the seam is the layer they connect on: how it authenticates, how it logs, how it enforces policy, and how it makes every autonomous action auditable after the fact. In a world where humans are no longer in the loop on most integrations, the substrate is the loop. Pick well and the next decade of integrations runs on a single accountable layer. Pick badly and the next decade runs on no one's, at the speed of light.

Why it persists: an operating-model failure

The reason three decades of standards have not solved the seam, and the reason MCP and A2A will not solve it on their own, is that the seam is not a technology problem. Each function bought its own tool against its own shortlist; the integrations between them were left to an under-resourced team, against deadlines none of the original buyers cared about. Ninety tools per stack and a 49 per cent utilisation rate are not a coincidence; they are what the procurement model was set up to produce. Technology moved on; the way enterprises buy and own their stack did not. Until ownership of the seam sits with someone, no amount of iPaaS, and no amount of MCP, will close the gap.

What works instead

The reflexive counter-argument is that the only alternative to best-of-breed is the all-in-one suite that best-of-breed replaced, with all of its compromises. That is a false choice. The useful pattern is a single accountable core for the part of the stack that must work as one, the place where signals are turned into decisions and decisions into action, with open boundaries so specialist tools plug in at the edges where they add value. Best-of-breed belongs at the periphery, not load-bearing in the middle. The test: when a customer journey breaks, is there one place to look, and one party who owns it?

And on Monday morning, the work is concrete. Count the integrations, not the tools. Walk the five questions in Exhibit 2 against every connection in the stack. Who maintains it? How would you know if it silently failed? Where does the data go? What does it cost in time? Who owns it when it breaks? The number of connections, and the answers to that last question, tell you more about real operating risk than any feature comparison.

The boxes are the easy part. The lines are where you live — and increasingly, where agents will. What ought to sit beneath both is the question this series will keep returning to.


About Appice.   Appice is the real-time, audit-grade decisioning and execution layer for regulated industries. Deployed under operator control: on-premise, private cloud, or hybrid. A Moment to Think is a series on the decisions you'll act on for years. Read, discuss, and share.