Legacy in der SOA-Welt

Der Marktdruck macht es erforderlich, dass Unternehmen kontinuierlich auf Veränderungen reagieren und ihre Prozesse anpassen, um wettbewerbsfähig zu bleiben. Diese Änderungen wirken sich auch auf die Legacy-Systeme aus und machen Anpassungen an diesen erforderlich. Mit zunehmendem Alter wächst für gewöhnlich der Aufwand für die Wartung und Anpassung solcher Systeme und damit auch deren Wartungsetat. Im Banken- und Versicherungsumfeld ist es nicht selten, dass die Altanwendungen über zehn Millionen Zeilen Code aufweisen. Die Realität zeigt aber, dass maximal 30 Prozent davon geschäftsrelevante Prozesse abbilden. Ab einem gewissen Punkt sind der finanzielle oder zeitliche Aufwand für Wartung oder Anpassung so hoch, dass ein Weiterbetreiben des Systems aus wirtschaftlichen Gesichtspunkten nicht mehr sinnvoll ist und das System grundlegend überarbeitet werden muss, sofern es nicht gleich ganz durch ein neues System ersetzt werden soll. Hierbei werden dann häufig Teile oder das komplette System auf eine neue Technologie oder Architektur wie SOA, JEE oder .Net migriert. Es gibt viele mögliche Migrationsstrategien, etwa Re-Engineering, Re-Hosting oder Re-Fronting. Je nach Legacy-System und Projekt können unterschiedliche Strategien sinnvoll sein. Im Folgenden wird das Re-Engineering betrachtet, also die Neustrukturierung und partielle oder auch vollständige Neuentwicklung des Anwendungssystems unter Beibehaltung der bestehenden fachlichen Funktionalität. Diese Funktionalität muss aus dem Legacy-System rekonstruiert werden, man spricht hier auch von einem ­Design Recovery. Dieses kann je nach Struktur und Alter der Applikation ziemlich komplex und mühsam sein. Ein Ansatz, der sich auf Modellierung und Generierung stützt, kann bei einem Re-Engineering vorteilhaft sein, um Kosten und Risiken zu senken. Die Grafik auf dieser Seite verdeutlicht den Prozess der Migration eines Legacy-Systems. Auf der linken Seite befindet sich die alte Anwendungssoftware, auf der rechten Seite die neue. Ausgehend vom Legacy-System gelangt man zu einem abstrakten Modell der Fachlichkeit und kommt von dort wieder zu einer konkreten Implementierung in der Zieltechnologie. Zur Darstellung der Fachlichkeit lässt sich die in der Software-Entwicklung für den Programmentwurf weit verbreitete und von der OMG standardisierte Unified Modeling Language (UML) verwenden. Um von links nach rechts zu kommen, das heißt, um das Legacy-System zu migrieren, ist es notwendig, folgende Punkte zu verstehen und zu visualisieren: die Domäne des Systems mit seinen Business-Entitäten, deren Beziehungen untereinander, die Applikationslogik und die mit dem System unterstützen Geschäftsprozesse.

Verständnis der Domäne erforderlich
Neben der Herausforderung, die Domäne und die realisierten Geschäftsprozesse des Legacy-Systems rekonstruieren und verstehen zu müssen, bringt eine Migration noch weitere Probleme mit sich. So müssen während der Umstellung die komplexen Beziehungen zwischen den Leistungsmerkmalen der alten und den entsprechenden Features der neuen Anwendung gehandhabt werden. Ansonsten besteht die Gefahr, den Bezug zwischen bereits migrierten Funktionen und nach und nach hinzukommenden zu verlieren, was sich negativ auf die Projekt- und Risiko-Kontrolle auswirken könnte. Hinzu kommt noch die Komplexität, die entsteht, wenn in Teams parallel entwickelt wird. Auch Probleme in der Kommunikation zwischen den Betreuern des alten und den Entwicklern des neuen Systems müssen berücksichtigt werden, da die Technologien und Begrifflichkeiten, in denen diese sich ausdrücken, oft sehr unterschiedlich sind. Deshalb sollte man den beteiligten Rollen eine einheitliche und systemneutrale Sicht anbieten, die es allen Beteiligten ermöglicht, über Systemaspekte in einer gemeinsamen Sprache zu kommunizieren – etwa eben über Modelle.

Quellcode analysieren
Zur Analyse des Quellcodes eines Altsystems bietet sich die Verwendung eines Asset Mining Tools an, wie zum Beispiel RMW von Relativity oder die Asset Transformation Workbench (ATW) von IBM. Diese Werkzeuge bieten Möglichkeiten, um Quellcode aufzubereiten und eine geeignete Sicht darauf zu erstellen. Hierbei bleibt man jedoch in der Do­mäne und den Begrifflichkeiten der Technologie, mit der die Legacy-Anwendung entwickelt wurde. Das bedeutet, dass diese Werkzeuge die alte Software auf eine Art und Weise darstellen, in der man mit den Entwicklern und Betreuern des Altsystems darüber kommunizieren kann. Diese aufbereitete Sicht auf den Quellcode dient als Input, um daraus das Domänenmodell, die Applikationslogik und die Prozesse in einem UML-Modell zu rekonstruieren. Diese Rekonstruktion kann mit entsprechenden Werkzeugen teilautomatisch erfolgen oder durch den Benutzer geführt werden. Das entstehende UML-Modell dient dann als Grundlage für die Kommunikation zwischen den Beteiligten während der Rekonstruktion und kann später als Ausgangspunkt für ein generatives Forward-Engineering verwendet werden.

Modellierung der ­Geschäftsprozesse
Die in einem Legacy-System implementierten Geschäftsprozesse lassen sich gewöhnlich nur schwer direkt aus dem Quellcode extrahieren. Hier bietet es sich an, zusammen mit den Anwendern und Betreuern des Altsystems die Prozesse zu rekonstruieren und zu modellieren. Dabei können gängige Werkzeuge zur Modellierung von Geschäftspro­zessen, wie zum Beispiel Aris von IDS Scheer, eingesetzt werden. Sind die Prozesse rekonstruiert, so kann man daraus ein UML-Modell erzeugen, um zusammen mit dem Modell der geschäftlichen Entitäten und der Applikationslogik ein umfassendes Modell der Legacy-Anwendung zu bekommen. Im nächsten Schritt gilt es, die Implementierung der rekonstruierten Geschäftsprozesse im Quellcode des Legacy-Systems zu identifizieren. Dabei kann wieder das Asset Mining Tool verwendet werden, um effizient und schnell den entsprechenden Quellcode zu finden und mit Zusatzinformation zu annotieren. Dieser annotierte Code definiert die fachlich relevanten Anteile des alten Programmsystems wie Definitionen von Datenstrukturen, Validierungs- und Applikationslogik, Screenflows und damit die Implementierung der Geschäftsprozesse. Mit geeigneten Werkzeugen wird dieser fachlich relevante Quellcode dann ebenfalls in das UML-Modell überführt. Diese Transformation kann teilweise automatisch oder durch den Benutzer gesteuert erfolgen. Aufgrund der Zusatzinformationen, mit denen der Quellcode annotiert wurde, können dabei die erzeugten Modellelemente mit den entsprechenden Elementen der Geschäftsprozesse verknüpft werden. Das Ergebnis ist ein UML-Modell des Legacy-Systems, das alle Business-Entitäten, die Applikationslogik und die Geschäftsprozesse enthält. Spezielle Werkzeuge zum Re-Engineering von Legacy Systemen bieten hier Unterstützung, um einen iterativen und inkrementellen Migrationsprozess zu realisieren. Dadurch ist es möglich, das Altsystem Stück für Stück zu analysieren und fachlich relevante Anteile nach und nach in das UML-Modell zu überführen.

Generierung der ­Zielapplikation
Das UML-Modell dient nun als Quelle, als Platform Independent Model (PIM), für ein generatives Forward-Engineering im Sinn der Model Driven Architecture (MDA). Es wird entsprechend der neuen Zieltechnologie und Zielarchitektur refaktoriert, mit dafür spezifischen Informationen erweitert und damit ein Platform Specific Model (PSM) erzeugt. Aus diesem kann nun eine Implementierung für die neue Zieltechnologie teilweise automatisch erzeugt werden. In dem beschriebenen Migrationsprozess spielt das UML-Modell eine zentrale Rolle. Es dient als Integrationspunkt und Kommunikationsmedium für die verschiedenen Handlungsstränge während einer Migration. Im Gegensatz zu herkömmlichen Vorgehensweisen ermöglicht dieser Ansatz, Aufgaben bei der Migration eines Legacy-Systems in einem Team effizient zu planen, zu verteilen und zu steuern. Spezielle Tools zur Migration von Legacy-Systemen bieten noch weitere Unterstützung, zum Beispiel in Form von integrierten Workflow Engines, die diesen Migrationsprozess abbilden. Dadurch erhöhen sich die Effizienz und die Beherrschbarkeit eines Migrationsprojektes, und sowohl Kosten als auch Risiken bei der Planung und Durchführung des Projektes lassen sich reduzieren.

Thomas Wölfle ist Senior Entwickler und Christian Jäschke Marketing ­Manager bei der Beratungsfirma ­interactive Objects in Freiburg.