Legacy Software: Definition, Probleme und Lösungen

In der Regel umschreibt man „alte“ Software, die nicht mehr weiterentwickelt wird als Legacy Software. Als Abgrenzung zu „neuer“ Software, die entwickelt werden soll oder schon entwickelt wird. Dabei handelt es sich um eine Zeit der Veränderung und der Transformation, mit einem Fokus auf das Neue. Mit Blick auf die bestehende „alte“ Software spricht man von einem Erbe oder einem Vermächtnis, also von Legacy.

Software ist lebendig und verändert sich kontinuierlich. Es gibt neue Kundenanforderungen, der Funktionsumfang wächst und neue Projekte werden umgesetzt. Wenn man schematisch auf die Lebensdauer von Software blickt, sieht man, dass nach einem anfänglichen Peak bei der Neuentwicklung der Aufwand für neue Funktionalität annähernd gleich bleibt. Man spricht davon, dass die Software evolviert. Aber Tools und Komponenten veralten, es gibt Sicherheitslücken in Bibliotheken, externe Systeme werden nicht mehr weiterentwickelt, neue Technologien entstehen. Irgendwann stellt man fest, dass der Aufwand, um neue Funktionen zu implementieren, immer größer wird. Es ist ein schleichender Prozess, der irgendwann zu einem extremen Ergebnis führt: die Software evolviert nicht mehr.

Wenn Software zur Legacy wird, liegt die größte Bedrohung im Bereich der Wirtschaftlichkeit. In der Vergangenheit wurden immense Investition in die Software getätigt. Jetzt drohen die damit erwirtschafteten Umsätze zurückzugehen oder ganz einzubrechen. Gleichzeitig müssen wieder ähnlich dimensionierte Investition in eine neue Software getätigt werden.

In der Praxis zeigt sich ein zusätzliches Problem: Das Team der Knowhow-Träger:innen und Software-Expert:innen ist vollständig mit der Umsetzung von Kundenanforderungen und Projekten ausgelastet. Es sind keine Kapazitäten vorhanden, um einen solchen Wechsel durchführen zu können. Hier kann evtl. eine Task-Force orientierte Softwareentwicklungsfirma weiterhelfen, z.B. mit einer Beiboot-Strategie.

Software entwickelt sich kontinuierlich weiter und stellt auch immer eine Reaktion auf Kundenanforderungen dar. Diese sind entweder implizit - wie Sicherheit und Performance - oder explizit – wie Funktionalität und „Haptik“/User Experience. So ist eine Desktop-Anwendung, die über ein Terminal-Fenster bedient wird, weniger komfortabel als eine Browser-Anwendung. Ein Self-Service ist attraktiver als eine Installation durch ein:en Administrator:in.

Es sind immer wieder ähnliche Symptome, die auf Legacy Software hinweisen:

• Evolvierbarkeit - Schwierig zu warten: Es wird zunehmend schwieriger, die Software zu warten. Das liegt am fehlenden Überblick, welche Auswirkung Codeänderungen haben und das Hinzufügen von neuen Features wird immer aufwendiger und somit kostspieliger. 
• Sicherheitslücken: Diese entstehen, weil die zugrundeliegenden Bibliotheken und Frameworks nicht mehr weiterentwickelt werden oder so viel neuer sind, dass eine Aktualisierung nicht mehr möglich ist.
• Integration: Die Software lässt sich schwer in andere Software integrieren und kann auch nur schwer andere Anwendungen bei sich integrieren. In der Regel, weil die verwendete Plattform oder Schnittstelle nicht den modernen Anforderungen genügt.
• Wettbewerb: Konkurrenzprodukte haben deutlich weniger Funktionen, wirken aber schlanker und leichtgewichtiger. Die eigene Software lässt sich aber nicht „verschlanken“.
• Wachstum: Das Wachstum und die Innovationsfähigkeit ist eingeschränkt, was dazu führt, dass nicht alle Kundenprojekte zu einem marktfähigen Preis umgesetzt werden können. Ausschreibungen werden seltener gewonnen.

Grundlegend gibt es zwei Lösungsmöglichkeiten. Die erste Möglichkeit ist, die Software komplett neu zu implementieren. Die zweite Möglichkeit: die Legacy Software wird modernisiert und somit saniert.

Die Erfahrung als Anbieter individueller Softwareentwicklung zeigt, dass eine Software Modernisierung in der Regel schneller und sicherer, vor allem aber auch wirtschaftlicher durchzuführen ist, als eine vollständige Neuimplementierung. Denn das wichtigste Ziel der Software Modernisierung besteht darin, die getätigten Investitionen in die Software zu erhalten.

Jede Anwendung besteht abstrakt gesehen aus drei Teilen: 

• Der Zugangspunkt zur Applikation. Dieser Präsentations-Layer kann eine Desktop-UI, eine Web-UI, eine Web-API, eine Mobile-Anwendung oder etwas Ähnliches sein. Alles das, was für die Verwendung benötigt wird.
• Das fachliche Modell. Die Domänen-Logik der Anwendung ist das Herz der Anwendung und spiegelt das Fachwissen des Unternehmens wider. Hier sind in der Regel sehr viele Details implementiert, Ausnahmen abgebildet und auf Korrektheit geprüft.
• Das technische Modell. Hier sind Schnittstellen zu Drittsystemen, Zugriffe auf Datenbanken und Dateien sowie Konfigurationen und Parameter für den Betrieb enthalten.

Bei der Software Modernisierung besteht der erste Schritt darin, diese Teile klar zu benennen und sicherzustellen, dass keine Aspekte vermischt sind oder Querreferenzen enthalten sind. Eventuell bedarf es eines Software-Reengineerings, um diese Trennung herzustellen.

Hier stehen verschiedene Strategien und Maßnahmen zur Verfügung.

Beispiel: Cloud Migration durch Parallel-Betrieb Desktop-UI und Webanwendung

Der Software Rewrite einer Desktop-Anwendung ist langwierig. Eine geschickte Lösung ist ein Parallelbetrieb zwischen Desktop-UI und einer Web-Anwendung. Hierzu wird der Kern der Anwendung, also das fachliche und technische Modell durch „Software Recycling“ wieder- bzw. weiterverwendet. Es wird eine neue Präsentationsschicht auf das fachliche Modell gesetzt. Ein Pattern hierfür könnte ein „Backend for Frontend“ sein, welches genau die Prozesse und Teile implementiert, die von den Kunden als „Cloud-Anwendung“ verlangt wird. 

Durch Softwarewartung (kleine Änderungen) oder durch Software Reengineering (größere Änderungen) kann dann das fachliche und technische Model in einen neuen Betriebsmodus überführt werden. Zum Beispiel indem einzelne Komponenten isoliert werden und dann als Micro-Services in einer Cloud-Umgebung betrieben werden. Entweder als Container oder in einer Platform-as-a-Service Umgebung wie Microsoft Azure.

Beispiel: Software Modernisierung unter Beibehaltung der technischen Kompatibilität

Eine Software agiert nicht im „luftleeren Raum“. Oft gibt es eine große User-Basis mit vielen Daten und unzähligen Schnittstellen zu Fremdsystemen – lesend und schreibend. Eine Software Modernisierung muss berücksichtigen, dass Daten und Schnittstellen weiterhin verfügbar bleiben, um von den Benutzer:innen und/oder dem Mark akzeptiert zu werden. 

So kann beispielsweise bei der Migration einer „alten“ Technologie wie VB6 auf eine moderne Umgebung wie .NET zuerst das fachliche Model technisch aktualisiert werden. Dabei bleiben die externen Schnittstellen und vor allem die Datenbank bestehen. Falls Integrationskomponenten vorhanden sind, werden diese so migriert, dass sie von beiden Technologien verwendet werden können. Komponenten werden „COM-Fähig“ gemacht und Schnittstellen um Webservices ergänzt. Somit bleibt die Anwendung technisch kompatibel und nach und nach werden weitere Teile migriert – bei vollem Parallelbetrieb der alten und neuen Softwarelösungen. 

Damit geht man den Schwierigkeiten eines “Big-Bang”, bei dem zu einem definierten Zeitpunkt alles auf einmal umgestellt werden muss, sehr elegant aus dem Weg.

Beispiel: Teilmodernisierung zur Behebung von Sicherheitslücken

Manchmal muss eine Anwendung auf Grund von regulatorischen Bedingungen und Zertifizierungsanforderungen auch weit über ihren Produkt-Lebenszyklus gewartet und weiterentwickelt werden, obwohl ein neues Produkt längst am Markt ist. Wenn z.B. eingebundene Drittherstellerkomponenten kritische Sicherheitslücken enthalten und nicht mehr aktualisiert werden, bleibt nur, die betreffenden Komponenten durch eine Neuentwicklung zu ersetzen. Man ist zur Software Modernisierung in Teilen gezwungen.

Dabei besteht die Herausforderung, es technisch besser zu machen und gleichzeitig für Benutzer:innen und Schnittstellen alles so zu lassen, wie es ist. Die Schwierigkeit besteht darin, die technische Kompatibilität zu erhalten, was gerade bei UI-Komponenten sehr herausfordernd sein kann.

Eine gute Strategie besteht hier etwa darin, die alte Komponente mit modernen Technologieren nachzuimplementieren und sie mittels einer Kompatibilitätsschicht in die alte Technologie zu integrieren. Ein häufiges Szenario es eine Ablösung von VB6 Komponenten mit einer Neuentwicklung in .net. 
 

Nach einem Workshop zum Herstellen eines gemeinsamen Verständnisses über die Kundenanforderungen und Vision der Software geht es darum, Handlungsfelder zu identifizieren. Sind die abstrakten Teile der Software klar voneinander getrennt und entkoppelt? Müssen einzelne Komponenten und Drittsysteme ersetzt werden, weil sie Sicherheitslücken haben? Wo sind die Performance-Engpässe und durch was sind diese verursacht?

Das gesamte Team hat jetzt eine genaue Vorstellung über die Software und kann Maßnahmen definieren und Strategien entwickeln. Diese werden grob in ein Produkt-Backlog überführt und es werden in einigen wenigen Sprints ein neues Feature aus dem Backlog umgesetzt, um den Plan für die Software-Modernisierung zu evaluieren. Z.B. ist ein Use-Case jetzt in einer Web-Anwendung umgesetzt, der zuvor in der monolithischen Windows-Applikation enthalten war.

Und so werden sukzessive und nach Bedarf weitere Teile migriert. Die Software bleibt lebendig und modern und das Team agiert motiviert mit modernen Software Craftsmanship-Praktiken.