Alte Systeme, zunehmende Komplexität und höhere Sicherheitsrisiken: Viele Unternehmen kämpfen mit veralteten IT-Landschaften. Nadine Riederer, CEO bei Avision, erklärt im Interview mit ITWelt.at, warum digitales Aufräumen oft sinnvoller ist als ein kompletter Neubau, wie man den Wert sauberer Software misst und welche Rolle KI-gestützte Tools heute spielen. [...]
Sie haben kürzlich in einem Kommentar guten Code mit einer aufgeräumten Wohnung verglichen. Wo sehen Sie die größten strategischen Parallelen zwischen digitalem Ausmisten und klassischem IT-Management?
Der erste Schritt ist immer eine saubere Bestandsaufnahme. Man muss wissen, welche Systeme und Anwendungen überhaupt im Einsatz sind, in welchem Zustand sie sich befinden und wofür sie genutzt werden. Ohne diese Baseline fehlt die Grundlage für jede strategische Entscheidung. Gleichzeitig gilt es, die relevanten Stakeholder einzubeziehen: Wer arbeitet mit den Anwendungen? Welche Abhängigkeiten bestehen? Das ist vergleichbar mit einer Wohnung – auch dort muss ich erst einmal wissen, was ich überhaupt habe, bevor ich entscheiden kann, was bleibt und was wegkommt.
Viele Unternehmen kämpfen mit historisch gewachsenen, monolithischen Systemen. Ab welchem Punkt lohnt sich das „Aufräumen“ mehr als ein kompletter Neubau?
Grundsätzlich lohnt es sich fast immer, zunächst aufzuräumen, weil das Risiko deutlich geringer ist. Schritt für Schritt lassen sich Systeme modernisieren, ohne gleich alles neu aufsetzen zu müssen. So, wie man auch eine Wohnung nach und nach umgestalten würde, statt alle Möbel radikal zu entsorgen und neu zu kaufen. Letzteres ist meist nur für diejenigen möglich, die über sehr große Budgets verfügen. Natürlich gibt es Ausnahmen: Wenn Technologien so veraltet sind, dass sie keine Zukunft mehr haben – zum Beispiel bei Legacy-Systemen in Cobol – führt kein Weg an einem Neubau vorbei. Aber in den meisten Fällen ist der evolutionäre Weg, also ein kontinuierliches Aufräumen, langfristig erfolgreicher und nachhaltiger als die große Revolution.
Welche Methoden und Kennzahlen haben sich in der Praxis bewährt, um ungenutzte oder überflüssige Codebestandteile systematisch zu identifizieren?
Hier kommen unterschiedliche Tools ins Spiel – je nach Programmiersprache. Ein bekanntes Beispiel ist SonarQube, das nicht nur ungenutzten oder toten Code identifiziert, sondern auch direkt in den Entwicklungsumgebungen Warnungen ausgibt. Daneben gibt es weitere spezialisierte Tools wie Knip. Solche Werkzeuge helfen, strukturiert und nachvollziehbar Code-Ballast sichtbar zu machen und geben Teams eine objektive Grundlage für Entscheidungen.
Wie lässt sich ein kontinuierlicher Pflegeprozess verankern, wenn viele Unternehmen Software-Entwicklung immer noch projektbasiert denken?
Ein reines Projektdenken führt oft dazu, dass nur neue Features entwickelt werden, aber grundlegende Aufräumarbeiten auf der Strecke bleiben. Nachhaltig funktioniert es nur, wenn Unternehmen Software-Entwicklung als Lifecycle-Prozess begreifen. Das bedeutet: Auch zwischen Projekten muss kontinuierlich gepflegt, aktualisiert und aufgeräumt werden – etwa durch das Entfernen veralteter Bibliotheken oder das Einspielen von Sicherheitspatches. Eine wichtige Unterstützung bietet dabei eine Software Bill of Materials (SBOM), also eine Stückliste aller eingesetzten Komponenten, Abhängigkeiten und Bibliotheken. Mit Tools wie DependencyTrack lässt sich dadurch sehr einfach prüfen, was aktualisiert oder entfernt werden muss.
Sie erwähnen, dass Entwickler „Mut“ brauchen, um sich von Altem zu trennen. Wie wird dieser Mut in Ihrem Team gefördert, und welche internen Prozesse helfen dabei, die Risiken zu minimieren?
Wir setzen stark auf das sogenannte Pfadfinder-Prinzip: Jede Stelle im Code sollte besser verlassen werden, als man sie vorgefunden hat. Dafür schaffen wir eine Kultur ohne Fingerpointing – Fehler sind erlaubt, solange sie dazu beitragen, den Code langfristig zu verbessern. Mut darf nicht bestraft werden.
Gleichzeitig achten wir darauf, dass Aufräumarbeiten nicht im blinden Aktionismus enden. Jede Änderung sollte geplant erfolgen. Das wichtigste Sicherheitsnetz sind Tests – idealerweise automatisierte. Bevor Code entfernt wird, stellen wir sicher, dass die Anwendung testbar ist. So lassen sich Seiteneffekte besser kontrollieren, auch wenn sie nie vollständig ausgeschlossen werden können.
Wie lässt sich der Wert „aufgeräumter Software“ quantifizieren, um ihn gegenüber Stakeholdern und Budgetverantwortlichen transparent zu machen?
Unaufgeräumte Software ist teuer – und zwar auf vielen Ebenen. Sie verursacht hohe Entwicklungskosten, weil jede Änderung aufwendig analysiert werden muss und Seiteneffekte schwer abzuschätzen sind. Rollouts bergen ein hohes Risiko, Testabdeckungen sind oft lückenhaft und Ausfallrisiken steigen. All das verzögert die Time-to-Market und belastet Budgets langfristig.
Auf der anderen Seite lässt sich der Nutzen aufgeräumter Software durchaus messen: durch Benchmarks mit vergleichbaren, modernisierten Anwendungen, durch eine niedrigere Anzahl an Hotfixes nach Releases, eine geringere Ausfallhäufigkeit oder eine signifikant schnellere Time-to-Market. Auch die laufenden Betriebskosten sind in aufgeräumten Systemen deutlich niedriger.
Sehen Sie im Bereich KI-gestützter Tools eine neue Qualität beim „Aufräumen von Code“? Welche Tools gibt es?
Die Antwort ist ein klares „Jein“. KI-gestützte Tools wie ChatGPT, Gemini, Microsoft Copilot oder Mistral sind bereits heute eine große Hilfe – insbesondere bei Dokumentation, Vorschlägen für Refactoring oder beim Erstellen von Code. Je neuer und kleiner eine Anwendung ist, desto besser funktionieren diese Werkzeuge.
Bei älteren, monolithischen Anwendungen stoßen sie aber noch an Grenzen: Die Vorschläge sind nicht immer optimal und erfordern eine erfahrene Entwicklerhand, die bewertet, korrigiert und in kleinen Schritten weiterarbeitet. KI kann hier also unterstützen, aber sie nimmt uns die Arbeit nicht ab. Wir gehen davon aus, dass sich das in den kommenden Jahren deutlich verbessern wird. Aktuell aber bleibt das Zusammenspiel aus Werkzeugen und Erfahrung der entscheidende Erfolgsfaktor.
Be the first to comment