Legacy IT: Herausforderungen, Strategie und 5Rs
Für Freunde des Black- und Death-Metal sei gleich zu Beginn klargestellt, dass dieser Artikel sich nicht um das Musikmagazin „Legacy“ dreht. Vielmehr geht es um die wörtliche Übersetzung „Altlast“, die wir aus dem Blickwinkel der IT betrachten wollen.
Herausforderungen auch abseits des Hosts
Mit dem Begriff Legacy wird in der IT als erstes der Host assoziiert. Dieser kann zu Recht aus Sicht der Informatik als alt bezeichnet werden – liegt der Start doch schon über 50 Jahre zurück. Dies gilt analog für viele auf dem Host entwickelte Anwendungen und für die eingesetzten Programmiersprachen. Die Anwendungen sind meist historisch gewachsen. Das Ende der Berufstätigkeit der Key Player und die schwindende Entwicklergemeinde lassen die Anwendungen als Altlasten erscheinen. Gleichzeitig erhöhen die Kosten des proprietären Systems den Modernisierungsdruck.
Zunehmend werden jedoch auch jüngere Systeme zu einer (Alt-)Last für Unternehmen. Dies ergibt sich zum einen aus den zunehmenden Anforderungen. Der wachsende Umfang an Anforderungen kann dazu führen, dass ursprünglich für einen kleinen Anwendungsbereich entwickelte Software im Laufe der Jahre sukzessive erweitert wird. Weil die Architektur der Anwendungen kein ungehemmtes Wachstum trägt, erfordert die Wartung und der Betrieb solcher Anwendungen mehr und mehr Aufmerksamkeit. Dies umso mehr, wenn der Bedarf an kürzeren Releasezyklen durch Continuous Integration und automatisierte Tests nicht von Anfang an mitgedacht oder konsequent durchgeführt wurde. Die technischen Schulden wachsen mit der Zeit.
Die Anforderungen aus der Digitalisierung und der Wunsch von Entwicklern nach neuen Technologien treiben die Modernisierung voran. Dies kann auch nur die Peripherie einer Anwendung betreffen. Die Entwicklungen in der Robotik sowie des IoT und der Einzug von Smart Devices in den Alltag fordern laufende Erneuerungen rund um den Kern einer Software. Die Integrationsfähigkeit der Software mit anderen Anwendungen und im Rahmen einer Orchestrierung in automatisierten Geschäftsprozessen ist heute gefragter denn je.
Zum anderen entstehen Altlasten durch das End of Life der eingesetzten Technologien. Für diese können aufgrund der rasanten Entwicklung nicht erst nach 50 Jahren, sondern bereits nach zehn bis fünfzehn Jahren der Support und die Unterstützung der Community auslaufen. Als Beispiel sei Java EE erwähnt, dessen Zukunft aktuell mehr als ungewiss ist (vgl. Java EE ist tot – es lebe Spring (Boot)!). Neben der Architektur der Anwendung und Implementierung der Geschäftslogik sind gleichfalls Java EE Frontends betroffen, die auf JavaServer Faces (JSF) basieren. Weitere Technologien, die rund um das Ökosystem Java EE entstanden sind, können mit betroffen sein.
Der Umgang mit Altlasten erfordert eine auf die Anwendungslandschaft abgestimmte Legacy-IT-Strategie. Präventiv ist ein laufendes Architekturmanagement sinnvoll, um Handlungsbedarfe frühzeitig zu erkennen und die Entstehung von Legacy Software zu verhindern.
Wege zur Legacy-IT-Strategie
Wichtig in der Praxis ist es, Handlungsbedarfe frühzeitig zu erkennen, zu kommunizieren und geeignete Maßnahmen zu ergreifen.
IT-Abteilungen sind die Handlungsbedarfe grundsätzlich bekannt. Dennoch kann es helfen, eine systematische Aufnahme der Anwendungslandschaft in Form eines Architekturbildes vorzunehmen. In Form von Prozesslandkarten können die Kern- und Nebenprozesse anschaulich dargestellt und mit den Anwendungen in Einklang gebracht werden. Dies erlaubt eine klare Zuordnung von Verantwortlichkeiten und die Fokussierung auf Kernprozesse und -produkte. Eine Technologielandkarte stellt Cluster aus technischer Sicht zusammen, auf deren Basis das Erkennen von Handlungsfeldern möglich ist.
In diesem Zusammenhang spielt die Konsolidierung von Anwendungen eine Rolle. Bei einigen Unternehmen sind auf Grund von Fusionen, Zukäufen oder des Angebotes von Dienstleistungen für verschiedene Mandanten Anwendungen mit überschneidenden Zuständigkeiten entstanden. Dies sind nicht zwingend Legacy-Anwendungen, dennoch können Handlungsoptionen wie für Legacy-Systeme anwendbar sein.
Das Architekturbild bildet die Basis für die Kommunikation. Die Risiken können konkret benannt und Handlungsbedarfe dargestellt werden. Gepaart mit den im Folgenden erläuterten Handlungsoptionen und einem möglichen Zielbild wird die Situation für Entscheider in Form einer Legacy-IT-Strategie transparent.
Auswahl aus den 5Rs
Als 5Rs werden die fünf Strategien zum Umgang mit Legacy IT bezeichnet: Retire, Replace, Reengineer, Rehost, Retain. Die Auswahl einer konkreten Strategie hängt zu einem großen Teil von der Ausgangssituation ab.
Die Strategie Replace bezeichnet den Austausch der Legacy-Anwendung durch ein anderes fachliches Anwendungssystem. Die Legacy-Anwendung kann durch eine gekaufte Standardsoftware oder eine Individualentwicklung ersetzt werden. Replace wird fast einheitlich für die Ablösung von Host-Systemen gewählt. Kündigt ein Hersteller den End of Life seiner Software an, ist ein Replace unumgänglich. Dies kann auch Eigenentwicklungen treffen, wenn eingesetzte Frameworks, Bibliotheken oder Laufzeitumgebungen nicht mehr unterstützt werden.
Die Modernisierung eines Systems, das sogenannte Reengineer, erfolgt in Schritten. Für die Wahl einer Vorgehensweise eignet sich die Orientierung an Komponenten oder Schichten. Die Option Reengineer bietet sich an, wenn es keines vollständigen Austausches aller Technologien bedarf und die Umsetzung der fachlichen Logik beibehalten werden kann.
Mit Retire ist die Abschaltung der Legacy Anwendung gemeint. Zuvor sind sehr oft die Daten gemäß einem fachlichen Regelwerk, in das Zielsystem zu überführen. Dies wird als fachliche Datenmigration bezeichnet (vgl. Fachliche Datenmigration bei Legacy-Anwendungen). Die finale Abschaltung der Legacy Anwendung wird in vielen Fällen trotzdem verhindert. Historische Daten oder Restanten werden nicht migriert, weil deren Abbildung im Zielsystem nicht wirtschaftlich ist. Falls dies dennoch erfolgt ist, bedarf die Abschaltung einer sorgfältigen Planung. Die bisher über Schnittstellen versorgten und angebundenen Systeme sowie die anwendungsübergreifenden Abläufe müssen auch nach der Abschaltung reibungslos funktionieren.
Die reine Verlagerung der Legacy Anwendung auf eine andere Betriebsplattform wird durch die Strategie Rehost ausgedrückt. Mit einem Rehost kann der laufende Betrieb gesichert und Kosten reduziert werden. Für den Anwender ergeben sich trotz der für den Rehost gebundenen Ressourcen keine Verbesserungen. Deshalb wird diese Strategie nur bei sehr dringenden Gründen und einer kurzfristig erforderlichen Ablösung gewählt.
Besteht kein dringender Handlungsbedarf, kann die Strategie Retain gewählt werden. Die Legacy Anwendung wird weiter betrieben.
Fazit
Legacy ist in allen Unternehmen ein bekanntes Handlungsfeld. Bei den grundlegenden Herausforderungen variiert deren Bedeutung und Einfluss auf die Legacy-IT-Strategie abhängig vom konkreten Fall. Die Umsetzung in den Unternehmen ist eine mittel- bis langfristige Aufgabe. Für eine reibungslose Modernisierung kommt den Querschnittsthemen wie Cloud, IT-Sicherheit und Testautomatisierung eine hohe Bedeutung zu.
In den letzten Monaten haben wir unsere Kunden gezielt zum Thema Legacy IT befragt. Dabei wurden die oben genannten Herausforderungen ausnahmslos bestätigt.
