Eine effiziente und schlanke Verbindung einzelner Services bzw. Softwarekomponenten ist wohl der Wunsch in jedem Unternehmen. Doch häufig ist die Umsetzung schwierig: Gewachsene Systeme, fehlende Ressourcen und auf andere Projekte verplante Mitarbeiter sind nur einige Gründe, die dafür sorgen, dass neue Prozesse häufig mit starken Abhängigkeiten vieler Systeme innerhalb der Softwarearchitektur implementiert werden.
Das Ergebnis davon ist eine immer stärker werdende Abhängigkeit dieser Systeme und eine Softwarearchitektur, deren Schema Ähnlichkeit mit einem Ball hat. Kurz: Das Ergebnis ist genau das Gegenteil des frommen Wunsches.
Eine gute Möglichkeit das Ziel einer effizienten und schlanken Verbindung zu ermöglichen und wenigstens einige der oben genannten Stolpersteine aus dem Weg zu räumen, ist der Ansatz der ereignisgesteuerten Architektur (event driven architecture).
Sämtliche softwaregestützten Unternehmensprozesse werden in diesem Architekturansatz ohne limitierende Abhängigkeiten flexibel und ereignisgesteuert – möglichst in Echtzeit – über eine Middleware gesteuert. Schauen wir uns die ereignisgesteuerte Architektur genauer an.
Schematischer Aufbau des Architekturmodells
Die Kommunikation in einer event driven architecture verläuft im Gegensatz zu anderen Architekturmodellen asynchron. Über eine Middleware als Mediator – in der Regel handelt es sich um einen Message Broker – wird der Austausch der Events / Ereignisse in Form von Nachrichten orchestriert.
Eine Nachricht beschreibt jeweils ein Event, d. h. ein für andere Services relevantes Ereignis innerhalb oder außerhalb des Systems. Als Voraussetzung für ein erfolgreiches Processing muss die Nachricht alle relevanten Daten enthalten. Weitere benötigte Daten stellt der Service, der die Nachricht verarbeitet, selbst zur Verfügung.
Um dies zu gewährleisten wird ein konkretes Event-Schema definiert, welches sicherstellt, dass jedes Event die unbedingt notwendigen Informationen beinhaltet.
Als Sender der Nachrichten erwartet der Mediator keine Rückmeldung bzw. nimmt keinen Einfluss darauf, welcher Service einer Anwendung ein Event verarbeitet. Seine Aufgabe ist es, die Nachricht den lose gekoppelten Services der Anwendungen zur Verfügung zu stellen. Es ist möglich, dass das Event von mehreren Services verarbeitet wird, die für Ereignisse des jeweiligen Typs registriert sind.
Das Event selbst ist nichts weiter als die Änderung eines Systemzustandes. Beispiele sind Auftragseingänge, Transaktionen oder Fehlermeldungen. Grundsätzlich können Events gespeichert werden. Welche Ereignisse permanent gespeichert werden, hängt wesentlich von ihrer Signifikanz ab. Viele Ereignisse sind temporär relevant und besitzen eine vordefinierte Gültigkeitsdauer. Nach Ablauf dieser werden sie gelöscht.
Für den Erfolg einer event driven architecture in einem Unternehmen ist Idempotenz (Eigenschaft einer Methode, dass sie nach mehrmaliger Verwendung die gleichen Ergebnisse liefert wie bei der ersten Anwendung) essentiell. Das mehrfache Lesen eines Events durch einen Service darf nicht zur Folge haben, dass das Event mehrfach verarbeitet wird. Die Daten des Events selbst sind nicht veränderbar. Ändert sich der Status, ist ein neues Event mit dem veränderten Datensatz zu erzeugen. Nun können sich für Events dieses Typs registrierte Komponenten die Nachricht abholen. Das Duplizieren von Daten bzw. die Erzeugung von Redundanzen stellt im Rahmen ereignisgesteuerter Architekturen kein Problem dar.
Ein Beispiel für einen Prozess mit event driven architecture
Schauen wir uns einen Auftragseingang aus einem Webshop beispielsweise genauer an.
Sobald der Middleware die Information vorliegt, dass ein neuer Auftrag eingegangen ist, kann sie das Auftragsereignis als Nachricht zur Verfügung stellen. Das System, dass für den Versand des Auftrags zuständig ist, kann sich nun diese Nachricht in sein System abspeichern und für die systemeigenen Prozesse verwenden.
Ist der Auftrag versendet, so kann in der Middleware eine Nachricht darüber bereitgestellt werden, die dann z.B. vom Webshop verarbeitet wird, um im “Mein Konto”-Bereich anzuzeigen, dass der Versand erfolgt ist.
Ebenso wäre es möglich, dass sich das Fakturasystem beide Nachrichten ebenfalls abspeichert, um darauf basierend die Rechnung des Auftrages zu erstellen und nach dem Versand des Auftrages ebenfalls zu versenden.
Sowohl der Webshop, als auch das Versandsystem und das Fakturasystem haben in unserem Beispiel keine direkte Schnittstelle zueinander, alle Nachrichten werden über den Mediator bereitgestellt.
Entkopplung einzelner Anwendungen zur effizienteren Umsetzung neuer Prozesse
Einer der größten Vorteile der event driven architecture liegt in der hohen Abstraktionsfähigkeit des Ansatzes und der Entkopplung einzelner Anwendungen/Softwarekomponenten.
Die schematische Darstellung der einzelnen Softwarekomponenten aufgeteilt in Services und ihrer Vernetzung über die Middleware vermittelt einen guten Überblick über bestehende Informationssysteme sowie den unternehmensinternen und unternehmensübergreifenden Informationsfluss. Neue Mitarbeiter oder externe Dienstleister können so schneller das große Ganze erfassen und sind schneller fähig neue Konzepte für die Unternehmensprozesse zu erarbeiten.
Ebenso ist es durch die klare Struktur und Aufgabenverteilung der Systeme möglich neue Prozessanforderungen in den dafür vorgesehenen Systemkomponenten zu verorten und so alle notwendigen Projektbeteiligten zu identifizieren. Wird ein neuer Prozess implementiert behält jede Komponente ihre Autonomie und geht mit Ereignissen so um, wie es ihre Routinen vorgeben und kann die Anforderungen unabhängig von anderen Komponenten umsetzen.
Fällt ein Service aus, beschränkt es sich auf ein lokales Problem. Einzelne Geschäftsprozesse können bei Bedarf auf mehrere Komponenten aufgeteilt werden, was eine signifikante Prozessverbesserung durch schnellere Informationsverarbeitung zur Folge hat.
Je nach vorhandener IT-Architektur und der Managementstruktur eines Unternehmens ist der fachliche und technische Aufwand der Umstellung auf eine eventbasierte Architektur mehr oder weniger groß. Wer auf einer Meta-Ebene fachliche Agilität in sein Unternehmen integrieren und Schritt für Schritt weg vom etablierten, klassischen Prozessmanagement-Modell oder gar einem gewachsenen System möchte, trifft mit der Implementierung einer übergeordneten, eventbasierten Softwarearchitektur häufig eine gute Wahl.
Wettbewerbsvorteile und Prozessoptimierungen durch Analysen generieren
Neben der Umsetzung von Unternehmensprozessen bietet eine event driven architecture noch einen nutzenbringenden Nebeneffekt. Die generierten Nachrichten erhalten Unmengen an Informationen, deren Auswertung wertvolle Erkenntnisse bringen und auch genutzt werden kann.
Diese Informationen können dann als Grundlage für softwarebasierte und von Mitarbeitern getroffene Entscheidungen dienen und somit beispielsweise Wettbewerbsvorteile bringen. Ereignisse können demzufolge automatisch weiterverarbeitet, publiziert oder relevanten Personengruppen zur Verfügung gestellt werden. Durch ein sogenanntes Event Filtering nach bestimmten Kriterien grenzt die Anzahl an Ereignissen ein und sorgt für ein schnelleres, zielgerichtetes Processing.
Fazit
Die Implementierung von Event Driven Architecture in einem Unternehmen ergibt sich oft aus der Notwendigkeit einer höheren Flexibilität und dem Wunsch nach effizienten Prozessen. Das übergeordnete bzw. überbetriebliche Konzept kann bestehende serviceorientierte Softwarearchitekturen ergänzen und dort verbessern, wo sich Defizite in der Verarbeitung von Ereignissen zeigen. Softwareanwendungen können unabhängig voneinander betrachtet und jeweils im eigenen Tempo mit eigenen Prioritäten weiterentwickelt werden. Durch die Implementierung einer ereignisbasierten Architektur können sich somit die Umsetzung neuer Prozesse verbessern sowie direkt und indirekt Leistungs- und Wettbewerbsvorteile eines Unternehmens ergeben. Bestehende Systeme komplett durch eine ereignisgesteuerte Architektur zu ersetzen, kann sich als sinnvoll und langfristig rentabel erweisen.
Interessieren Sie sich für weitere Informationen zum Thema event driven architecture? Dann sollten Sie unser Webinar zum Thema nicht verpassen. Anlässlich der #diwodo20 (Digitale Woche Dortmund) teilen wir mit Ihnen unsere Erfahrungen zur ereignisgesteuerten Architektur und weisen auf Stolpersteine hin. Wir erklären Ihnen konkret an Beispielen, welchen Mehrwert der Ansatz Ihnen bietet und welchen Impact er auf die Entwicklung und Organisation haben kann. Weitere Informationen - auch zur Anmeldung - finden Sie hier.
