Software ist oft über viele Jahre, manchmal sogar über mehrere Jahrzehnte im Einsatz. Irgendwann stellt sich die Frage: Komplett neu entwickeln oder alte Anwendungen migrieren? [...]
Software wird im Laufe ihres Lebenszyklus‘ immer wieder mit Hilfe von Updates an neue Anforderungen angepasst, Fehler werden bereinigt. Doch irgendwann reichen derlei Mikroanpassungen nicht mehr aus. Das User Interface wirkt dann altbacken und die Funktionalität ist nicht mehr zeitgemäß. Es stellt sich die Frage: Neuentwicklung oder Anwendungsmigration?
Softwaresysteme bestehen aus vielen Einzelkomponenten, darunter etwa eine Datenbank, Module für die Business-Logik und die Benutzeroberfläche. All diese Bestandteile müssen gewartet und an sich ändernde Anforderungen angepasst werden. Dabei kann der Lebenszyklus eines Anwendungssystems über viele Jahre reichen. Neue Anforderungen (Use Cases) werden dann über Updates integriert.
Probleme, wenn sich die technologische Basis stark verändert
Der Umfang solcher Updates ist unterschiedlich. Oft kommt es zu funktionellen Anpassungen, und es werden laufen Fehler und Unzulänglichkeiten beseitigt. Während des Lebenszyklus eines Anwendungssystems ändert sich die technologische Basis oft stark. Das liegt daran, dass Betriebssysteme umfassende Updates erfahren, die Hardware Fortschritte macht und auch komplette Architekturen von Anwendungssystemen wechseln. Beispiele sind etwa
- die Weiterentwicklung des Betriebssystems, zum Beispiel von Windows XP, über Windows 7, 8, 10 zur aktuellen Version Windows 11;
- leistungsfähigere Hardware, zum Beispiel die Nutzung größerer Bildschirme;
- Änderungen bei den Anwendungsarten: statt Desktop- werden Web-Applikationen eingesetzt oder
- der veränderte Aufbau grafischer Benutzeroberflächen in allen Fragen des Designs und der User Experience.
Der technische Fortschritt und der Wunsch, Softwaresystem durch Updates kontinuierlich anzupassen, sind oft nicht mehr miteinander vereinbar. Kommt der Umstand hinzu, dass sich neue geschäftliche Anforderungen nur noch schwer oder gar nicht mehr in das bestehende Anwendungssystem integrieren lassen, entsteht eine „Lücke“ zwischen den Geschäftsanforderungen und der IT. Dieses Problem lässt sich dann nur noch begrenzt aufschieben.
In einer solchen Situation bieten sich unterschiedliche Lösungen an. Eine generelle Empfehlung ist dabei nicht möglich, es gilt die Erfolgsaussichten, die Kosten und die Durchführbarkeit sorgfältig abzuwägen. Immer wichtiger wird dabei der Faktor Zeit. Die Handlungsalternativen sind Neuentwicklung, der Umstieg auf Standardsoftware und Migration. Wir möchten im Folgenden auf die Herausforderungen der Softwaremigration eingehen, dabei aber auch die alternativen Optionen kurz beleuchten.
Strategische Optionen
Ein Softwaresystem vollständig neu zu entwickeln verlangt, sämtliche Funktionen des bisherigen Softwaresystems von Grund auf neu zu konzipieren und umzusetzen. Bei der Auswahl der Technologie und der Systemarchitektur sind Kompromisse kaum möglich. Zudem können der bisherige Quellcode und andere Ressourcen des Altsystems (Legacy-Applikation) nicht genutzt werden. Hilfereich sind gegebenenfalls Kenntnisse der Fachdomäne und von möglichen Schwachstellen des bisherigen Systems. Der zeitliche Aufwand und die benötigten Ressourcen werden hier besonders groß sein. Kommen jedoch die Alternativen nicht in Frage, dann ist eine Neuentwicklung unvermeidlich.
Wenn das Ziel mit Standardsoftware erreicht werden kann, sollte deren Einsatz geprüft werden. ERP- und CRM-Systemen lassen sich oft konfigurieren und individuell anpassen. So können Entwicklungskosten gespart werden, allerdings treten auf der anderen Seite Lizenz- und Konfigurationskosten auf. In vielen Fällen wird ein Unternehmen seine spezifischen Ziele aber nur mit Individualsoftware erreichen.
Softwaremigration – Herausforderungen und Chancen
Deshalb kann eine Softwaremigration, deren Sinn die Überführung eines bestehenden Anwendungssystems in eine neue Technologie ist, die Lösung sein. Abhängig davon, welche Bereiche eines Systems betroffen sind, unterscheiden sich dabei der Aufwand und das Vorgehen. Typische Teilbereiche sind eine Migration der Datenbank oder der Benutzeroberfläche.
Ziel eines solchen Vorhabens ist es, vorhandene Ressourcen wie Daten und Quellcode entweder direkt zu übernehmen oder weitestgehend zu transformieren. Gelingt das, können viele Ressourcen gespart werden. Die Machbarkeit einer Softwaremigration hängt vor allem von der Qualität des Altsystems ab. Die Programmlogik muss in einem Zustand sein, der eine Weiternutzung durch Migration erlaubt. Ist das nicht der Fall, muss geprüft werden, ob vor der Softwaremigration zunächst eine Sanierung des alten Quellcodes durchgeführt werden sollte.
Das gilt auch, wenn bestimmte Funktionen nicht in das Neusystem übernommen werden sollen. Eine Bereinigung des Quellcodes vor der Migration verringert den Aufwand. Neue Funktionen sollten tendenziell erst nach der Migration umgesetzt werden. Grundsätzlich gilt: Sanierung, Erweiterung und Migration sind unterschiedliche Vorhaben – jeweils mit einer eigen Komplexität. Sie sollten daher nicht miteinander vermischt werden.
Vorgehensweise und Werkzeugunterstützung
Ein Migrationsprojekt durchläuft – ähnlich einem Entwicklungsprojekt – typischerweise die folgenden Phasen:
- Planung,
- Ist-Analyse,
- Soll-Konzeption,
- Tool-Auswahl,
- wirtschaftliche Bewertung,
- Risikoanalyse,
- Entscheidungsfindung und die
- technische Umsetzung.
Eine Werkzeugunterstützung ist in allen Phasen möglich und sinnvoll. Die Migrationswerkzeuge lassen sich in folgende Klassen entsprechend ihrer Aufgabe einteilen: Codeanalyse, Programmtransformation, Programmkapselung, Datenkonvertierung und Datenkapselung. Je nach den Anforderungen, die sich aus einer dezidierten Projektanalyse ergeben, kommen ein oder mehrere Werkzeuge zum Einsatz. Manchmal ist es auch notwendig, einzelne Tools anzupassen – zum Beispiel bei der Transformation von Quellcode oder beim Datenimport.
Ein Beispiel: Eine typische Praxisanforderung ist die Migration von Desktop- zu Web-Anwendungen. Die Vorteile einer modernen Web-Anwendung sind die plattformunabhängige Ausführbarkeit, ein geringer Aufwand für Installation und Updates, ein direkter Mehrbenutzerbetrieb und anderes. Oft ist das Legacy-Anwendungssystem eine klassische Client Server-Applikation.
Die Desktop Anwendungen basieren meist auf älteren Technologien wie Windows Forms oder dem .NET-Framework, wenn wir in der Windows-Welt bleiben. Als Programmiersprachen findet man diverse Versionen von C# und Visual Basic. Der Datenaustausch, typischerweise mit einem Datenbank- und einem Dateiserver, erfolgt über das Netzwerk. Die Migration zu einer Web-Applikation kann beispielsweise über das Web-Migrationsframework Wisej erreicht werden.
Damit ist es möglich, eine bestehende Anwendungsstruktur einer Desktop-Applikation in eine Web-Applikation zu überführen. Das Besondere dabei ist, dass die technologische Basis, das heißt das .NET Framework, beibehalten beziehungsweise aktualisiert wird. Die eigentliche Applikation wird nach der Migration auf dem Server und nicht mehr auf jedem Client ausgeführt. Auch für die große Herausforderung der GUI-Transformation gibt es eine Lösung. Existierende Dialogmasken – auf der Basis von Windows Forms – können weitgehend automatisch übernommen werden.
Um das zu erreichen, bildet das Framework die visuellen Steuerelemente der Oberfläche, zum Beispiel Labels, Texteingabefelder, Buttons etc. in Form von Web-kompatiblen JavaScript-Komponenten mit Hilfe einer spezialisierten User-Interface-Bibliothek nach. Der gesamte Prozess erfolgt automatisiert. Erweiterungen und umfassende Modernisierungen mit neuen und ansprechenden Komponenten sind dabei möglich und meist auch erwünscht.
Die Benutzeroberfläche wird daher nicht nur vom Desktop in den Browser gebracht, sondern auch umfassend in Fragen des Handlings und des Designs den neuen Anforderungen angepasst. Eine weitere Besonderheit ist die Nutzung eines visuellen Designers für die Gestaltung. Der bekannte Prozess der Umsetzung einer Windows-Forms-Anwendung wird mittels des Frameworks für die Web-Entwicklung transformiert. Im Ergebnis entsteht eine Single-Page-Web-Applikation, die nur die Technologien HTML, CSS und JavaScript nutzt und daher plattformneutral auf jedem Zielsystem im Browser ausgeführt werden kann.
Das beschriebene werkzeuggestützte Migrationsprinzip darf aber nicht darüber hinwegtäuschen, dass mit dem Wechsel der Technologie von einer Desktop- zu einer Web-Applikation wichtige Fragen zu klären sind. Das betrifft beispielsweise den veränderten Hardwarezugriff, die Interaktion mit anderen auf den Client laufenden Anwendungen oder den Wechsel zu einem Mehrbenutzerbetrieb. Das bedeutet, dass die Umsetzung in jedem fall genau geplant werden muss.
Praxis
Beispielhaft für viele Migrationsprojekte soll hier kurz ein Vorhaben bei Harris vorgestellt werden. Das Unternehmen unterstützt den öffentlichen Sektor durch die Bereitstellung spezialisierter Software in den Bereichen Fondsbuchhaltung, Personalwesen, Regulierung und Rechnungsstellung. Harris ersetzte ein 150 Visual-Basic-6-Anwendungen umfassendes Softwarepaket durch eine integrierte webbasierte Architektur und eine moderne Benutzeroberfläche.
Die Software-Suite umfasst Finanzmodule wie Buchhaltung, Anlagevermögen und Gehaltsabrechnung. Mit Hilfe des Web-Frameworks gelang es, die Technologie in relativ kurzer Zeit zu angemessenen Kosten zu aktualisieren. Einen Eindruck von der modernisierten Benutzeroberfläche vermitteln die nachfolgenden Abbildungen. Gegenüber einer althergebrachten Visual-Basic-6-Desktop-Anwendung zeigt sich nun ein modernes und frisches Design.
Die erreichten Ergebnisse des Migrationsvorhabens lassen sich wie folgt zusammenfassen: plattformübergreifende browserbasierte Technologie, einfachere Installation und Wartung, Einsparungen bei Hardware- und Bereitstellungskosten, saubere, einfache, elegante, moderne Benutzeroberfläche, Verbesserungen der Zugänglichkeit und eine kurze Bearbeitungszeit.
Ökologische Aspekte
Bisher wurden ausschließlich ökonomische Gründe für die Vorteile einer Softwaremigration angeführt. Bei der Softwareerstellung rücken heute aber auch Aspekte der Nachhaltigkeit in den Fokus. Grundsätzlich kann man davon ausgehen, dass eine Neuentwicklung immer einen größeren ökologischen Fußabdruck hinterlässt als eine erfolgreiche Softwaremigration, bei der es gelingt, einen Gutteil des Quellcodes und der Programmstruktur weiter zu nutzen. Softwaremigration kann den Lebenszyklus eines Anwendungssystems erheblich verlängern und damit zu einer Schonung der knappen Ressourcen beitragen.
Fazit: Nicht alles, was alt ist, muss entsorgt werden
Eine funktionierende Businesslogik, die über viele Jahre weiterentwickelt wurde, ist oft zu schade, u, sie wegzuwerfen. Man kann sie auch nicht in kurzer Zeit neu implementieren. Das ist auch nicht notwendig, denn das Ergebnis würde in vielen Fällen keine direkte Verbesserung oder Erweiterung der Funktionalität mit sich bringen. Vorhandene Features des Altsystems würden lediglich mit viel Aufwand für das neue Anwendungssystem neu implementiert.
In vielen Fällen scheint daher die Prüfung einer Softwaremigration lohnend. Erfahrungen aus der Praxis haben gezeigt, dass sich so Ressourcen und Kosten einsparen lassen, die an anderer Stelle dringender benötigt werden. Zudem ist eine Softwaremigration schneller erledigt als eine Neuentwicklung. Dennoch gilt auch hier: Aufwand, Komplexität und Durchführung eines umfassenden Migrationsprojektes erfordern eine professionelle Planung und Vorgehensweise, denn jedes Projekt ist ein Einzelfall.
*Dr. Veikko Krypczyk ist begeisterter Entwickler und Fachautor. Als promovierter Wirtschaftsinformatiker ist er besonders an Fragen einer effizienten Nutzung von IT für Unternehmensprozesse interessiert.
Be the first to comment