Event Modeling ist kein Architekturwerkzeug — es ist ein Adoption-Werkzeug

Event Modeling wird meistens technisch eingeführt: Commands, Events, Read Models, ein Zeitstrahl an der Wand. Das ist korrekt und unterschätzt zugleich, was tatsächlich passiert. Der größte Effekt entsteht nicht im Code, sondern im Raum.

Was im Workshop tatsächlich passiert

Ein Event-Modeling-Workshop bringt Fachbereich, Entwicklung und Betrieb an denselben Zeitstrahl. Modelliert wird, was im Geschäft passiert — nicht, welche Tabellen es gibt.

Der Ablauf ist bewusst simpel:

1. Ereignisse sammeln. Was passiert im Ablauf, in der Vergangenheitsform: „Bestellung aufgegeben", „Zahlung bestätigt", „Lieferung avisiert".
2. Zeitlich ordnen. Der Zeitstrahl macht Lücken sichtbar, die in Prosa unsichtbar bleiben.
3. Auslöser ergänzen. Welche Aktion oder welches System löst das Ereignis aus?
4. Sichten ergänzen. Welche Information braucht jemand, um die nächste Entscheidung zu treffen?
5. In Scheiben schneiden. Jede Scheibe ist eigenständig lieferbar und für sich testbar.

Nach einem halben Tag steht ein Bild, das alle lesen können. Das ist der Punkt.

Warum das Adoption ist

Adoption beginnt nicht bei der Schulung, sondern bei der Beteiligung. Wer den Ablauf mitmodelliert hat, erkennt ihn später in der Software wieder — und erklärt ihn Kolleginnen selbst, ohne dass ein Change-Programm nötig wäre.

Drei Effekte sehen wir regelmäßig:

• Fachliche Begriffe werden geklärt. Dass „Auftrag" in Vertrieb und Produktion Unterschiedliches meint, fällt am Zeitstrahl in Minuten auf. In einem Lastenheft überlebt der Widerspruch bis zum Test.
• Ausnahmen kommen früh auf den Tisch. Der Satz „das machen wir manchmal anders" ist der wertvollste Moment des Workshops.
• Verantwortung wird sichtbar. An jeder Scheibe hängt eine Person, die sie fachlich vertritt.

Typische Fehler

• Zu früh technisch werden. Sobald Datenbanken diskutiert werden, verliert der Fachbereich den Anschluss und der Workshop kippt in ein Entwicklermeeting.
• Nur die Führungsebene einladen. Die relevanten Ausnahmen kennen die Menschen, die den Prozess täglich ausführen.
• Das Modell als Dokument behandeln. Ein Event Model ist ein lebender Arbeitsstand. Wird es eingefroren, ist es in drei Monaten Dekoration.
• Alles modellieren wollen. Zwei bis drei Kernabläufe reichen. Der Rest folgt dem gleichen Muster.

Was danach vorliegt

Aus einem Sprint von zwei bis vier Wochen kommen typischerweise: das Event Model der Kernprozesse, ein Schnitt in lieferbare Scheiben mit Reihenfolge und Risiken, eine Ownership-Karte und eine Entscheidungsvorlage mit Aufwandskorridoren. Damit lässt sich entscheiden, ob und wie gebaut wird — und wer danach verantwortlich ist.

Ob das Ergebnis anschließend mit Event Sourcing, einer klassischen relationalen Umsetzung oder etwas dazwischen gebaut wird, ist eine zweite, kleinere Frage. Sie lässt sich sauber beantworten, sobald der Ablauf geklärt ist.

Wie wir daraus einen konkreten Schritt machen, steht im Event-Modeling-Sprint und in unserer Übersicht zu Event Sourcing.