Software-Modernisierung, Teil 3 Ansätze für die Software-Modernisierung

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Legacy-Software verursacht oft unnötig hohe IT-Kosten. Eine Modernisierung kann sich also lohnen. Allerdings sollte nachhaltige Anpassung von Software vorab gut geplant werden – andernfalls kann es während oder nach der Modernisierung zu erheblichen Problemen kommen.

Viele Unternehmen setzen noch auf sogenannte Legacy-Software: Programme und Tools, die teilweise schon seit Jahrzehnten genutzt werden und fest in die Arbeitsabläufe integriert sind. Für den Geschäftsbetrieb unverzichtbar, schluckt solche Altsoftware nicht selten enorme Ressourcen der IT-Abteilung, die tagtäglich damit kämpft, den Betrieb aufrecht zu erhalten. Legacy-Software entwickelt sich so mit der Zeit zu einer Art trojanischem Zeit- und Geldfresser, der trotz allem moderne Standards nur noch mit hohem Aufwand erfüllt.

Legacy-Software oft tief integriert

Dummerweise sind viele Legacy-Lösungen tief in Unternehmensstrukturen integriert, oft essenziell für den Arbeitsablauf und nicht selten hochkomplex und schlecht dokumentiert, weil sie über einen langen Zeitraum organisch gewachsen ist. Alte, kostenintensive Lizenzen, fehlende Schnittstellen und veraltete, nicht-intuitive Oberflächen und Wissensverlust (etwa durch Ruhestand älterer Mitarbeiter) drücken die Kosteneffizienz.

Schlimmstenfalls setzt sie auf veraltete Hardware, die im Falle eines Defekts immer schlechter auszutauschen ist. Doch selbst, wenn dieser Worst-Case noch nicht eintritt: Die Modernisierung von Legacy-Software ist oft schon aus Kosten- und Effizienzgründen sowie für die mittelfristige Aufrechterhaltung des Betriebs dringend nötig – und stellt gleichzeitig eine Gefahr für eben diesen Betrieb des Unternehmens dar.

Bestandsaufnahme vornehmen

Um diesem Dilemma zu entrinnen, gilt es, nach Feststellung des Modernisierungsbedarfs eine Strategie für die Modernisierung der Software zu entwickeln. Zunächst ist natürlich eine Bestandsaufnahme des Ist-Zustands der aktuellen Lösung samt Prüfung von Kosten und Alternativen notwendig:

• Welche Unternehmensbereiche sind betroffen?

• Welche Funktionen liefert die Software und welche Schnittstellen und Dateiformate nutzt sie?

• Können künftige Funktionen noch implementiert werden?

• Gibt es gegebenenfalls inzwischen moderne Softwareprodukte, die die Legacy-Software funktional ersetzen können?

• Oder ist eine vollständige Neuentwicklung notwendig, da das Produkt sehr speziell ist?

• Wer kann die Modernisierung übernehmen und wie lange wird sie dauern?

• Was soll das Ziel der Modernisierung sein?

• Und nicht zuletzt sollte natürlich eine Kostenplanung erstellt werden.

Teilmodernisierung oder vollständige Neuentwicklung?

Grundsätzlich gibt es natürlich mehrere Möglichkeiten, eine Software-Modernisierung durchzuführen. Dabei kommt es vor allem darauf an, wie sich der aktuelle Bestand zeigt und eine wie tiefgehende Softwaremodernisierung überhaupt notwendig ist. So kann es durchaus sein, dass ein altes Produkt nur in Teilen modernisiert werden muss: Etwa, wenn ein grundsätzlich noch solides Legacy-Produkt eine neue Benutzeroberfläche benötigt. Allerdings ist hier die Grenze für weiteres Flickwerk bei diesem Beispiel natürlich fließend.

Ansätze für die praktische Modernisierung

In aller Regel ist es im Unternehmensbereich wichtig, den Betrieb einer Software aufrechtzuerhalten, bis das modernisierte Produkte ausgerollt wird. Hier gibt es verschiedene Ansätze, die anhand der Bestandsaufnahme geprüft werden können. Da Software in aller Regel drei Ebenen hat – Benutzeroberfläche, Steuerungsfunktionen und Datensätze – ist es sinnvoll, zunächst die ersten beiden Bereiche zu aktualisieren und die Daten anschließend zu migrieren.

1. Lift and Shift durch Virtualisierung

Der wohl einfachste und störungsfreieste Ansatz ist das sogenannte Lift-and-Shift-Prinzip: Man „nimmt die alte Software hoch“ und schiebt die neue an ihre Stelle. Dank den Möglichkeiten der Virtualisierung kann es sich, abhängig von der Anwendung, lohnen, das Legacy-Produkt zunächst platz- und energiesparend als virtuelle Instanz auf moderner Infrastruktur weiterzubetreiben, während die Neuentwicklung im Hintergrund läuft.

Das hat mehrere Vorteile: Einerseits ist der Betrieb des Legacy-Produkts nach Belieben und ohne all zu hohen technischen Aufwand gewährleistet. Andererseits kann diese Lösung durch den Verzicht auf dedizierte Hardware die Energiekosten des Legacy-Produkts schnell deutlich senken und die Performance steigern. Daher bietet sich eine Virtualisierung übrigens auch für Altsoftware an, die noch keiner Modernisierung bedarf und natürlich auch für die neue Lösung.

Der größte Vorteil ist aber, dass die Software-Modernisierung mit überschaubaren Infrastrukturkosten machbar ist. Zumal es obendrein einen beliebigen Zeitpuffer gibt, in dem das Legacy-Produkt neben der modernisierten Software betrieben werden kann, etwa für die Sicherstellung aller Funktionen oder den Datenabgleich.

2. Adaptierung zwischen neuer und alter Lösung

Eine Alternative stellt das Adaptieren der alten und neuen Software-Lösung dar: Im laufenden Betrieb wird die vorhandene Softwarelösung sozusagen ummantelt und und per Software-Schnittstelle mit der neuen Lösung verbunden. Dadurch wird die Altsoftware sozusagen ein Teil der neuen Software und kann nach und nach Daten abgleichen und abgeschaltet werden, sobald das redundante neue System zuverlässig läuft.

Diese Vorgehensweise bietet sich dort an, wo eine Virtualisierung nicht oder nur mit hohem Risiko möglich ist – etwa in Systemen, die spezielle Hardware-Schnittstellen bedienen oder sicherheitsrelevant sind. Auf diese Weise wird zu jedem Zeitpunkt dafür gesorgt, dass das Altsystem funktioniert – bis das neue System vollständig ausgerollt ist. Grundsätzlich kann diese Variante aber auch mit Lift & Shift kombiniert werden.

3. Laufendes Re-Coding der alten Lösung

Eine zusätzlich Alternative kann – zumindest in gut dokumentierten Legacy-Systemen – das stückweise Neucodieren der alten Lösung samt Continuous Integration sein: Ob automatisiert oder manuell, vorhandener Alt-Code wird nach und nach auf ein modernes Niveau gehoben und angepasst, wobei sich diese Umwandlung aber nicht wie bisher auf Teile, sondern nach und nach auf das ganze Software-Produkt erstreckt.

Diese Lösung kann mit der Adaptierung und/oder Lift and Shift zusammen verwendet werden, bietet sich aber vor allem in restlos veralteten Systemen an, die keine Möglichkeit mehr zur Modernisierung bieten, etwa weil sie auf obsoleten Betriebssystemen aufsetzen oder altbackene Hardware benötigen. Die Migration ist in diesem Modell natürlich komplex und mit biologischen Verfallsprozessen vergleichbar: Die neue Software überwuchert mit der Zeit das Altprodukt wie ein Pilz, um es zu guter Letzt vollständig aufzulösen.

4. Vollständige Neuentwicklung

Last but not least gibt es natürlich auch den Ansatz, ein Produkt von Grund auf neu zu entwickeln und erst anschließend auszurollen. Hier spielt vor allem der Zeit- und Kostenfaktor eine große Rolle: Bei den zumeist hochkomplexen Systemen wird im Rahmen dieses Ansatzes irgendwann der Hebel umgelegt und die neue Software ist in Betrieb. Neben den hohen Kosten zu Beginn ist vor allem der Zeitfaktor nicht unerheblich: Ein nahtloser Übergang ist kaum möglich, zusätzliche Kosten und Verzögerungen entstehen durch Schulungen von Mitarbeitern oder das aufwändige Testing in sicherheitsrelevanten Bereichen.

Das lässt sich durch die Kombination mit Parallelbetrieb oder Virtualisierung der Altsoftware zwar abfedern; trotzdem liegt es in der Natur der Sache, dass eine Neuentwicklung nie vom Start weg perfekt ist. Dadurch müssen gegebenenfalls Folgekosten und Zeitaufwand für die Optimierung und Probleme im Betriebsablauf berücksichtigt werden. Eine vollständige Neuprogrammierung bietet sich von daher nur an, wenn die Legacy-Software sehr schlecht dokumentiert ist und kaum Möglichkeiten zur direkten Modernisierung bietet.

(ID:47944858)