Mit Event-Driven Architecture vorhandene Potenziale heben

Digitale Geschäftsmodelle und -prozesse etablieren, sie flexibel gestalten und Teile davon skalierbar machen, dies wollen heute immer mehr Unternehmen. Dafür bedarf es elastischer und schlanker Softwarekomponenten, die in Form von kleinteiligen Services untereinander verbunden werden. In der Realität vorherrschend sind jedoch monolithische Softwarearchitekturen, in denen Prozesse softwaretechnisch stark ineinandergreifen. Die dahinterliegenden IT-Systeme sind deshalb stark voneinander abhängig; Änderungen oder Neuerungen sind mit hohem Aufwand verbunden.

Digitale Geschäftsmodelle und -prozesse etablieren, sie flexibel gestalten und Teile davon skalierbar machen, dies wollen heute immer mehr Unternehmen. Dafür bedarf es elastischer und schlanker Softwarekomponenten, die in Form von kleinteiligen Services untereinander verbunden werden. In der Realität vorherrschend sind jedoch monolithische Softwarearchitekturen, in denen Prozesse softwaretechnisch stark ineinandergreifen. Die dahinterliegenden IT-Systeme sind deshalb stark voneinander abhängig; Änderungen oder Neuerungen sind mit hohem Aufwand verbunden.

Ein Ansatz, der mehr Flexibilität und Lösungsvarianten bietet, ist jener der ereignisgesteuerten Architektur (Event-Driven Architecture). Dabei werden ereignisbringende (Producer)- und ereignisnutzende (Consumer) Softwarekomponenten entkoppelt, so dass sie unabhängig voneinander skaliert, aktualisiert und eingesetzt werden können. Der Ansatz ist anpassungsfähig und für kleine ebenso wie für große, komplexe Anwendungen anwendbar. Nebeneffekt: Daten können asynchron und in Echtzeit verarbeitet werden.

Wie sieht eine ereignisgesteuerte Architektur nun im Einzelnen aus? Die Kommunikation darin verläuft im Vergleich zu anderen Architekturvarianten asynchron. Über eine Middleware – häufig in Form eines Message Brokers – wird der Austausch der Events in Form von Nachrichten orchestriert. Diese werden in Topics und Partitionen organisiert, wobei jedes Topic aus vielen Partitionen bestehen kann. Jede Partition ist eine geordnete, unveränderbare Abfolge von Nachrichten, in die neue Nachrichten mit der Zeit hinzugefügt werden. Eine Nachricht beschreibt jeweils ein Event, das heißt ein für andere Services relevantes Ereignis innerhalb oder außerhalb des Systems. Ereignisse können entweder den Zustand eines Datenobjektes beschreiben oder sie können Identifikatoren sein.

Grundsätzlich müssen die Nachrichten alle relevanten Daten enthalten, die ein erfolgreiches Prozessieren der Ereignisse ermöglichen, mit anderen Worten die für den Prozess oder Geschäftsvorfall notwendig sind. Etwaige darüber hinaus benötigte Daten stellt der Service, der die Nachricht verarbeitet, selbst zur Verfügung. Der Message Broker nimmt keinen Einfluss darauf, welcher Consumer einer Anwendung eine Nachricht verarbeitet. Seine Aufgabe ist es, die Nachricht den entkoppelten Consumer-Services der Geschäftsanwendungen zur Verfügung zu stellen. Nachrichten können auch von mehreren Consumern verarbeitet werden, sofern sie für Ereignisse des jeweiligen Topics registriert sind.

Den Nachrichten in einer Partition wird eine eindeutige ID zugewiesen („Offset“), die jede Nachricht innerhalb der Partition eindeutig identifiziert. Im Gegensatz zu anderen Messaging-Systemen müssen sich die Consumer selbst um die Verwaltung des Offsets kümmern, was aber auch einen großen Vorteil mit sich bringt: Normalerweise würde ein Consumer den Offset chronologisch abarbeiten, um eine Nachricht nach der anderen zu lesen. In diesem Fall kann aber der Offset bewegt und somit die Nachrichten in jeder beliebigen Reihenfolge gelesen werden. Durch diese Logik können beispielsweise Nachrichten mehrfach gelesen werden, falls Prozesse oder Datenflüsse erneut verarbeitet werden müssen.

Das Event selbst ist nichts weiter als die Änderung eines Systemzustandes, welche in einer Nachricht abgebildet wird. Beispiele sind Bestellungen, Warnmeldungen, Fehlermeldungen beziehungsweise Transaktionen aller Art. Events können persistiert werden. Welche Events permanent gespeichert werden, hängt wesentlich von ihrer Bedeutung ab. Viele sind temporär relevant und besitzen eine vordefinierte Gültigkeitsdauer, welcher in einer retention policy konfiguriert wird. Nach Ablauf dieser Dauer werden sie gelöscht. Dem gegenüber bietet die Apache-Kafka-Technologie die Möglichkeit, Daten auch längerfristig zu persistieren. Sollen Daten archiviert werden, greift man auf günstigere Alternativen, wie beispielsweise Object Stores, zurück.

Für den Erfolg einer Event-Driven-Architecture im Unternehmen ist es essenziell, dass das erneute Lesen eines Events durch einen Service nicht zur Folge hat, dass das Event mehrfach ungewollt verarbeitet wird. Die Daten eines Events selbst sind nicht veränderbar. Ändert sich der Status, ist ein neues Event mit dem veränderten Datensatz zu erzeugen. Anschließend können sich für Events dieses Typs registrierte Consumer die Nachricht abholen. Die Erzeugung von Redundanzen stellt im Rahmen ereignisgesteuerter Architekturen kein Problem dar. Mit Funktionalitäten wie beispielsweise log compaction wird die Datenmenge stark komprimiert.

Wie das Aufsetzen einer solchen Architektur in der Praxis funktioniert, lässt sich am Beispiel eines Use-Cases aus dem Umfeld E-Mobilität darstellen; hier aus der Perspektive eines E-Mobility Service Providers (EMP). Alle einzelnen Applikationen in diesem Beispiel sind nicht direkt miteinander verbunden!

Nachdem ein Electric Vehicle (EV) an einem öffentlichen Charge Point aufgeladen wurde, übermittelt der Betreiber der Ladestation eine Ladetransaktion an den EMP. Sobald diese Transaktion über eine Producer-Applikation der Middleware zugänglich gemacht wurde, kann sie das Ereignis als Nachricht zur Verfügung stellen. Die Anwendung, die für die korrekte Bepreisung des Ladevorgangs zuständig ist, kann nun diese Nachricht konsumieren, abspeichern und für die entsprechende Prozessierung verwenden.

Ist die Bepreisung erfolgt, kann ein neues Event mit Status „Bepreisung erfolgt“ entstehen, welches dann zum Beispiel von einem App-Backend verarbeitet wird, um die Ladetransaktion in der App des EV-Drivers anzuzeigen (mit Details wie zum Beispiel wann wo und wieviel geladen wurde). Parallel dazu kann das Fakturasystem das Event nutzen, um darauf basierend eine Rechnung zu erstellen. Wiederum parallel dazu können die Transaktionen über einen Analytics-Stream beispielsweise an eine Fraud-Detection-Anwendung transportiert werden, um Anomalien zu entdecken. Ferner lassen sich die Daten für Analysen des Ladeverhaltens nutzen, um die digitalen Produkte kundenfreundlicher zu gestalten.

Ein wichtiges Merkmal und zugleich wesentlicher Nutzen der Event-Driven Architecture ist das damit verbundene effektive Abstraktionsvermögen. Durch Abstraktion können Applikationen beziehungsweise Softwarekomponenten entkoppelt betrieben, entwickelt und skaliert werden. Die Aufteilung in Services und ihre Vernetzung über die Middleware vermittelt einen klaren Überblick über Daten- und Prozessflüsse. So lässt sich wesentlich schneller ein Gesamtbild aller Zusammenhänge erfassen. Neue Geschäftsmodelle können schneller etabliert, Prozesse verändert oder erweitert werden. Gleichzeitig unterstützt die Architektur ein agiles Projektmanagement, indem Aufgaben sehr kleinteilig geschnitten und die jeweils erforderlichen Projektbeteiligten treffsicher identifiziert werden. Resultat: Unternehmen können schnell und effektiv auf veränderte Märkte oder Umstände reagieren.

Naturgemäß fallen in Geschäftsprozessen beziehungsweise IoT-Anwendungen immens viele Daten an oder gesamte Geschäftsmodelle basieren auf den Daten selbst. Eine Event-Driven-Architecture eröffnet die Möglichkeit, Erkenntnisse in Echtzeit zu generieren, Ineffizienzen zu identifizieren, Anomalien zu entdecken, Prognosen zu rechnen, Scorings durchzuführen oder Live-Dashboards zu beliefern – das gesamte Spektrum der Data Analytics. So können datengetriebene Geschäftsmodelle etabliert und Entscheidungen automatisiert werden.

Zur Umsetzung einer ereignisgesteuerten Architektur gibt es inzwischen eine Vielzahl an Technologien:

Apache Kafka ist eine Plattform für verteiltes Data-Streaming und Event-Verarbeitung. Sie ist in der Lage, Event-Streams in Echtzeit zu veröffentlichen, abonnieren, speichern und zu verarbeiten. Das Produkt unterstützt eine Reihe von Use-Cases, bei denen es auf einen hohen Durchsatz und eine gute Skalierbarkeit ankommt. Dazu minimiert es die Notwendigkeit von Punkt-zu-Punkt-Integrationen für die gemeinsame Datennutzung in bestimmten Anwendungen und reduziert so die Latenzzeiten auf Millisekunden.

Bezugsmodelle:

Maschine-zu-Maschine-Kommunikation (M2M) und das Internet der Dinge (IoT) werden integriert, um die Automatisierung zu erhöhen, die Kommunikation und Selbstüberwachung zu verbessern und intelligente Maschinen zu produzieren, die Probleme analysieren und diagnostizieren können, ohne dass der Mensch eingreifen muss.

Diese Szenarien in der produzierenden Fertigung erfordern die Verarbeitung großer Datenmengen in Echtzeit. Unternehmenskritische Einsätze ohne Ausfallzeiten oder Datenverluste sind K.O.-Kriterien. Die Integration mit Edge-Geräten/Maschinen, IoT-Gateways, Unternehmenssoftware und vielen anderen Systemen ist entscheidend für den Erfolg. Eine offene, elastische und flexible Architektur wird zum Muss, um sich in die oftmals monolithische Realität zu integrieren, aber auch um zukunftsfähig zu sein für den Aufbau von cloud-native und hybriden Applikationslandschaften. Die Unterstützung der wichtigsten IoT-Standards wie OPC-UA und MQTT ist obligatorisch.

Pay-per-Use-Modelle im Maschinenbau

Im Maschinenbau werden Digitalisierungslösungen derzeit nur zögerlich umgesetzt. Gründe dafür sind ein sehr hoher Individualisierungsgrad für die Überwachung von Maschinen und Prozessen und der damit einhergehende Realisierungsaufwand sowie fehlende Möglichkeiten, die Informationen direkt in der jeweiligen Produktarchitektur wirtschaftlich zielführend einzusetzen. Eine Aufwand-Nutzen-Rechnung ist daher komplex. Darüber hinaus sehen sich Maschinen- und Anlagenbauer sowie Maschinenanwender vor der Herausforderung, einen sehr flexiblen Markt mit oftmals investitionsintensiven Maschinen und Anlagen bei komplexer werdenden Produktionsabläufen zu bedienen.

Diesen Herausforderungen lässt sich durch die Nutzung einer Einführungsmethode für Digitalisierungslösungen begegnen. So werden aus technisch-technologischer Sicht Methoden und Konzepte erarbeitet und erprobt, mit denen eine deutliche Flexibilitätssteigerung durch die Nutzung von Pay-per-X-Geschäftsmodellen auf Basis einer erweiterten Transparenz von Prozess und Maschine möglich wird. Somit ergeben sich die Handlungsfelder

Der Event-Driven Architecture Ansatz bietet alle dafür notwendigen Integrations- und Verarbeitungsvarianten von Daten.

Die Implementierung einer Event-Driven Architecture ergibt sich oft aus der marktgeforderten höheren Flexibilität, dem Wunsch nach effizienten Prozessen und der Operationalisierung neuer Geschäftsmodelle. Softwareanwendungen können entkoppelt werden, das heißt jeweils im eigenen Tempo mit eigenen Prioritäten neuentwickelt, weiterentwickelt sowie betrieben und skaliert werden. Durch die Verwendung einer Event-Driven Architecture werden vorhandene Potenziale gehoben, Wettbewerbsvorteile ausgebaut und neue datengetriebene Geschäftsmodelle ermöglicht.

Quelle: Matthias Bauer

Matthias Bauer ist seit 2020 Teamlead Data Science bei der X-INTEGRATE Software & Consulting GmbH (Teil der TIMETOACT GROUP) und bringt mehr als 15 Jahre Expertise als Solution Architect mit. Daten dafür nutzen, Großes zu schaffen und Mehrwerte zu erzielen – in seinen Worten: Data Thinking – ist seine Leidenschaft. Matthias ist erfahren in Artificial Intelligence, Data Science und Data Management; dabei bedient er von Data Warehousing bis hin zu Data Virtualization ein breites Spektrum an datenbezogenen Fragestellungen. 

Die X-INTEGRATE Software & Consulting GmbH ist IBM Premium-Partner und Spezialist für Business Integration Software auf Basis etablierter Methodik, offener Standards und IBM Middleware sowie Open Source Plattformen.