Events - Die Lösung aller Probleme der Software-Produktentwicklung?!

Die Entwicklung von komplexen Softwareprodukten ist kein einfaches Unterfangen. Jeder Entwicklungsleiter, Product Manager oder auch Product Owner weiß das sehr genau. Kundenspezifische Sonderwünsche mit einer Produktstrategie zu vereinen ist eine ständige Zerreißprobe. Über viele Jahre gewachsene Strukturen machen selbst die kompetentesten Entwicklungsteams immer langsamer und die Umsetzung neuer Features wirkt zunehmend schwerfälliger. Oft wünscht man sich die Leichtigkeit eines Start-ups in der die Code-Basis noch überschaubar ist und man schnell und einfach neue Dinge umsetzen sowie an Kunden ausliefern kann.

In den letzten Jahren konnte man beobachten, dass Events oder Event-basierte Architekturen immer populärer werden. Die Nutzung dieser Konzepte verspricht Skalierbarkeit und Erweiterbarkeit. Bei allen großen Cloud Anbietern stehen Managed Services bereit, um uns bei der Umsetzung von Anwendungen auf Basis dieser neuen Paradigmen zu helfen. Auch die Cloud-Infrastrukturen basieren auf den gleichen Konzepten.

Diese Entwicklung wirft verschiedene Fragen auf. Kann ich als Softwareprodukthersteller diese Mechanismen in meinem Alltag nützlich einsetzen? Helfen sie dabei meine typischen Probleme (flexible Erweiterbarkeit, unbefriedigende Entwicklungsgeschwindigkeit) zu adressieren? Wie genau funktionieren Event-basierte Ansätze? Welche Nachteile oder Fallstricke sind zu erwarten?

Diese Fragen beschäftigen uns seit einiger Zeit sehr intensiv und das möchten wir zum Anlass nehmen unsere Erkenntnisse hier mit Euch zu teilen. Los geht’s!

Events – Was ist das eigentlich genau?

Unter Events verstehen wir Geschäftsereignisse, d. h. Dinge, die in der (realen) Welt passieren bzw. passiert sind. Beispiele können sein: ich habe eine Yogamatte bestellt, ich habe meine Online-Banking App auf dem Smartphone geöffnet, mein Notebook Akku ist leer oder der Drucker hat keinen gelben Toner mehr. Hier ist es wichtig zu betonen, dass wir uns hier nicht auf (technische) Nachrichten beschränken, die z. B. in Messaging Queues abgelegt werden. Obwohl das eine mögliche Option für die technische Umsetzung von Event-basierten Architekturen ist, wäre die Einschränkung zu stark.

Genau betrachtet sind Events die elementaren Bestandteile, aus denen alle Geschäftsprozesse bestehen. Egal welchen Prozess man betrachtet, er lässt sich als Folge von Ereignissen/Events beschreiben. Events sind also primär fachliche Elemente, die überall existieren – und sich u. U. in einer technischen Realisierung wiederfinden.

Diese Dualität zwischen Fachlichkeit und Technologie ist Teil jeder Softwareproduktentwicklung. Fachliche Anforderungen müssen technisch umgesetzt werden. Der Charme von Events besteht aber genau darin, dass man das gleiche Konzept für beides nutzen kann. Statt fachliche Anforderungen „nur“ in Prosa oder groben User Stories zu formulieren, können sich Events potenziell in einem Anforderungsworkshop und im Code in sehr ähnlicher Form wiederfinden. Die Kluft zwischen Anforderungen und Umsetzung wird kleiner. Klingt gut? Dann schauen wir einmal an wie das praktisch aussieht.

Events in der Anforderungsanalyse

Die Erfassung und Dokumentation von Anforderungen ist schon immer eine Herausforderung. Allein die Beteiligung von unterschiedlichen Stakeholdern (z. B. Kunden, Fachexperten, Entwicklern, Produktmanagern) zwingt uns zwangsläufig dazu eine Sprache zu finden, die alle verstehen und eine Methode zu nutzen, mit der alle arbeiten können. Dabei gilt: Je einfacher, desto besser.

Nutzt man Events bei der Kommunikation zwischen diesen Stakeholdern beschränkt man sich automatisch auf die einfachste Art fachliche Abläufe zu diskutieren. Die Fragen „Was passiert zuerst?“, „Was passiert danach?“ und „Was könnte noch alles passieren?“ kann prinzipiell jeder beantworten und verstehen. Es ist kein technisches Know-how notwendig und doch werden alle notwendigen Informationen eingesammelt. Prozessschritte werden erfasst. Ausnahmen werden dokumentiert. Gleichzeitig werden Begrifflichkeiten eindeutig definiert und Missverständnisse beseitigt. Doch wie geht das praktisch?

Im einfachsten Fall bedient man sich der Methode „Event Storming“, bei der man im Rahmen eines Workshops mit allen Stakeholdern möglichst viele Post-its mit Ereignissen beschriftet. Danach ordnet man die Post-its auf einer Zeitleiste an und diskutiert den Geschäftsprozess entlang dieser Zeitleiste. Dabei wird automatisch klar, falls Begriffe unterschiedlich verwendet werden oder Events unklar sind. Die Teilnehmenden erarbeiten ein tiefes, gemeinsames Verständnis der Fachlichkeit. Entwickler verstehen besser was fachlich abläuft. Fachexperten verstehen besser welche Fragen aus Entwicklungssicht geklärt werden müssen.

Am Ende eines solchen Event Storming Workshops entsteht also eine große Menge von Events und gemeinsames Prozess-Know-how. Das mag erst einmal sehr informell und weich klingen, aber nicht selten fehlt genau dieses Verständnis und führt zu riesigem Aufwand in der Zusammenarbeit zwischen Entwicklungs­abteilungen und Fachexperten. Nur wenn alle Stakeholder ihr Wissen einbringen können, kann ein sehr gutes Produkt entstehen. Die Einfachheit des Ansatzes ist hier eine große Stärke. Die Teilnehmer von Event Storming Workshops sind regelmäßig überrascht wie viel Wissen in diesem Format entsteht und vor allem ausgetauscht wird. Selbst wenn alle Beteiligten vorher der Meinung waren ein klares Bild zu haben, gibt es oft riesige Überraschungen wie weit die Vorstellungen tatsächlich auseinander lagen.

Mit einer langen Liste von Events ist die Entwicklungsabteilung jedoch noch nicht in der Lage fertige Software zu liefern. Um Anforderungen so weit zu konkretisieren, dass Code entstehen kann, sind weitere Schritte notwendig. Unter anderem muss geklärt werden, wie auf Events genau reagiert werden muss. Welche Daten sind notwendig? Wo und wie werden diese Daten abgelegt?

Um diese nächsten Schritte zu gehen, stehen weitere Event-zentrierte Methoden bereit. So hilft „Event Modeling“ dabei Ereignisse mit externen Systemen und Benutzeroberflächen in Verbindung zu bringen. Hier werden Fragen wie „Was passiert, wenn ein Benutzer den Button XYZ drückt?“ oder „Welches externe System muss informiert werden, wenn XYZ geschieht?“ beantwortet. So kann man sich schrittweise hin zu einem (gemeinsamen) Bild vorarbeiten bei dem klar wird, wie genau das Softwareprodukt oder ein neues Feature funktionieren soll. Ist dieses Bild klar, kann mit der technischen Umsetzung, d. h. dem Schreiben von Code begonnen werden. Allerdings sollte das möglichst koordiniert geschehen, d. h. es muss eine Architektur festgelegt werden, die sicherstellt, dass jedes Stück Code seinen definierten Platz hat und neuer Code leicht hinzugefügt werden kann. Und auch hier können uns Events helfen.

Event-basierte Architekturen

Gute Softwarearchitekten zu finden ist genauso wichtig wie herausfordernd. Sie beeinflussen den Erfolg einer Softwareproduktfirma maßgeblich. Sie stellen die technischen Weichen für die nächsten Jahre. Ein, zwei falsche Entscheidungen können später ganze Entwicklungsmannschaften in die Verzweiflung treiben und demotivieren, ja den Erfolg der Firma in Gänze gefährden.

Die Implikationen von Architekturentscheidungen sind so weitreichend, weil eine Code-Basis nur noch schwer zu ändern ist, wenn sie einmal groß und eng gekoppelt ist. Wer schon einmal einen Monolith mit ein paar Millionen Zeilen Code verstehen oder verändern wollte, kann das sicher einfach nachvollziehen. Doch was helfen uns Events an dieser Stelle?

Events – wenn sie richtig benutzt werden – kehren eine wichtige Sache beim Denken und Implementieren um. Events beziehen sich immer auf die Vergangenheit. Sie drücken aus, dass etwas passiert ist. Sie drücken nicht aus, dass etwas passieren soll. Dies mag wie ein marginaler Unterschied klingen, aber für eine Softwarearchitektur ist das ein riesiger Unterschied. Statt anderen Komponenten mitzuteilen was diese machen sollen (z. B. „Bitte sende eine E-Mail mit einem neuen Passwort an Nutzer XYZ“) fokussieren sich Events darauf es anderen Komponenten zu erlauben auf etwas zu reagieren (z. B. „Ein neuer Benutzer hat sein Passwort vergessen“).

Durch die Kommunikation von Dingen, die bereits passiert sind, lässt eine Event-basierte Architektur es zu, dass (neue) Komponenten auf Ereignisse reagieren können (und müssen) statt diese explizit aufzurufen oder zu informieren. Die Umkehrung dieser Verantwortlichkeit ist der Schlüssel zu Erweiterbarkeit und weniger Abhängigkeiten.

Event-basierte Architekturen entkoppeln Komponenten sehr stark voneinander. Das allein ist schon eine überragende Eigenschaft dieses Architekturmusters. Doch sie tun das nicht nur an beliebigen technischen Grenzen, sondern an fachlichen und damit logischen Grenzen. Sie entkoppeln also genau dort, wo es später fachliche Erweiterungen oder Veränderungen geben wird. Wir nennen das fachliche Sollbruchstellen. Es entsteht eine Landschaft aus Komponenten, die fachlich voneinander abgegrenzt sind. Das ist nicht neu (siehe auch Domain-driven Design), aber trotzdem positiv anzumerken.

Wenn eine Event-basierte Architektur so flexibel ist, bleibt ja eigentlich nur noch die Frage wie man sie umsetzen kann. Gibt es hier fertige Frameworks oder Managed Services? Sind diese Technologien produktionsreif?

Events technisch umsetzen

Zuerst die gute Nachricht: Events sind auf technologischer Ebene seit vielen Jahren in den verschiedensten Variationen verfügbar. Nahezu jedes weit verbreitete Framework bietet Möglichkeiten an Events auszutauschen. Egal ob Java, .NET oder ein anderes Ökosystem – alle bieten Mechanismen an, um Events innerhalb von Prozessen oder auch über Prozessgrenzen hinweg auszutauschen. Alle großen Cloud-Anbieter haben Managed Services, um mit Events zu arbeiten (Message Queues, Event Broker etc.). Man muss also hier nichts selbst entwickeln. Es steht alles bereit.

Die Schwierigkeit bei der technischen Umsetzung besteht vielmehr darin, dass die Verarbeitung von Events oft verteilt passieren soll und, dass damit (naturgemäß) alle Probleme, die ein verteiltes System mit sich bringt auf einmal auch relevant werden. Transaktionshandling, Eventual Consistency, Asynchrone Kommunikation, Delivery Guarantees und vieles mehr müssen betrachtet und gelöst werden.

Für alle diese Themen gibt es bewährte Muster und Vorgehen. Allerdings müssen Entwicklungsteams dafür sensibilisiert werden, diese Muster zu lernen und richtig anzuwenden. Da verteilte Systeme sehr viel mehr Fallstricke bieten als unverteilte, darf man diesen Aspekt nicht unterschätzen. Gerade wenn ein Team lange mit bzw. an einem Monolith gearbeitet hat und sich nun umstellen muss, kann es hier zu unerwarteten Problemen kommen. Kommunikation über Prozessgrenzen hinweg ist eben substanziell anders als ein lokaler Methodenaufruf.

Sind Events nun eine Lösung für alle meine Probleme oder nicht?

Die Verwendung von Events im Entwicklungsprozess hat für Software-Produkthersteller ein enormes Potential. Alle Erfahrungen aus unserer Zusammenarbeit mit unseren Kunden bestätigen diese Einschätzung.

Events als durchgängiges einfaches, verständliches Konzept zu verwenden, klingt nicht nur gut. Die Verwendung von Events hebt das gemeinsame Verständnis auf eine neue Ebene, auf der ein konsistentes und besseres Softwareprodukt entstehen kann. Dadurch, dass alle Stakeholder miteinander sprechen und sich auch verstehen können, wird das Produkt gemeinsam definiert und verbessert. So addiert sich die Expertise der Fachexperten und der Entwickler nicht nur, sondern beide Gruppen können sich gegenseitig stimulieren.

Auch die Verwendung von Events bei Architektur und technischer Umsetzung birgt viele Vorteile. Erweiter­barkeit und Anpassung sind inhärent in diesem Architekturstil eingebaut. Die Umkehrung der Verantwortlich­keiten forciert eine lose Kopplung und vermeidet riesige untrennbare Komponenten per Design. Noch dazu ist die technische Infrastruktur überall frei - in Form von Frameworks oder als Managed Service - verfügbar.

Lediglich bei der Umsetzung von verteilten Event-basierten Architekturen ist Vorsicht geboten. Die Herausforderungen, die die Verteilung mit sich bringt, sind nicht auf die leichte Schulter zu nehmen. Hier ist es wichtig Teams zu schulen, um das notwendige Know-how aufzubauen. Das gilt genauso für die Verwendung von Events bei der Anforderungsanalyse. Der explizite Aufbau von technischem Know-how wird gerne unterschätzt, weswegen wir hier noch einmal darauf hinweisen wollen.

Fazit

Wenn Ihr ein Softwareprodukt herstellt, konnten wir Euch hiermit hoffentlich ein paar Anregungen geben, welche Möglichkeiten und Vorteile Events für Euch bieten können. Events sind sicher nicht die Lösung für alle Eure Probleme, aber sie bieten unheimliches Potential an vielen essenziellen Punkten maßgebliche Verbesserungen herbeizuführen.

Wenn Ihr mehr erfahren oder weiter diskutieren wollt, kontaktiert uns gerne und wir kommen ins Gespräch. Wir freuen uns darauf!