Das Zauberwort heißt Plattformwechsel

Wenn es um die Modernisierung von Legacy-Anwendungen geht, gilt der erste Gedanke immer noch dem Mainframe, der vor allem aus Handel, Banken und Versicherungen bis heute nicht wegzudenken ist.

Inzwischen sind jedoch auch die Applikationen der nächsten Generation bereits in die Jahre gekommen: unzählige unternehmenskritische Anwendungen, die in den 90er Jahren mit den damals neu aufgekommenen Desktop-Technologien wie Gupta Team Developer, Visual Basic oder auch Access realisiert wurden. 

Selbst viele in den 2000ern entstandene Desktop-Lösungen sollen inzwischen schon wieder modernisiert werden, um sie auf mobilen Geräten oder in der Cloud einzusetzen. Projektbeispiele zeigen, wie der erforderliche Plattformwechsel gelingen kann, ohne die über Jahrzehnte realisierte Funktionalität zu verlieren.

Natürlich träumt jeder Softwarearchitekt davon, mit der Anwendungsmodernisierung auf der grünen Wiese zu beginnen und die Lösung von Grund auf neu zu konzipieren. So lautete auch der ursprüngliche Plan bei Goodhart Sons, einem internationalen Stahlbauunternehmen mit spezialisiertem ERP-System, das als Individuallösung in Visual Basic 6 (VB6) entwickelt worden war. „Von der Angebotserstellung über Zeit- und Materialerfassung, Einkauf, Wareneingang, Kreditoren- und Debitorenbuchhaltung bis zum Personalwesen: Das ERP-System deckt unser gesamtes Geschäft ab“, berichtet IT-Manager Justin Townsend. Nachdem Microsoft mit jeder neuen Windows-Version seine .NET-Strategie weiter ausgebaut und im Gegenzug die Unterstützung für VB6 zurückgefahren hat, entschied man sich 2010 für eine Neuentwicklung auf Basis von VB.NET – eine offensichtlich naheliegende Option.

Allerdings stellte sich bald heraus, dass sich in dem über 20 Jahre intensiv weiterentwickelten VB6-Projekt weit mehr Funktionalität versteckte als zunächst gedacht. Nach sechs Jahren Kampf mit dem komplexen Code wurde das Projekt schließlich abgebrochen. Das ganze Paket von Grund auf neu zu schreiben, war einfach zu ambitioniert. Man entschied sich 2018 schließlich für eine toolbasierte Dienstleistung zur VB6-Migration. Das Modernisierungsprojekt brachte nicht nur den Quellcode auf C#.NET, sondern wandelte die Software auch gleich in eine HTML5-basierte Browseranwendung auf Basis des Web-Application-Frameworks Wisej um. Jetzt hat das Unternehmen eine Oberfläche, die auf dem Desktop elegant und modern wirkt, und die Schweißer im Außendienst können einfach ihre Mobiltelefone benutzen, um die Arbeitszeiten zu erfassen oder die Materialverfügbarkeit zu ermitteln.
 

VB6-Bildschirm vor der Anwendungsmodernisierung  

Das Vorgehensmodell macht den Unterschied

Ebenfalls auf externe Unterstützung setzte die DOMUS Software AG, als es darum ging, ihre Hausverwaltungssoftware für professionelle Immobilienverwalter DOMUS4000 fit für die Azure-Cloud zu machen. Der große Umfang der Software – immerhin 157 Anwendungen mit über einer Million Codezeilen und gut 700 Masken – sprach auch hier für einen werkzeugbasierten Ansatz. Für den Softwareanbieter standen jedoch auch handfeste wirtschaftliche Überlegungen im Vordergrund: „Die Umstellung lohnt sich ja nur, wenn ich auch einen Markteffekt habe“, erläutert Vorstand Stephanie Kreuzpaintner. „Da konnte uns das Gesamtkonzept aus Migration zum Festpreis und Redesign der Benutzeroberfläche einfach überzeugen.“

Entscheidend für einen reibungslosen Projektablauf ist vor allem das Vorgehensmodell des externen Anbieters. Schon in der Evaluierungsphase sollte durch eine qualifizierte Grob- und Feinanalyse Klarheit darüber geschaffen werden, wo die Problembereiche und Abhängigkeiten im Code liegen. Idealerweise wird am Ende ein Festpreisangebot mit genauem Zeitplan für die weitere Vorgehensweise vorgelegt.

Während der eigentlichen Portierungsphase ist ständige Kommunikation der wichtigste Faktor für einen flüssigen Projektablauf. Jeden Dienstag um 11 Uhr fand eine Telefonkonferenz zwischen DOMUS und dem beauftragten Dienstleister statt, in der die Projektverantwortlichen und Entwickler die aktuellen Prozessschritte der letzten Woche besprochen und die für die laufende Woche anstehenden Meilensteine geplant haben. So entstand ein ganzheitlicher Projektplan mit entsprechenden Eskalationsstufen und einer Meilensteinplanung, nach deren Fortschritt sich die zu leistenden Teilzahlungen richteten. Alle Beteiligten wussten jederzeit, wo man mit dem Projekt gerade stand.
 

Web-Frontend nach der Anwendungsmodernisierung  

Nicht alles lässt sich automatisieren

Neben der Erfahrung und dem Vorgehensmodell spielen bei der Auswahl eines passenden Dienstleisters allerdings auch die verfügbaren Portierungswerkzeuge eine entscheidende Rolle. „Für die Umstellung von Millionen Codezeilen etwa von Gupta nach .NET bedarf es einer ganzen Reihe ausgereifter und hoch spezialisierter Werkzeuge“, weiß Günter Hofmann, Geschäftsführer des Anwendungsmodernisierers fecher. „Erst wenn 80 bis 90 Prozent des Gesamtaufwands durch die Tools abgedeckt sind, wird das Migrationsmodell für den Kunden finanziell attraktiv.“

Um dies zu gewährleisten, sollte beim Dienstleister bereits viel Erfahrung mit ähnlichen Projekten vorhanden sein und sich in den eingesetzten Werkzeugen niederschlagen. „Sonst tun sie im Grunde nichts anderes, als die Software von Grund auf neu zu schreiben – genau wie wir selbst es getan hätten“, bringt es Joe LaBuda, Executive Vice President von Harris Local Government auf den Punkt. Bevor das zweijährige Modernisierungsprojekt für seine Softwaresuite für die Kommunalverwaltung startete, sprach er deshalb nicht nur mit verschiedenen Referenzkunden, sondern ließ sich mit seinem Team anhand eines Pilotprojekts vom angebotenen Ansatz überzeugen. „Wir haben dafür das Inkasso-Modul unserer Suite ausgewählt, da es recht komplex ist, verschiedene Technologien verwendet und auch Integrationen von Drittprodukten benötigt.“ Nachdem der migrierte Code die Qualitätssicherung bestanden hatte, war man mehr als zuversichtlich, auf dem richtigen Weg zu sein.

Trotzdem ist keine Software wie die andere. Um den händischen Programmieraufwand für die projektspezifischen Herausforderungen zu reduzieren, ist es wichtig, dass auch individuelle Codeanpassungen regelbasiert möglich sind. So war bei Harris ein eingesetztes ActiveX-Berichtwerkzeug eines Drittanbieters durch einen neuen .NET- und Browser-kompatiblen Report Writer zu ersetzen, was durch entsprechende Ersetzungsregeln automatisiert erfolgen konnte. Manuelle Eingriffe hingegen erforderte eine hartcodierte Verbindung zu den eingesetzten Quittungsdruckern, für die nicht einmal ein Windows-Treiber existierte. Um diese auch in der neuen Browser-Logik weiterhin betreiben zu können, musste eine kleine Windows-Tray-App geschrieben werden. Es sind Überraschungen wie diese, die jeden Architekturwechsel zu einem einzigartigen Erlebnis machen, so das Fazit.

Architektur der modernisierten Web-Anwendung  

Der Vorteil liegt in der Architektur

Aber genau um diesen Architekturwechsel und die damit verbundene Öffnung geht es den Unternehmen, die ein Portierungsprojekt, etwa in die .NET-Welt, angehen. „Endlich sind wir mit unserer Entwickungsumgebung state of the art, angefangen davon, wie der Code aussieht, bis zur Frage, in welchen Foren man sich dazu austauschen kann oder wo man Entwickler dafür findet“, fasst Software Developer Simon Voggeneder von der Lang Finanzsoftware GmbH zusammen.

Deren Hauptanwendung „Kredit Manager“ war zuvor eine einzige große Datei. Im Zuge der Portierung wurde dieser Code-Monolith in Funktionsbausteine aufgeteilt und es sind vermehrt einzelne Klassen und einzelne, ausgelagerte Dialoge entstanden. So hat sich die Gefahr für Konflikte verringert und das Entwicklungsteam kann viel genauer nachverfolgen, wo im Code tatsächlich Änderungen erfolgt sind.

„Das Einzige, was aus heutiger Sicht sicher anders machen würden“, lacht Voggeneder. „Wir würden die Portierung bereits viel früher angehen.“