Leider gilt auch in der Softwaremodernisierung, dass es sehr stark darauf ankommt, um welche Art der Modernisierung es sich handelt. Je nach Ausgangsbasis und Zielen sind unterschiedliche Kategorien von Werkzeugen notwendig. In diesem Artikel wird eine Einordnung möglicher Vorgehensweisen auf Basis der Auslöser eines Modernisierungsvorhabens vorgestellt: Strategie, Business oder Entwicklung.
Strategie-initiierte Softwaremodernisierung
Bei der Strategie-initiierten Softwaremodernisierung liegt der Schwerpunkt auf der Umsetzung eines übergeordneten Transformationsprogramms oder -plans innerhalb eines Unternehmens. Typische Programme sind etwa «Digitale Transformation», «Cloud-Migration» oder unternehmensweite Konsolidierungsvorhaben. Charakteristisch für diese Art von Modernisierungsprogrammen ist, dass diese von der Unternehmensleitung oder der IT-Führungsebene initiiert sind und darauf abzielen, die gesamte IT-Infrastruktur und/oder Softwarelandschaft des Unternehmens zu modernisieren. Die Modernisierung wird im Einklang mit den strategischen Zielen und Bedürfnissen des Unternehmens geplant und durchgeführt, um langfristige Wettbewerbsvorteile (wieder) zu erzielen. Ausgangsbasis sind oft Strategiepapiere und grob beschriebene Transformationsprogramme. Meist sind die Ziele der Modernisierung noch nebulös beschrieben («schnellere Time-to-Market», «360° Customer Excellence», «Digitalisierungspartner für Branche XY werden»). Doch der Umfang dieser Art der Modernisierung kann enorm sein, da er nicht nur Veränderungen in der Technik umfasst, sondern auch Prozesse, Arbeitsabläufe und Organisationsstrukturen. Daher unterliegen Strategie-initiierte Softwaremodernisierungen einem hohen Risiko des Scheiterns, da im Worst Case über Jahre hinweg unklare Ziele mit extrem viel Aufwand im zwei- bis dreistelligen Millionenbereich verfolgt werden. Zudem sind typische Herausforderungen ein fehlendes Verständnis in der vorhandenen Belegschaft, ein großer Gap zwischen den Wünschen und der vorhandenen IT, sowie dadurch eine inhärente Orientierungslosigkeit und institutionelle Überforderung. Daher wird bei dieser Modernisierungsvariante neben einem separaten Budget auch ein Fokus auf ein umfassendes Change Management notwendig.
Auf der IT-Seite ist es ratsam, konsequent die Konkretisierung der strategischen Ziele einzufordern. Insbesondere muss die Notwendigkeit und der Hintergrund der Programmdurchführung motiviert werden. Ein Check auf Verständlichkeit und der inhaltlichen Integrität der Veränderungsbedarfe ist dringend notwendig, um zu vermeiden, mit unterschiedlich verstandenen Zielen Aktionen loszutreten. Daher ist eine unabhängige Prüfung der vorhandenen Zukunftspläne unerlässlich. Danach erfolgt die Ausarbeitung bzw. die Aktualisierung der IT-Strategie. Im besten Fall enthält diese aus der Transformationsvision abgeleitete greifbare und verständliche Ziele. Auch können hier bereits schnell nachvollziehbar abgeleitete erste No-Brainer-Maßnahmen (z. B. Ausruf eines Einkaufsstopps von neuer On-Premise-Software, wenn Softwaresysteme in die Cloud migriert werden sollen) erarbeitet werden.
Da der Scope bei Programmen meist sämtliche IT-Systeme in einem Unternehmen umfasst, ist hier die Erarbeitung eines Überblicks z. B. in Form eines Softwareinventars sinnvoll. Das Unternehmen muss wissen, wo es aktuell steht, bevor die Schritte in Richtung der Ziele vorgenommen werden können. Um dieses Situationsbewusstsein initial effizient zu erstellen, sollten betroffene Systeme und IT-Infrastrukturkomponenten als Blackbox grob erfasst werden, um sich anfangs nicht in Details zu verlieren. Relevanter sind die Zusammenhänge zwischen Systemen und der von ihnen benötigten Infrastruktur. Um Überblicke über die derzeitige Situation zu erhalten, sind hier Techniken aus dem klassischen Enterprise-Architektur-Umfeld wie ArchiMate unter Verwendung von Enterprise-Architektur-Management-Softwaresystem (z. B. leanIX) möglich. Innovative Startpunkte bieten hier die Wardley-Mapping-Technik zur wertorientierten Visualisierung der Zusammenhänge in der IT im Zusammenspiel mit Domain-Driven Design (DDD) zur Bewertung von Softwaresystemen. Für die Dokumentation von IT-Prozess- und Organisationsthemen können klassische Verfahren aus der Geschäftsprozessmodellierung als auch Organisationsschaubilder verwendet werden, um ein gemeinsames Bild über Abläufe und Personal zu gewinnen. Auf der anderen Seite liegen hier derzeit Team Topologies sowie Big Picture Event Stormings aus dem DDD derzeit im Trend, welche in agilen Umfeldern passender einsetzbar sind.
Damit eine Strategisch-initiierte Softwaremodernisierung nicht im Sande verläuft, braucht es hier auch eine grobe Modernisierungs-Roadmap, welche die geplanten Schritte, messbare Meilensteine und Zeitpläne für die Umsetzung des Transformationsprogramms festlegt, einschließlich der Priorisierung von notwendigen Initiativen und der zugeordneten Personalkapazitäten und Ressourcen. Leichtgewichtig kann dies etwa mit einer Technologie-Roadmap umgesetzt werden, in der verschiedene Praktiken und Technologien mit verschiedenen Support-Zeithorizonten verortet oder einfachen Lebensphasen (abwarten, ansehen, austesten, anwenden, aufhören, abbauen) versehen werden. Die detaillierten Ziele und klaren Prioritäten helfen bei der Fokussierung und dem späteren Check, ob das Gesamtvorhaben auf dem richtigen Weg ist. Dies schafft eine solide Basis, nachfolgend die Modernisierung einzelner Softwaresysteme und deren Infrastruktur Schritt für Schritt zielgerichtet anzugehen.
Business-initiierte Softwaremodernisierung
Die Business-initiierte Softwaremodernisierung bezieht sich auf die Modernisierung eines bestimmten Softwareprodukts (auch: Produktlinie oder Teil eines Produkts) aus geschäftlichen Gründen. Diese Art der Modernisierung wird in der Regel von den Produktmanagern oder Verantwortlichen für eine spezifische Produktsparte aufgrund von äußeren Einflüssen ausgelöst. Typischerweise hat die Business-initiierte Modernisierung einen starken Fokus auf die eigene Produktqualität, wo es darum geht, dass fachliche Anforderungen sowie Qualitätsanforderungen an das Produkt angemessen umgesetzt wurden (oder zukünftig umgesetzt werden können). Dazu konzentriert sich die Modernisierung vorwiegend auf die Verbesserung der Benutzererfahrung, die einfachere Erweiterung um neue Funktionen und Integrationsmöglichkeiten.
Quellen, um eine fundierte Zielvision eines Modernisierungsvorhaben zu erarbeiten, sind vorhandenes Kundenfeedback und Marktanforderungen als auch die konkreten Bedürfnisse neuer Benutzer und Benutzerinnen des Systems sowie die Weiterentwicklungsideen der Projektverantwortlichen. Wichtig ist hier auch die Klärung des notwendigen Veränderungsdrucks. Dieser kann etwa in Form von fundamental neuzudenkender fachlicher Ansätzen, höheren Qualitätsansprüchen oder geänderten Randbedingungen (z. B. aufgrund von regulatorischen Änderungen oder auch durch die bereits beschriebenen Modernisierungsprogramme) vorliegen. Konkret lassen sich diese Maßnahmen im Rahmen eines Architektur-Assessments (hohe Flugebene) oder Architektur-Reviews (tiefere Flugebene) durchführen. Hierdurch wird eine Analyse der Zielsetzung des Systems mit dem aktuellen Zustand vorgenommen. Teilnehmende sind hier nicht nur Beteiligte aus der Softwareentwicklung selbst, sondern vor allem Stakeholder mit Produkt-strategischer Entscheidungskompetenz (wie Produktmanager oder Sales). In diesem Scope können zur Kommunikation der notwendigen architekturellen Veränderungen klassische Methoden aus der Architekturentwicklung wie arc42 verwendet werden. Hier bietet es sich an, eine Dokumentation der aktuellen Softwarearchitektur nachzuerfassen sowie die geplante Zielarchitektur detailliert auszuformulieren. Im Abgleich mit dem vorhandenen Status Quo des bestehenden Softwaresystems folgt aus einer Gap-Analyse ein Handlungsbedarf. Durch die anschließende, risikoadäquate Bewertung der anstehenden Änderungen sowie das Festlegen der Handlungsbereiche ergibt sich hier eine konkrete Todo-Liste zum Abarbeiten für das Softwareentwicklungsteam. Diese kann auch gezielte Abbaumaßnahmen von nicht mehr benötigter Anwendungsfunktionalität beinhalten.
Bei länger dauernden Umbaumaßnahmen kann auch das Erarbeiten und Festhalten einer Übergangsarchitektur sinnvoll sein, welche die Zwischenwelt beim Wandel vom Ist- in den Soll-Zustand des Softwaresystems beschreibt. Konkret können damit notwendige Mittel zur Modernisierung wie Datenmigrationen, inkrementelle Sanierungskonzepte oder konkrete Architekturtaktiken zur gezielten Verbesserung von Qualitätsdefiziten beschrieben werden. Die Implementierung der Übergangsarchitektur wird jedoch letztendlich entfernt, wenn die Modernisierung abgeschlossen ist.
Parallel laufende Anpassungen der Produktphilosophie und -Roadmap haben hier zudem einen fundamentalen Einfluss auf die Details dieser Modernisierungsvariante.
Entwicklungs-initiierte Softwaremodernisierung
Die Entwicklungs-initiierte Softwaremodernisierung konzentriert sich auf die Verbesserung spezifischer Problemstellungen innerhalb des Softwareprodukts selbst bzw. dessen Erstellung. Die Initiierung erfolgt durch direkt an der Produktentwicklung beteiligten Stakeholdern wie Softwareentwickelnde, Tester oder Product Owner. Auslöser sind typischerweise interne Probleme bei der effizienten Weiterentwicklung des Softwaresystems, wie Performance-Probleme, schlechte Wartbarkeit oder Security-Issues, aber auch Ineffizienzen beim Entwicklungsprozess. Diese sind von den einzelnen Mitentwickelnden selbstständig lösbar oder unter Hinzuziehung externer Experten bewältigbar. Der Scope dieser Modernisierungsarbeiten benötigt keine zusätzlichen, außerhalb des Budgetrahmens liegenden Zusatzaufwände. Die Modernisierung (meist: Refactorings oder kleinere Restrukturierungen) können in der Regel innerhalb eines definierten Zeitrahmens konzentriert neben der eigentlichen Produktweiterentwicklung durchgeführt werden.
Generell ist dies die einfachste Art der Modernisierung, da hier viele Verfahren zur Durchführung existieren. Typische Startpunkte sind die Sammlung von aktuellen Problemen im Rahmen einer regelmäßig durchgeführten Retrospektive als auch kleine Workshops wie Pre Mortem oder Risk Storming. Oft sind die Probleme jedoch Projekt-intern bekannt und können direkt durch passende Maßnahmen wie Code-Refactorings, Bibliotheks-Refresh, Threat-Modeling, Performance-Optimierungen als auch durch Pair Programming oder Schulungen umgesetzt werden. Was inhaltlich modernisiert wird, entscheidet das konkret vorliegende Problem. Anhaltspunkte hierfür bieten etwa die Idee der Quality Driven Software Architecture, wodurch sich passende Lösungen in Form von Architekturtaktiken bei spezifischen Qualitätsproblemen identifizieren lassen, als auch die spezielle Fachliteratur in den vorhandenen Problemfeldern.
Die Entwicklungs-initiierte Softwaremodernisierung ist risikoärmer als die beiden anderen Varianten, da die durchgeführten Maßnahmen direkt Feedback in der weiteren Entwicklung erzeugen. Kontinuierlich durchgeführt, hält sie Softwaresysteme über einen langen Zeitraum «fit for purpose», ohne ein (vielleicht zu großes) Rad drehen zu müssen. Die wesentliche Herausforderung bei der Entwicklungs-initiierten Softwaremodernisierung in der Realität ist jedoch, dass dieser Variante wenig Aufmerksamkeit und das Verständnis der Notwendigkeit zukommt. Insbesondere bei Unternehmen, die nicht ursprünglich mit digitalen Geschäftsmodellen starteten, ist das Vertrauen und die Zuversicht in die passende und wirtschaftliche Umsetzung von Verbesserungen direkt aus den Teams heraus gering. Daher erfolgt diese Variante nicht in dem Maß, das notwendig wäre, um ein Softwaresystem dauerhaft erfolgreich weiterzuentwickeln. Dies führt oft dazu, dass nach einiger Zeit die beiden oben beschriebenen Initiierungen benötigt werden, da die Teams vor nicht mehr zu überwindenden Hürden stehen. Bei Unternehmen mit einer starken Engineering-Kultur ist die projekt-initiierte Softwaremodernisierung bei der täglichen Entwicklungsarbeit bereits in Fleisch und Blut übergegangen. Es wird nicht mehr nach einer Modernisierung gefragt, sondern notwendige Verbesserungen werden bei Problemen eigenständig durchgeführt.
Zusammenfassung
Dieser Artikel hat die wesentlichen Charakteristika der verschiedenen Varianten von Software-Modernisierungsvorhaben herausgestellt und Vorschläge für Ansatzpunkte von auch umfangreichen Softwaremodernisierungen aufgeführt. Insgesamt unterscheiden sich das Vorgehen und die konkrete Maßnahmen zwischen Strategie-initiierten, Business-initiierten und Entwicklungs-initiierten Softwaremodernisierungen. Diese Unterscheidung hilft, am Anfang direkt in die richtige Werkzeugkiste zu greifen und dadurch ein Softwaremodernisierungsvorhaben nicht falsch zu beginnen. Denn auch hier gilt: «no size fits all»!
Vielen Dank an Stefan Paal und Joachim Praetorius für das Feedback zu einer früheren Version dieses Beitrags! Das Header-Bild wurde mit leonardo.ai generiert.