Legacy ist gespeichertes Prozesswissen

Kürzlich sagte jemand zu mir: “If it ain’t broken, don’t fix it.”

Das klingt nach einer einfachen, vielleicht etwas altmodischen Aussage. Als ob man es vor allem vermeiden sollte, etwas zu ändern, solange das System noch läuft.

Aber in Legacy-Umgebungen höre ich etwas anderes darin. Nicht: Lass es in Ruhe, weil Alt gut genug ist. Sondern: Sei vorsichtig, denn niemand weiß mehr genau, warum es funktioniert.

Und das ist ein sehr anderes Problem.

Denn wenn niemand weiß, wie ein System wirklich zusammenpasst, ist es ersetzen keine einfache technische Migration mehr. Man zieht an einem Faden, ohne zu wissen, wohin er führt. Bevor man es weiß, öffnet sich die Büchse der Pandora.

Eine alte Schnittstelle stellt sich als noch benötigt heraus. Ein Feld, das niemand benutzt, speist einen Bericht. Ein nächtliches Skript korrigiert Daten, auf die drei Abteilungen angewiesen sind. Eine seltsame Verzögerung verhindert, dass eine Maschine in einen Fehlerzustand geht. Eine Ausnahme im Code stellt sich als alte Kundenvereinbarung heraus. Eine manuelle Excel-Liste ist Teil des eigentlichen Prozesses.

Und dann entdeckt man, dass das alte System nicht nur Software oder Hardware war. Es war Gedächtnis. Nicht ordentlich dokumentiert, nicht elegant entworfen, nicht immer sicher oder zukunftssicher — aber gefüllt mit Jahren von Prozesswissen.

Deshalb finde ich “If it ain’t broken, don’t fix it” eigentlich nicht ganz scharf genug. Ich würde es lieber so formulieren:

Wenn es nicht kaputt ist, verstehe zuerst, warum es noch funktioniert.

Wie Legacy entsteht

In vielen Organisationen wird Legacy vor allem als Belastung gesehen. Alte Programmiersprachen, alte Datenbanken, alte Server, alte SPSen, alte SCADA-Umgebungen, alte Schnittstellen, alte Bildschirme, mit denen niemand mehr zufrieden ist.

Und manchmal ist das berechtigt. Alte Systeme können anfällig sein. Sie laufen möglicherweise auf Hardware, die nicht mehr erhältlich ist, sind von Software abhängig, für die keine Patches mehr kommen, und erfüllen moderne Sicherheitsanforderungen, Monitoring oder Integrationsanforderungen schlecht.

Aber das ist nur eine Seite der Geschichte. Die andere Seite ist, dass ein solches altes System oft jahrelang mit der Realität mitgewandert ist. Nicht mit der Realität, wie sie einmal in einem Prozessdiagramm dargestellt wurde, sondern mit der Realität, wie sie tatsächlich war. Eine Ausnahme wurde hinzugefügt. Dann noch eine. Ein temporärer Workaround wurde permanent. Ein Skript, das schnell gebraucht wurde, wurde geschäftskritisch. Eine Schnittstelle, die niemand mochte, blieb, weil drei Prozesse davon abhingen.

Das habe ich selbst hautnah erlebt. Vor Jahren arbeitete ich an einem Steuerungssystem in einem Kraftwerk — Enteissung des Lufteinlasses. Auf dem Papier war es eine klare Anlage mit einer klar definierten Funktion. In der Praxis gab es eine ganze Schicht von Logik darum herum, die nirgendwo dokumentiert war: Ausnahmen für bestimmte Wetterbedingungen, manuelle Overrides, die Operatoren im Laufe der Jahre hinzugefügt hatten, Zeitabhängigkeiten, die stillschweigend verhinderten, dass die Anlage sich selbst in Schwierigkeiten brachte. Nichts davon stand in einem Konstruktionsdokument. Es steckte im System, und in den Köpfen der Menschen, die damit arbeiteten.

So entsteht Legacy. Nicht weil Menschen töricht sind oder niemand aufgepasst hat, sondern weil Organisationen sich verändern, Prozesse sich verschieben, Kunden andere Dinge verlangen, die Gesetzgebung sich ändert, Maschinen älter werden und Menschen Lösungen finden, um die Arbeit zu erledigen.

Alt ist nicht automatisch veraltet

Es gibt ein Missverständnis, das vielen Legacy-Diskussionen zugrunde liegt: dass alte Technologie automatisch veraltete Technologie ist. Das stimmt nicht immer.

Viel grundlegende Technologie ist noch dieselbe. Eine relationale Datenbank ist noch eine relationale Datenbank. Ein TCP/IP-Netzwerk ist noch ein TCP/IP-Netzwerk. Auch in industriellen Umgebungen sind viele Prinzipien überraschend konstant: messen, regeln, rückkoppeln, begrenzen, sichern, protokollieren.

Die Hülle ändert sich — Tooling, Schnittstellen, architektonischer Kontext. Denke an ereignisgesteuerte Architekturen, Zero Trust, Cloud-native Muster. Aber die zugrundeliegende Logik hat sich oft weniger verändert, als Menschen denken.

Manchmal liegt das Problem nicht darin, dass die Technologie grundlegend veraltet ist, sondern dass die Welt um das System herum sich verändert hat. Das System musste einmal eine Aufgabe in einem definierten Kontext erfüllen. Jetzt muss dasselbe System mit modernen Anwendungen verbinden, Daten an Dashboards liefern, neue Sicherheitsanforderungen erfüllen, mehreren Abteilungen zur Verfügung stehen und in eine Governance passen, die damals noch nicht existierte.

Dann ist das System nicht unbedingt kaputt. Es ist einfach in einer Welt gelandet, für die es nie entworfen wurde.

Der formale Prozess ist nicht immer der echte Prozess

Eines der größten Risiken bei der Modernisierung ist es, mit dem formalen Prozess zu beginnen. Menschen schauen auf Dokumentation, Prozessdiagramme, Architekturschemata, wie Dinge einmal gedacht waren.

Das scheint logisch. Aber in Brownfield-Umgebungen reicht das oft nicht aus.

Der echte Prozess liegt im Verhalten. In Ausnahmen. In manuellen Schritten. In alten Skripten. In Datenbankwerten, die einmal temporär waren. In Operatoraktionen, die so lange existieren, dass niemand sie mehr als Workarounds erkennt. Und oft ist das Legacy-System der einzige Ort, wo dieser echte Prozess noch sichtbar ist — nicht schön, nicht vollständig, nicht ordentlich beschrieben, aber vorhanden.

Deshalb kann ein altes System technisch veraltet und funktional noch reifer als das neue Design sein. Das ist unbequem, aber wichtig. Denn ein modernes System, das nur dem formalen Prozess folgt, kann perfekt gebaut sein und in der Praxis trotzdem scheitern. Nicht weil die Technologie schlecht ist, sondern weil es die echte Organisation nicht versteht.

Neue Technologie löst alte Unwissenheit nicht auf.

Modernisierung kann Wissen zerstören

Wenn man ein Legacy-System ersetzt, ohne zu verstehen, welches Wissen darin steckt, wirft man nicht nur alte Technologie weg. Man wirft organisatorisches Gedächtnis weg.

Das passiert selten in einem großen Knall. Es passiert subtil. Nach dem Go-live stellt sich heraus, dass bestimmte Ausnahmen nicht mehr funktionieren. Berichte stimmen leicht nicht. Maschinen reagieren anders. Operatoren beginnen zusätzliche Prüfungen durchzuführen. Benutzer führen Excel-Listen. Abteilungen bauen Schattenprozesse. Der Betrieb erhält Benachrichtigungen, die niemand vorhergesehen hatte.

Und nach ein paar Monaten fragt sich jeder, warum das neue System so viel Ärger macht. Nicht weil die Modernisierung falsch war, sondern weil das alte System sorgfältiger hätte gelesen werden sollen.

Wie dann?

Nicht durch blindes Ersetzen von Legacy. Aber auch nicht durch Stehenlassen von allem. Die Kunst besteht darin, das System zunächst lesbar, dann handhabbar und erst dann ersetzbar zu machen.

Beginne mit Beobachten — und mit Gesprächen. Schaue nicht nur auf Dokumentation, sondern vor allem auf Verhalten. Was kommt rein? Was geht raus? Welche Ausnahmen gibt es? Welche Abteilungen, Maschinen, Berichte oder Entscheidungen hängen von diesem System ab? Und mindestens genauso wichtig: Sprich mit den Menschen, die damit arbeiten. Der Operator, der diese Maschine seit fünfzehn Jahren bedient. Der Administrator, der einmal dieses nächtliche Skript geschrieben hat. Der Planer, der jeden Montag einen Excel-Export durchführt, von dem niemand wusste, dass er existierte. Das echte Prozesswissen steckt oft nicht in Code oder Konfiguration, sondern in den Köpfen der Menschen. Und dieses Wissen verschwindet, wenn man diese Menschen nicht einbezieht, bevor man mit dem Ersetzen beginnt.

Mache das verborgene Prozesswissen explizit. Viel Logik befindet sich nicht mehr in Dokumenten, sondern in Code, Skripten, Datenbankfeldern, Konfigurationsdateien, Operatoraktionen, Excel-Listen und alten Schnittstellen. Kartiere das — nicht um es für eine Schublade zu dokumentieren, sondern um es in das neue Design mitzunehmen.

Lege eine sichere Hülle um das System. Füge Logging hinzu. Füge Monitoring hinzu. Prüfe Backups. Beschränke den Zugang. Segmentiere das Netzwerk. Mache Schnittstellen explizit. Baue möglicherweise eine API-Schicht, Export-Schicht oder Middleware-Komponente. Nicht um das alte System schöner zu machen, sondern um es handhabbar zu machen.

Ersetze dann Schritt für Schritt. Erst eine Schnittstelle. Dann einen Prozessschritt. Dann ein Modul. Wo möglich, lass Altes und Neues vorübergehend nebeneinander laufen. Vergleiche Output, Verhalten, Fehler und Ausnahmen — nicht nur technisch, sondern auch funktional.

Eine Big-Bang-Migration scheint manchmal effizient, aber in Brownfield-Umgebungen ist das oft falsche Sicherheit. Man entdeckt die echte Komplexität erst, wenn das neue System die alte Realität tragen muss.

Die Regel ist einfach: Ersetze keine Komponente, deren Funktion du noch nicht verstehst. Oder schärfer: Du darfst etwas erst ausschalten, wenn du weißt, warum es einmal eingeschaltet wurde.

Modernisierung beginnt mit Verständnis

Legacy ist selten nur ein technisches Problem. Es ist eine Kombination aus Technologie, Prozess, Geschichte und vergessenen Entscheidungen.

Wer nur auf das Alter eines Systems schaut, sieht vor allem Risiko. Wer genauer hinschaut, sieht auch Wissen. Das bedeutet nicht, dass alte Systeme bleiben sollen wie sie sind — manche Systeme müssen wirklich ersetzt werden, manche Schnittstellen sind gefährlich, manche Abhängigkeiten sind unverantwortlich, manche Technologie ist nicht mehr sicher oder handhabbar.

Aber auch dann beginnt gute Modernisierung nicht mit Abriss. Sie beginnt mit Verständnis.

Was tut dieses System wirklich? Warum funktioniert es so? Welches Wissen steckt darin? Was muss bleiben, was kann gehen, was muss neu gestaltet werden?

Legacy entsteht nicht immer, weil Technologie veraltet. Manchmal entsteht Legacy, weil die Welt um das System herum sich ändert. Und genau deshalb ist Modernisierung keine Frage des Ersetzens von Alt durch Neu — es ist das sorgfältige Übertragen von funktionierendem Wissen in eine Form, die wieder zur aktuellen Realität passt.

“If it ain’t broken, don’t fix it.”

Aber vor allem:

“Wenn es nicht kaputt ist, verstehe zuerst, warum es noch funktioniert.”