The average mid-size enterprise now runs somewhere between ten and twenty SaaS products. Each one has an API of varying quality. Most have webhooks. Some have native integrations with other tools. And somehow, it all needs to work as a coherent system. This is the integration problem, and it's more common than any single technology challenge we encounter.
What You Need to Know
- There are three main integration patterns: point-to-point, middleware/hub, and event-driven. Each has trade-offs
- Point-to-point works for two or three connections. Beyond that, it becomes exponentially harder to maintain
- Middleware (iPaaS platforms like MuleSoft, Dell Boomi, or Workato) adds a layer of abstraction but introduces a new dependency
- Event-driven architecture is the most flexible long-term pattern, but requires more upfront design
- Start with the data flows that matter, not the tools that are loudest
The Patterns
Point-to-Point
System A talks directly to System B. You write the integration code, deploy it, maintain it. This is fine when you have two or three connections. It's the simplest approach and the fastest to implement.
The problem is that it doesn't scale linearly. Three systems need three connections. Five systems need ten. Ten systems need forty-five. Each connection is its own maintenance burden, its own failure point, its own thing that breaks at 2am on a Saturday. We've inherited codebases with sixty-plus point-to-point integrations and I can tell you: nobody knows which ones are still active.
45
point-to-point connections required to fully integrate just 10 systems
Source: n(n-1)/2 combinatorial growth
Middleware / Integration Hub
An iPaaS (Integration Platform as a Service) sits in the middle. Systems connect to the hub, and the hub manages the routing, transformation, and orchestration. MuleSoft, Dell Boomi, Workato, and Zapier (at the simpler end) all fit this pattern.
The advantage is centralisation. You have one place to monitor data flows, one place to handle errors, one place to see what's connected to what. The disadvantage is dependency. The hub becomes critical infrastructure. If it goes down, everything goes down. And the licensing costs for enterprise iPaaS platforms are not trivial.
For most organisations in the 10-50 employee range, something like Workato or even Zapier handles 80% of the integration work. For larger organisations with complex data flows, MuleSoft or Boomi earn their price tag. The mistake is choosing based on where you want to be rather than where you are.
Event-Driven
Systems publish events. Other systems subscribe to the events they care about. Nobody knows or cares who's listening. A customer is created in the CRM, and an event fires. The billing system picks it up and creates an account. The support system picks it up and creates a profile. The analytics system picks it up and updates a dashboard.
This is the most flexible pattern and the one that scales best long-term. Adding a new system means subscribing to the events it needs, not building connections to every other system. But it requires more upfront design: you need a clear event schema, a reliable message broker (RabbitMQ, Apache Kafka, AWS EventBridge), and a team that understands eventual consistency.
Event-driven architecture isn't harder to build. But the design work pays for itself every time you add a new system.
John Li
Chief Technology Officer
Where to Start
Don't try to integrate everything at once. Identify the two or three data flows that cause the most pain.
Usually it's one of these:
Customer/contact data. The "single source of truth" problem. Where does the canonical customer record live? Everything else should read from there.
Financial data. Invoice amounts, payment status, revenue figures. When finance and sales disagree on revenue, you have an integration problem.
Operational status. Project status, order status, case status. The data that people check ten times a day because they don't trust the system to be current.
Pick one. Sort it out properly. Learn from the experience. Then do the next one.
Practical Advice
Document your data flows before choosing tools. A whiteboard diagram of "what data moves where" saves more money than any technology selection process.
Version your APIs from day one. The number of organisations I've seen break their own integrations because they changed an API without versioning it is genuinely depressing.
Monitor your integrations. If you can't tell me, right now, whether your CRM-to-billing integration ran successfully last night, you have a monitoring problem. And monitoring problems become data problems faster than you'd think.
Accept eventual consistency. In most business contexts, data that's consistent within a few minutes is fine. Don't build complex synchronous integrations when an async approach with a short delay would do the job. The simpler architecture will be more reliable.
60%
of integration projects exceed their planned timeline due to data quality issues discovered mid-implementation
Source: MuleSoft Connectivity Benchmark Report, 2021
The Meta-Lesson
Integration architecture isn't a technology problem. It's a data governance problem. The technology is a means to an end. If you don't know what data matters, where it lives, and who owns it, no tool will save you. Start with the map. The tools come after.