Software, die hält: Warum wir bei der Fachlichkeit anfangen — und nicht beim Stack

Die Technologiefrage ist selten die schwierige Frage.

Wenn ein Software-Vorhaben startet, wird oft zuerst über den Stack gesprochen. Welche Sprache, welches Framework, welche Cloud, welche Datenbank. Das ist verständlich — es sind konkrete, entscheidbare Fragen. Aber es sind selten die Fragen, an denen ein System später scheitert.

Systeme scheitern daran, dass niemand präzise beschreiben konnte, was fachlich eigentlich passiert. Welche Ereignisse treten in diesem Geschäft auf? Wer löst sie aus? Was folgt daraus? Was muss nachvollziehbar bleiben, auch in drei Jahren, wenn jemand fragt, warum eine Rechnung so und nicht anders aussieht?

Deshalb beginnen wir nicht beim Stack. Wir beginnen bei der Fachlichkeit.

Event Modeling: die Fachlichkeit sichtbar machen, bevor Code entsteht

Event Modeling ist im Kern eine einfache Idee: Man legt die Ereignisse eines Geschäftsprozesses zeitlich nebeneinander und schaut sie gemeinsam an. Nicht als abstraktes Datenmodell, sondern als Abfolge dessen, was tatsächlich geschieht. Angebot erstellt. Angebot versendet. Angebot angenommen. Auftrag angelegt. Lieferung terminiert.

Das Entscheidende daran ist nicht die Notation. Das Entscheidende ist, wer im Raum sitzt. Event Modeling funktioniert, weil die Menschen, die den Prozess täglich verantworten, dieselbe Darstellung lesen können wie die Menschen, die das System bauen. Es gibt keine Übersetzungsschicht, in der Missverständnisse verschwinden und drei Monate später als Änderungsanforderung wieder auftauchen.

In fast jedem Workshop dieser Art passiert dasselbe: Nach etwa einer Stunde widersprechen sich zwei Personen aus derselben Abteilung darüber, wann genau ein Auftrag als angenommen gilt. Diese Diskussion hätte auch später stattfinden können — dann allerdings als Bug, als Eskalation oder als teure Nachverhandlung.

Ein Modell, das die Fachabteilung nicht lesen kann, ist kein Modell. Es ist eine Vermutung mit Diagrammcharakter.

Event Sourcing: Nachvollziehbarkeit als Architekturprinzip

Wenn man ohnehin in Ereignissen denkt, liegt es nahe, sie auch zu speichern. Genau das ist Event Sourcing: Der Zustand eines Systems ergibt sich aus der Abfolge der Ereignisse, die dazu geführt haben, statt aus einer Tabelle, die nur das jeweils letzte Ergebnis kennt.

Das klingt zunächst nach einem technischen Detail. Praktisch verändert es, wie Organisationen einem System begegnen.

• Historie ist beantwortbar. Die Frage „Wie war der Stand am 3. März?" ist keine Rekonstruktionsarbeit, sondern eine Abfrage.
• Fehler sind erklärbar. Man sieht nicht nur, dass ein Wert falsch ist, sondern welches Ereignis ihn erzeugt hat.
• Auswertungen entstehen später. Neue Sichten auf dieselben Ereignisse lassen sich nachträglich bauen, ohne die Vergangenheit zu verlieren.
• Vertrauen wächst. Fachabteilungen führen keine Schattentabelle mehr, wenn das System ihre Fragen zuverlässig beantwortet.

Der letzte Punkt ist der wichtigste. Adoption entscheidet sich nicht in der Schulung, sondern in dem Moment, in dem jemand dem System eine unangenehme Frage stellt. Antwortet es überzeugend, wird es benutzt. Antwortet es nicht, entsteht daneben eine Tabellenkalkulation — und die ist am Ende die eigentliche Konkurrenz.

Event Sourcing ist dabei kein Selbstzweck. Es ist die richtige Wahl, wenn Fachlichkeit komplex ist, Historie zählt und Entscheidungen später begründet werden müssen. Für eine simple Verwaltungsmaske ist es Überbau. Genau das sagen wir dann auch.

Technologieoffen heißt: schlank, langlebig, wartbar

Wir legen uns nicht auf eine Sprache oder ein Framework fest, weil die richtige Wahl vom Kontext abhängt: vom Team, das das System später betreibt, von der Lebensdauer, von der Integrationslandschaft, von den Fähigkeiten, die im Unternehmen schon vorhanden sind.

Was wir uns fest vornehmen, sind drei Eigenschaften:

1. Schlank. Jede zusätzliche Komponente ist eine zusätzliche Ausfallquelle und ein zusätzlicher Grund, warum in zwei Jahren niemand mehr etwas anfassen will.
2. Langlebig. Wir wählen Bausteine, die in fünf Jahren wahrscheinlich noch gepflegt werden — und nicht das, was im aktuellen Quartal am meisten Aufmerksamkeit bekommt.
3. Wartbar. Der entscheidende Test ist nicht, ob das System heute funktioniert, sondern ob eine neue Entwicklerin in zwei Wochen eine Änderung sicher durchführen kann.

Ein System, das nur die Menschen verstehen, die es gebaut haben, ist kein Vermögenswert. Es ist eine Verbindlichkeit mit Charme.

Ownership: jemand steht für das Ergebnis gerade

Der häufigste strukturelle Fehler in Software-Vorhaben ist nicht technischer Natur. Er besteht darin, dass Verantwortung auf Rollen verteilt ist statt auf Personen. Ein Lenkungsausschuss entscheidet, ein Dienstleister liefert, eine Fachabteilung testet — und wenn etwas nicht passt, war es das Zusammenspiel.

Ownership bedeutet bei uns etwas Konkretes: Es gibt namentlich eine Person, die für den technischen Verlauf und das Ergebnis geradesteht. Diese Person trifft Entscheidungen, begründet sie schriftlich und nachlesbar, und sagt auch dann etwas, wenn die unangenehme Nachricht früh kommt statt spät.

Dazu gehört die Bereitschaft, gegen den eigenen Auftrag zu argumentieren. Wenn eine einfachere Lösung die bessere ist, sagen wir das — auch wenn das Projektvolumen dadurch kleiner wird. Das ist nicht Idealismus. Es ist der einzige Weg, wie technische Beratung überhaupt vertrauenswürdig sein kann.

Was daraus folgt

Gute Software entsteht nicht aus der Auswahl moderner Werkzeuge, sondern aus einer sauber verstandenen Fachlichkeit, einer Architektur, die Nachvollziehbarkeit ernst nimmt, und einer Person, die für das Ergebnis geradesteht.

Alles andere — Sprache, Framework, Infrastruktur — ist eine Folgeentscheidung. Wichtig, aber nachgelagert.

Wenn Sie gerade vor einem Vorhaben stehen und unsicher sind, ob die Fachlichkeit tragfähig beschrieben ist: Genau dort fangen wir an.