Warum Legacy nicht das Problem ist

Narben

Als Student habe ich einmal ein paar Tage bei einem Stuckateur gearbeitet. Schmutzige Arbeit. Staub überall.

Der Meister hatte Hände voller Hornhaut und Narben. Spuren vieler kleiner Unfälle und Fehler, die im Laufe eines Arbeitslebens passieren.

Aber was er mit diesen Händen schuf, war beeindruckend.

Mit einfachen Schablonen – manchmal auch freihändig – formte er Stuck, der nahezu perfekt aussah.

Damals dachte ich: Diese Hände sind kaputt.

Heute denke ich anders darüber.

Diese Hände waren nicht kaputt. Sie waren erfahren.

Jede Narbe erzählte von einem Problem, das einmal gelöst werden musste.

Wer ein Legacy-System liest, stößt schnell auf Stellen, die Fragen aufwerfen.

Workarounds. Seltsame Datenstrukturen. Entscheidungen, die auf den ersten Blick keinen Sinn ergeben.

Viele nennen das technische Schulden.

Aber oft sind es einfach Narben.

Spuren realer Probleme, die irgendwann gelöst werden mussten.

Software entsteht nicht im Lehrbuch.

Sie entsteht in der Realität von Unternehmen:

Ein Legacy-System ist deshalb mehr als alter Code.

Es ist ein Archiv von Entscheidungen.

Es enthält Wissen über Prozesse und Abläufe, das sich über Jahre aufgebaut hat.

Viele Projekte beginnen mit der falschen Frage:

„Wie ersetzen wir dieses System?”

Die wichtigere Frage wäre:

„Warum ist dieses System so geworden, wie es ist?”

Wenn dieses Verständnis fehlt, wird beim Neubau nicht nur Technologie ersetzt.

Oft geht auch Wissen verloren.

Modernisierung bedeutet deshalb nicht, Legacy zu zerstören.

Modernisierung bedeutet zuerst:

Welche Prozesse trägt das System? Welche Entscheidungen sind darin verborgen?

Erst danach kann man sinnvoll modernisieren.

Schritt für Schritt.

Legacy ist kein Zeichen von Rückstand.

Legacy ist ein Zeichen dafür, dass ein System lange genug überlebt hat, um wichtig zu werden.

Die Aufgabe guter Architektur ist deshalb nicht, Legacy loszuwerden.

Die Aufgabe guter Architektur ist es, Legacy zu verstehen.