Wettbewerbsfähigkeit durch Softwaremigration erhalten
Software nutzt sich zwar durch Nutzung nicht ab, dennoch altert diese. Um das Potenzial neuer Technologien zu nutzen, muss man bestehende Applikationen stetig anpassen. Die Ablösung von Altsystemen durch aktuelle Anwendungssysteme wird als Softwaremigration bezeichnet. Dabei sollen aus Gründen des Investitionsschutzes möglichst viel Bestandteile des Altsystems weiterverwendet werden. Die richtige Strategie und ein durchdachter Werkzeugeinsatz sind entscheidend. Der Artikel stellt unterschiedliche Szenarien aus der Praxis vor.
Die Gründe für eine Softwaremigration sind unterschiedlich [1]:
- Verbesserung des Anwendernutzens,
- Sicherstellung des notwendigen rechtlichen Zustandes,
- Behebung von Fehlern,
- Erweiterung des Funktionsumfangs,
- Verbesserung der Integration in die vorhandenen Softwaresysteme/ Verbesserung der Interoperabilität,
- Verringerung der Kosten/ Erhöhung der Produktivität/ Effizientere Nutzung der Ressourcen und/oder
- Einhaltung strategischer Vorgaben.
Unternehmen stehen dabei vor der Frage des richtigen Zeitpunktes einer Softwaremigration. Das Altsystem genügt oft noch den aktuellen Anforderungen, d. h. die Aufgaben lassen sich damit meist noch bewältigen. Andererseits ist bereits klar, dass künftig andere Herausforderungen zu meistern sind. Das Problem lässt sich leichter durchdringen und der passende Zeitpunkt der Migration finden, wenn man sich der Bedeutung der genutzten Software im betreffenden Geschäftsbereich bewusst wird. Die Rolle der Informationstechnik, insbesondere der Software, ändert sich in einem erheblichen Ausmaß. Historisch hat sich IT lediglich als Dienstleister im Sinne eines "Werkzeuges" verstanden. Der Fokus war primär technikgetrieben. Über eine Vielzahl von Zwischenstufen verschiebt sich dieser Fokus und die Bedeutung der IT hin zu einem Business-Innovator. Software liefert in diesem Stadium wichtige Beiträge zur Weiterentwicklung des Geschäftsmodells oder verändert dieses sogar dauerhaft. Unternehmen, welche auf diesem Weg erfolgreich sind, haben gegenüber der Konkurrenz die Chance auf Wettbewerbsvorteile. Je mehr ein Unternehmen auf die Innovationsfähigkeit seiner Softwaresysteme angewiesen ist, desto eher sollte es sich für eine Migration eines bestehenden Altsystems entscheiden.
In diesem Artikel werden nach einem Überblick drei gängige Szenarien der Softwaremigration aus der Praxis vorgestellt. Dabei wird neben dem konzeptionellen Vorgehen auch die besondere Rolle des Werkzeugeinsatzes diskutiert.
Softwaremigration im Überblick
Unter technologischen Gesichtspunkten müssten Applikationen vollständig neu entwickelt werden, welche den Anforderungen auf Dauer nicht genügen. Gegen diesen Schritt sprechen der große Aufwand und die damit einhergehenden Kosten. Alternativ werden in der Praxis Szenarien der Softwaremigration geprüft (s. Tabelle 1).
Tabelle 1: Szenarien der Softwaremigration
Szenario der Softwaremigration | Beschreibung | Bedingung |
---|---|---|
Re-Implementierung | Die Neucodierung basiert darauf, dass alle notwendigen Informationen aus dem Altsystem übernommen werden. Die Architektur bleibt weitgehend erhalten, der Quellcode wird neu erstellt, zum Beispiel auch in einer anderen Programmiersprache. | Die grundsätzliche Struktur der ursprünglichen Lösung muss weiterhin geeignet sein. |
Konversion | Es geht um eine automatisierte Transformation der Daten bzw. Programme in die für die Zielumgebung notwendige Form. Voraussetzung ist das Verständnis des Altsystems. Dieses wird ggf. mittels Reverse-Engineering-Techniken erreicht. | Werkzeuge, welche für eine qualitativ gute Konversion sorgen, sind vorhanden bzw. können entwickelt werden. |
Kapselung | Hier bleiben die Daten und Programme des Altsystems in ihrer ursprünglichen Umgebung bestehen. Diese werden von einem Wrapper umhüllt und Zugriffsschnittstellen werden implementiert. Auf diese Art und Weise kann man über das Neusystem auf die Dienste des Altsystems zugreifen. Die Systemschnittstellen werden durch Reengineering verändert und der Legacy-Code bleibt konstant. | Das Altsystem ist hinsichtlich der Funktionalität noch brauchbar. Sind Fehlerkorrekturen oder Anpassungen notwendig, müssen diese im Altsystem vorgenommen werden. |
Auch die Verwendung von Standard-Software kann eine Möglichkeit sein, die gesteckten Ziele zu erreichen. Welche Strategie man wählt, ist u. a. von den Kosten und vom Zustand des Altsystems abhängig. Es handelt sich stets um eine projektindividuelle Entscheidung. Die Softwaremigration kann einen oder mehrere Teilbereiche eines Systems umfassen, d. h. Daten-, Programm-, Benutzeroberflächen- und Schnittstellenmigration. In der Praxis vermischen sich diese Aspekte oft (Abb. 1).
Ebenso ergibt sich oft die Notwendigkeit, sukzessive das System über alle Teilbereiche hinweg zu erneuern. Für die Anwender ist im besonderen Maße ein Update der Benutzeroberfläche von Interesse. Eine besondere Herausforderung ist die Transformation des Programmcodes. Altsysteme weisen oft eine komplexe Businesslogik auf, deren Implementierung viel Aufwand verursacht hat. Eine Neuimplementierung wäre kaum weniger aufwändig und würde sehr viele Ressourcen binden, welche dann für die Entwicklung von neuen Features nicht zur Verfügung stehen. Das Ziel ist es daher Ansätze und Methoden zu finden, welche es ermöglichen möglichst große Teile des bisherigen Systems weiterzuverwenden.
Werkzeugunterstützung
Unabhängig davon, welcher Migrationsprozess eingesetzt wird, sind Werkzeuge erforderlich, um den gewählten Prozess zu unterstützen. Neben den typischen Tools für die Softwareentwicklung, wie Editoren, integrierte Entwicklungsumgebungen und Werkzeuge zum Management der Projektaufgaben, kommen weitere spezielle Tools zum Einsatz. Üblicherweise ist trotz Werkzeugeinsatzes eine vollständig automatische Migration i. d. R. nicht möglich.
Modernisierung von Applikationen für den Desktop
Desktop-Applikationen waren sehr lange die Basis für betriebliche Systemumgebungen. Meist sind diese in eine klassische Client-Server-Struktur eingebunden. Für derartige Systeme ist der Migrationsdruck u. a. aus den folgenden Gründen groß:
- Notwendigkeit der Integration neuer Funktionen,
- Anpassung der Benutzeroberfläche (Designs und Interaktion),
- Herstellen einer Lauffähigkeit auf unterschiedlichen Devices (Desktop, Mobile),
- Bereitstellen für unterschiedliche Betriebssysteme (Windows, macOS, Linux, iOS, Android),
- Verlagerung der Businesslogik in universell über das Internet adressierbare RESTful-Services (Microservice) und/ oder
- Anbindung neuer Formen der Schichten zur Datenhaltung.
Die Software auf den Clients wurde ursprünglich für die unterschiedlichen Versionen des Windows- Betriebssystems entwickelt. Der Support für Windows 2000 und Windows XP ist bereits seit längerer Zeit abgelaufen. Der Support von Windows 7 endete am 14. Januar 2020. Auch aktuelle Versionen von Windows 10 laufen sukzessive in das Support-Ende. Nach dem Ende des erweiterten Supports für Unternehmen können ggf. Sicherheitsupdates kostenpflichtig bezogen werden. Spätestens jetzt ist es Zeit, Szenarien für die künftige Nutzung der Software zu entwickeln.
Viele Legacy-Anwendungen für Windows basieren auf den Programmiersprachen Delphi und C++Builder. Hier gibt es zum Beispiel eine effektive Möglichkeit der Migration mit RAD Studio [3]. Das Ziel ist es, einen möglichst großen Teil des bisherigen Programmcodes weiter zu verwenden oder nur geringfügig anpassen zu müssen. Sehr viele noch heute eingesetzte Desktop-Applikationen wurden noch für frühere Versionen von Windows entwickelt. Zwar hat sich die grundsätzliche Bedienung nicht geändert, aber zahlreiche neue und heute übliche Funktionen standen damals noch nicht zur Verfügung. Ebenso haben sich Design und Bedienung geändert. Üblich sind beispielsweise heute hochauflösende Monitore und der Einsatz der Software auf unterschiedlichen Geräteklassen. Um diese Anforderungen zu erfüllen, muss eine umfassende Anpassung der Software erfolgen. Je nach Ausgangssituation und Ziel der Softwaremigration können unterschiedliche Lösungsszenarien in Betracht kommen.
Tabelle 2: Lösungsoptionen der Softwaremigration am Beispiel der Nutzung von RAD Studio
Ist-Situation im Legacy-System | Zielsetzung | Art der Migration | Vorgehen |
---|---|---|---|
Oberfläche im Look-&-Feel der vergangenen 15 Jahre | Modernisierung des Designs, Unterstützung von Touch und hochauflösenden Monitoren | Benutzeroberfläche | Verwendung der Komponenten und des User Interface Designers, um Benutzerschnittstellen zu gestalten, welche den heutigen Anforderungen entsprechen. |
Applikation nur unter Microsoft Windows lauffähig | Erstellen von geräte- und plattformübergreifenden Applikationen | Systemmigration | Erstellung von geräteübergreifenden Applikationen aus einem einheitlichen Quellcode, welche direkt unter den Systemen Windows, macOS, Linux, Android und iOS laufen durch Einsatz des Frameworks FireMonkey. |
Daten stammen aus einer Datenquelle | Heterogene Datenquellen sollen an die Software angebunden werden können. | Datenmigration | Einsatz der FireDAC-Komponenten zur universellen Anbindung von Datenbanken. |
Monolithische Softwarearchitektur | Softwarearchitektur auf der Basis von Microservices | Systemmigration | Diese erfolgt durch eine Nutzung des RAD Servers. Die Übertragung der Programmlogik aus der Applikation ist in wenigen Schritten als Service in die Cloud möglich. Die Services können dann als RESTful-APIs universell durch jeden beliebigen Client genutzt werden. |
Besonders erwähnenswert ist die Möglichkeit, eine bisher nur auf dem Desktopsystem laufende Applikation mit vertretbarem Aufwand auch für andere Geräte – zum Beispiel Smartphones – zur Verfügung zu stellen. Dabei können große Teile des Quellcodes für die Businesslogik übernommen werden. Oft soll die Architektur des Anwendungssystems geändert werden. Typisch ist die Überführung einer klassischen Client-Server-Applikation in ein REST-fähiges Softwaresystem. Dabei wird die Businesslogik vom lokalen Client auf den Server verlagert. Liegt die Legacy-Applikation in Form von Delphi- oder C++-Quellcode vor, kann der Einsatz des RAD Servers eine effiziente Möglichkeit der Migration bieten. Dabei erfolgt die gesamte Entwicklung in RAD Studio unter dem Einsatz fertiger Komponenten. Bestehender Quellcode kann auf den RAD Server transformiert werden. Oft sind dazu keine oder nur minimale Codeanpassungen notwendig. Dieses Vorgehen führt zu einer Anpassung der Systemarchitektur. Aus einem klassischen Client-Server-Ansatz wird eine moderne Microservice-Architektur (Abb. 2).
Von der Desktop-Applikation zur Web-Applikation
Ein weiteres Szenario besteht darin, statt einer Modernisierung einer Desktop-Applikation den Wechsel zu einer modernen Web-Applikation zu vollziehen. Web-Applikationen bieten bekanntermaßen Vorteile hinsichtlich Installation, Aktualität, Mehrbenutzerbetrieb und laufende Kosten. Es gibt unterschiedliche Technologien für die Umsetzung. Insbesondere kann danach unterschieden werden, welche Aufgaben vom Client und vom Server übernommen werden. Viele Desktop-Anwendungen wurden mit Visual Basic, C# oder VB .NET und Windows Forms (User-Interface) erstellt. Kennzeichnend sind oft komplexe Benutzeroberflächen mit einer Vielzahl von Dialogen und Steuerelementen. Derartige bestehende Applikationen als Web-Applikationen komplett neu zu erstellen, wäre sehr aufwändig. Dieser Vorgang ist auch insbesondere deshalb wenig wirtschaftlich, da die typischerweise gewählten Technologien ein schnelles Erstellen komplexer Benutzeroberflächen – wie man es mit den beschriebenen Werkzeugen, also Visual Basic, Windows Forms usw. – gewohnt war, nicht unterstützen. Demgegenüber steht die stetige Forderung nach einer schnellen Time-to-Market.
Mit Wisej [4] steht ein Ansatz bereit, um webbasierte Unternehmensanwendungen mit Hilfe des .NET-Frameworks zu entwickeln. Die Technologie eignet sich zum einen für Rapid (Web) Application Development und zum anderen für eine einfache Migration von Desktop-Anwendungen ins Web. Wisej wird innerhalb der Entwicklungsumgebung Visual Studio installiert und ausgeführt. Das besondere dieses Applikation-Frameworks besteht in den Punkten Design der Benutzeroberfläche, technische Umsetzung und Flexibilität. Die Benutzeroberfläche wird im Designer von Visual Studio erstellt. Dies funktioniert auf die gleiche Art und Weise, wie man es seit langem bei der Erstellung der Oberflächen für WinForms-Anwendungen gewohnt ist, d. h. aus einer umfassenden Palette von Komponenten werden per Drag-&-Drop die passenden Elemente zum Aufbau der Dialoge ausgewählt. Zu den Komponenten zählen sowohl Standard-Controls, zum Beispiel Buttons und Textboxen, als auch Steuerelemente für Spezialaufgaben. Eine Erweiterung über Extensions ist möglich. Für eine Vielzahl der bekannten Controls aus WinForms finden sich funktionsgleiche Entsprechungen in Wisej. Auch die Programmlogik wird über Events verknüpft. Die Darstellung im Visual Studio folgt dem WYSIWYG-Ansatz, d. h. die Masken sehen zur Designzeit genauso aus wie zur Laufzeit.
Vereinfacht wird die Anwendungslogik vom Client auf den Server verlagert. Dazu erhält die serverseitige Middleware Ajax-Anfragen vom Client im JSON-Format, sendet die Anfragen als .NET-Events an die serverseitigen Komponenten, sammelt die Änderungen am User-Interface und sendet die Unterschiede als JSON-Paket zurück an den Client. Die Antwort wird von der Middleware auf Clientseite weiterverarbeitet. Ebenso werden Event-Anfragen von den Widgets gesammelt und als Anfragen an den Server übermittelt. Auf Seiten des Servers wird mit dem .NET-Framework programmiert. Damit kann eine Wisej-Anwendung die Geschäftslogik und Datenbankwelt von .NET nutzen. Wisej basiert auf dem Single-Page-Konzept, wo eine HTML-Seite geladen wird und dann die einzelnen Objekte manipuliert werden, um den geänderten Anwendungsinhalt anzuzeigen. Dies geschieht optimiert mit Hilfe der Fast-DOM-Technik. Die Kommunikation erfolgt über Web-Sockets oder http und kann optional komprimiert werden (Abb. 3).
Auf der Serverseite basieren die Komponenten auf .NET und werden zur Designzeit erstellt. Wisej-Widgets bilden die serverseitigen verwendeten Komponenten für das User-Interface eins zu eins ab. Das User-Interface wird durch das entsprechende JavaScript-Widget gerendert. Der Kern der Applikation beruht dabei weiterhin serverseitig auf .NET. Die Umsetzung zur Web-Applikation erfolgt automatisiert.
Aus der Perspektive der Migrationsansätze hat man es daher mit einer Kapselung des Altsystems zu tun. Das bedeutet auch, dass das Altsystem grundsätzlich noch funktional geeignet sein muss, denn es wird idealerweise durch die Migration transformiert, d. h. der Quellcode und die Architektur bleiben unverändert.
Im Ergebnis entsteht eine klassische Web-Applikation. Interessant ist aber der Weg. Mit HTML, CSS, JavaScript und anderen diversen Technologie-Stacks des Webs kommt man als Entwickler nicht oder nur wenig in Berührung. Im Idealfall kann man eine Desktop-Applikation mit wenigen Schritten zu einer Web-Applikation migrieren, indem man lediglich einige Verweise austauscht. Größere Business-Applikationen beinhalten teilweise sehr viele Formulare, die ursprünglich im grafischen Designer gestaltet wurden. Diese Formulare haben sich grundsätzlich bewährt. Die Neuimplementierung mit Web-Techniken kann bei großen Projekten schnell zu einem nicht akzeptablen Aufwand führen. Dieser kann minimiert werden.
Erweiterung um mobile Services
Datenhaltige Business-Applikationen basieren oft auf stationären ERP- oder CRM-Systemen. Diese Systeme sind auf eine Nutzung vor Ort ausgelegt. Im Rahmen der zunehmenden Digitalisierung besteht sehr häufig die Notwendigkeit die Geschäftsprozesse zu mobilisieren. Darunter versteht man die Fähigkeit der Mitarbeiter eines Unternehmens, die relevanten Geschäftsvorfälle möglichst vollständig auf mobilen Geräten (Smartphone, Tablet) durchzuführen. Die Notwendigkeit einer solchen veränderten Bearbeitungsweise wird kaum noch in Frage gestellt. Kundennähe, schnelle Reaktionszeiten, 24/7-Verfügbarkeit und die Notwendigkeit der Einsparung von Fixkosten sind nur einige Gründe. Man kann heute davon ausgehen, dass die teilweise Verlagerung der Prozesse auf mobile IT-Technologie einen ebenso großen Entwicklungsschritt darstellt, wie vor einigen Jahrzehnten die Einführung der computergestützten Daten- und Prozessbearbeitung. Diese Feststellung gilt unabhängig von der Branche. Zweifelsohne kann man diese Entwicklung eine Weile ignorieren, der Markt wird sie jedoch einfordern. Unternehmen, welche bereits auf strategischer Ebene die Öffnung ihrer IT für die mobile Nutzung beschlossen haben, sind auf dem richtigen Weg. Um eine solche mobile IT bereitzustellen, müssten bisherige Softwaresysteme komplett neu ausgerichtet werden. Eine einfache Erweiterung bzw. Anpassung ist bestenfalls im Einzelfall möglich, kann jedoch kein Ansatz für ganze Branchenlösungen sein. Im Rahmen eines IT-Erweiterungsprojektes mit dem Charakter eines Migrationsvorhabens kann ein Lösungsansatz darin bestehen, den "mobilen Service" gewissermaßen an die bestehende IT "anzudocken". Der Vorteil liegt auf der Hand: Das bestehende System kann weiterhin im Einsatz bleiben und dennoch werden die strategischen Ziele der Modernisierung erreicht. Dazu ist es notwendig, dass eine verbindende Middleware eingesetzt wird. Diese kapselt aus Sicht der neuen IT die Daten- und Programmschicht der bestehenden IT-Systeme. Wir haben es mit der Migrationsstrategie der Kapselung zu tun.
Ein Beispiel für die Umsetzung eines solchen Vorhabens für Business-Applikationen ist die Service-App des Unternehmens EASY Software AG [5]. Über diesen Service können unterschiedliche Backend-Systeme an den neuen mobilen Service angebunden werden. Im Moment sind es über 40 unterschiedliche Systeme bekannter Hersteller von ERP- und CRM-Systemen. Die Auswahl und Anbindung erfolgen über ein cloudbasiertes Komponenten- bzw. Modul-Market System. Zu den Systemen gehören Backendsysteme wie SAP, Microsoft Dynamics Nav und diverse Datenbanken, wie MySQL, PostgreSQL, Microsoft SQL usw. Darüber hinaus wird die Integration von Facebook-Konten oder Google-Diensten unterstützt. Über Konnektoren können weitere Systeme direkt und individuell angebunden werden (Abb. 4).
In diesem Kontext ist neben dem Thema Datenhaltung auch die Fragen der Bereitstellung der Software zu betrachten. Die mobilen Apps (z. B. "Kundendienst-App") können nicht wie klassische Software direkt auf dem Zielgerät installiert werden. Grundsätzlich existiert ein Zwang der Nutzung des App-Stores. Die Bereitstellung erfolgt über den Apple B2B-Appstore oder über den privaten Channel des Google Play-Stores. Die Nutzung dieses Weges des Deployments ist den Nutzern also bestens vertraut.
Fazit
Die Anwendungsmigration ist ein komplexes Themenfeld der modernen Softwareentwicklung. Neben der richtigen Strategie sind eine umfassende Planung und ein ausgewählter Werkzeugeinsatz für den Erfolg entscheidend. Eine universelle Strategie und Vorgehensweise kann es nicht geben, dazu ist jedes Projekt zu individuell. Aktuell typische Aufgaben aus der Praxis, zum Beispiel eine umfassende Modernisierung der Benutzeroberfläche für Desktop-Anwendungen oder ein Wechsel der Anwendungsart von einer Desktop-Applikation hin zu einer modernen Web-Anwendung, können unter bestimmten Voraussetzungen sehr effizient erfolgen. Gelegentlich kann es auch gelingen, bestehende Softwaresysteme um neue Komponenten so zu erweitern, dass beide Systeme miteinander interagieren und ein Austausch der Legacy-Systeme nicht dringlich ist. Das ist zum Beispiel dann der Fall, wenn mobile Services ergänzt werden können und damit ein direkter Anstieg des Kundennutzens erreicht werden kann. Idealerweise wird die dazu notwendige Software als Cloudservice bereitgestellt.
- Die Beauftragte der Bundesregierung für Informationstechnik: Migrationsleitfaden
- H. Sneed u.a.: Softwaremigration in der Praxis, dpunkt Verlag, 2010
- RAD Studio
- Wisej
- Easy Software