Wie Events helfen, erfolgreiche Softwareprodukte zu entwickeln

Die Entwicklung von Softwareprodukten hakt oft daran, dass die Fachexperten beim Beschreiben der Produktanforderungen unter sich geblieben sind. Die Fachexperten wissen zwar, wie ihr Business und dessen Prozesse funktionieren. Sie kennen genügend Stellen und Leistungsparameter, die zu verbessern wären. Oft wissen sie aber nicht, wie das technisch am besten umgesetzt werden kann und auf welche technischen Hürden ihre Wünsche möglicherweise treffen. Umgekehrt wissen die Softwareentwickler oft nicht, was das Feature bezwecken soll, das sie umsetzen. Möglicherweise wäre der Zweck viel einfacher zu erreichen. Die einen verwenden ihren fachlichen, die anderen ihre technischen Begriffe – es sind zwei Welten. Wenn man von Anfang an beide Perspektiven zusammenbringt, können Softwareentwickler und Fachexperten gemeinsam das zu lösende Problem entdecken. Sie können sich ein Vokabular und Verständnis der verwendeten Begriffe schaffen und schließlich einen Lösungsansatz entwerfen, der das fachliche Problem genau trifft.

In diesem Beitrag wollen wir Euch eine einfache und flexible Methode vorstellen, welche die fachübergreifende Kommunikation beflügelt. Sie kann vor allem in der Product Discovery eingesetzt werden, wenn sich aus einer Idee die Anforderungen für ein Softwareprodukt herausbildet, aber auch später im Entwicklungsprozess. Wir haben dazu mit Sven Richter von mind-to-matter gesprochen. Er arbeitet seit über 10 Jahren mit vielen Kunden aus den Bereichen E-Commerce, Automotive und Banken, Geschäftsideen schnellstmöglich (manchmal innerhalb von nur 6 Wochen!) in funktionierende Softwareprodukte umzusetzen. Er setzt Event Storming häufig als Werkzeug in der Produktentwicklung ein und moderiert dabei den Prozess.

Seine Antworten haben wir für Euch zusammengefasst:

Wie setzt ihr Events in der frühen Produktentwicklung ein?

Event Storming ist ein Workshop Format. Fachexperten und Softwareentwickler werden je nach Bedarf zu einem, manchmal auch zwei Tagen eingeladen. Vor Ort oder remote sind beide möglich. Wir starten mit einer Menge Post-Its und einer weißen Wand. Wir versuchen die wesentlichen fachlichen Ereignisse (Events), aus denen ein Geschäftsbereich oder -prozess besteht, in einer chronologischen Reihenfolge an die Wand zu bringen. Wir konzentrieren uns bewusst auf Ereignisse - auf das, was fachlich passiert -, um alle technischen Vorannahmen z. B. zu Systemen, Prozessen, Daten usw. zu vermeiden. Sonst bringt man schon zu viel Lösung mit ins Spiel. Vielleicht ist die Lösung aber viel einfacher. Wir wollen auch nicht alles mit komplexen Diagrammen oder Modellierungssprachen überladen.

Normalerweise arbeiten wir dabei in 3 Phasen. Ich vergleiche dies ganz gern mit dem Landeanflug in einem Flugzeug.

Phase 1 – Überflug: Wir befinden uns noch ganz weit oben und sehen Felder und Straßen.

In dieser Phase geht es darum, sich die fachliche Perspektive (Business Domäne) zu erschließen. Wie verläuft die "Geschichte" der Wertschöpfung? Die Fachexperten erklären, was nacheinander in der Domäne passiert. Die Softwareentwickler stellen Verständnisfragen und hinterfragen auch schon, warum es so gemacht wird. Um das Ganze zu vereinfachen, beginnen wir meistens mit einem einfacheren Szenario eines Geschäftsablaufs und nehmen an, dass er gelingt ("happy path"). Es werden im Wesentlichen folgende Fragen beantwortet:

Es werden folgende Fragen beantwortet:

• Was sind die wichtigen Geschäftsereignisse (Events)?
• In welcher Reihenfolge treten die Events typischerweise auf?
• Wo gibt es noch kritische Punkte oder Unklarheiten?
• Wo genau sind die Einstiege und das Ende des Geschäftsprozesses?

Am Ende der Phase erhalten wir ein erstes chronologisches Bild über die fachliche Wertschöpfung – eine grobe Landkarte von (Geschäfts-)Feldern und Straßen, auf die sich alle beziehen können.

Phase 2 – Landeanflug: Felder und Straßen werden deutlicher und die größeren Zusammenhänge und Verbindungen sichtbar.

In der zweiten Phase erweitern wir unser Verständnis zu den Ereignissen: Was hat diese Ereignisse ausgelöst? (Commands) Welche Akteure spielen eine Rolle? Welche Informationen sind nötig? Welche Geschäftsregeln gibt es, die einen Einfluss auf die Ereignisse haben? Das hilft uns, Ereignisse der Domäne als zusammengehörig anzusehen und gegen andere abzugrenzen. Wir definieren Zuständigkeitsbereiche (sogenannte Bounded Contexts), weil die fachlichen Ereignisse zu ähnlichen Aufgaben im Geschäftsprozess gehören. Ein Fachbegriff hat in einem Kontext seine spezifische Bedeutung. Wir geben diesen Kontexten Namen, die ihr fachliches Verhalten und ihre Aufgabe ausdrücken, keine technischen Ausdrücke oder Systemnamen. Jeder Kontext sollte nur eine einzige Aufgabe haben und diese auch nur als einziger, damit wir später unsere Anwendung gut modularisieren können.

Wir arbeiten an Fragen wie:

• Wo können wir fachliche Verantwortungen genau voneinander abgrenzen?
• Welchen wichtigen Begriffen gehören in diese Kontexte und was bedeuten sie dort?
• Welche (Sub-)Domäne macht unser ureigenstes Geschäft aus, in dem unsere Wettbewerbsvorteile und Alleinstellungsmerkmale liegen?
• Wie interagieren die abgegrenzten Bereiche miteinander?

Phase 3 – Auf der Landebahn: Wir erreichen die Landebahn und setzen auf der Oberfläche auf.

In der letzten Phase schließen wir die Landung ab. Das gemeinsame fachliche Verständnis hilft uns jetzt, schon in Richtung Produkt-Architektur und Objekt-Struktur zu denken. Die Abgrenzung in Module und das Verständnis der Verhaltensweisen einzelner Objekte werden verfeinert. Die gemeinsam gefundenen Begriffe finden sich im Code wieder. Diese Phase kann oft auch ohne Fachexperten stattfinden. Die Konzepte, die wir hier verwenden (z. B. Aggregat, Value Object), kommen aus dem Domain-Driven Design. Diese Fragen sind zum Beispiel:

• Welche Entitäten, Aggregate und Value Objects gibt es innerhalb eines Bounded Context?
• Wie funktioniert genau die Interaktion zwischen bestimmten Kontexten, wie die mit externen Systemen?
• Müssen wir weiter unterteilen oder zusammenfassen?

Über die drei Phasen des Landeanflugs haben wir dieselbe Region aus unterschiedlichen Zoomstufen betrachtet und sind allmählich von der fachlichen Perspektive zur technischen übergegangen. Die begriffliche Grundlage ist aber immer dieselbe geblieben und wird es über die weitere Produktentwicklung bleiben, auch wenn sie sich weiterentwickelt. Fachexperten und Softwareentwickler wissen anhand des Bildes der Geschäftslogik, worüber sie sprechen. Sie können schnell auf den Punkt kommen und erfassen, was die jeweils andere Seite möchte. Beim Event Storming geht es also um das Erarbeiten eines geteilten mentalen Modells („Landkarte“) und das Etablieren einer gemeinsamen Sprache. Das Modell grenzt fachliche Zuständigkeiten deutlich ab - diese fachliche Abgrenzung wird sich auch in der Architektur wiederfinden.

Was ist aus Deiner Sicht das zentrale Problem, das gelöst wird?

• Oft wird bei der Produktentwicklung viel zu schnell an technischen Lösungen gearbeitet. Viel wichtiger ist es aber, zuerst eine Vorstellung davon zu entwickeln, was in der Geschäftsdomäne passiert, welche wichtigen Geschäftsereignisse (Events) es gibt und was dafür getan werden muss, dass sie auch stattfinden. Die Produktentwicklung soll sich an der Frage ausrichten, wozu unser Produkt eigentlich da ist - und nicht was technisch gerade naheliegt. Das führt zu Komplexität, die Lösung ist meistens einfacher.
• Wenn sich alle frühzeitig eine gemeinsame Vorstellung der Geschäftslogik erarbeiten, können wir schneller die richtigen Produktentscheidungen treffen. Das minimiert den Umsetzungsaufwand und maximiert die Arbeit, die wir den Features widmen, die den größten Kundenwert stiften.
• Wir verlieren uns nicht in Detailfragen oder versuchen architektonische Probleme zu lösen, die wir gar nicht haben.

Wann kann oder sollten wir Event Storming einsetzen?

Da gibt es verschiedene Anlässe:

• Der häufigste Fall ist, dass eine neue Softwarekomponente in ein bestehendes Produkt integriert werden soll.
• Wer seine Softwarelandschaft erneuern möchte und dies schrittweise bervorzut. Die neuen Teile müssen also mit den bisherigen weiter funktionieren.
• Im Geschäftsumfeld oder im Softwareprodukt wird nach Verbesserungsmöglichkeiten gesucht.
• Es soll ein ganz neues Softwareprodukt gebaut werden.

Wie wirkt sich Event Storming auf spätere Phasen der Produktentwicklung aus?

Von Anfang an haben wir auf eine Abgrenzung der Komponenten aufgrund von fachlichen Aufgaben geachtet, dadurch verfügen wir jetzt über eine wartbare Architektur, die leichter angepasst werden kann. Gut fachlich abgegrenzte Domänen vermeiden Kopplung. Die gemeinsame Diskussion der Wissensträger macht sehr früh die kritischen Punkte der Geschäftslogik und der Umsetzung deutlich. Das vermeidet spätere und dadurch teurere Anpassungen. Die Erleichterung der Kommunikation und Vermeidung von Missverständnissen haben wir ja schon besprochen.

Das klingt super! Wie kann ich denn morgen damit starten?

• Du musst entscheiden, für welches Produkt oder Teilprodukt Du Event Storming anwenden möchtest.
• Du brauchst Fachexperten aus Deinem Unternehmen oder von Deinen Kunden und Softwareentwicklern.
• Du brauchst jemanden, der den Workshop moderiert. Das muss nicht unbedingt jemand von außen sein.  Das kann auch jemand übernehmen, der Erfahrung im Moderieren hat (z. B. ein Scrum Master) und das Team durch die Fragen leitet.

Und dann kannst Du schon loslegen!

Wir hoffen, Euch hat dieser Einblick in Event Storming anregt, gemeinsam mit Kunden oder Fachexperten frühzeitig ein gemeinsames Modell und Vokabular zu finden, um so erfolgreiche Softwareprodukte zu entwickeln.

Sven hat noch eine ganze Menge Expertentipps, wie ihr Euch die Anwendung von Event Storming leichter macht. Event Storming ist auch erst der Anfang. Das Arbeiten mit Events ist auch in späteren Phasen der Produktentwicklung wahnsinnig hilfreich. So setzen Methoden wie Event Modeling nahtlos an und treiben das technische Design von Softwareprodukten. Event-getriebene Implementierungsstacks erlauben höchst skalierbare und erweiterbare Produktimplementierungen. Aber dazu mehr in späteren Beiträgen. Wer jetzt schon Fragen hat, kann sich auch gern direkt mit Fragen an uns wenden oder Themen zur Vertiefung vorschlagen.