Architektur-Argumentation
Event Sourcing: Wann es sich lohnt — und wann nicht.
Klassische Systeme speichern, was gerade gilt. Nicht, warum es gilt. Diese Seite erklärt, was diese Lücke real kostet — und wann sie den Aufwand einer anderen Architektur nicht rechtfertigt.
Was das System ist — und was in ihm passiert ist.
Jedes Fachsystem trägt zwei Wahrheiten. Die eine ist das Domain-Modell: was gilt, welche Regeln greifen, welcher Zustand aktuell ist. Die andere ist die Historie: welche Ereignisse in welcher Reihenfolge dazu geführt haben.
Die meisten Systeme speichern nur die erste. Ein Update überschreibt den alten Wert, und mit ihm verschwinden Begründung, Kausalität und Kontext. Was bleibt, ist ein Zustand ohne Erklärung — und die Erklärung ist genau das, wonach im Ernstfall gefragt wird.
Zustandsorientiert
Der Kundenrabatt beträgt 12 %. Seit wann, durch wen und aufgrund welcher Regel — unbekannt.
Ereignisorientiert
Rabatt am 14. März auf 12 % gesetzt, ausgelöst durch die Jahresvereinbarung, freigegeben von der Vertriebsleitung. Der Zustand ergibt sich daraus.
Zwei Perspektiven auf dasselbe Problem.
Geschäftsführung und Technik erleben die fehlende Historie unterschiedlich — die Ursache ist dieselbe.
Was es kostet und riskiert
Nachweispflicht ohne Nachweis
Prüfer, Kunden oder Behörden fragen nach dem Zustand zu einem Stichtag. Die Antwort entsteht in Handarbeit aus Logs, Backups und Erinnerung — pro Anfrage mehrere Personentage.
Regeländerungen werden zu Projekten
Eine neue Berechnungsregel bedeutet Migration, Testfenster, Downtime und Risiko. Fachliche Entscheidungen verzögern sich, weil die Technik sie teuer macht.
Wissen hängt an Personen
Warum das System sich so verhält, wissen zwei oder drei Leute. Onboarding dauert Monate, Urlaub wird zum Risiko, externe Hilfe wird teurer als nötig.
AI-Vorhaben scheitern an Erklärbarkeit
Sobald Entscheidungen automatisiert werden, wird Nachvollziehbarkeit zur Zulassungsbedingung. Fehlt sie, bleibt das Projekt im Pilotstatus stecken.
Die Schmerzpunkte, wie sie sich anfühlen.
Nicht als Architekturbegriff, sondern als Satz, der in Meetings tatsächlich fällt.
„Warum stand der Preis im März auf diesem Wert? Das kann uns niemand beantworten."
Verlorene Historie: Gespeichert ist nur der aktuelle Zustand.
Ereignisse sind der Speicher. Der Zustand zu jedem Zeitpunkt lässt sich abspielen statt rekonstruieren.
„Wir sehen, dass es geändert wurde. Wir wissen nicht, warum."
Verlorene Kausalität: Auslöser und Kontext einer Änderung fehlen.
Jedes Ereignis trägt Absicht, Auslöser und Kontext — nicht nur den neuen Wert.
„Diese Regeländerung braucht ein Migrationsprojekt und ein Wartungsfenster."
Schema- und Datenmigrationen als Standardweg für fachliche Änderungen.
Neue Auswertungen und Regeln laufen auf der bestehenden Ereignisfolge. Die Vergangenheit muss nicht umgeschrieben werden.
„Die Zahlen im Reporting stimmen nicht mit dem System überein."
Dual Writes: Mehrere Datenhaltungen, die auseinanderlaufen.
Eine Quelle der Wahrheit, aus der alle Sichten abgeleitet werden — inklusive Reporting und Suche.
„Das weiß nur die Kollegin, die das damals gebaut hat."
Domain-Wissen lebt in Köpfen statt im Modell.
Das Fachmodell wird explizit, benannt und versionierbar. Onboarding liest, statt zu fragen.
„Für das Audit bauen wir noch schnell ein Logging ein."
Audit-Layer nachträglich aufgesetzt — lückenhaft und pflegeintensiv.
Auditierbarkeit entsteht strukturell, weil die Historie das System trägt und nicht daneben mitläuft.
„Wir liefern langsamer als vor drei Jahren, mit mehr Leuten."
Wachsende Regressionsangst in einem gewachsenen System.
Klarer fachlicher Schnitt, ableitbare Sichten und Replay senken die Kosten jeder Änderung.
„Wir können nicht erklären, warum das System so entschieden hat."
Undurchsichtige Zustände — besonders kritisch bei automatisierten Entscheidungen.
Entscheidung, Kontext und Ergebnis sind einzeln festgehalten und jederzeit abspielbar.
Diese Kosten stehen in keinem Budget. Sie erscheinen als „sonstige IT-Kosten", als Beratungsposten oder als verlängerte Time-to-Market — und summieren sich über Jahre.
Was das Unternehmen konkret davon hat.
Nicht Eleganz, sondern Eigenschaften, die sich in Kosten und Risiko niederschlagen.
Auditierbarkeit by design
Manipulationssicherheit und Nachweisfähigkeit entstehen aus der Struktur, nicht aus einem nachträglichen Audit-Trail, der gepflegt und verteidigt werden muss.
Neue Logik auf alter Historie
Eine geänderte Business-Regel kann rückwirkend auf der bestehenden Ereignisfolge ausgewertet werden — ohne Datenmigration und ohne Verlust der alten Sicht.
Zustand zu jedem Zeitpunkt
Reporting, Analytics und spätere AI-Features bekommen eine belastbare Grundlage statt eines Momentaufnahme-Exports.
Explizites, versionierbares Domain-Modell
Business und Technik sprechen über dieselben Begriffe. Missverständnisse werden früher sichtbar, Alignment geht schneller, Key-Person-Risiko sinkt.
Erklärbar über Jahre
Systeme bleiben verständlich und weiterentwickelbar, auch wenn das ursprüngliche Team längst nicht mehr da ist.
Replay statt Spekulation
Debugging, Was-wäre-wenn-Analysen und der Vergleich zweier Strategien laufen auf realen Daten statt auf Annahmen.
Warum Regulierung der ehrlichste Grund für Event Sourcing ist.
Event Sourcing wird selten wegen der Technik gekauft. Es wird gekauft, weil jemand eine Frage beantworten muss, die nur eine unveränderliche Historie beantwortet.
NIS2, der EU AI Act und der Cyber Resilience Act verlangen Unterschiedliches — aber alle drei enden an derselben Stelle: Wer hat wann was entschieden, und können Sie das belegen? Das ist keine Dokumentationsfrage. Es ist die Frage, ob das System seine eigene Geschichte kennt.
Regulierung ist dabei der wiederkehrende Anlass, nicht das eigentliche Thema. Die Pflichten kommen gestaffelt und ändern sich — jede neue Stufe stellt dieselbe Grundfrage neu. Eine Architektur mit fachlichen Ereignissen als Fundament beantwortet die nächste Runde mit demselben Fundament. Eine, die nur Zustände speichert, beginnt jedes Mal von vorn.
Deshalb raten wir nicht aus Technikbegeisterung zu Event Sourcing, sondern dort, wo diese Fragen absehbar sind. Und wir sagen genauso klar, wann ein sauberes Datenmodell mit Änderungsprotokoll reicht — das ist öfter der Fall, als die Szene zugibt.
Die Umsetzungssicht im Detail: NIS2, EU AI Act und Cyber Resilience Act.
Total Cost of Ownership: Die sichtbaren Kosten sind der Einstieg.
Die eigentlichen Treiber entstehen über die reale Lebensdauer eines Systems — und die ist meist länger als geplant.
- Wartung und EvolutionLaufende Kosten steigen, weil jede Änderung mehr Absicherung braucht als die vorherige.
- Forensik bei IncidentsJede Compliance-Anfrage und jeder Vorfall bindet erfahrene Leute für Tage — genau die, die sonst liefern würden.
- Verzögerte ReleasesAngst vor Seiteneffekten verschiebt Termine. Der Umsatzeffekt taucht in keiner IT-Kostenstelle auf.
- Externe ExpertiseWenn das Domain-Wissen nicht mehr im Haus ist, wird es zugekauft — dauerhaft und zu Tagessätzen.
- Gescheiterte AI-VorhabenAgenten-Projekte scheitern selten am Modell, sondern an fehlender Erklärbarkeit und fehlendem Vertrauen.
Wie lange bleibt Software im Unternehmen wirklich?
- Kernsysteme und wichtige Individualanwendungen
- 10–15 Jahre
- ERP und vergleichbare zentrale Systeme
- 12–20 Jahre
- Legacy-Bestand in Konzernen heute
- 15–21 Jahre
Software wird selten ersetzt, weil sie technisch abgelaufen ist. Sie wird ersetzt, wenn der Schmerz größer wird als der Austauschaufwand. Bis dahin lebt sie länger als geplant — und wird teurer.
AI-Agenten machen aus dem Problem eine Zulassungsfrage.
Agentische Systeme treffen Entscheidungen, rufen Werkzeuge auf und handeln über längere Zeiträume. Klassische Zustandsspeicher passen dazu strukturell nicht.
Problem
- Eine Entscheidung überschreibt den Zustand — Begründung und Kontext sind danach weg.
- Bei Fehlern oder Compliance-Fragen lässt sich nicht rekonstruieren, was der Agent zu diesem Zeitpunkt wusste.
- Mehrere Agenten erzeugen Race Conditions und Seiteneffekte, die niemand nachvollziehen kann.
- Das Debugging mehrstufiger Läufe wird extrem teuer, weil jeder Lauf einmalig ist.
Mit Event Sourcing
- Vollständige, nachvollziehbare Historie jeder Aktion und jedes Werkzeugaufrufs.
- Rekonstruktion des exakten Kontexts zu jedem Zeitpunkt der Ausführung.
- Koordination mehrerer Agenten über dieselbe Ereignisfolge statt über geteilten Zustand.
- Replay für Debugging, Experimente und den belastbaren Vergleich zweier Strategien.
Und wann Sie das nicht brauchen.
Sinnvoll, wenn
- Ihre Systeme länger als sieben bis acht Jahre leben sollen
- Sie in regulierten oder vertrauenskritischen Domänen arbeiten
- Sie AI-Agenten in Entscheidungsprozesse einbinden wollen
- Sie die Kosten von „wir wissen nicht mehr, warum der Zustand so ist" bereits spüren
- Agilität für Sie heißt, Regeln zu ändern, ohne die Vergangenheit zu zerstören
Nicht nötig, wenn
- Sie einfache Systeme mit kurzer Lebensdauer und geringer fachlicher Komplexität bauen
- Der aktuelle Schmerz — fehlende Historie, Audit-Aufwand, teure Regeländerungen — klein genug ist
- Ein sauberes Datenmodell mit ordentlichem Änderungsprotokoll Ihre Anforderungen vollständig deckt
Häufige Fragen
- Was können wir im Prüfungsfall konkret vorlegen?
- Eine lückenlose, nachträglich nicht veränderbare Folge fachlicher Ereignisse: wer wann welche Entscheidung ausgelöst hat, in welcher Reihenfolge, mit welchen Daten. Dazu den Zustand des Systems zu jedem beliebigen Zeitpunkt — rekonstruiert, nicht behauptet. Das ist der Unterschied zwischen Dokumentation und Belegbarkeit: Ein System, das nur den aktuellen Stand speichert, kann die Frage „warum steht das heute so?“ nicht beantworten.
- Wann lohnt sich Event Sourcing?
- Wenn fachliche Nachvollziehbarkeit, Auditierbarkeit oder häufige Regeländerungen zum Kostenfaktor werden und das System über viele Jahre betrieben wird. Bei einfachen, kurzlebigen Systemen ist der Aufwand nicht gerechtfertigt.
- Wie lange lebt Unternehmenssoftware realistisch?
- Kernsysteme und wichtige Individualanwendungen bleiben typischerweise 10 bis 15 Jahre, ERP- und vergleichbare zentrale Systeme oft 12 bis 20 Jahre. Legacy-Bestand in Konzernen ist heute im Schnitt 15 bis 21 Jahre alt.
- Was ist der Unterschied zwischen Event Sourcing und einem Audit-Log?
- Ein Audit-Log läuft neben dem System mit und kann lückenhaft oder nachträglich veränderbar sein. Bei Event Sourcing sind die Ereignisse das System: Der Zustand wird aus ihnen abgeleitet, deshalb kann die Historie nicht am Betrieb vorbei entstehen.
- Brauchen wir dafür CQRS oder Domain-Driven Design?
- Nicht zwingend, aber die Kombination ist üblich. CQRS trennt schreibende von lesenden Sichten, Domain-Driven Design liefert den fachlichen Schnitt. Event Modeling ist der Weg, beides gemeinsam mit den Fachbereichen zu erarbeiten, bevor Code entsteht.
- Können wir das in einem bestehenden System einführen?
- In der Regel schrittweise: ein fachlich abgegrenzter Bereich zuerst, der Rest bleibt unverändert. Das ist der übliche Einstieg bei einer Modernisierung — nicht die Neuentwicklung des gesamten Bestands.
Die eigentliche Frage
Wie teuer wird es in acht bis zwölf Jahren, wenn Ihr System die Historie und die Begründung von Entscheidungen nicht nachvollziehbar speichert — besonders dann, wenn AI-Agenten Teil dieser Entscheidungen werden?
Praxisbeispiele: Wer hat was zugesagt? Wenn niemand rekonstruieren kann, was passiert ist und Wer hat die Kreditprüfung übersprungen? Auftragsabwicklung über fünf Systeme.
Zum Weiterlesen: wann sich Event Sourcing lohnt, Event Modeling als Adoption-Werkzeug und Monolith modernisieren ohne Neubau.