Integration sprawl does not arrive as a decision. It arrives as a sequence of reasonable Tuesdays: the store needs to tell the CRM about a new customer, the CRM needs to tell the invoicing tool, the invoicing tool needs to tell the spreadsheet, and support needs to see all three. Each connector is justified on its own. The total is not justified by anyone, because nobody ever proposes the total.
The useful question is not how to build these connections better. It is how many of them should exist at all.
The arithmetic nobody does at the start
If N systems each hold part of the truth about the same entities and each needs to agree with the others, the pairwise connection count is N(N-1)/2. Five systems is ten connections. Eight is twenty-eight.
| Systems | Pairwise connectors | Auth schemes to maintain | Failure modes to understand |
|---|---|---|---|
| 3 | 3 | 3 | 3 |
| 5 | 10 | 10 | 10 |
| 8 | 28 | 28 | 28 |
The columns are identical on purpose. Each connector is not a line on a diagram; it is an independent piece of software with its own credential lifecycle, its own rate limit, its own retry behaviour, its own idea of whether events arrive in order, and its own way of breaking. Two connectors to the same vendor from different tools do not share any of that.
A hub-and-spoke automation platform genuinely reduces this to N connectors, and that is a real gain in build cost and observability. It leaves the harder half untouched, because the count that hurts is not how many connectors you maintain. It is how many systems believe they own the customer record.
Every connector is four separate promises
When people say an integration is “done”, they usually mean data moved once in a demo. A connector you can depend on has to answer four questions, and each answer is a design decision that differs per vendor.
Authentication and its lifecycle. API key, OAuth with refresh, HMAC-signed requests, a bearer token in a header. Refresh tokens expire, keys get rotated by someone who did not know, and the failure is usually silent for hours.
Retry and idempotency. If the receiving system times out after committing, a retry either creates a duplicate or is safely ignored, depending entirely on whether the receiver supports idempotency keys. That is the vendor’s choice, not yours.
Ordering and conflict. If an update and a delete arrive out of order, what is the final state? If both systems edited the same field between syncs, which wins? “Last write wins” is a policy, and it is the policy that loses data.
Failure semantics. Does a failed delivery retry, dead-letter, or vanish? A connector that fails loudly is a Tuesday. A connector that fails quietly is a quarter of bad decisions.
Multiply those four by twenty-eight and the maintenance burden is clear without needing a study to prove it.
The failure case: the refund that three systems disagreed about
A merchant runs a store, a CRM, a help desk and an accounting package, connected pairwise. A customer’s order is refunded in the payment provider by a support agent working in the help desk, which fires a webhook to the store. The store marks the order refunded and syncs the customer’s lifetime value to the CRM on its next hourly run.
The accounting package receives refunds by a nightly export from the store. That night, the store’s export job runs before the hourly CRM sync completes, so the refund reaches accounting; the CRM’s lifetime value figure updates an hour later; and the help desk, which was where the refund actually originated, has no listener for the store’s webhook at all.
Three weeks later the customer emails asking why they have been chased for payment. The dunning sequence runs from the CRM, which had the updated lifetime value but not the invoice state, because nobody built that particular edge of the graph. Everyone assumed the refund had propagated because it had propagated somewhere.
The instructive part is the diagnosis. There is no bug to fix. Each connector did what it was built to do. The defect is the topology: four systems holding four partial views of one order, with no arrangement of connectors that makes them consistent at any single moment.
When point-to-point is exactly right
This is not an argument against integration. It is an argument against integration as a substitute for a data model. Point-to-point is the correct pattern when three conditions hold together:
- The other system is a genuine specialist. A payment network, a bank data aggregator, an e-signature provider, a calendar. You are not going to build these, and you should not try.
- The flow is directional. Facts move one way. A signature request goes out; a completion event comes back. Nobody edits the same record on both sides.
- The failure mode is survivable and visible. A missed alert in a chat channel is an annoyance. A missed stock decrement is oversold inventory.
Judged that way, most healthy integration lists are short and narrow: payments in, bank feeds in, signatures out and back, alerts out, mailbox both ways. Oneop’s integration list has this shape deliberately. Slack and Microsoft Teams receive five specific events through an incoming webhook you create in your own workspace, which is alerting, not a second inbox. QuickBooks sends changes inbound by webhook as they happen while outbound pushes run on demand, because “two-way sync” without a stated cadence is how accounting integrations disappoint people. Salesforce syncs Contacts, Accounts and Opportunities, with Accounts pull-only.
Notice that each of those has a direction stated. A connector whose direction cannot be stated in one sentence is a connector whose conflict policy has not been decided.
When point-to-point is a symptom
The symptom version looks different. It is a two-way sync of an entity both systems can edit, built because two tools each hold half of something that should have been one record. The tell is the vocabulary: “keeping them in sync”, “reconciliation”, “the nightly job”, “source of truth for that field”.
If you are writing field-level conflict rules between your CRM and your billing system, the integration is not the problem to solve. The problem is that two systems own the customer, and the connector is the tax you pay for that.
The alternative is unglamorous: reduce the number of systems that claim ownership of the same fact. When the CRM record, the ticket, the project, the invoice and the stock level live in one database, the connection between them is a foreign key rather than a connector, and a foreign key has no auth, no retries, no ordering assumptions and no failure mode. It also has no lag, which is why a report can read the invoice raised two minutes ago straight from the reporting engine with no extract step in between.
The honest cost of consolidation
Concentrating records in one vendor is a real risk and should be priced as one. Before consolidating, demand three things: full data export in a format you can actually reload, real import tooling rather than a professional services quote, and transparent limits published as numbers.
There is also a depth requirement. Consolidation is only worth it if the consolidated system is genuinely deep in each area, which is the thing most suite products fail at. Evaluate the modules you rely on individually, and judge them against the specialist you would otherwise buy.
The remaining trade-off is that some specialists are irreplaceable, and for those, point-to-point is correct forever. Keep them, state their direction, verify their webhooks, and stop pretending the other twenty connectors are the same kind of thing. The related architectural argument for software that acts rather than merely reads is in why your AI agent should live inside your system of record, and the channel version of the same consolidation case is in running a two-channel support operation. For the broader definition, see what is an AI-first customer platform.