Enterprise application integration (EAI) is an architecture decision, not a shopping trip. No one tool handles the not-uncommon mix of legacy ERP, mainframe(s), SaaS, and a critical data warehouse. You need to match each workload to the most suitable integration pattern. Know when to choose ESB, iPaaS, API-led, and event-driven, and when not to.
Key Points
- Enterprise application integration is an architecture decision, as no single tool handles mixed legacy and SaaS well.
- Every pattern has a breaking point: point-to-point dies at the fifth system, the ESB concentrates blast radius, microservices sprawl auth and governance, and event-driven trades consistency for throughput.
- Most enterprises already run two or three integration approaches, and that is the right design when you split workloads on purpose instead of by accident.
- Legacy systems outlive their migration deadlines, so the integration layer is permanent infrastructure.
Every integration roadmap I get pulled into opens with a logo slide. Some platform, some magic quadrant, some magic promise to unify the estate. That’s an impossible single platform choice when you have a legacy ERP system nobody wants to touch, payroll running on a mainframe, three siloed marketing SaaS apps, and a company-wide data warehouse.
No single platform fits that bill. The real question isn’t picking a single product, it’s about matching product to estate member.
It helps to define enterprise application integration the way it behaves, while avoiding its marketing hype. It is the practice of connecting multiple applications and disparate systems to make sure data and business processes flow. All while allowing flexibility on where those systems live or how they communicate.
Our goal is to break data silos formed when every team buys its own software. That is not a product category. It is a decision space that takes into account the decade-old systems to 18-month-old SaaS. That usually results in implementing more than one approach that has to coexist.
The Patterns and the Exact Point Where Each One Fails
The integration patterns themselves have barely changed since Gregor Hohpe and Bobby Woolf codified 65 of them in 2003. What changes is which one you reach for. Real EAI expertise is knowing where each one breaks.
Point-to-Point Integration
Point-to-point integration is where most teams start. You write code so System A talks directly to System B. It is quick for the first connection and a trap by the fifth, because the math is unforgiving. N systems connected directly need N(N-1)/2 connections. Ten systems means 45 connections.
It only gets worse from there. Every field rename in one system can break every integration touching it, and there is no single place to watch the whole thing. But point-to-point is a prototyping tool, not an architecture. Past four or five systems, it’s technical debt you are choosing on purpose.
Hub-and-Spoke
The hub-and-spoke model fixes the math. Every system connects once to a central layer that routes, transforms, and translates protocols, which drops you from N-squared connections back to N. Enterprise Service Bus (ESB) is the classic implementation, the grown-up form of service-oriented architecture and message-oriented middleware.
It still wins where it was born: legacy-heavy, on-prem estates with a zoo of protocols and web services (SOAP, JMS, MQ, proprietary EDI) and a regulatory need to audit every message that moves. The catch is blast radius. That central hub becomes a single thing the whole business depends on, and AWS is blunt about the failure mode: when the bus has problems, everything routed through it has problems at the same time. One bad transformation rule can stall billing, fulfillment, and customer relationship management.
There is a quieter ESB failure, too, and it is the one that actually kills teams. Business logic creeps into the transformation rules because shipping a rule change is faster than shipping a code release. A year later you have business-critical logic living in a text box in the integration layer, with no tests, no documentation, and no source control. I have inherited that system. It was worse than the spaghetti it replaced.
Microservices and API Integration
Microservices and API-led integration swing the pendulum the other way. You get small services that deploy independently, talk over lightweight APIs (application programming interfaces), and each own their data. It suits organizations with real DevOps maturity and strong product ownership. But the complexity doesn’t vanish, it merely relocates.
Microsoft’s own architecture guidance says it plainly: each service is simpler, the system as a whole is more complex. Authentication is where it bites. Forty services across three environments with two auth methods is 240 configurations to get right, and every one is a place to leak. The governance you used to centralize is now everyone’s part-time job.
Event-Driven Architecture
Event-driven architecture decouples producers from consumers through a broker like Kafka or RabbitMQ, and it is the right call for genuinely high-volume, real-time work: transaction streams, telemetry, inventory events where synchronous request-response would melt under load. The tradeoff is eventual consistency and debugging difficulty.
Martin Fowler has cautioned for years that patterns like CQRS add risky complexity for most systems. Worse, streaming systems keep running while they quietly corrupt data. A duplicate event, a missing event, or a schema change nobody coordinated, all while the dashboards stay green.
| Pattern | Fits when | Fails when |
| Point-to-point | Fewer than 5 stable systems, one owner | A 4th or 5th system appears (N-squared) |
| Hub-and-spoke / ESB | Legacy, on-prem, heterogeneous protocols, audit needs | Blast radius and shadow logic at the hub |
| Microservices / API-led | DevOps maturity, independent deploys, product teams | Auth and governance sprawl at scale |
| Event-driven | High-volume, real-time, many consumers | Eventual consistency, silent data corruption |
ESB Versus iPaaS, and Why the Real Answer Is “Both”
This question gets asked a lot, but it’s not a winner-take-all choice. Too many think they have to pick one, and unfortunately, end up with the wrong tool.
Traditional EAI and the ESB still win where governance and centralized auditability dominate. Even more so when the estate is legacy-heavy and on-prem. If a regulator can ask you to produce an audit trail of every message between two systems, a centralized bus is doing real work for you.
But iPaaS wins on the other side, where your estate is cloud-forward and SaaS-heavy. Where you have a lean integration team and low-code connectors, turn a three-month ESB project into three days. The strangler pattern lives here: new integrations land on iPaaS while the old ESB connections retire one at a time.
The production reality is that most organizations run two or three of these at once, and that is not a failure to consolidate. It is the correct design. Roughly 72% of mid-market and enterprise companies already run two or more integration platforms. The mistake is not running more than one approach. The mistake is letting them sprawl by accident because nobody decided which workloads belong where.
One caution that never shows up on the demo. Vendor lock-in is real on both sides, and on iPaaS it is deferred, which makes it more dangerous. Year one is the honeymoon: connectors are fast, everything ships. Year two and three are when the proprietary flow definitions, the connector ecosystem, and the per-connection pricing make leaving expensive. Decide your exit criteria and keep an integration inventory before you sign a multi-year deal, not after.
The Legacy Bridge Is the Job, Not a Detour
Experienced integrators know an uncomfortable truth about integration strategy: legacy systems are rarely temporary. They just tend to stick around. Just look at the large SAP ECC migration reality. As of late 2024, only around 39% of SAP ECC customers had moved to S/4HANA, and analysts expect close to half will stick with their legacy ERP install past the 2027 deadline. These ERP systems aren’t going anywhere on your timeline.
Legacy is a constraint to design around, and I use the integration layer to solve that bit of fun. It handles translation between system generations especially well, marrying old protocols and formats into something the new systems can chew on. Industries with the largest collection of legacy systems, like banking, insurance, healthcare, and energy, are where this integration shines because downtime carries penalties, and those older systems are still carrying real business load.
Just make sure the costs around that bridge are known, especially since people are the expensive part. The engineers who genuinely understand both a mainframe transaction interface and a modern event stream are rare and pricey. Then there is version skew, where one end updates monthly, and the other annually. The integration layer has to absorb that difference forever.
The nice part though, is that the bridge usually beats full replacement on long-term return, as long as you keep maintenance costs in mind.
The Uncomfortable Truth
- Legacy systems routinely outlive every migration deadline you set for them.
- The scarce, expensive resource is people who speak both COBOL and Kafka.
- “We’ll retire it after the migration” is the most expensive sentence in integration planning.
The Tradeoffs Nobody Puts on the Slide
Every integration approach is a trade-off. The job is to know what the costs are and what you can live with.
Centralization buys you governance and costs you blast radius. A central ESB or API gateway is the one place to enforce auth, rate limiting, schema validation, and audit logging, which is genuinely valuable and sometimes legally required. Just know that this means you have one place where failure could take down everything at once. Governance means accepting the concentration risk. That means the choice becomes an engineering question on how to contain the blast, not whether it exists.
Distribution runs the other way. Break a monolith into dozens of services, and you chose independence at the price of a larger security surface. The endpoints, auth configurations, and attack surface multiplied all at once. Security in transit stops being optional housekeeping and becomes core design:
- TLS everywhere
- Mutual TLS for service-to-service
- Centralized certificate management with key rotation.
Teams that discover this in year two discover it through an incident.
Then there is the bottleneck that hides in plain sight. Every message through an ESB or gateway adds latency for transformation and routing. With enough load, and as endpoints grow, the central node quickly becomes a bottleneck. This is exactly why high-volume, real-time work often escapes the central layer entirely and goes straight to an event broker built for throughput rather than transformation. Route by workload, not by habit.
Real-Time Is a Separate Decision from Your Architecture
Do you want to save money? If yes, you need to decide whether your system needs to be real-time or not. And, by the way, that answer has nothing to do with which integration pattern you use. ESB can batch and scheduled jobs work with microservices. The workload decides how often the data has to move, not the architecture diagram.
Batch is cheaper and simpler to make fault-tolerant. Batch works just fine for financial reporting, master-data synchronization, payroll, and bulk migration. A failed batch can be rerun without the consistency drama.
Real-time data integration comes to play for fraud detection, live inventory, and payments. It also costs more in infrastructure, expertise, operational pain, and so on.
The worst version is the streaming pipeline that quietly corrupts its own outputs while every dashboard still glows green.
Teams over-invest here way too often. Default to batch and earn your way into real-time per workload, and only make the jump when the latency cost is acceptable. Many workloads that “need” real-time are fine being synced every 15 minutes.
Data quality deserves the same skepticism. Integration doesn’t fix bad data at the source. It inherits it, and it can hide it. Make sure the transformation layer isn’t filling in missing values with “defaults” that are just covering up bad data mapping or incomplete inputs. Schema evolution, idempotency, and encoding mismatches need to be first-class design concerns because the integration layer is where they either get caught or get laundered.
| Workload | Default cadence | Use real-time only when |
| Financial reporting | Batch | Intraday decisions have real business value |
| Payroll | Batch | Almost never |
| Master-data sync | Batch or scheduled sync | Stale data breaks active transactions |
| Bulk migration | Batch | Almost never |
| Fraud detection | Real-time | Latency means money lost |
| Live inventory | Near-real-time or real-time | Overselling creates material cost |
| Payments | Real-time | Customer flow or settlement depends on it |
How to Decide
Don’t shop for a magic platform that will unify your estate. It doesn’t exist. Map your estate by workload class and by the legacy-versus-modern line, then marry each class to the best-fit approach:
- ESB or a governed hub where compliance and on-prem protocol complexity dominate.
- iPaaS where the estate is cloud-native, and the team is lean.
- API-led, where you are exposing systems of record to product teams.
- Event-driven architectures where real-time volume genuinely demands it.
Expect to run more than one, and design the seams between them with purpose.
Be honest about the estate you actually have. Really look at it, legacy and all. Match each piece to the approach that makes its constraints survivable. Get that right, and the platform question mostly answers itself.
