Ablöse von geschäftskritischen Softwaresystemen
Bestandssoftwaresysteme sind für die meisten Unternehmen von entscheidender Bedeutung. Diese Softwaresysteme sind das Herzstück der bestehenden IT-Architektur. Ihre Schnittstellen sind eng mit dem Rest der IT-Landschaft verbunden und liefern unverzichtbare Daten für die Business Services.
Im Laufe der Jahrzehnte wurden diese Legacy-Systeme schrittwiese modernisiert oder zusätzliche Funktionalität wurde dem System hinzugefügt. In der Regel haben diese Erweiterungen die Komplexität der Systeme erhöht. Durch die inkrementelle Entwicklung dieser Softwaresysteme wurden zusätzliche Programmiersprachen und Technologie-Stacks hinzugefügt.
Bestandssoftwareablöseprojekte oder Software-Modernisierungsprojekte sind oft groß angelegte und mehrjährige Projekte. Aufgrund der Komplexität der gewachsenen Systeme besteht ein außerordentliches Risiko, dass diese Ablöseprojekte scheitern. Auf der anderen Seite sind die von diesen Systemen bereitgestellten Business-Services entscheidend für den Geschäftserfolg und moderne Organisationen haben keine Wahl, diese gewachsenen Softwaresysteme zu modernisieren.
Sysparency empfiehlt eine der folgenden Strategien, um unverzichtbare Legacy-Softwaresystemen zu modernisieren:
- MAINTAIN
Aufrechterhaltung des Status quo und Betrieb des Legacy-Systems
- WRAPPING
Umschließen von Komponenten in einer neuen Umgebung (z. B. Virtualisierung)
- MIGRATION
System in eine neue Umgebung oder Programmiersprache umwandeln
- RE-IMPLEMENTATION
Neuschreiben von Komponenten mit gleichem Design
- REPLACEMENT
Ersetzen durch ein neu entwickeltes oder gekauftes Softwaresystem
Software-Archäologie (engl. Software Reverse Engineering) ist der erste Schritt zur erfolgreichen Ablöse von Legacy-Softwaresystemen. Der Zweck der Software-Archäologie ist es, Software zu kartieren und zu messen, um den Dokumentations-, Wartungs- und Entwicklungsprozess bestehender Softwaresysteme besser zu unterstützen. Vor der Ablöse eines Systems muss der Systemumfang vollständig erfasst werden und die Struktur der Systeme müssen besser verstanden werden. Es werden dabei die Folgenabschätzungen zu vorgeschlagenen Änderungen vorgenommen und die Kosten für die unterschiedlichen Ablöse- und Modernisierungsstrategien berechnet. Für die Erstellung von Business Case Rechnungen von kritischen Software Legacy-Anwendungen empfiehlt sich ein Durchrechnungszeitraum von über 10 bis 15 Jahre. Im Schnitt sind die geschäftskritischen Softwareanwendungen bis zu über 20 Jahren im Einsatz und rechnen sich erfahrungsgemäß auch erst ab zehn Jahren im Einsatz.
Der nächste Schritt in der Ablöse von Bestandssoftwaresystemen ist die Generierung der Dokumentation der Bestandssoftwarelösung. Der Zweck der automatisch generierten Softwaredokumentation ist es, den Analysten, den Software- und Wartungsingenieuren detaillierte Informationen über einzelne Softwarekomponenten zur Verfügung zu stellen. Jeder Teil der Dokumentation zeigt eine andere Ansicht auf das vorhandene Softwareprogramm. So wird die Struktur des Programms und die Funktionalität beschrieben. Berechnungen werden durch mathematischen Formeln dargestellt. Die Benutzeroberflächen grafisch aus dem Quellcode aufbereitet und die Daten-Struktur und Batch-Elemente als Diagramme ausgewiesen.
Welche Teile und Tiefe der Dokumentation ein Stakeholder im Ablöseprojekt benötigt, hängt von der anstehenden Aufgabe ab. Die Anwendung neu zu erstellen, die Funktionalität zu analysieren oder die Fehlerquelle zu suchen oder nach dem besten Ort zum Einfügen einer Änderung zu suchen. Nur durch eine saubere Systemdokumentation des Bestandssystems können Risiken minimiert und Probleme bei der Umstellung auf ein neues System vermieden werden. Die Nachdokumentation wird anschließend nicht nur für die Konzeption des Ablösesystems benötigt, sondern oft auch für die Einschulung neuer Mitarbeiter, da das Legacy-System trotzdem noch einige Zeit gewartet werden muss.
Anschließend an die Dokumentation der Bestandssysteme erfolgt die Auswahl von geeigneten Standardsoftwaresystemen. Die Standard-Funktionalität dieser Systeme wird in einem generalisierten Funktionskatalog aufbereitet und die Lücken (Gaps) zu dem bestehenden System erfasst. Nun entscheiden Fachbereich, Technik und Management, ob die bisherigen zusätzlichen Funktionalitäten auch in Zukunft benötigt werden und geschäftskritisch sind. Aus dem Funktionskatalog und dem Ergebnis der Gap-Analyse werden nun die Ausschreibungsunterlagen erstellt und am Markt das richtige Produkt mit dem richtigen Integrator ausgewählt. Sollte es zu einer individual entwickelten Softwarelösung kommen, so werden die bestehenden Funktionalitäten in Anforderungen für das neue System umgewandelt. Durch die lückenlose Dokumentation des Bestandssystems läuft man nicht Gefahr auf Funktionen und Anforderungen zu vergessen.
Während der Umsetzung eines Ablöseprojekts wird starke Scope-Governance verlangt. Das neue System muss schließlich die bestehende und benötigte Funktionalität vollständig beinhalten und sollte um moderne Begeisterungsfaktoren angereichert sein.
