Die heutige Softwarewelt ist kompliziert und verändert sich laufend. Viele Unternehmen kämpfen mit veralteten und ursprünglich eigenentwickelten oder angeschafften Applikationen, welche aufgrund einer mittlerweile modernen IT-Architektur, Mitarbeitendenfluktuation oder des fehlenden Know-hows nicht mehr weiterentwickelt werden (können). Teilweise verlangt auch ein Betriebssystem eine solche Umstellung, da die Legacy Applikation von der neuen Betriebssystemversion nicht mehr unterstützt wird.
Daraus erwachsen eine Vielzahl von Risiken, wie zum Beispiel dass kritische Fehler nicht mehr zeitgerecht korrigiert werden können. Oder man den Standards der abzubindenden Applikationen nicht mehr Folge leisten kann und die eigenen Applikationsverantwortlichen des Unternehmens verlieren das Interesse, die veraltete Software weiter zu betreiben. Schlussendlich können die Prozesse nicht mehr oder nurmehr ineffizient ausgeführt werden. Wenn eine solche Applikation für businesskritische Geschäftsprozesse im Einsatz steht, geht von ihr somit das Risiko aus, diese Prozesse zu verlangsamen, zu unterbrechen oder gar zu einem Stillstand im Unternehmen zu führen. So steht man spätestens dann unfreiwillig und mit einem gewissen Druck vor der Entscheidung der Modernisierung dieser Applikation.
Vorgehen zur Problemlösung
Zu Beginn muss in Abstimmung mit der Unternehmens- und der damit verknüpften Digitalisierungsstrategie geprüft werden, ob die Anforderungen und Prozesse von damals noch zeitgemäss sind. Des Weiteren ist eine exakte Abgrenzung zu parallel entstandenen Applikationen wichtig, um Redundanzen bei den zu entwickelnden Funktionen zu vermeiden. Dabei gilt es, die bestehende IT-Architektur des Unternehmens beizuziehen. Sobald diese Themen geklärt sind, macht es Sinn, mögliche Lösungen auszuarbeiten.
Schlüsselthema IT-Architektur
Eine durchdachte IT-Architektur der neuen Applikation ist ein entscheidender Erfolgsfaktor. Dabei helfen die heutigen Architekturgrundsätze, die je nach Branche und Unternehmen leicht variieren können:
- Flexibilität des Benutzer-Interfaces
- Geschwindigkeit der Applikation selbst und dessen Anzeige
- Zügiges Anbinden von internen und externen Services
- Hohe Releasezyklen für das Einbinden neuer Businessanforderungen und kritischer Fehlerbehebung
- Motivationssteigerung der
Mitarbeitenden - Wiederverwendbarkeit von
einzelnen Services - Einsatz von Microservices
je nach Nutzen - Die Wartung und Weiterentwicklung sollen kosteneffizient sein.
Diese Grundsätze sind mit der Geschäftsleitung, den Anwendenden und den Betreibenden gemeinsam festzulegen. Dadurch wird sichergestellt, dass die Ziele der Anwenderinnen und Anwender und der IT harmonieren und in die gleiche Richtung zeigen.
Es gibt bewährte Praktiken und Methoden, Legacy Applikationen mit einem kontrollierbaren Risiko zu erneuern. Mit einem Katalog an Massnahmen, vereinbarten Spielregen im agilen Umfeld und kompetenten Entscheidungsträgerinnen und Entscheidungsträgern kommt man gemeinsam zum Ziel, bevor es zu einer Verlangsamung der Prozesse oder gar einem Stillstand im Unternehmen führt.
Dominic Beusch
Exec. MBA Digital Transformation
Schwerpunkte
Leitung von Softwareentwicklungsprojekten, Entwicklung von IT-Strategien, Erarbeitung von Digitalisierungsstrategien, Implementierung von E-Services
«Make or Buy»-Entscheidung
Nachdem die Anforderungen und die IT-Architektur definiert sind, gilt es, allfällig vorhandene Lösungen auf dem Markt zu evaluieren. Auf dieser Basis kann anschliessend eine «Make or Buy»-Entscheidung getroffen werden. Festgelegte Entscheidungskriterien mit einer Gewichtung dieser und einer allfälligen SWOT-Analyse unterstützen diesen Prozess. Wichtige Kriterien sind beispielsweise Referenzprojekte, Kosten, Risiken, Implementierungsdauer, Technologieerfahrung, Skalierbarkeit der Ressourcen oder auch die Kompetenzen der Projektmitarbeitenden.
Agile Umsetzung
Unabhängig von der «Make or Buy»-Entscheidung gibt es diverse Methoden für die anschliessende Umsetzung. Die Praxiserfahrung hat gezeigt, dass insbesondere bei einer Neuentwicklung die «agile Methode» sehr effizient sein kann. Hierbei werden aus einer visionären Beschreibung der künftigen Applikation (zum Beispiel Nutzen, Effizienzsteigerung usw.) konkrete «Use Cases» und daraus «User Stories» abgeleitet. Sobald eine erste «User Story» vorliegt, kann auf dieser Basis bereits entwickelt und getestet werden, während weitere «User Stories» parallel dazu erarbeitet werden. Damit wird das Ziel verfolgt, den Anwenderinnen und Anwendern schnellstmöglich in einer echten Umgebung erste Resultate zeigen zu können und sie eng im Prozess mit einzubinden. Das Ergebnis ist ein erster Entwicklungsstand, wobei die Anwendenden optimalerweise bereits einen Nutzen für sich ziehen können. Ein wichtiger Erfolgsfaktor bei einer agilen Umsetzung sind klare Regeln im Projektteam. Denn Agilität bedeutet nicht, dass das Projekt unkoordiniert und unstrukturiert abläuft. Die Verantwortlichkeiten und die Arbeitspakete innerhalb des definierten Sprint-Zyklus müssen definiert sein und eingehalten werden. Zum Beispiel, bis wann eine User Story erstellt ist, ab wann es einen klickbaren Prototypen mit Design gibt oder ab wann das Backlog (Arbeitsbestand) gefüllt und durch die Entwicklerinnen und Entwickler geschätzt wird. Nach der Entwicklung einer Funktion und erfolgreichem Testing inklusive einer Abnahme kann das Projektteam in Eigenregie festlegen, wann jeweils ein produktiver Release an die Anwendenden verteilt wird.
Schnelle Entscheidungen
Im Rahmen eines solchen agilen Vorgehens sind schnelle Entscheidungen von fachlicher und technischer Natur von hoher Wichtigkeit und entscheiden oft über Erfolg oder Nichterfolg. Hierfür müssen definierte Gremien und Kompetenzträger bestimmt werden, die ausreichend schnell entscheiden und schlussendlich die Verantwortung für diese Entscheidungen übernehmen. Wenn es um die Modernisierung einer Applikation geht, sind die Fach- und IT-Strategie beizuziehen, um den langfristigen Blick nicht aus den Augen zu verlieren. Software- und Hardwarearchitektur-Entscheidungen beeinflussen die Richtung des Unternehmens stark. Hier ist vor allem wichtig, die Anwenderinnen und Anwender mit einzubeziehen und sachlich die Vor- und Nachteile der jeweiligen Option darzustellen.
Mehr zum Bild
«Agile Projekte sind transparenter, aber auch intensiver»
Als Helikopterpilot vergleicht Dominic Beusch agile Projekte mit einem Flug: Man startet, hebt ab, manövriert sich durch das Wetter, Wolken und schlechte Sicht, navigiert zu den jeweiligen Zielen und hat schliesslich die Landung als schwierigste Phase vor sich. In sein Generative-Art-Bild eingeflossen ist daher ein Bild von einer Rotation, die an den Helikopter erinnern soll. Nicht nur als Pilot, auch als Berater und Projektleiter für Software-Projekte, auf die Dominic Beusch spezialisiert ist, weiss er, dass auf jede Aktion eine Reaktion folgt.
