Event-driven Architecture – Pros und Contras?

Das Paradigma Event-driven Architecture (dt. Ereignisgesteuerte Architektur) wird seit den 70er Jahren für System-Analysen und -Designs eingesetzt. Die erste weitverbreitete Software Engineering Methode war der Standard SSADM (Structured Systems Analysis and Design Method) der britischen Regierung und wurde in den 90er Jahren von der UBS und anderen Schweizer Grossunternehmen adaptiert.

Eine der drei SSADM-Kerntechniken war Entity Event Modelling , welche (geschäfts-)systemrelevante Ereignisse und deren Auswirkungen auf Geschäftsprozesse und Datenbasen identifizierte, analysierte und modellierte – um daraus Anforderungen für neue Applikationen abzuleiten.

Damals wie heute werden mit dem Begriff «Event» drei Charakteristiken assoziiert: Es ist ein «Vorkommnis» innerhalb oder ausserhalb eines (Geschäfts-)Systems, welches

• für das System relevant ist und eine Reaktion erfordert,
• unbegrenzt oft auftreten kann und eine standardisierte Antwort erfordert,
• für eine bestimmte Zeit aufbewahrt werden muss.

Während die grundsätzliche Bedeutung von Events für jedes System evident ist, geben ihre Identifizierung, Priorisierung und Handhabung im Rahmen einer Event-driven Architecture heute noch – oder wieder – Anlass für kontroverse Diskussionen der Pros und Contras?

Common Event-driven Architecture Design Pattern [Reference]

Vor diesem Hintergrund will dieses SITIC Topic Forum einige Antworten zu den folgenden Leitfragen vermitteln:

1. Welchen Nutzen und Vorteile bietet eine Event-driven Architecture (EDA)?
2. Welche Voraussetzungen müssen für den Einsatz einer EDA erfüllt sein?
3. Welche Herausforderungen müssen bei Einsatz der EDA gemeistert werden?
4. Wie stellt man Governance sicher (Auffindbarkeit der Events, Evolution der Events)?
5. Macht es Sinn, (und falls ja, wann) Daten zu replizieren und redundant zu halten, mit welchem Kosten/Nutzen-Verhältnis?
6. Welche Plattformen bieten die geeignete Infrastruktur für EDA?
7. Wie gelingt der Mindshift von einer Command-orientierten in eine Event-orientierte Denkwelt?
8. Was sind die Grenzen der Event-Orientierung? Oder m.a.W.: Gibt es in der EDA-Welt noch Platz für ein Command Pattern, synchron oder auch asynchron?
9. Welche Alternativen gibt es zu einer Event-driven Architecture?

Willkommen sind Business IT Professionals, welche im Unternehmen Aufgaben der Digitalisierung, der digitalen Transformation, Unternehmens- und IT-Architektur wahrnehmen.

Pax, Schweizerische Lebensversicherungs-Gesellschaft AG
Aeschenplatz 13, 4002 Basel

Richard Huber, Leiter Solution Architecture
Damien Wieser, Solution Architecture

Fachliche Moderation: Markus Schacher, KnowGravity Inc.
Organisatorische Leitung: Kurt Wehrli, SITIC

13.00 – 13.15
Begrüssung durch Richard Huber und Damien Wieser, PAX
Eröffnung durch Kurt Wehrli, SITIC, und Markus Schacher, KnowGravity Inc.

13.15 – 13.50
Externe Keynote
Event-Driven Architecture – Definition, Motivation und Herausforderungen
Markus Schacher, KnowGravity Inc.

Eine Event-Driven Architecture (EDA) beschreibt einen Lösungsansatz, wie ein System aufgebaut sein soll, damit es effizient, angemessen und flexibel auf Ereignisse in seinem Umfeld reagieren kann. Die Art von Systemen, die durch eine EDA sinnvoll gesteuert werden können, reicht dabei von einer Waschmaschine bis hin zur Gesellschaft eines Staates. In diesem Einführungsvortrag werden kurz die Grundsätze und die wichtigsten Eigenschaften einer EDA sowie deren Herkunft aufgezeigt.

13.55 – 14.15
Keynote der Gastgeberin
Event-driven Architecture im Realitätscheck
Richard Huber und Damien Wieser, PAX

Trendige Architekturkonzepte und innovative Designparadigmen versprechen uns oft vollmundig eine schöne neue Welt. Im Falle der Event-driven Architecture gehört zu diesen Versprechen unter anderem eine Verbesserung in der Entkopplung von Anwendungen, in der Skalierbarkeit, in der Fehlerresilienz oder in der Erweiterbarkeit von Eventkaskaden.

Pax hat sich vor knapp zwei Jahren entschlossen, die Integration seines neu entwickelten Kundenportals mittels Event-driven Architecture zu realisieren. In der Zwischenzeit haben wir auch weitere Anwendungen in dieses Konzept aufgenommen. In einem Erfahrungsbericht betrachten wir nochmals die Vorteile, die wir uns zu Beginn unserer Reise erhofft haben und die uns zu diesem Schritt bewogen haben. Anschliessend analysieren wir, welche dieser Vorteile sich tatsächlich bemerkbar gemacht haben. Dort wo wir noch eine Lücke zwischen Erwartung und Realität sehen, spekulieren wir über die Gründe und darüber was es braucht, um diese Vorteile doch noch zu erreichen.

14.20 – 14.50
Interne Keynote
Umgang mit Events aus Business-Sicht
Dr. Andreas Spichiger, BK-DTI

Am Beispiel von «Heiraten» wird die Bedeutung eines guten fachlichen Umgangs mit Events klar. Über Jahrhunderte hat sich im Zivilstandswesen eine Regulation entwickelt, die nähere Betrachtung verdient. Insbesondere auch, weil dies klare Spezifikations- und Implementierungshinweise für andere Anwendungsfelder gibt.

Über Dr. Andreas Spichiger
Andreas Spichiger ist seit 1994 in verschiedenen Branchen und Firmen als Architekt tätig, zuletzt bei PostFinance und danach zehn Jahre an der Berner Fachhochschule als Leiter des E-Government-Instituts. Seit 2019 verantwortet er die Architektur der Bundesverwaltung.

14.50 – 15.20
Pause & Networking 

15.20 – 15.50
Erfahrungsbericht
Die Umsetzung der Cloud Events @BKW Referenzarchitektur
Maurice Bachor, BKW

Die BKW Cloudevent Referenzarchitektur beschreibt die Nutzung eines modernen Integrations-Patterns in der BKW. Sie setzt einen relativ leichtgewichtigen Standard zur Erzeugung system-übergreifender Prozesse. Ein Cloud-Event ist eine Spezifikation zur allgemeinen Beschreibung eines Ereignisses (siehe cloudevents.io). Allerdings gibt es dabei einige zu meisternde Herausforderungen wie das Tracing, Logging und Errorhandling bei asynchronen und verteilten Prozessen, wie auch die Denkweise der beteiligten Personen, welche sich erst an die neue Vorgehensweise gewöhnen müssen. Dieser Erfahrungsbericht zeigt Lösungsansätze auf und beschreibt die Referenzarchitektur.

Über Maurice Bachor
Maurice Bachor arbeitet seit 2013 bei der BKW als Teamleiter und Solution Architekt. Er initiierte die Entwicklung von nativen Cloud-Lösungen bei der BKW und setzt weiterhin voll auf die Cloud. Er leitet das Team für Cloud Services und Integration. Zuvor arbeitete als Solution Architekt, Consultant und Entwickler bei namhaften Anbietern von Informatikdienstleistungen.

15.55 – 16.25
Erfahrungsbericht
Commands, Events und Datastreams – Divide and Conquer in Microservice-Architekturen
Beat Winistörfer, Die Mobiliar

Das (Ver)teilen liegt in der Natur von Microservice-Architekturen. Business-Prozesse machen aber selten halt an den Microservice-Grenzen. In diesem Vortrag wird besprochen wie mit Commands, Events und Datastreams die Umsetzung von Business-Prozessen beherrscht werden kann, so dass schlussendlich ein konsistenter Zustand und hohe Verfügbarkeit erreicht werden. Und wie mit Fällen und Aufgaben die Benutzer dabei involviert werden und ihnen damit die Übersicht über die verteilten Prozesse ermöglicht wird.

Über Beat Winistörfer
Beat Winistörfer arbeitet seit über acht Jahren in der Applikationsarchitektur der Mobiliar als Domänenarchitekt Partner und Basisdienste sowie als Systemarchitekt in einem der Release Trains der agilen Software Delivery Organisation. In diesen Rollen beschäftigt er sich intensiv mit der Umsetzung von Business-Prozessen und den damit einhergehenden Anforderungen an die Arbeitsorganisation. Zuvor war er bei hp und rtc für die BEKB tätig, auch dort mit Schwerpunkt Business-Transaktionen. Er hat an der Universität Zürich Wirtschaftsinformatik studiert.

16.30 – 17.00
Erfahrungsbericht
Event-driven Architecture @ Baloise
Frank Baier, Basler Versicherungen

Vor zweieinhalb Jahren hat die Baloise Schweiz mit der Apache Kafka Einführung begonnen, Event-Driven Architecture als grundlegendes Architektur-Paradigma für domänenübergreifende Kommunikation zu etablieren. Eine zugrunde liegende Basisarchitektur definiert die groben Eckpfeiler, die grosse Akzeptanz erfährt. Doch es gibt auch Aspekte, welche die Frage aufwerfen, wo die Grenzen einer EDA liegen? Soll ein DWH via EDA integriert werden? Wie sollen Querschnittsysteme integriert werden, die bisher kein Branchen-Knowhow haben?

Über Frank Baier
Frank’s Rolle in der Baloise ist Integrationsarchitekt der IT-CH. Dabei unterstützt er in allen Fragen rund um Architektur und Design und leistet teamübergreifende Beratung. Zudem ist er bei der Einführung der neuen Schaden-Lösung aktiv und gestaltet die Integration von Guidewire Claims in die Baloise Landschaft mit.

17.00 – 17.20
Diskussion und Zusammenfassung im Plenum.
Take-Aways für die Leitfragen.

17.20 – 18.15
Networking beim Apéro

Verbindliche Anmeldung bitte via Email an kurt.wehrli@sitic.org

Für SITIC-Mitglieder ist die Teilnahme im Rahmen der Jahresmitgliedschaft unentgeltlich.
Nicht-Mitgliedern werden 375 CHF in Rechnung gestellt, der Zahlungseingang muss vor dem Sharing erfolgen.

Eine ereignisgesteuerte Architektur, engl. Event-driven Architecture (EDA), ist eine Software-Architektur, in der das Zusammenspiel der Komponenten durch Ereignisse gesteuert wird.

Ereignisse können sowohl von außen, z. B. durch Benutzereingaben oder Sensorwerte, als auch vom System selbst (z. B. Änderungs-Benachrichtigungen) ausgelöst werden.

Ein Ereignis kann Auslöser für eine Ereignisbehandlung sein, mit der das System reagiert. Eine ereignisgesteuerte Architektur hat kaum Kontrolle darüber, wann Daten verarbeitet werden. Ein einfaches Beispiel ist die grafische Benutzeroberfläche: Hier bestimmt der Benutzer, wann welche Daten verarbeitet werden, indem er Aktionen ausführt und damit Ereignisse auslöst.

Der Einsatz dieser Architektur setzt bei der Planung und Entwicklung voraus, dass alle Systeme, die an der Abwicklung des Ereignisses beteiligt sind, miteinander kommunizieren können. Typischerweise setzt die ereignisgesteuerte Architektur eine Definition voraus, was als Ereignis anzusehen ist. Dafür überwachen Computersysteme oder Sensoren den Status von Objekten und können gegebenenfalls ein Ereignis auslösen. Es folgen die Verarbeitung des Ereignisses nach definierten Regeln und die Folge des Ereignisses. Ist es während der Ereignisverarbeitung nicht möglich, sofort die definierte Folge des Ereignisses zu erzielen, wird das Ereignis im erreichten Status zwischengespeichert und erst dann weitergeführt, wenn die Folge erreicht werden kann.

Den größten Nutzen hat die ereignisgesteuerte Architektur, wenn sie bereits in der Planungsphase berücksichtigt wird. Bereits vorhandene Software auf eine ereignisgesteuerte Architektur umzustellen, kann mangels der benötigten Schnittstellen zu inakzeptablem Aufwand führen.

Die ereignisgesteuerte Architektur ergänzt die serviceorientierte Architektur, da Dienste durch Ereignisse ausgelöst werden können. Auf Basis der ereignisgesteuerten Architektur können insbesondere Systeme für ereignisgesteuerte Prozessketten entwickelt werden.

[Referenz]

An event-driven application is a computer program that is written to respond to actions generated by the user or the system. In a computing context, an event is any identifiable occurrence that has significance for system hardware or software. As such, events include both user-generated actions like mouse clicks and keystrokes and system-generated events such as program loading.

Event-driven programming separates event-processing logic from the rest of a program’s code. The event-driven approach contrasts with batch processing. Because event-driven programming is an approach rather than a type of language, event-driven apps can be created in any programming language. Depending on the specific application, event-driven processing can improve responsiveness, throughput and flexibility.

[Reference]