Mobile-Menu

Infrastruktur-Erneuerung ohne Big Bang Modernisierung ist der bessere Neubau

Von Jürgen Bernert 6 min Lesedauer

Viele ältere IT-Systeme funktionieren zwar, ihre Staubschicht bremst aber Performance, Sicherheit und Weiterentwicklung. Die Lösung: Eine schrittweise Modernisierung, die technische Schulden reduziert und Innovationen ermöglicht, ohne den Betrieb zu unterbrechen.

Historisch gewachsenes Code-Chaos voller Abhängigkeiten und Sicherheitslücken? Hier schafft eine schrittweise Modernisierung nachhaltige Abhilfe.(Bild: ©  Ilja - stock.adobe.com)
Historisch gewachsenes Code-Chaos voller Abhängigkeiten und Sicherheitslücken? Hier schafft eine schrittweise Modernisierung nachhaltige Abhilfe.
(Bild: © Ilja - stock.adobe.com)

Wer in der IT arbeitet, kennt das Szenario genau: Etliche Anwendungen erledigen im laufenden Betrieb ihre Aufgaben zwar zur Zufriedenheit der Fachseite, unter der Haube versteckt sich aber ein über die Jahre gewachsenes Code-Chaos und undurchsichtige Abhängigkeiten. Selbstverständlich ist von einer Dokumentation keine Spur, die Performance befindet sich seit geraumer Zeit im freien Fall und potenzielle Sicherheitslücken würden den Verantwortlichen Albträume bereiten – wenn sie denn davon wüssten.

Dystopische Einzelfälle? Nein, eher Alltag in vielen Unternehmen. Erschwerend kommt hinzu, dass die Zeit nicht auf Seiten der Entwickler-Teams ist. Immer noch sind unzählige Systeme im Betrieb, die schon 20 oder 30 Jahre auf dem Buckel haben und in grauer Vorzeit von einer einzigen Person entwickelt wurden. Während das Wissen um die Architektur und Logik also auf wenigen Schultern ruht, kreisen Renteneintritt, Ausfall oder Jobwechsel wie ein Damoklesschwert über der Anwendung.

Gründe gibt es also genug, um die eigenen angestaubten Systeme einmal genauer unter die Lupe zu nehmen und fit für zukünftige Aufgaben zu machen. Dabei stellt sich die Frage nach dem richtigen Vorgehen. Frühere Ansätze, Systeme komplett neu aufzubauen, sind regelmäßig gescheitert. Gründe dafür gibt es viele, allen voran konnten die Fachabteilungen in vielen Fällen schlicht ihre Anforderungen nicht präzise formulieren. Lösungsversuche wie der Einsatz einer Modellierungssprache, etwa UML (Unified Modeling Language), waren zwar eine nette Idee, haben die Komplexität allerdings nur weiter erhöht. Big-Bang-Migrationen bergen daneben aber auch weitere hohe Risiken wie Betriebsstillstand, Dateninkonsistenzen oder massive Fehlerwahrscheinlichkeit. Ein kompletter Neubau ignoriert das über Jahre gewachsene Wissen und erzeugt neue technische Schulden. Was also tun?

Schrittweise Modernisierung und KI-gestützte Analyse

Neuere, in der Praxis bereits bewährtere Vorgehensweisen setzen auf eine iterative Modernisierungsstrategie. Systeme werden also modulweise modernisiert, ungenutzte Funktionen abgeschaltet, technische Schulden schrittweise abgebaut. Jede Änderung liefert einen echten Wert, erlaubt Kurskorrekturen und reduziert Abhängigkeit. Wer wissen will, was sich alles in seinem historischen Code versteckt hält, kann glücklicherweise auf moderne, KI-gestützte Tools zurückgreifen, die bestehende Anwendungen analysieren, Abhängigkeiten erkennen und ungenutzte Funktionen identifizieren. Die KI liefert dabei lediglich Vorschläge und verschafft Entwicklern einen wichtigen Überblick. Wichtig ist, dass jede Empfehlung weiterhin von Fachanwendern validiert wird. Entscheidungen, welche Funktionen die Mitarbeitenden in Zukunft benötigen oder ob bestehende Prozesse verändert werden, bleiben fest in menschlicher Hand.

Für nachhaltig erfolgreiche und effiziente Modernisierungsprojekte muss die initiale Analyse zunächst grundlegende Fragen der tatsächlichen Nutzung klären: Welche Prozesse greifen auf welche Module zu? Wo liegen kritische Abhängigkeiten? Nur mit diesen Informationen lässt sich ein belastbares Modernisierungskonzept erstellen. KI-Tools unterstützen zudem bei der Priorisierung von Modulen nach Geschäftsrelevanz und Risiko – vor allem in Systemen, die jahrzehntelang gewachsen sind.

Für den Durchblick: Das große Entwirren

Besonders Legacy-Systeme sind oft chaotisch aufgebaut, der berühmte „Big Ball of Mud“ ist also keine Seltenheit. Änderungen in einem Modul lösen Seiteneffekte und Fehler aus, die Wartung wird in der Konsequenz teuer und riskant. Ein nicht neuer aber verlässlich funktionierender Lösungsweg für das Entwirren des Chaos-Codes ist weiterhin ein Domain-Driven Design, mit dem Entwickler-Teams den Code so strukturieren, dass er einzelne fachliche Domänen klar abbildet. Mit dieser Strategie sind relevante Code-Bereiche bei fachlichen Änderungen zukünftig schnell und eindeutig identifizierbar.

Diese architektonische Trennung ist fundamental für die langfristige Wartbarkeit und Erweiterbarkeit des Systems. Eng damit verbunden ist der Einsatz von Microservices, die es ermöglichen, einzelne fachliche Bereiche unabhängig voneinander zu entwickeln, zu deployen und zu skalieren. Aber Achtung beim Ausmisten: Nicht alles muss in den virtuellen Mülleimer. In enger Absprache mit der Fachseite sollte entschieden werden, welche gut funktionierenden Funktionen erhalten bleiben, welche kritischen Module modernisiert werden müssen und welche ein für alle Mal aussortiert gehören.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Netzwerktechnik, IP-Kommunikation und UCC

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Die konkrete Umsetzung sollte nach Möglichkeit agilen Prinzipien folgen – die Vorteile überwiegen schlicht. Während ein erstes Minimalprodukt entwickelt und Schritt für Schritt erweitert wird, können auf diese Weise Unit-, Integrations-, System- und Akzeptanztests kontinuierlich die Funktionalität sichern.

Fachliche Einbindung und Ressourcenplanung

Die größte Herausforderung der schnell komplexen Modernisierung ist in vielen Fällen, wie oftmals fälschlich angenommen, nicht die IT-Personaldecke, sondern die Verfügbarkeit fachlicher Ressourcen. Fachanwender müssen aber unbedingt kontinuierlich eingebunden sein, um Prozesse zu bewerten, Prioritäten zu setzen, generierte User Stories zu prüfen und Testfälle zu validieren. Ohne diese Einbindung entstehen Systeme, die den tatsächlichen Bedarf nicht abbilden.

Die Freistellung von Fachkräften aus dem Tagesgeschäft ist oft entscheidender als die Bereitstellung von Entwicklern. KI kann Analyse und Artefakterstellung beschleunigen, ersetzt aber keine langjährige menschliche Expertise aus dem Arbeitsalltag. Nur durch kontinuierliche Abstimmung lassen sich Prozessoptimierungen und funktionale Anforderungen korrekt umsetzen. Die Einbindung erfolgt optimalerweise schrittweise, in Sprints: Fachanwender überprüfen User Stories, definieren Testfälle, validieren Masken und geben kontinuierliches Feedback. So entsteht eine enge Schleife zwischen technischer Umsetzung und fachlicher Realität.

Technische Schulden runter, Sicherheit hoch

Technische Schulden manifestieren sich nicht nur in unleserlichem Code oder fehlender Dokumentation, sondern vor allem in gewachsenen Abhängigkeiten – und diese sind heute eines der größten Sicherheitsrisiken in Legacy-Systemen. Sicherheit ist deshalb kein nachgelagerter Aspekt der Modernisierung, sondern muss von Beginn an integraler Bestandteil jeder technischen Analyse sein.

Grundsätzlich entstehen Sicherheitslücken auf zwei Ebenen: durch selbst geschriebenen Code und durch eingesetzte Komponenten und Bibliotheken. Erstere sind meist beherrschbar. Saubere Programmierung, valide Eingabeprüfungen und korrekt initialisierte Variablen verhindern klassische Angriffsvektoren wie SQL- oder XML-Injection. Diese Risiken sind bekannt, gut dokumentiert und mit etablierten Entwicklungsstandards adressierbar.

Das deutlich größere Gefahrenpotenzial liegt jedoch in externen Abhängigkeiten. Weit verbreitete Bibliotheken und Frameworks sind für Angreifer besonders attraktiv, weil sich der Rechercheaufwand mehrfach auszahlt. Während individuell entwickelter Code einen gezielten Angriff erfordert, existieren für bekannte Schwachstellen in Standardkomponenten oft tausende fertige Exploits. Die Log4j-Krise hat dieses strukturelle Problem exemplarisch und drastisch offengelegt.

Für Modernisierungsprojekte folgt daraus eine zwar unbequeme, aber zwingende Konsequenz: Ein laufendes Migrationsprojekt rechtfertigt keinen Weiterbetrieb eines unsicheren Altsystems. Kritische Sicherheitslücken dürfen nicht über Monate oder Jahre toleriert werden, nur weil bald, einen genaueren Zeitpunkt gibt es meistens nicht, ein neues System entstehen soll. Patch- und Update-Management wollen daher frühzeitig etabliert sein, ganz explizit auch für das bestehende System.

Konkret bedeutet das:

  • Vollständige Identifikation aller eingesetzten Komponenten und Bibliotheken.
  • Abgleich mit bekannten Sicherheitslücken und verfügbaren Updates.
  • Ersatz von Abhängigkeiten, die nicht mehr gepflegt oder aktualisiert werden können.
  • Klare Entscheidung, welche Komponenten wiederverwendbar sind und welche nicht.

In manchen Fällen existiert für eine verwundbare Komponente kein direkter Nachfolger. Dann führt kein Weg an einer Neuentwicklung vorbei. Paradoxerweise geschieht diese optimalerweise zuerst im alten System. Die Komponente wird isoliert, mit Tests abgesichert, neu implementiert und anschließend sowohl im Legacy- als auch im Zielsystem eingesetzt. Dieser Ansatz reduziert Risiken, verkürzt die spätere Migration und verhindert doppelte Arbeit.

Damit verschiebt sich aber auch der Blick auf Modernisierung grundlegend. Sie ist kein harter Übergang von alt zu neu, sondern ein kontinuierlicher Sicherheits- und Qualitätsprozess, der beide Welten gleichzeitig betrifft. Verbesserungen im Altsystem sind kein verlorener Aufwand, sondern fließen direkt in die Zielarchitektur ein. Eng damit verknüpft ist die Frage der eingesetzten Technologien. Ein Wechsel der Programmiersprache ist dabei selten der entscheidende Hebel. Bestehender Code kann auch innerhalb derselben Sprache modernisiert werden – durch bessere Strukturierung, klar abgegrenzte fachliche Domänen und saubere Schnittstellen. Die Wahl einer neuen Sprache oder Plattform ist vielmehr eine strategische Abwägung zwischen Stabilität, Performance, Fachlichkeit und Ressourcenverfügbarkeit.

Jürgen Bernert.(Bild:  Avision)
Jürgen Bernert.
(Bild: Avision)

Nachhaltige Modernisierung gelingt durch konsequente Detailarbeit. Wer technische Schulden abbaut, ohne Abhängigkeiten und Sicherheitsrisiken systematisch zu adressieren, verschiebt das Problem lediglich. Erst wenn Analyse, Sicherheitsbewertung, fachliche Strukturierung und schrittweise Erneuerung zusammenspielen, entstehen Systeme, die stabil, erweiterbar und sicher sind. Ohne Stillstand, ohne Big Bang und ohne neue Altlasten.

Über den Autor

Jürgen Bernert ist Geschäftsführer des auf IT-Revival spezialisierten Dienstleisters Avision.

(ID:50772282)