29.04.2026 10:52 Uhr

Im Interview erklärt Event-Modeling-Erfinder Adam Dymitruk, warum Software einen Blueprint braucht – und wie Business und Technik endlich eine Sprache nutzen.

Ich habe überall die gleichen Fehlermuster gesehen. Agile brachte uns einen Backlog aus zusammenhanglosen Aufgaben, aber keine kohärente Vorstellung davon, wie Informationen tatsächlich über die Zeit durch das System fließen. Das aufwendige Design von RUP (Rational Unified Process) und UML (Unified Modeling Language) haben wir gegen gar kein Design eingetauscht. Gleichzeitig hat sich unsere Branche immer wieder in Abstraktionen verliebt, die naturgemäß subjektiv sind und sofort zum Kompromiss werden, sobald mehrere Menschen sie teilen müssen. Spezifikationen für traditionelle Systeme ignorierten die Vorteile einer minimalen, sinnvollen Kopplung über einen unveränderlichen Ledger aus Events, und traditionelle Datenbanken sind auf den Status Quo ausgelegt: sie zeigen dir, was da ist, aber niemals, wie es dorthin gekommen ist. Dieser Mangel an Kausalität macht es deutlich schwieriger, das System zu auditieren, zu skalieren oder zu erklären. Obendrein gab es die weitverbreitete Unfähigkeit, Aufwände in der Softwareentwicklung zu schätzen, und ich wusste, dass ich unseren Kunden verlässlichere Budgets und Zusagen machen konnte.

Mir wurde letztlich klar: Wenn wir das System als Storyboard darstellen könnten (wie ein Filmskript oder einen Screencast dessen, was kommen soll), könnten wir die Lücke zwischen Business und Technik mit einer universellen und menschenfreundlichen Notation schließen.

Breite Resonanz fand das Ganze, als ich 2018 den ursprünglichen Artikel veröffentlichte, um es von anderen Ansätzen abzugrenzen, denn ich nutzte die Notation, um Event Sourcing und andere Konzepte in verschiedenen Tech-Communities zu erklären. Auf Hacker News wurde er an diesem Tag zur Top-Story hochgevotet.

Wie sich zeigt, sind alle, unabhängig vom Tech-Stack, das Stille-Post-Spiel mit Anforderungen leid. Die Leute wollen das Gesamtbild sehen. Sie wollen das Filmskript ihres Systems sehen, bevor sie Millionen für die Verfilmung ausgeben.

Stell dir dein System als Zeitleiste vor. Von links nach rechts bilden wir genau ab, was Schritt für Schritt passiert. Wir verwenden vier einfache Bausteine, mehr nicht:

Statt über User Stories zu streiten (die oft nur vage Wünsche sind), zeichnen wir die gesamte Reise als Storyboard. Wenn du den Fluss von einem Screen zu einem Command, zu einem Event und dann zurück zu einer View auf einem anderen Screen nicht zeichnen kannst, dann hast du keine Anforderung. Du hast eine Vermutung. Am Ende einer Session hast du keinen Stapel Tickets, du hast einen Blueprint. Er ist so klar, dass ein Entwickler genau weiß, was er bauen muss, und der Business-Owner genau weiß, wofür er bezahlt. Wir holen Software vom kreativen Schreiben zurück zum Engineering.

Der Blueprint krempelt alles um, weil er dem einen Ding Rechnung trägt, dem Software nicht entkommen kann: der Zeit.

Er beendet das Stille-Post-Spiel, das man von traditionellen Anforderungen kennt. Ein Business-Analyst schreibt eine So-sollte-es-sein-Anforderung, ein Entwickler übersetzt das in ein Klassendiagramm, und ein Tester versucht zu erraten, was ursprünglich gemeint war. Mit dem Blueprint haben wir eine gemeinsame Sprache. Wir alle schauen auf dieselbe Zeitleiste. Wenn ein Stakeholder ein Raum-gebucht-Event sieht, aber feststellt, dass davor kein Zahlung-verarbeitet-Event steht, kann er auf die Lücke zeigen. Das geht mit einem 40-seitigen Word-Dokument oder einem Jira-Backlog nicht.

Er entlarvt auch die Magie. User Stories sind berüchtigt für ihr vages Geschwafel. In einer Story heißt es dann vielleicht: „Als Nutzer möchte ich eine personalisierte Empfehlung erhalten.“ Großartig. Wie? In einem Event Model musst du offenlegen, wie es funktioniert. Wenn du die Linie von den Daten zum Screen nicht ziehen kannst, existiert das Feature nicht. Das zwingt uns, früh mit der Realität umzugehen, statt zwei Wochen vor dem Launch fehlende Teile zu entdecken.

Der Blueprint ist außerdem im großen Maßstab begreifbar. Du kannst Dich vor ein sechs Meter langes Event Model an der Wand stellen (oder vor ein riesiges Miro-Board) und ein komplexes Banking-System in zehn Minuten verstehen. Du folgst einfach den Pfeilen. Versuch das mal mit einem Jira-Backlog. Du klickst drei Stunden lang auf „Nächste Seite“ und weißt immer noch nicht, wie die Zinsberechnung tatsächlich den Monatsauszug beeinflusst. Der Blueprint gibt dir räumliches Gedächtnis: Du erinnerst Dich daran, dass die Checkout-Logik dort drüben rechts ist, und das macht Navigation und mentales Modellieren mühelos.

Schließlich macht er Integration sichtbar. Wir bauen die Login-Story, dann die Profil-Story. Aber bei Software geht es darum, wie diese Dinge zusammenspielen. Der Blueprint zeigt die Integrationspunkte als First-Class Citizens. Wir sehen genau, wie ein Event im Versand-Slice eine View im Kundenservice-Slice beeinflusst.

Der Klick passiert meist während der Storyboarding-Phase. Wir haben das chaotische Brainstorming mit den orangefarbenen Klebezetteln (Events) hinter uns und beginnen jetzt, sie auf der Zeitleiste auszurichten. Der Moment der Erkenntnis kommt, wenn ein Domänenexperte, vielleicht ein Versandleiter oder ein Buchhalter, auf den Bildschirm zeigt und sagt: „Moment, wenn das Event Bestellung versandt dort passiert, woher weiß der Kunde dann seine Tracking-Nummer? Wir haben dafür keinen Screen.“

Das ist der Klick. Zum ersten Mal ist die Business-Person nicht bloß ein Gast in einem technischen Meeting; sie ist die leitende Architektin. Sie erkennt, dass die orangefarbenen Klebezettel die Realität ihres Geschäfts sind, und dass der Blueprint das erste Mal ist, dass sie die Logik ihres eigenen Unternehmens in einer Form sehen, die für sie wirklich Sinn ergibt.

Von diesem Punkt an verschiebt sich die Dynamik grundlegend. Entwickler hören auf, „Mach dir keine Sorgen, wie das funktioniert“ zu sagen, und beginnen stattdessen: „Schauen wir mal auf die Zeitleiste.“ Das Gespräch verlagert sich von abstraktem Vertrauen zu empirischer Evidenz. Da wir alle auf dieselbe 2D-Karte von Information schauen, die sich durch die Zeit bewegt, gibt es keinen Spielraum mehr für Interpretation. Wenn ein Schritt fehlt, ist das ein physisches Loch an der Wand. Ich habe CEOs erlebt, die seit 20 Jahren keine Zeile Code mehr gelesen haben und ganz begeistert waren, weil sie das System endlich lesen konnten. Sie merken, dass sie die Logik selbst auditieren können, ohne einen Übersetzer zu brauchen.

Wenn alle im Raum erkennen, dass Events die letzte Quelle der Wahrheit sind, hören sie auf, über Klassen und Datenbanken zu streiten, und beginnen, über die Reise zu sprechen. Das ist der Moment, in dem du aufhörst, eine Entwicklungsbude zu sein, und anfängst, ein Engineering-Team zu sein.

Event Modeling löst das Problem mit einem Vokabular aus vier Begriffen: den Screens, Commands, Events und State Views, über die wir bereits gesprochen haben. Das war’s. Wenn du einen Klebezettel, eine Zeitleiste und einen Screen verstehen kannst, bist du Architekt. Wir reden nicht mehr über Klassen, sondern über Events (Tatsachen, die geschehen sind). Wir reden nicht mehr über API-Endpunkte, sondern über Commands (was der Nutzer tun möchte). Wenn du die Einstiegshürde so weit senkst, vereinfachst du nichts unzulässig, sondern erhöhst tatsächlich die Strenge, weil die Personen mit dem meisten Wissen endlich teilnehmen können.

Ich erlebe das oft bei Buchhaltern oder Compliance-Verantwortlichen. Das sind Menschen, die in Tech-Meetings traditionell extrem gelangweilt sind. Ich erinnere mich an eine Session für ein großes Logistikunternehmen, in der wir den Erstattungsprozess modelliert haben. Die Entwickler hatten ein komplexes Diagramm mit State Machines und Status-Flags. Der CFO saß im Raum und schaute verwirrt.

Wir sind zu einem Event Model gewechselt und haben die Zeitleiste gezeichnet: Zahlung empfangen (Event), dann Erstattung angefordert (Command), dann Erstattung ausgegeben (Event). Plötzlich stand der CFO auf, zeigte auf die Lücke zwischen Anfrage und Ausgabe und sagte: „Moment. Bei uns kannst du nicht einfach eine Erstattung ausgeben. Du brauchst erst einen Audit-Log-Eintrag und ein Steuerumkehr-Event, sonst verstoßen wir gegen das Gesetz.“

Darauf waren die Entwickler nicht einmal gekommen. Weil wir uns nicht hinter technischem Jargon versteckt haben, konnte die Person, die die rechtliche Realität des Geschäfts verstand, das Loch in der Zeitleiste sehen. Das ist die Stärke des Blueprints: Er macht den Domänenexperten zum Lead-Validator.

Wir Menschen sind zum Geschichtenerzählen geboren. Wir erzählen seit 50.000 Jahren Geschichten an Lagerfeuern; wir schreiben seit etwa 30 Jahren Java. Wenn du eine Zeitleiste zeigst, knüpfst du an die Art und Weise an, wie das menschliche Gehirn Informationen natürlich speichert. Das verlagert das Gespräch von „Wie programmieren wir das?“ zu „Stimmt diese Geschichte?“.