IT-Management
Technische Schuld
Ein übliches Szenario im IT-Bereich ist unter dem Begriff “historisch gewachsen” oder “technische Schuld” bekannt:
Ihre IT-Landschaft ist über die Zeit komplex und unübersichtlich geworden, einige Anwendungen müssten mal “aufgeräumt” werden, eine Prüfung der IT-Architektur oder nur einiger Anwendungen wäre angebracht. An dieser Stelle sind zwei grundsätzliche Handlungsfelder zu berücksichtigen.
Der Fix
Zum einen ist es angeraten, die dringendste technische Schuld zeitnah zu beseitigen. Häufig behindern veraltete, fehlerbehaftete Anwendungen oder eine suboptimale Architektur die Geschäftsprozesse, vereinzelt werden SLAs von Services gefährdet. In diesen Fällen ist die Wiederherstellung der Service-Funktionalität prioritär. Workarounds als temporäre Maßnahme können den Zeitraum bis zur Umsetzung einer soliden Lösung überbrücken.
Solide Lösung
Das zweite Handlungsfeld besteht darin, eine solide Lösung zu entwickeln. Hier geht es nicht nur allein um die Entwicklung einer technisch nachhaltigen Lösung, sondern auch um den Entwurf einer Strategie, die technische Schuld zukünftig weitestgehend vermeidet. Insbesondere bei unternehmenskritischen Anwendungen kann ein regelmäßiges Refactoring viel Zeit und Ärger im Nachgang ersparen, da der “Clean-Code” Level und die Architektur konstant auf einem hohen Niveau gehalten werden. Die Fehleranfälligkeit sinkt hierdurch, zukünftige Releases können aufgrund der aufgeräumten Software-Struktur pünktlich geliefert werden.
Nachhaltigkeit
Häufig wird auf Refactoring-Phasen verzichtet, da sie keine neuen Funktionalitäten bereitstellen. Tatsächlich aber werden durch den Verzicht zukünftige Features immer langsamer und schwieriger umgesetzt werden können. Zudem nimmt die Fehleranfälligkeit und damit das Riskio von Service-Ausfällen zu. Es ist unter dem Strich in der Regel günstiger, regelmäßige Refactoring-Phasen in den normalen Entwicklungsprozess zu integrieren.