SOA: Migration von Legacy Systemen

Unternehmen und Behörden, die seit Jahrzehnten umfangreich auf den Einsatz von IT setzen, wie z. B. Banken oder Ministerien, stehen vor der permanenten Herausforderung, ihre IT-Systeme zu modernisieren. Dafür gibt es vielseitige Gründe.

Bevor wir auf das eigentliche Thema eingehen, möchten wir an dieser Stelle auf unseren Artikel zu den SOA-Grundlagen hinweisen, in dem wir das Thema SOA-Neulingen näherbringen.

Zurück zu den Gründen, wieso Banken oder Ministerien permanent ihre IT-Systeme modernisieren müssen: Zum einen sind die bestehenden Systeme nicht mehr in der Lage die an sie gestellten Anforderungen zu erfüllen. Die Systeme sind zu statisch und der Wartungsaufwand ist zu hoch. Zum anderen gibt es immer weniger Personal, das die eingesetzten Technologien wie z. B. Cobol, PL/1, Fortran oder den Umgang mit Betriebssystemen wie MVS beherrscht. Es fehlt schlicht der Nachwuchs, um die Systeme weiterhin zu betreiben. Die Entwicklergeneration, die diese Systeme entwickelt hat und beherrscht, verabschiedet sich aus der Arbeitswelt. Die nachfolgende Generation hat meist wenig interesse, sich mit diesen Technologien auseinanderzusetzen. Die genannten Gründe führen zu einem hohen Druck, die Systeme auf neue Technologien zu migrieren. Die Notwendigkeit zur Migration dieser veralteten IT-Systeme ist vielen Unternehmen seit Jahren bewusst, doch mit den hohen Kosten vor Augen wird sie oft nur zögerlich durchgeführt. Neben den Legacy Systemen, die beispielsweise noch auf Mainframetechnologien basieren, sind in der Zwischenzeit Legacy Systeme entstanden, die ich hier als Legacy Systeme der zweiten Generation bezeichnen möchte. Dies sind Systeme, die zwar bereits grafische Benutzeroberflächen besitzen und die auf einem objektorientierten Design basieren, dessen Lebensdauer aber inzwischen überschritten wurde. Im Prinzip haben diese Systeme mit den gleichen Problemen zu kämpfen wie die Legacy Systeme der ersten Generation. Hoher Wartungsaufwand und wenig Flexibilität.

Ist die Entscheidung zur Migration eines Systems gefallen, muss entschieden werden, ob es Sinn macht, auf eine individuelle Entwicklung zu setzen, oder das System in eine Standardsoftware zu migrieren. Dazu bieten sich beispielsweise die auf dem Markt befindlichen ERP-Systeme an. Die Vorteile von Standardsoftware sind klar, aber es gilt zu berücksichtigen, dass der Zwang entstehen kann, die Geschäftsprozesse an die Standardsoftware anzupassen. In einem gewissen Rahmen ist durch Customizing eine Anpassung der ERP-System möglich, aber das hat unter Umständen sehr enge Grenzen. Das Anpassen der Prozesse kann sinnvoll sein, aber wenn gerade die Geschäftsprozesse in ihrer Art und Weise einen Wettbewerbsvorteil darstellen ist das keine wirkliche Option. Dann sind unter Umständen umfangreiche Erweiterungen, im extremen Fall sogar Modifikationen der ERP Software, notwendig. In diesem Fall macht der Einsatz von Standardsoftware wenig Sinn, da die Vorteile im Vergleich zu einer Individualentwicklung hinfällig werden. Im weiteren Verlauf geht es um die Migration in eine Individuallösung auf Basis einer serviceorientierten Architektur. Hier gibt es die Möglichkeit einer kompletten Migration und die der partiellen kontinuierlichen Migration.

Komplette Migration

Eine Möglichkeit ist es das neue System erst komplett zu entwickeln und dann zu aktivieren, wenn es fertiggestellt wurde. Das Legacy System verrichtet bis dahin weiterhin seinen Dienst. Durch diesen harten Schnitt ergeben sich mehrere Probleme. Erstens handelt es sich auch bei Legacy Systemen um sogenannte “Lebende Systeme”. Das bedeutet, dass laufend nötige Anpassungen bzw. Änderungen an ihnen gemacht werden. Damit das neue System nicht auf einen alten Stand gestartet wird, muss die Spezifikation des neuen Systems auf dem neuesten Stand gehalten werden. Je nachdem wie häufig das Legacy System diesen Anpassungen unterliegt, gerät man schnell in einen Kreislauf und ist hauptsächlich damit beschäftigt, das in der Entwicklung befindliche System an die neuen Anforderungen anzupassen. Das zweite Problem stellt die oft hohe Komplexität der Prozesse dar. Alle möglichen Sonderfälle in der neuen Software zu berücksichtigen ist oft nicht möglich. Fehlende Dokumentation der Prozesse bzw. des Legacy Systems sind der Hauptgrund dafür. Das bedeutet, dass das System nicht mit den gewünschten Fähigkeiten bzw. der vollen Funktionalität gestartet werden kann, die von den Stakeholdern erwünscht ist. Dies ist nicht förderlich für die Akzeptanz des neuen Systems und kann ein Projekt je nach Ausmaß des Defizits komplett gefährden. Auch das Testen des neuen Systems im Ganzen ist sehr aufwändig und, je nach Grad der Komplexität, lückenlos praktisch nicht möglich. Als letztes kommt noch die Datenmigration zwischen den Systemen hinzu. Da das Legacy System bis zum Stichtag im Produktivbetrieb ist, müssen die Daten schnell ins neue System gebracht werden. Hier gilt es, Inkonsistenzen zu vermeiden, insbesondere im Hinblick auf die Kommunikation mit anderen Systemen. Sie sehen, die Risiken der kompletten Migration sind in der Summe zu groß, die Kosten zu schlecht beherrschbar, um die komplette Migration ernsthaft in Erwägung zu ziehen. Der Ansatz eignet sich nur bei der Migration von kleinen Systemen, deren Relevanz nicht systemkritisch ist und der Kostenrahmen überschaubar bleibt.

Partielle kontinuierliche Migration

Bei einer partiellen kontinuierlichen Migration geht es darum, gezielt einen Prozess nach dem anderen zu betrachten und diesen dann auf die neue Technologie umzustellen. Diese Vorgehensweise bietet sich für SOAs wegen ihrer Prozessorientierung an. Die Vorteile liegen darin, dass die signifikanten Faktoren wie bsp. die Kosten bzw. die Dauer der Migration besser eingeschätzt werden können. Dazu findet für jeden Prozess eine separate Bewertung statt. Das führt zu einer Reduzierung der Risiken. Auf der technischen Seite lassen sich die einzelnen Prozesse gut testen, da die Tests in einem produktiv nahen Umfeld gemacht werden können. Allerdings bringt das auch einen Mehraufwand bei der Entwicklung des Systems mit sich. Die bereits umgestellten Prozesse müssen mit dem Legacy System kommunizieren. Hier entsteht ein unter Umständen hoher Aufwand, um die erforderlichen Schnittstellen bereitzustellen. Zudem muss darauf geachtet werden, sich nicht an die Architektur des Legacy Systems zu binden und so die Möglichkeiten des neuen Systems einzuschränken. Ein weiteres Problem bzw. Eigenschaft der Legacy Systeme ist, dass diese nicht prozessorientiert entwickelt wurden. Oft sind diese Systeme auf Basis von prozeduralen Programmiersprachen entwickelt worden. Dies hat zur Folge, dass die Prozesse keinesfalls in Modulen bzw. Funktionen gekapselt sind. Vielmehr gibt es eine starke Bindung von Modulen bzw. Funktionen über viele, unter Umständen auch andersartige, Prozesse hinweg. Dies führt dazu, dass nicht ohne weiteres ein Prozess herausgelöst werden kann, ohne einen anderen Prozess in seiner Funktionalität zu beeinträchtigen. Das bedeutet, dass mit großer Wahrscheinlichkeit für die Migration Anpassungen an dem Legacy System gemacht werden müssen. Ein zusätzlicher Aufwand, der bei der Projektplanung zu berücksichtigen ist.

Migrationsstrategien

Die Migrationsstrategie spezifiziert die Technik, mit der das Legacy System migriert werden soll. Für eine Migration stehen im Wesentlichen vier Migrationsstrategien zur Auswahl. Dabei handelt es sich um die Konversions- , die Wrapping- , Reimplementierungs- und die Increase-Strategie.

Konversionsstrategie

Konversion bedeutet eine automatische Transformation der Daten und Programme in eine neue Technologie. Dadurch lassen sich im Vergleich zur Reimplementierungsstrategie Kosten sparen. Allerdings muss das Legacy System so strukturiert sein, dass es eine automatisierte Transformation zulässt. Gegebenenfalls müssen die Werkzeuge für die Migration auch noch selbst entwickelt werden. Dies kann die Kosten einer Reimplementierung schnell übersteigen, sodass abgewägt werden muss, welcher Weg für eine 1:1 Umstellung zu wählen ist. Dieser Migrationsstrategie sollte mit einem gesunden Maß an Skepsis gegenübergetreten werden. Systeme, die prozedural entwickelt wurden, automatisch in moderne objektorientierte Strukturen zu transformieren, ist äußerst schwierig und die Ergebnisse meistens enttäuschend. Diese Migrationsstrategie kann bestenfalls nur ein Zwischenschritt auf dem Weg zu einer Serviceorientierten Architektur sein. Die Transformation der Technologie ändert nicht die Architektur im notwendigen Maße. Nach der Konversion muss die Architektur des IT-Systems angepasst werden. Es ist also wenig gewonnen. So wenig, dass diese Strategie für die Migration in eine SOA nicht geeignet erscheint.

Wrappingstrategie

Unter der Wrapping-Strategie versteht man das Kapseln der alten Programme in eine neue Technologie. Das bedeutet, dass das Legacy System an sich in seiner alten Form bestehen bleibt. Der Zugriff auf das System geschieht dann über Schnittstellen, die in einer neuen Technologie entwickelt wurden. Das kann beispielsweise eine moderne GUI sein oder es werden über Web-Services Funktionen des Legacy Systems “öffentlich” zur Verfügung gestellt. Dies ist eine Methode, um schnell und günstig ans Ziel zu kommen, allerdings bleiben die Altlasten in großen Teilen erhalten.

Reimplementierungsstrategie

Bei der Reimplementierung geht es um die Neucodierung des Legacy Systems. Das bedeutet, dass das neue System nicht in der Funktionalität erweitert wird, sondern lediglich der aktuelle Funktionalitätsumfang des Legacy Systems in einer anderen Technologie abgebildet wird. Das Legacy System bildet die Ausgangsbasis und die Architektur bleibt im Wesentlichen erhalten. Das ist jedoch nur möglich, wenn das Legacy System derart modular strukturiert ist, dass sich diese Module sinnvoll in Services kapseln lassen. Falls notwendig werden auch die Datenstrukturen angepasst.

Increasestrategie

Hier wird nicht nur eine Reimplementierung des Legacy Systems vorgenommen. Die Increasestrategie stellt im Wesentlichen eine Erweiterung der Reimplementierungsstrategie dar. Die existierende Funktionalität wird abgebildet, aber es finden auch neue Anforderungen in das System. Falls notwendig, wird die bestehende Architektur des Legacy Systems aufgebrochen und verändert. Bei der Migration auf eine SOA ist das die Regel. Das Legacy System bildet zusammen mit den neuen Anforderungen die Ausgangsbasis. Diese Strategie ist mit einem höheren Risiko verhaftet, aber meist bei der Migration in eine SOA der einzig gangbare Weg. Der Kunde ist häufig mit dem Funktionalitätsumfang oder den technischen Parametern des Legacy Systems unzufrieden, daher ist es zwingend notwendig, die neuen Anforderungen direkt mit einfließen zu lassen.

Leitfaden für eine Migration

Welche Vorgehensweise stellt die geeignetste dar? Im wesentlich gilt, dass Migrationsprojekte so individuell wie die Legacy Systeme sind. Dennoch halte ich nur zwei der genannten Strategien für sinnvoll. Das sind in geringen Fällen die Reimplementierungsstrategie und im Wesentlichen die Increasestrategie. Neben der Frage, welche Strategie eingesetzt wird, stellt sich die Frage wie eine sinnvolle Vorgehensweise bei einer Migration aussehen kann (siehe Abbildung). Dort gibt es natürlich die üblichen Schritte, die es im Rahmen eines solchen Projektes zu erledigen gilt. Doch es gibt auch spezifische und technische Fragen zu klären, z. B.  wie mit der Datenbasis zu verfahren ist. Sollen die Daten so lange wie möglich innerhalb des Legacy Systems persistiert oder so früh wie möglich auf die neue Technologie gehievt werden etc. Ein Rahmenwerk bzw. ein Modell, das den System-Architekten beim Lösen solcher Fragestellungen unterstützen soll, wird in einem späteren Blog vorgestellt. Die Abbildung zeigt, auf welche Phasen sich dies auswirken wird.

 

Literatur:

[1] Harry M.Sneed, Ellen Wolf, Heide Heilmann: Softwaremigration in der Praxis. dpunkt.verlag, 1.Auflage, ISBN 978-3-89864-564-5, 2010

[2] Michael Schidlauske: Migration von Legacy Systeme in Serviceorientierte Architekturen, 2010