Event-basierte Architektur richtig einsetzen: Warum nicht jede Integration ein Event braucht.

Die event-basierte Architektur gehört aktuell zu den meistdiskutierten Architekturansätzen im Integrationsumfeld. Spätestens mit der Einführung der SAP Integration Suite, der Ablösung von SAP PI/PO oder der Einführung eines Event Brokers wie SAP Event Mesh stellt sich in vielen Unternehmen dieselbe Frage: Sollten künftig alle Integrationen event-basiert umgesetzt werden?

Die Motivation dahinter ist nachvollziehbar. Event-basierte Ansätze versprechen eine lose Kopplung zwischen Systemen, eine bessere Skalierbarkeit und die Möglichkeit, neue Anwendungen schneller in bestehende Landschaften zu integrieren. In der Praxis erleben wir jedoch regelmäßig, dass aus einer sinnvollen Technologieentscheidung schnell die Erwartung entsteht, künftig jede Schnittstelle über Events abzubilden. An dieser Stelle lohnt sich ein genauer Blick auf die fachlichen und technischen Anforderungen.

Wenn das neue Werkzeug plötzlich jedes Problem lösen soll

In Kundenprojekten beobachten wir häufig ein ähnliches Muster. Entweder wird die SAP Integration Suite eingeführt und die neu verfügbaren Services sollen möglichst breit genutzt werden oder bestehende PI/PO-Landschaften werden modernisiert. In anderen Fällen wurde bereits in einen Event Broker investiert, etwa in SAP Event Mesh oder Solace und nun soll die Investition möglichst umfassend genutzt werden.

Mit dieser Ausgangssituation gehen oft hohe Erwartungen einher. Viele Unternehmen verbinden eine event-basierte Integration mit niedrigeren Integrationskosten, einer vereinfachten Systemlandschaft und weniger Abhängigkeiten zwischen Anwendungen. Diese Annahmen sind jedoch nur teilweise richtig. Denn die Einführung eines Event Brokers löst Architekturprobleme nicht automatisch. Tatsächlich entstehen oft neue Fragestellungen, die in der ursprünglichen Betrachtung nicht berücksichtigt wurden.

Warum Event Mesh nicht automatisch Komplexität reduziert

Nicht jedes System spricht Events

Eine wichtige Erkenntnis aus zahlreichen Integrationsprojekten lautet: Die Integrationsfähigkeit eines Systems bestimmt maßgeblich die Architektur. Während moderne Cloud-Anwendungen häufig APIs und Event-Schnittstellen bereitstellen, kommunizieren viele Bestandsanwendungen noch immer ausschließlich über synchrone Schnittstellen, klassische Nachrichtenformate oder proprietäre Integrationsmechanismen. Wenn ein Zielsystem keine Events verarbeiten kann, entsteht zusätzlicher Aufwand für Adapter, Konvertierungen oder Integrationslogik. Die gewünschte Vereinfachung bleibt dann häufig aus.

Der Event Broker wird zur zusätzlichen Plattform

Ein weiterer Aspekt wird in frühen Diskussionen oft unterschätzt. Ein Event Broker ist nicht nur ein technischer Transportkanal, sondern eine zusätzliche Plattform, die betrieben und überwacht werden muss. Themen wie Monitoring, Fehleranalyse, Event-Retention, Dead-Letter-Queues, Berechtigungen und Governance gewinnen an Bedeutung. Die Komplexität verschwindet also nicht. Sie verschiebt sich lediglich an eine andere Stelle der Architektur. Das bedeutet nicht, dass Event Broker kompliziert oder problematisch sind. Es bedeutet lediglich, dass die Entscheidung für eine event-basierte Integration immer auch betriebliche Anforderungen mit sich bringt.

Thin Events sind häufig nur der Anfang

Besonders im SAP-Umfeld führt ein weiterer Punkt regelmäßig zu Missverständnissen. Viele SAP S/4HANA Standard Events werden als sogenannte Thin Events bereitgestellt. Sie enthalten oft lediglich technische Informationen sowie die Identität des betroffenen Geschäftsobjekts, beispielsweise die ID eines Geschäftspartners, Kunden oder Materials. Die eigentlichen Geschäftsdaten befinden sich weiterhin im Quellsystem. Ein Konsument, der weitere Informationen benötigt, muss diese anschließend über eine API abrufen. Aus einem vermeintlichen „Event statt API“-Szenario wird dadurch häufig ein „Event plus API“-Szenario. Gerade für Architekten ist diese Unterscheidung wichtig. Die Einführung einer Event-Plattform ersetzt APIs nicht automatisch. In vielen Fällen ergänzen sich beide Integrationsmuster sinnvoll.

Wo eine event-basierte Architektur ihre größten Stärken ausspielt

Trotz dieser Einschränkungen gibt es zahlreiche Szenarien, in denen eine event-basierte Architektur ihre Vorteile hervorragend ausspielen kann. Ein typisches Beispiel ist die Verteilung von Änderungen an mehrere Empfängersysteme.

Wird beispielsweise ein Geschäftspartner in SAP S/4HANA geändert, interessieren sich möglicherweise mehrere Systeme gleichzeitig für diese Information. Ein CRM-System benötigt die aktualisierten Stammdaten, eine Marketing-Plattform möchte Zielgruppen aktualisieren, ein Analytics-System verarbeitet die Änderungen für Auswertungen und eine Eigenentwicklung führt weitere Folgeprozesse aus. Ohne Event-basierte Integration müssten diese Systeme häufig einzeln angebunden werden.

Mit einem Event Broker veröffentlicht das Quellsystem eine Änderung lediglich einmal. Alle interessierten Systeme können das Ereignis abonnieren und unabhängig voneinander verarbeiten. Gerade bei Echtzeit-Szenarien mit mehreren Konsumenten entsteht dadurch ein hoher Mehrwert. Neue Anwendungen lassen sich später ergänzen, ohne bestehende Schnittstellen verändern zu müssen. Hier entsteht die oft zitierte lose Kopplung tatsächlich in der Praxis.

APIs, Prozessintegration und Events ergänzen sich

Eine häufige Fehlannahme besteht darin, Integrationsmuster gegeneinander auszuspielen. Tatsächlich erfüllen APIs, Prozessintegration und Events unterschiedliche Aufgaben. Eine hilfreiche Faustregel lautet:

APIs beantworten Fragen. Events informieren über Veränderungen.

Wenn ein Webshop den aktuellen Preis eines Produkts benötigt oder eine mobile Anwendung Stammdaten abfragen muss, erwarten die Konsumenten eine direkte Antwort. In solchen Szenarien sind APIs weiterhin die richtige Wahl. Ähnlich verhält es sich bei Benutzerdialogen in Fiori-Anwendungen, bei Kundenportalen oder bei externen Partneranbindungen. Überall dort, wo eine unmittelbare Reaktion erforderlich ist, bleibt synchrone Kommunikation unverzichtbar. Auch klassische Prozessintegration behält ihre Bedeutung. Genehmigungsprozesse, mehrstufige Workflow-Abläufe oder komplexe Orchestrierungen benötigen häufig eine zentrale Prozesssteuerung mit definierten Status- und Fehlerbehandlungen. Die richtige Frage lautet daher nicht, welches Integrationsmuster moderner ist, sondern:

Welches Integrationsmuster erfüllt die Anforderungen des konkreten Use Cases am besten?

Fazit

Die Diskussion über event-basierte Architektur wird häufig zu technisch geführt. Die eigentliche Architekturentscheidung sollte jedoch immer vom fachlichen Nutzen ausgehen. Event Mesh und andere Event Broker bieten enorme Vorteile, wenn mehrere Systeme in Echtzeit auf Änderungen reagieren sollen und eine lose Kopplung gewünscht ist. Gleichzeitig gibt es zahlreiche Szenarien, in denen APIs oder klassische Prozessintegration die bessere Wahl bleiben. Unsere Projekterfahrung zeigt daher immer wieder dasselbe Muster: Erfolgreiche Integrationsarchitekturen setzen nicht auf ein einziges Integrationsparadigma. Sie kombinieren Events, APIs und Prozessintegration dort, wo die jeweiligen Stärken am besten zur Anforderung passen.

Wenn Sie aktuell die SAP Integration Suite einführen, Ihre PI/PO-Landschaft modernisieren oder den Einsatz von SAP Event Mesh bewerten, unterstützen wir Sie gerne bei der Auswahl der passenden Integrationsarchitektur. Weitere Beiträge rund um SAP Integration Suite, API Management und Event-Driven Architecture finden Sie ebenfalls in unserem Blog.