Software-Modernisierung: Altsysteme reparieren, ersetzen oder in Ruhe lassen

Was ein System zum Altsystem macht

Das Alter ist nicht das Kriterium. Software, die vor fünfzehn Jahren geschrieben wurde und die verstanden, dokumentiert und günstig zu ändern ist, ist kein Altsystem. Software, die vor drei Jahren geschrieben wurde und die niemand anzufassen wagt, schon.

Die praktische Definition ist einfacher: Ein System ist ein Altsystem, wenn die Kosten einer Änderung in keinem Verhältnis zum Umfang der Änderung stehen. Alles andere – das alte Framework, die nicht mehr unterstützte Datenbank, der Entwickler, der gegangen ist – zählt nur wegen seiner Wirkung auf diese Zahl.

Die Modernisierung von Legacy-Software – im amerikanischen Englisch „legacy modernization“ – ist die Arbeit, diese Zahl wieder zu senken. Softwaremodernisierung dieser Art ist nicht automatisch dasselbe wie der Ersatz der Software.

Es gibt vier Optionen, nicht zwei

Das Gespräch schrumpft meist auf „neu bauen oder nichts tun“ zusammen. Dazwischen liegen zwei weitere Optionen, und oft sind sie die richtigen.

In Ruhe lassen

Das System ist stabil, das Unternehmen verlangt keine Änderungen, und es ist kein Sicherheitsrisiko. Das ist eine legitime Antwort und wird zu selten gewählt. Software, die fertig ist, braucht kein Projekt.

Warten und eingrenzen

Halten Sie das System gepatcht, überwacht und sicher, und bauen Sie nichts mehr daran an. Neue Arbeit findet anderswo statt. Das verschafft günstig Jahre an Zeit und ist der richtige erste Schritt, solange der Fall für einen Neubau nicht belegt ist.

Im laufenden Betrieb modernisieren

Ersetzen Sie Teile davon, während es weiterläuft – ein Modul, eine Integration, eine Ansicht nach der anderen. Pro Arbeitseinheit langsamer, aber der Betrieb steht nie still, und jeder Schritt ist umkehrbar.

Neu bauen

Neu anfangen, mit demselben geschäftlichen Bedarf und einer neuen Umsetzung. Die teuerste und riskanteste Option und gelegentlich die einzig ehrliche Antwort – meist dann, wenn die Plattform selbst am Ende ist, nicht bloß veraltet.

Welcher Ansatz zur Modernisierung von Altanwendungen passt

Es gibt nicht den einen richtigen Weg, Altsysteme zu modernisieren. Die Entscheidung fällt leichter, wenn Sie nicht mehr fragen, wie alt das System ist, sondern was es Sie kostet.

Warten und eingrenzen passt, wenn das System seine Aufgabe erfüllt, Änderungen selten sind und sich die Beschwerden auf das Aussehen beziehen statt auf die Funktion. Nichts davon rechtfertigt ein Projekt.

Modernisierung im laufenden Betrieb passt, wenn bestimmte Teile des Systems den Großteil der Probleme verursachen. Wenn vier Fünftel Ihrer Änderungsanfragen ein einziges Modul betreffen, haben Sie das Problem gefunden – und es ist nicht die ganze Anwendung.

Ein Neubau passt, wenn die darunterliegende Plattform tatsächlich am Ende ist – eine Laufzeitumgebung ohne Sicherheitsupdates, ein Anbieter, den es nicht mehr gibt, eine Datenbank, die sich nicht mehr lizenzieren lässt – oder wenn sich das Geschäft, das die Software abbildet, so grundlegend verändert hat, dass das Datenmodell falsch ist und nicht nur alt.

Ein System, das überall teuer zu ändern ist, ohne dass sich die Probleme irgendwo bündeln, hat meist ein Dokumentations- und Wissensproblem statt eines technischen. Das ist günstiger zu beheben als eine Modernisierung oder ein Neubau, und es lohnt sich, es zuerst auszuschließen.

Warum ein Neubau nicht der Standard sein sollte

Ein Neubau ist verlockend, weil die neue Version nur als Idee existiert, und Ideen haben keine Sonderfälle. Das abzulösende System hat fünfzehn Jahre davon angesammelt, die meisten undokumentiert, viele davon tragend.

Das zweite Problem ist die Dauer. Ein Neubau liefert nichts, bis er alles liefert. Das Unternehmen betreibt also zwei Systeme, finanziert zwei Teams und friert das alte System für die Dauer des Projekts ein. Währenddessen bringen die Wettbewerber Neues heraus.

Das dritte: Bei einem Neubau werden teure Lektionen noch einmal gelernt. Die seltsame Regel in der Preislogik steht meist da, weil etwas passiert ist, und wer sich daran erinnert, ist oft nicht mehr da. Welche Regeln wichtig waren, merken Sie, wenn der Neubau ohne sie in Produktion geht.

Nichts davon macht einen Neubau falsch. Es macht ihn zu der Option, für die man argumentieren muss, statt zu der, von der alle ausgehen.

Modernisierung im laufenden Betrieb in der Praxis

Die Modernisierung von Altanwendungen dieser Art funktioniert so, dass das neue System vor das alte gesetzt wird und Funktionen Stück für Stück hinüberwandern. Der Traffic wird an die Implementierung geleitet, die das jeweilige Stück gerade verantwortet, und das alte System schrumpft, während das neue wächst.

Der Nutzen: Jeder Schritt ist klein, releasefähig und umkehrbar. Ist ein Schritt falsch, leiten Sie zurück und beheben ihn, statt das Problem erst nach zwei Jahren zu entdecken.

Die Kosten sind real: Eine Zeit lang betreiben Sie zwei Systeme und das Routing dazwischen, was komplexer ist als jedes der beiden für sich. Das ist der Preis dafür, den Betrieb nicht anzuhalten, und er lohnt sich in der Regel.

Es verändert auch das Gespräch über die Finanzierung. Eine schrittweise Modernisierung lässt sich neben der Feature-Arbeit aus dem normalen Entwicklungsbudget bezahlen, während ein Neubau eine Investitionsentscheidung braucht und einen Sponsor in der Geschäftsleitung, der auf seinem Posten bleibt.

Was Warten tatsächlich kostet

Die Entscheidung aufzuschieben ist selbst eine Entscheidung, und sie hat einen Preis, den man benennen sollte.

Änderungen werden jedes Jahr langsamer, also kostet dieselbe Roadmap mehr. Das Recruiting wird schwieriger, weil Engineers verständlicherweise ungern Jahre auf einer Plattform ohne Zukunft verbringen. Das Sicherheitsrisiko wächst, denn auch in nicht mehr unterstützten Abhängigkeiten werden weiter Schwachstellen entdeckt. Und das Wissen geht weiter mit den Menschen, die es haben.

Nichts davon erzwingt eine Entscheidung in diesem Quartal. Zusammen erklären sie, warum die Systeme, die in Panik neu gebaut werden, fast immer jene sind, die man noch ein Jahr hat laufen lassen – mehrere Jahre in Folge.

Fragen, die Sie vor einer Festlegung beantworten sollten

Was kostet eine typische Änderung heute?

Vergleichen Sie eine kleine Änderung heute mit derselben Änderung vor fünf Jahren. Kann das niemand beantworten, ist das das Erste, was gemessen werden sollte – die gesamte Entscheidung beruht auf dieser Zahl.

Wo bündeln sich die Probleme?

Sehen Sie sich die letzten fünfzig Änderungen an und welche Teile des Systems sie betrafen. Eine Bündelung spricht für eine Modernisierung im laufenden Betrieb, eine gleichmäßige Verteilung für etwas anderes.

Was passiert, wenn Sie zwei Jahre lang nichts tun?

Lautet die Antwort, dass es weiterläuft und nichts offenliegt, haben Sie mehr Zeit, als das Gespräch vermuten lässt. Geht es um eine nicht mehr unterstützte Laufzeitumgebung oder einen Anbieter, den es nicht mehr gibt, haben Sie weniger.

Wer versteht die aktuellen Regeln noch?

Was auch immer Sie entscheiden: Dieses Wissen muss aufgeschrieben werden, bevor diese Menschen gehen. Das sollte vor dem Projekt geschehen statt währenddessen.

Lässt es sich schrittweise finanzieren?

Ein Plan, der drei ununterbrochene Jahre und einen einzigen Sponsor braucht, ist fragil. Einer, der jedes Quartal Nutzen liefert, übersteht Budget- und Führungswechsel.