Most B2B companies do not decide on an integration strategy. They accumulate integrations, one urgent requirement at a time, until the connections between systems are more complex than the systems themselves.
The decision that prevents most integration pain is deciding what is authoritative for each entity. One system owns customers, one owns orders, one owns invoices. Without that, every integration becomes a negotiation about who wins, resolved differently each time by whoever built it.
Start with a system-of-record map
| Entity | Authoritative system | Everyone else |
|---|---|---|
| Prospect / lead | CRM | Read-only copy |
| Customer master | ERP or finance | Read-only copy |
| Product and pricing | ERP or PIM | Read-only copy |
| Order | ERP once confirmed | Status visibility |
| Invoice and payment | Finance | Read-only copy |
| Support ticket | Helpdesk | Read-only copy |
| Employee | HR system | Read-only copy |
The exact assignment matters less than making it explicitly and writing it down. The right-hand column is what prevents the bidirectional-sync problems.
Three architectures, in order of cost
| Approach | Works until |
|---|---|
| Point-to-point connections | Around five or six integrations |
| Hub with shared middleware | Scales well; costs money and learning |
| Event-driven with a message backbone | Scales furthest; needs real engineering maturity |
Point-to-point is not a mistake at three integrations. It becomes one at fifteen, and the transition is much harder than the original builds.
What every integration needs, regardless of architecture
- A named owner — a person, not a team inbox.
- Idempotency, because retries and duplicate events are normal.
- Retry with backoff for transient failures.
- A dead-letter path someone reviews.
- Alerting to a human when it stops working.
- Reconciliation proving both sides agree.
- Documentation of what it moves and why.
Build the reconciliation report with the first integration, not the tenth. It is the only thing that tells you the integration is working rather than merely running. Systems drift quietly, and the alternative discovery mechanism is a customer or an auditor.
Failure modes worth designing against
| Failure | Without design | With it |
|---|---|---|
| Target system down | Data lost | Queued, processed later |
| Malformed record | Whole batch stops | One record to dead letter |
| Duplicate delivery | Duplicate order created | Ignored, idempotently |
| Credentials expired | Silent stop | Alert before expiry |
| Schema changed upstream | Silent field loss | Validation failure raised |
| Volume spike | Rate limits hit, data lost | Backpressure and retry |
A pragmatic path from here
- Inventory what exists — every integration, what it moves, who owns it, whether it is monitored.
- Kill what is unused. There will be some.
- Write the system-of-record map and circulate it for disagreement.
- Add monitoring and alerting to what remains, starting with the business-critical ones.
- Add reconciliation to the ones moving financial or customer data.
- Only then consider consolidating onto a platform, if the count justifies it.
Signs the accumulation has passed the threshold
- Nobody can list all the integrations.
- Failures are discovered by users or customers.
- The same transformation logic exists in several places.
- Changing a field in one system breaks something unexpected.
- Two systems disagree and nobody can say which is right.
- Integrations exist whose purpose nobody can explain.
Planning integrations, or trying to regain control of existing ones? Tell us what connects to what. See Salesforce integration patterns, Zoho and ERP, and CRM data migration.