Enterprise Application Integration (EAI): Definition, Architektur, Nachfolger iPaaS

Q: Welche EAI-Patterns sollte man als ERP-Verantwortlicher kennen?

Vier Patterns decken den Großteil der Praxis ab: Message-Queue für entkoppelte asynchrone Übergabe, Publish/Subscribe für Event-Verteilung an mehrere Konsumenten, Request/Reply für synchrone Abfragen, Orchestrierung für mehrstufige Geschäftsprozesse. Das Standard-Referenzwerk ist Enterprise Integration Patterns von Hohpe und Woolf (2003).

Q: Welche EAI-/iPaaS-Anbieter sind im DACH-Mittelstand etabliert?

Im klassischen EAI-Segment: SEEBURGER, Lobster_data, X4 BPMS (SoftProject), IBM App Connect, Software AG webMethods. Im Cloud-iPaaS-Segment: Boomi, MuleSoft, SAP Integration Suite, Microsoft Logic Apps und Power Automate, Workato, Celigo, ecosio. Wahl-Treiber sind ERP-Konnektor-Verfügbarkeit, EU-Rechenzentrum und deutschsprachiger Support.

Enterprise Application Integration (EAI) bezeichnet die technische Integration heterogener Geschäftsanwendungen — typischerweise ERP, CRM, MES, WMS, Lager-Systeme und Finanzbuchhaltung — über zentrale Middleware-Plattformen. EAI entstand in den späten 1990er-Jahren als Antwort auf die Punkt-zu-Punkt-Vernetzung gewachsener IT-Landschaften und etablierte den Enterprise Service Bus (ESB) als Architektur-Standard der 2000er. Heute ist EAI als Begriff weitgehend abgelöst durch iPaaS (Integration Platform as a Service), das die gleichen Aufgaben Cloud-nativ, Subscription-basiert und mit vorgefertigten Konnektoren löst. Die zugrundeliegenden Patterns — Message-Queue, Pub/Sub, Orchestrierung — bestehen jedoch weiter.

Historische Architektur: Point-to-Point, Hub-and-Spoke, ESB

Drei Architektur-Stufen prägten die EAI-Geschichte: Point-to-Point verband jede Anwendung direkt mit jeder anderen — bei n Systemen entstanden bis zu n × (n−1) / 2 bilaterale Schnittstellen, mit exponentiell wachsendem Wartungsaufwand. Hub-and-Spoke führte einen zentralen Integration-Broker (z. B. IBM MQSeries Integrator, webMethods Enterprise) ein, der Nachrichten transformierte und routete; alle Spokes sprachen nur mit dem Hub. Enterprise Service Bus (ESB) verallgemeinerte das Hub-Modell zu einem verteilten Bus mit Service-Endpunkten, Mediation, Protokoll-Konvertierung und Orchestrierung — bekannte Implementierungen sind IBM Integration Bus, Oracle Service Bus, JBoss/WSO2 ESB und Microsoft BizTalk. ESB-Projekte galten als schwergewichtig: dedizierte Server, lange Implementierungszeiten, hohe Lizenzkosten, spezialisierte Teams.

EAI vs. iPaaS vs. ETL — klare Abgrenzung

EAI integriert Anwendungen in der Regel synchron oder near-realtime und transportiert dabei Geschäftsereignisse (Auftrag angelegt, Rechnung gebucht). iPaaS ist die Cloud-native Weiterentwicklung von EAI — Self-Service-Flow-Designer, vorgefertigte SaaS-Konnektoren, mandantenfähige Runtime, pay-per-use. ETL (Extract, Transform, Load) dagegen bewegt typischerweise Massen-Datensätze im Batch-Verfahren zwischen Quellsystem und Data-Warehouse — orientiert auf Analyse, nicht auf operative Geschäftsprozesse. Faustregel: Wer Aufträge in Echtzeit zwischen Shop und ERP synchronisiert, betreibt EAI/iPaaS. Wer nachts Umsatzdaten ins Data-Warehouse lädt, betreibt ETL. Die Übergänge verschwimmen — moderne iPaaS-Plattformen beherrschen beide Modi.

Typische EAI-Patterns

Message-Queue — asynchrone Punkt-zu-Punkt-Übertragung über persistente Queues (RabbitMQ, ActiveMQ, IBM MQ, Apache Kafka als modernes Streaming-Pendant)
Publish/Subscribe — ein Produzent veröffentlicht Events, beliebig viele Konsumenten abonnieren (Domain-Events bei Auftrag, Lieferung, Zahlung)
Request/Reply — synchroner Aufruf mit Korrelations-ID, typisch über SOAP, später REST
Orchestrierung — zentrale Ablaufsteuerung mehrerer Service-Calls (BPEL, BPMN-Engines, heute Camunda/Zeebe)
Choreographie — dezentrale Event-Kollaboration ohne zentralen Dirigenten
API-Gateway — Zugriffspunkt für externe Konsumenten mit Authentifizierung, Rate-Limit und Transformations-Layer (Kong, Apigee, Azure API Management)
Adapter-Pattern — Konnektor übersetzt zwischen System-Protokoll (z. B. SAP IDoc, EDIFACT) und Bus-Format

Bekannte EAI- und iPaaS-Tools

Im klassischen On-Premises-EAI-Markt prägten IBM App Connect (vormals IIB / WebSphere), Microsoft BizTalk Server (seit 2020 im Wartungs-Modus), Oracle SOA Suite, TIBCO BusinessWorks und webMethods (Software AG, heute IBM) das Bild. Im DACH-Markt sind besonders SEEBURGER (Bretten), Lobster_data (Pöring) und X4 BPMS (SoftProject, Ettlingen) etabliert. Auf der Cloud-iPaaS-Seite dominieren Boomi, MuleSoft (Salesforce), SAP Integration Suite, Microsoft Logic Apps / Power Automate, Workato, Celigo und für EDI-fokussierte Mittelstands-Szenarien ecosio. Open-Source-Optionen: Apache Camel, n8n, Mule Community Edition.

Auswahlkriterien für DACH-Mittelstand

Bei der Tool-Wahl im deutschsprachigen Mittelstand werden meist sechs Kriterien geprüft: (1) Pre-built ERP-Konnektoren — verfügbare Adapter für SAP S/4HANA, Microsoft Dynamics 365 BC, Sage, DATEV, proALPHA, Infor sparen Wochen an Implementierungsaufwand. (2) DSGVO und EU-Datenresidenz — Frankfurter oder Münchner Rechenzentren, Auftragsverarbeitungs-Vertrag nach Art. 28 DSGVO, Sub-Processor-Listen mit EU-Bindung. (3) On-Premises-Option oder Hybrid-Gateway — viele Mittelständler haben ERP-Systeme noch im eigenen Rechenzentrum; ein lokaler Agent schließt die Cloud-iPaaS an. (4) Support-Sprache und DACH-Partner — deutschsprachiger Support in Geschäftszeiten, lokale Implementierungspartner. (5) Preismodell — flow-basiert, konnektor-basiert oder volumen-basiert; flow-basierte Modelle skalieren bei wachsender Integrations-Anzahl ungünstig. (6) EDI-Fähigkeit — viele DACH-B2B-Szenarien brauchen EDIFACT, VDA, GS1, ZUGFeRD direkt im Tool.

Häufig gestellte Fragen

Was ist der Unterschied zwischen EAI und iPaaS?

EAI ist die Disziplin der Anwendungs-Integration, traditionell On-Premises über Middleware oder Enterprise Service Bus realisiert. iPaaS bezeichnet das Cloud-native Liefer-Modell der gleichen Aufgabe — Subscription-Pricing, vorgefertigte SaaS-Konnektoren, mandantenfähige Runtime, Self-Service-Flow-Designer.

Inhaltlich lösen beide das gleiche Problem: ERP, CRM, WMS und weitere Anwendungen zuverlässig miteinander sprechen lassen. iPaaS reduziert vor allem Setup-Aufwand, Server-Betrieb und Time-to-Value gegenüber klassischen ESB-Projekten der 2000er-Jahre.

Ist ein Enterprise Service Bus (ESB) heute noch relevant?

Für Greenfield-Projekte selten — die meisten Neu-Implementierungen wählen iPaaS oder eine Event-Streaming-Plattform (Apache Kafka, Confluent). Bestehende ESB-Installationen laufen in vielen DACH-Konzernen jedoch weiter und werden schrittweise migriert.

Microsoft BizTalk Server zum Beispiel ist seit 2020 nur noch in Long-Term-Support; SAP PI/PO wird mittelfristig durch SAP Integration Suite abgelöst. Eine vollständige Ablösung dauert in der Praxis 3–7 Jahre, da Hunderte Integrations-Flüsse migriert und neu getestet werden müssen.

Welche EAI-Patterns sollte man als ERP-Verantwortlicher kennen?

Vier Patterns decken den Großteil der Praxis ab: Message-Queue für entkoppelte asynchrone Übergabe (Auftrag in Queue, ERP konsumiert), Publish/Subscribe für Event-Verteilung an mehrere Konsumenten (Stammdaten-Änderung an CRM und Webshop gleichzeitig), Request/Reply für synchrone Abfragen (Verfügbarkeits-Check), Orchestrierung für mehrstufige Geschäftsprozesse (Auftrag → Bonitäts-Prüfung → Reservierung → Bestätigung).

Das Standard-Referenzwerk ist „Enterprise Integration Patterns" von Hohpe und Woolf (2003) — die dort beschriebenen 65 Patterns sind in jedem modernen iPaaS-Tool als Bausteine wiederzufinden.

Welche EAI-/iPaaS-Anbieter sind im DACH-Mittelstand etabliert?

Im klassischen EAI-Segment mit On-Premises-Wurzeln: SEEBURGER (Bretten), Lobster_data (Pöring), X4 BPMS (SoftProject, Ettlingen), IBM App Connect, Software AG webMethods. Im Cloud-iPaaS-Segment: Boomi (Dell), MuleSoft (Salesforce), SAP Integration Suite, Microsoft Logic Apps und Power Automate, Workato, Celigo, ecosio (Wien, EDI-fokussiert).

Wahl-Treiber sind in der Praxis ERP-Konnektor-Verfügbarkeit, EU-Rechenzentrum, deutschsprachiger Support und etablierte DACH-Implementierungs-Partner.

Wann lohnt sich Open-Source-EAI (Apache Camel, n8n) statt kommerziellem iPaaS?

Open-Source ist tragfähig, wenn ein internes Plattform-Team mit operativer Reife vorhanden ist. Apache Camel ist im Enterprise-Umfeld seit über 15 Jahren produktiv im Einsatz; n8n eignet sich für Low-Code-Flüsse und wächst auf mehrere tausend Flows pro Tag.

Trade-off: niedrigere Lizenzkosten, höhere Betriebsverantwortung — Monitoring, Patching, Skalierung, SLA und 24/7-Bereitschaft liegen beim eigenen Team. Mittelständler ohne dedizierte Integrations-Mannschaft wählen typischerweise kommerzielle iPaaS-Plattformen wegen Support-SLA.