Enterprise Application Integration (EAI) — Definition, Architecture and the iPaaS Successor
Enterprise Application Integration (EAI) denotes the technical integration of heterogeneous business applications — ERP, CRM, MES, WMS, warehouse systems, financial accounting — through centralised middleware platforms. EAI emerged in the late 1990s as the answer to point-to-point sprawl in grown IT estates and established the Enterprise Service Bus (ESB) as the architecture standard of the 2000s. The term has largely been superseded by iPaaS (Integration Platform as a Service), which delivers the same capability cloud-natively with subscription pricing and pre-built connectors. The underlying patterns — message queues, publish/subscribe, orchestration — remain in use.
Historical architecture: point-to-point, hub-and-spoke, ESB
Three architectural stages shaped EAI history. Point-to-point connected each application directly to every other — with n systems, up to n × (n−1) / 2 bilateral interfaces grew, with exponentially expanding maintenance cost. Hub-and-spoke introduced a central integration broker (IBM MQSeries Integrator, webMethods Enterprise) that transformed and routed messages; every spoke spoke only to the hub. Enterprise Service Bus (ESB) generalised the hub model into a distributed bus with service endpoints, mediation, protocol conversion and orchestration. Well-known implementations include IBM Integration Bus, Oracle Service Bus, JBoss/WSO2 ESB and Microsoft BizTalk. ESB projects were heavyweight: dedicated servers, long implementation timelines, high licence cost, specialised teams.
EAI versus iPaaS versus ETL
EAI integrates applications typically synchronously or near-real-time, carrying business events (order created, invoice posted). iPaaS is the cloud-native evolution of EAI — self-service flow designers, pre-built SaaS connectors, multi-tenant runtime, pay-per-use. ETL (Extract, Transform, Load), by contrast, moves bulk record-sets in batch mode between source systems and a data warehouse — oriented towards analytics, not operational business processes. Rule of thumb: synchronising orders in real time between shop and ERP is EAI/iPaaS work; loading sales data into the warehouse overnight is ETL. The boundaries blur — modern iPaaS platforms handle both modes.
Common EAI patterns
- Message queue — asynchronous point-to-point transport over durable queues (RabbitMQ, ActiveMQ, IBM MQ, Apache Kafka as the modern streaming counterpart)
- Publish/subscribe — one producer emits events, any number of consumers subscribe (domain events for order, shipment, payment)
- Request/reply — synchronous call with correlation ID, typically via SOAP, later REST
- Orchestration — central flow control across multiple service calls (BPEL, BPMN engines, today Camunda/Zeebe)
- Choreography — decentralised event collaboration without a central conductor
- API gateway — the entry point for external consumers with authentication, rate limiting and transformation layer (Kong, Apigee, Azure API Management)
- Adapter pattern — connector translates between system protocol (SAP IDoc, EDIFACT) and bus format
Established EAI and iPaaS tools
The classical on-premises EAI market was shaped by IBM App Connect (formerly IIB / WebSphere), Microsoft BizTalk Server (in maintenance mode since 2020), Oracle SOA Suite, TIBCO BusinessWorks and webMethods (Software AG, now IBM). In the DACH market, SEEBURGER (Bretten), Lobster_data (Pöring) and X4 BPMS (SoftProject, Ettlingen) are particularly established. On the cloud-iPaaS side: Boomi, MuleSoft (Salesforce), SAP Integration Suite, Microsoft Logic Apps / Power Automate, Workato, Celigo and, for EDI-centric mid-market scenarios, ecosio. Open-source options: Apache Camel, n8n, Mule Community Edition.
Selection criteria for DACH mid-market
Six criteria typically dominate tool selection in German-speaking mid-market. (1) Pre-built ERP connectors — available adapters for SAP S/4HANA, Microsoft Dynamics 365 BC, Sage, DATEV, proALPHA, Infor save weeks of implementation. (2) GDPR and EU data residency — data centres in Frankfurt or Munich, data-processing agreement under GDPR Art. 28, sub-processor lists with EU binding. (3) On-premises option or hybrid gateway — many mid-market organisations still host ERP in their own data centre; a local agent connects the cloud iPaaS. (4) Support language and DACH partners — German-language support in business hours, local implementation partners. (5) Pricing model — flow-based, connector-based or volume-based; flow-based models scale poorly as integration count grows. (6) EDI capability — many DACH B2B scenarios need native EDIFACT, VDA, GS1, ZUGFeRD support.
Related Topics
Frequently Asked Questions
What is the difference between EAI and iPaaS?
EAI is the discipline of application integration, traditionally realised on-premises through middleware or an Enterprise Service Bus. iPaaS denotes the cloud-native delivery model for the same task — subscription pricing, pre-built SaaS connectors, multi-tenant runtime, self-service flow designer. Both solve the same problem: making ERP, CRM, WMS and other applications talk reliably. iPaaS mainly reduces setup effort, server operations and time-to-value compared with classical ESB projects of the 2000s.
Is an Enterprise Service Bus (ESB) still relevant today?
Rarely for greenfield projects — most new builds choose iPaaS or an event-streaming platform (Apache Kafka, Confluent). Existing ESB installations, however, continue to run in many DACH enterprises and are migrated step by step. Microsoft BizTalk Server has been in long-term support since 2020; SAP PI/PO will be replaced over time by SAP Integration Suite. Complete replacement typically takes 3-7 years, since hundreds of integration flows need to be migrated and re-tested.
Which EAI patterns should an ERP owner know?
Four patterns cover the bulk of practice: message queue for decoupled asynchronous handover (order placed in queue, ERP consumes), publish/subscribe for event distribution to multiple consumers (master-data change to CRM and webshop in parallel), request/reply for synchronous queries (availability check), orchestration for multi-step processes (order → credit check → reservation → confirmation). The reference work is “Enterprise Integration Patterns” by Hohpe and Woolf (2003) — the 65 patterns described there reappear as building blocks in every modern iPaaS tool.
Which EAI/iPaaS vendors are established in the DACH mid-market?
Classical EAI segment with on-premises roots: SEEBURGER (Bretten), Lobster_data (Pöring), X4 BPMS (SoftProject, Ettlingen), IBM App Connect, Software AG webMethods. Cloud-iPaaS segment: Boomi (Dell), MuleSoft (Salesforce), SAP Integration Suite, Microsoft Logic Apps and Power Automate, Workato, Celigo, ecosio (Vienna, EDI-focused). Decision drivers in practice are ERP-connector availability, EU data centre, German-language support and established DACH implementation partners.
When does open-source EAI (Apache Camel, n8n) make sense over commercial iPaaS?
Open source is viable when an internal platform team with operational maturity is in place. Apache Camel has been in enterprise production for over 15 years; n8n is suited to low-code flows and scales to several thousand flows per day. Trade-off: lower licence cost, higher operational responsibility — monitoring, patching, scaling, SLA and 24/7 cover sit with the in-house team. Mid-market organisations without a dedicated integration squad typically pick commercial iPaaS for the support SLA.