Zum Inhalt springen

Insights

Technische Schulden abbauen: Wie Sie Ihre IT-Landschaft von der Wachstumsbremse befreien

Verschobene Updates, undokumentierte Erweiterungen und Systeme, die nur noch einer versteht: So bewerten Sie technische Schulden und bauen sie ab, ohne den Betrieb zu unterbrechen.

Dawid SochackiVeröffentlicht am Aktualisiert am 5 Min Lesezeit
Technische Schulden abbauen: Wie Sie Ihre IT-Landschaft von der Wachstumsbremse befreien

Technische Schulden sind der Grund, warum in vielen IT-Abteilungen der größte Teil der Zeit ins Am-Laufen-Halten geht statt in Neues. Sie lassen sich abbauen, aber nur schrittweise, mit Messung statt Bauchgefühl und ohne den Versuch, alles auf einmal neu zu schreiben.

Woran Sie technische Schulden erkennen

Technische Schulden sind die Folgekosten von Abkürzungen: ein Update, das verschoben wurde, weil gerade nichts kaputt war, oder eine Erweiterung, die schnell eingebaut und nie dokumentiert wurde. Dazu das Modul, das nur noch der Kollege versteht, der nächstes Jahr in Rente geht. Jede Abkürzung war für sich vernünftig. Die Summe ist das Problem.

Die Symptome kennen Sie: Releases dauern länger und gehen häufiger schief. Neue Mitarbeiter brauchen Monate, bis sie sich sicher bewegen, und jede Änderung an einer Stelle bricht etwas an einer anderen. Der verlässlichste Indikator ist der Anteil Ihrer Zeit, der in Wartung statt in Verbesserung fließt. Wenn Sie ihn nicht kennen, ist das selbst ein Symptom.

Der häufigste Fall: TYPO3 v12 auf v13 Upgrade durchführen, bevor es teuer wird

Nirgends häufen sich technische Schulden so unauffällig wie im Update-Stau. Ein Content-Management-System wie TYPO3 bekommt für jede Hauptversion nur begrenzt Sicherheitsupdates. Wer das Upgrade von Version 12 auf Version 13 verschiebt, spart kurzfristig Aufwand und läuft danach ohne Patches, während jede veröffentlichte Lücke sein System betrifft. Dazu kommen Erweiterungen, die für die neue Version nicht mehr gepflegt werden, und eine PHP-Version auf dem Server, die ebenfalls ausläuft. Aus einem verschobenen Upgrade wird so ein Projekt, und je größer der Abstand zwischen Ist- und Zielversion, desto teurer der Sprung. Was das Supportende konkret bedeutet, steht in Veraltete TYPO3-Systeme: Warum Ihr CMS das größte Sicherheitsrisiko sein kann.

Schritt eins: Bestand aufnehmen und bewerten

Der Abbau beginnt mit einer Liste, nicht mit einem Werkzeug. Für jedes System notieren Sie Version, Supportstatus, Abhängigkeiten und den Namen der Person, die es im Notfall reparieren kann. Werkzeuge wie SonarQube helfen bei eigenem Code, weil sie Testabdeckung und Komplexität messen. Für zugekaufte Systeme reichen die Versionsliste und ein Blick in die Wartungsverträge.

Bewerten Sie dann jede Schuld nach zwei Fragen: Was passiert dem Geschäft, wenn dieses System morgen ausfällt oder angegriffen wird? Und was kostet es, die Schuld zu beheben? Die Einträge mit großer Wirkung und überschaubarem Aufwand kommen nach oben. Meist sind das Sicherheitslücken in öffentlich erreichbaren Anwendungen und Systeme, deren Backup noch nie zurückgespielt wurde.

Legacy Software modernisieren ohne Ausfall: schrittweise statt Big Bang

Der teuerste Fehler ist der Versuch, das alte System in einem Zug durch ein neues zu ersetzen. Solche Projekte laufen über Jahre, das Altsystem verändert sich währenddessen weiter, und am Stichtag fehlt immer etwas. Modernisierung ohne Ausfall funktioniert anders: Sie lösen einzelne Bausteine heraus, etwa die Anmeldung oder die Dokumentenerzeugung, betreiben sie als eigenständige Dienste neben dem Altsystem und schalten Nutzer stufenweise um. Jeder Schritt hat einen Rückweg. Wenn etwas nicht funktioniert, geht es zurück auf den alten Stand, und kein Anwender hat es gemerkt.

Microservices sind dabei ein Mittel, kein Ziel. Ein Mittelstandsbetrieb mit einer Handvoll Anwendungen braucht keine fünfzig Dienste. Er braucht klare Schnittstellen zwischen den Teilen, die er tatsächlich hat. Den Ablauf in Phasen beschreibt Legacy Software modernisieren ohne Ausfall: Schritt für Schritt statt Big Bang.

Standards verhindern neue Schulden

Ohne Vorgaben entstehen neue Schulden schneller, als Sie alte abbauen. Das verlangt kein Gremium, sondern wenige verbindliche Regeln: Jede Änderung geht durch eine automatisierte Prüfung, bevor sie live geht, und jede Abhängigkeit hat einen Verantwortlichen, der ihr Supportende kennt. Kein System kommt außerdem ohne Staging-Umgebung und getestetes Backup in den Betrieb. Solche Prüfungen gehören in die Auslieferungskette, damit sie ohne Erinnerung laufen. Es geht nicht um Perfektion. Es geht darum, dass ein Verstoß auffällt, bevor er zur nächsten Schuld wird.

Zeit reservieren, sonst passiert nichts

Schuldenabbau, der stattfinden soll, „wenn Zeit ist“, findet nicht statt. Reservieren Sie einen festen Anteil jeder Planungsperiode für Wartung und Modernisierung, und führen Sie die Schulden als eigene Liste, die regelmäßig neu priorisiert wird. Machen Sie sichtbar, was erledigt wurde. Ein abgebautes Risiko ist eine Leistung, auch wenn kein Anwender einen Unterschied sieht. Teams, die diese Zeit haben, verlieren seltener Leute, weil niemand gern jahrelang dasselbe brüchige System flickt.

Wann externe Hilfe sinnvoll ist

Bei Systemen, für die intern niemand mehr die Hand heben will, hilft ein Partner, der die Modernisierung baut und danach betreibt, statt nur ein Konzept abzuliefern. Achten Sie darauf, dass er Betrieb und Wartung mit Reaktionszeiten übernimmt. Unsere Haltung dazu: Reaktionszeit garantiert, Lösung nach bestem Bemühen, und wenn ein System bei einem anderen Anbieter besser aufgehoben ist, sagen wir Ihnen das im ersten Gespräch.

Häufige Fragen

Lassen sich technische Schulden ganz vermeiden? Nein. Jedes Projekt geht Kompromisse zwischen Tempo und Sauberkeit ein. Das Ziel ist, sie bewusst einzugehen, aufzuschreiben und einen festen Rhythmus für den Abbau zu haben.

Wie lange dauert der Abbau? Erste Wirkung zeigt sich, sobald die kritischsten Lücken geschlossen sind, oft nach wenigen Wochen. Eine vollständige Modernisierung gewachsener Landschaften ist ein Vorhaben über Monate bis Jahre und endet nie ganz, weil Software altert.

Der nächste Schritt: eine Liste, ein Nachmittag

Schreiben Sie an einem Nachmittag alle Systeme auf, die Ihr Unternehmen trägt, mit Version, Supportende und der Person, die sie im Notfall repariert. Wo eine Spalte leer bleibt, liegt Ihre größte Schuld. Mit dieser Liste kommen Sie zu uns. Eine halbe Stunde reicht, und wir sagen Ihnen, welche Einträge wir zuerst anfassen würden und was das ungefähr bedeutet: Potenzial-Check buchen.

  • IT-Leitung mit Altsystem-Last

Mehr zum Thema