Most mid-market integration landscapes start the same way. A finance tool is connected directly to the ERP. The CRM is wired directly to the marketing automation platform. The customer support system has a custom script that pulls orders from the e-commerce platform three times an hour. Each connection was built at the moment it was needed, by whoever was available, using whatever tool was at hand.
For the first ten connectors, this works fine. At about the fifteenth, a pattern emerges. When a key system changes a field name, four different integrations break in four different ways. A new hire asking “how does data flow between these systems?” gets four different answers. The engineer who wrote the original e-commerce connector has left the company, and nobody is sure what happens when it fails. A requirement to add a new tool to the stack gets estimated at six weeks — not because the tool is hard, but because it needs to be wired to eight other things.
That is the point-to-point integration trap. It is a specific and predictable form of technical debt, and it has a known fix: the integration layer pattern.
The N-squared problem
The math is simple and unforgiving. If you have N systems and any of them might need to talk to any other, the number of potential connections is N times (N minus 1), divided by two. Five systems: ten possible connectors. Ten systems: forty-five. Twenty systems: a hundred and ninety.
Real companies never build all possible connectors, but they build far more than they track. Each new system added to the stack increases the potential connection count non-linearly. Each one of those connectors has its own:
Authentication approach (API keys, OAuth, shared secrets — often handled differently each time)
Data transformation (the shape of “customer” in the CRM is not the shape of “customer” in the ERP)
Error handling (silent drop, retry with exponential backoff, queue and alert, or nothing)
Observability (a log file somewhere, if anyone is logging)
Schedule (cron job every 15 minutes, webhook on event, on-demand, or broken)
Every integration is built from scratch, because there is no shared substrate. Every change to a source system ripples unpredictably into every integration that depends on it.
The integration layer alternative
The alternative pattern is hub-and-spoke, with the hub handling the concerns that every integration otherwise duplicates. It has three core elements.
A canonical data model
The organization defines the shape of its important business objects — customer, order, invoice, product — in one place, independent of any specific source or destination system. Source systems translate into the canonical model; destination systems translate from it. When a new system joins the stack, it does one translation (to or from canonical), not one translation per peer.
The canonical model is a domain asset, not a technology artifact. Defining it forces the organization to agree on what a customer actually is, across finance, sales, and operations. That conversation is painful. It is also the single highest-leverage thing an integration program produces, because it outlasts every specific tool in the stack.
Transform and adapt pattern
Adapters handle the connection to each specific system. Transformers handle the mapping between the specific system’s shape and the canonical model. The business logic of integration — routing, filtering, enrichment — lives in the hub, not in the adapters. This separation means a change to a source system’s schema is isolated to one adapter, not spread across every downstream integration.
A shared substrate for reliability
Retries, dead-letter queues, monitoring, alerting, and replay are built once at the platform level, not once per integration. When an integration fails, there is a known place to look. When a system was down and needs to be replayed, there is a known mechanism. The operational overhead stops scaling linearly with the number of integrations.
iPaaS versus build
Having decided to adopt an integration layer, the next decision is how to build it. Two families of answers:
iPaaS platforms. Workato, Mulesoft, Boomi, Zapier for the smaller end, Tray.io, Celigo. These are purpose-built integration platforms with visual flow designers, pre-built connectors to popular SaaS tools, managed infrastructure, and — at the enterprise end — governance features like role-based access, audit logging, and deployment pipelines.
Custom integration layer. Typically built on a message broker (Kafka or a cloud-managed equivalent), an orchestration engine (Temporal, Airflow, a workflow engine specific to the platform), and a set of services that implement adapters and transformers in code. Cloud-native companies often converge on this pattern.
The decision between them is not about which is better in the abstract. It is about which fits the specific company.
Decision framework
Four questions usually resolve the iPaaS-versus-build decision.
Volume and latency
iPaaS platforms are priced for moderate volumes — thousands to tens of thousands of events per day per flow is comfortable, hundreds of thousands starts to stress pricing and sometimes performance. If the integration is moving millions of records a day or requires sub-second latency, the custom path usually wins on total cost and operational characteristics.
Technical team capability
A custom integration layer needs engineers who are comfortable with distributed systems, message brokers, and operational infrastructure. A small team without that depth will struggle to operate a custom platform reliably. iPaaS lets a less specialized team — sometimes even a business analyst with integration sensibility — own the flow.
Governance and compliance needs
Regulated industries often need audit logs on every data movement, explicit access controls, and retention policies that the team can demonstrate under audit. Enterprise iPaaS platforms typically ship with these features built in; building them from scratch is a significant additional investment. In regulated environments, this often tilts the decision toward iPaaS even when the engineering team could technically build it.
Strategic importance of the integrations themselves
Sometimes the integration is the product — customer-facing data flows that are differentiated, or proprietary logic that cannot live in a third-party platform. When that is the case, the build path keeps the strategic capability inside the company. When the integrations are purely back-office plumbing, the capability is not strategic and iPaaS is the right fit.
What tends to get built in-house at mid-market
Among mid-market companies that have been through this decision, a hybrid pattern has emerged as the default. Standard SaaS-to-SaaS flows — Salesforce to HubSpot, QuickBooks to NetSuite — live on an iPaaS platform, because the pre-built connectors and visual flow designer genuinely speed up work that nobody wants to write from scratch.
High-volume, low-latency, or strategic integrations get built on a custom layer, typically Kafka plus a workflow engine plus a small set of services. These integrations are few (five to fifteen is typical) but they handle the flows where performance, cost, or strategic control make iPaaS a poor fit.
The hybrid is pragmatic. It uses iPaaS where iPaaS is good — quick to stand up, reasonable total cost at moderate volume, low specialization requirement on the team. It uses custom where custom is necessary — strategic flows, high-volume flows, flows that need fine-grained control. And it draws a clean line between the two, rather than letting point-to-point integrations accumulate underneath either.
The move itself
Companies that recognize they are in the point-to-point trap often ask how to migrate. The answer is usually slowly and in one direction. Pick a canonical model for the most central business objects first — customer and order, typically. Build one adapter for the highest-volume source system and one for the highest-volume destination. Route new integration requirements through the new layer. Leave the existing point-to-point connections alone until they break or until a change forces a rewrite.
Over eighteen to twenty-four months, the center of gravity shifts. The old connectors thin out, either retired or replaced. The new layer handles the majority of the traffic. Nobody remembers exactly when the transition happened, because it happened by a series of small decisions rather than a single big-bang migration. That is the healthiest shape an integration-platform rollout takes.
The point-to-point trap is avoidable. The cost of avoiding it rises sharply after the first dozen connectors. The companies that move early on the integration layer pattern spend less over a five-year horizon, add new systems faster, and have fewer Sunday-evening incidents. The ones that do not, usually do not because the cost of inaction is invisible until it is catastrophic.
Top comments (0)