Wer hat was zugesagt? Wenn niemand rekonstruieren kann, was passiert ist

Es ist Dienstag, 09:17 Uhr. Ein B2B-SaaS-Anbieter, rund 120 Leute, Wien plus Remote. Der Account Manager öffnet eine Mail von einem der größten Kunden:

„Die Opt-out-Funktion für die Weitergabe an Subprozessoren verhält sich nicht so, wie es im Vertrag und in den Workshops vereinbart wurde. Wir sehen darin ein akutes Compliance-Risiko und erwarten bis morgen eine lückenlose Rekonstruktion."

Die Geschäftsführung will in 90 Minuten vier Antworten: Was wurde wann genau zugesichert? Wer hat die finale Spezifikation freigegeben? Warum weicht das Verhalten davon ab? Welche rechtlichen und technischen Risiken bestehen?

Das ist der Moment, in dem sich zeigt, ob ein Unternehmen weiß, was in ihm passiert ist.

Die Suche, die jeder kennt

Die Werkzeuglandschaft ist unauffällig und typisch: Jira, GitLab, Confluence, Slack, Google Drive, in einzelnen Teams Notion, dazu Outlook und seit einem Jahr ein KI-Assistent, der „über alles" laufen soll.

• In Jira finden sich drei Epics und siebzehn Tickets. Beschreibungen unvollständig, Labels inkonsistent, Status teils seit Monaten unverändert.
• Die Confluence-Seite „Privacy Feature Spec v2.3" wurde zuletzt vor neun Monaten bearbeitet. In den Kommentaren widersprechen sich Produkt und Recht. Eine neuere Fassung existiert nur als Link auf ein Dokument in einem Slack-Thread.
• Im Channel für Datenschutzthemen liegen über vierzig Threads. Die entscheidenden Absprachen liefen in Direktnachrichten zwischen Product Owner, Legal und Architektur. Ein Teil ist durch Aufbewahrungsregeln bereits gelöscht.
• In GitLab liegen drei Merge Requests mit Commit-Nachrichten wie „quick privacy fix". Die eigentliche fachliche Diskussion steht in den Kommentaren und ist mit keinem Ticket verknüpft.
• Die Workshop-Notizen mit dem Kunden liegen in einem Notion-Bereich, von dem der Product Owner nichts wusste.

Nach zweieinhalb Stunden haben fünf Leute zusammengetragen, was auffindbar war. Die Bilder widersprechen sich. Der KI-Assistent liefert eine saubere Zusammenfassung — die aber die Direktnachrichten und die aktuellste rechtliche Stellungnahme nicht kennt und deshalb eine falsche Reihenfolge und eine falsche Verantwortlichkeit konstruiert. Niemand traut dem Ergebnis genug, um es dem Kunden oder dem Anwalt zu geben.

Was diese eineinhalb Stunden tatsächlich kosten

Der offensichtliche Posten ist der kleinste: fünf Personen, zweieinhalb Stunden, in der Regel die teuersten fünf im Haus. Dazu kommen die Posten, die in keinem Budget auftauchen:

• Eine zweite Runde, weil der Anwalt Rückfragen hat, die aus dem zusammengesuchten Material nicht beantwortbar sind.
• Verzögerte Releases, weil Product Owner und Architektur in dieser Woche nichts anderes machen.
• Ein Vertragsrisiko, das nicht bewertet werden kann, weil unklar ist, was zugesagt wurde. Bei einem siebenstelligen Jahresumsatz ist das keine Fußnote.
• Ein Vertrauensverlust beim Kunden, der nicht am Fehler hängt, sondern an der Antwort „wir prüfen das noch".

Der eigentliche Schaden ist nie der einzelne Vorfall. Es ist die Tatsache, dass dieselbe Suche vier- bis fünfmal im Jahr stattfindet und jedes Mal von vorne beginnt.

Der Fehler, den niemand findet

Die Abweichung hat eine banale Ursache. Im Juli wurde ein Performance-Hotfix eingespielt, der die Konfiguration eines Feature-Flags neu gesetzt hat. Dabei ist der Standardwert für das Opt-out gekippt — von „aktiv" auf „inaktiv".

In einem klassischen System ist dieser Vorgang unsichtbar. Die Konfigurationstabelle enthält einen Wert, und dieser Wert ist korrekt gespeichert. Was vorher dort stand, wer es geändert hat und in welchem Zusammenhang, ist beim Überschreiben verloren gegangen. Das System kann sagen, wie die Welt jetzt aussieht. Es kann nicht sagen, wie sie dahin gekommen ist.

Genau das ist der strukturelle Punkt, nicht ein Dokumentationsproblem: Wer nur Zustand speichert, verliert Begründung und Kausalität systematisch — und zwar leise. Ausführlicher steht das auf der Seite Event Sourcing: wann es sich lohnt.

Dieselbe Situation, anders gebaut

Nehmen wir an, dieses Unternehmen hätte vor gut einem Jahr angefangen, drei Bereiche event-sourced abzubilden — nicht alles, sondern genau die, in denen Nachvollziehbarkeit wehtut: Zusagen an Kunden, Compliance-relevante Produktentscheidungen und die zentralen Architekturentscheidungen.

Ein Event-Store hält für diese Bereiche die Fakten. Alles andere bleibt bestehen. Statt eines Zustands liegt dort eine Kette von Ereignissen:

• CustomerRequirementCaptured — die wörtliche Anforderung aus dem Workshop
• LegalOpinionProvided — die rechtliche Stellungnahme im Volltext, mit Bedingungen
• SpecificationVersionApproved — welche Fassung, freigegeben von wem
• ImplementationDecisionMade — die getroffene Architekturentscheidung samt Begründung
• CodeChangeLinked — Verweis auf den konkreten Merge Request
• FeatureDeployedToProduction und CustomerNotificationSent — was ausgeliefert und was kommuniziert wurde
• FeatureFlagDefaultChanged — die Änderung im Juli, mit Auslöser und verantwortlicher Person

Jedes Ereignis trägt neben den Fachdaten eine Aggregat-Kennung, Zeitstempel, Nutzer und Mandant sowie zwei Kennungen, die in dieser Situation den Unterschied machen: Causation und Correlation. Die eine sagt, welches Ereignis dieses ausgelöst hat, die andere, zu welchem fachlichen Vorgang es gehört. Damit ist die Kette vom Kundenwunsch bis zum Hotfix nicht rekonstruiert, sondern gespeichert.

Am Dienstagmorgen öffnet jemand eine Ansicht, die aus diesen Ereignissen berechnet wird — eine Projektion — und filtert auf den Kunden und das Thema Opt-out. Was er sieht, ist die vollständige Chronologie inklusive der Juli-Änderung, die den Widerspruch erklärt. Nicht in zweieinhalb Stunden, sondern in der Zeit, die das Laden der Seite braucht.

Die Confluence-Seite verschwindet dabei nicht. Sie hört nur auf, eine zweite Wahrheit zu sein, und wird zu einer Ableitung. Wenn sich die Spezifikation ändert, entsteht ein neues Ereignis; die alte Fassung bleibt im Stream stehen, statt überschrieben zu werden.

Warum KI-Agenten genau hier hängen

Der Assistent im ersten Teil dieser Geschichte hat nichts falsch gemacht. Er hat aus einem Dokumentenhaufen ohne verlässliche Zeitachse das plausibelste Bild erzeugt. Plausibel ist in Compliance-Fragen aber wertlos.

Mit einem Event-Stream ändert sich die Grundlage: Der Agent bekommt keine Dokumente, sondern eine zeitlich geordnete, berechtigungsgeprüfte Faktenmenge. Jede Aussage lässt sich auf ein Ereignis mit Kennung und Zeitstempel zurückführen — überprüfbar, ohne dem Modell glauben zu müssen. Wer Agenten in fachliche Prozesse lässt, braucht diese Rückführbarkeit ohnehin, spätestens beim ersten Audit.

Berechtigungen laufen dabei nicht über den Agenten, sondern über die Projektion. Welche Ereignisse ein Nutzer oder ein Mandant überhaupt sieht, entscheidet sich eine Ebene tiefer — dieselbe Logik, die auch bei Multi-Tenancy mit Keycloak greift.

Was das nicht löst

Event Sourcing macht keine Absprache sichtbar, die nie erfasst wurde. Wenn die entscheidende Zusage weiterhin in einer Direktnachricht fällt und niemand daraus ein Ereignis macht, steht sie auch in keinem Stream. Der Gewinn liegt nicht darin, dass das System die Disziplin ersetzt — sondern darin, dass es sie an einer einzigen, gut sichtbaren Stelle einfordert, statt sie über sechs Werkzeuge zu verteilen.

Der zweite ehrliche Punkt: Das ist kein Werkzeugkauf. Der aufwendige Teil ist die Einigung darauf, welche Ereignisse fachlich zählen und wie sie heißen. Genau deshalb ist Event Modeling in erster Linie ein Adoption-Werkzeug und kein Architekturdiagramm — es zwingt Fachbereich, Recht und Technik dazu, dieselbe Sprache zu benutzen. Das ist derselbe Übergang, der in den drei Übergängen beschrieben ist: Entschieden ist nicht umgesetzt, umgesetzt ist nicht angekommen.

Die Fragen, die im Enterprise immer kommen

Löschpflicht. Ein unveränderlicher Stream und das Recht auf Löschung schließen sich nicht aus, verlangen aber eine bewusste Entscheidung. Personenbezogene Daten gehören nicht roh ins Ereignis. Üblich sind Pseudonymisierung mit getrenntem Zuordnungsspeicher oder Crypto-Shredding: Die Nutzdaten liegen verschlüsselt im Ereignis, der Schlüssel außerhalb, und wird bei einem Löschbegehren vernichtet. Der Vorgang bleibt als Faktum, der Personenbezug verschwindet.

Aufbewahrung. Nicht jeder Stream muss ewig leben. Für abgeschlossene Vorgänge sind Snapshots plus Archivierung legitim, solange die Aufbewahrungsfrist der Fachlichkeit folgt und nicht der Bequemlichkeit.

Zugriff. Wer welche Ereignisse sieht, wird auf Projektionsebene entschieden, nicht in der Oberfläche. Das ist mehr Arbeit als ein Rollenfeld im Frontend — und der Grund, warum Auditoren solche Systeme mögen.

Bestandssysteme. Das läuft parallel weiter. Read-Models lassen sich in Jira oder das eigene Portal zurückspiegeln, damit die Teams dort bleiben, wo sie ohnehin arbeiten. Dieselbe schrittweise Logik wie beim Modernisieren eines Monolithen.

Wo man realistisch anfängt

Vier bis sechs Wochen bis zum ersten produktiven Stream sind machbar, wenn der Zuschnitt stimmt:

1. Eine Domäne wählen, in der die Frage „Was ist passiert?" heute regelmäßig gestellt wird und teuer ist. Kundenzusagen, Preis- und Vertragslogik oder Compliance-Entscheidungen sind die üblichen Kandidaten.
2. Die Ereignisse gemeinsam modellieren — Fachbereich, Recht, Technik an einem Tisch, auf Papier, bevor irgendetwas gebaut wird. Genau dafür gibt es den Event-Modeling-Sprint.
3. Einen Stream produktiv setzen, mit sauberen Causation- und Correlation-Kennungen von Anfang an. Nachträglich ergänzen ist mühsam. Für die Umsetzung mit einem spezialisierten Event-Store gibt es das EventSourcingDB-Angebot.
4. Eine Projektion bauen, die eine reale Frage beantwortet — die Zeitleiste eines Kunden, nicht ein Dashboard.
5. Das Read-Model dorthin zurückspiegeln, wo die Leute ohnehin arbeiten.

Wer vorher grundsätzlich prüfen will, ob sich der Ansatz überhaupt lohnt, findet die Abgrenzung in Event Sourcing ohne Angst. Und wenn die Frage eher lautet, wer diese Entscheidung im Haus trägt: dafür gibt es Fractional CTO.

Was bleibt

Der Unterschied zwischen den beiden Dienstagen ist keine Technologiefrage. Es ist die Entscheidung, ob die tatsächlichen Geschäftsereignisse festgehalten werden oder nur ihr letzter Zustand.

Die ehrliche Prüfung dauert eine Minute: Nehmen Sie die letzte unangenehme Kundenfrage, die Ihr Haus beantworten musste. Wie lange hat es gedauert, und wie sicher war die Antwort am Ende?