Von der Legacy- in die SOA-Welt

03.01.2006
Von Dirk Slama
Der Transformationsansatz Legacy-to-SOA kann helfen, komplexe und inflexible Bestandssysteme zu schlanken und agilen Anwendungslandschaften umzubauen.
Um zu entscheiden, was mit einem Altsystem passieren soll, müssen Unternehmen dessen strategischen Wert bestimmen sowie analysieren, wie flexibel es sich künftig noch anpassen und warten lässt.
Um zu entscheiden, was mit einem Altsystem passieren soll, müssen Unternehmen dessen strategischen Wert bestimmen sowie analysieren, wie flexibel es sich künftig noch anpassen und warten lässt.

Seit Jahrzehnten versuchen Unternehmen, die Evolution ihrer komplexen, heterogenen Anwendungslandschaften besser in den Griff zu bekommen. Bemühungen, den dennoch entstehenden Anwendungswildwuchs durch Integration zu lösen, schlugen allesamt fehl. So sind Systeme für Enterprise Application Integration (EAI) und Middleware nur taktische Mittel und liefern punktuelle Lösungen. Sie adressierten aber die strukturellen Probleme der Anwendungslandschaften nur selten. Silo-Architekturen, Shadow Accounts und Batch-Integration sorgen nach wie vor häufig für Redundanzen, Inkonsistenzen und drastische Ineffizienzen.

Ratschläge

• Analysieren und bewerten Sie, welche Optionen zur Modernisierung der Anwendungslandschaft existieren.

• Untersuchen Sie, ob sich eine Kombination verschiedener Ansätze empfiehlt, zum Beispiel die Transformation von Kernsystemen zusammen mit kommerziellen Komponenten, integriert auf der Prozessebene.

• Nutzen Sie bei der Umsetzung die Möglichkeiten, welche die SOA zur Koordination von Fachbereich und IT bietet.

• Binden Sie die Fachbereiche frühzeitig ein, insbesondere bei der Umsetzung prozessorientierter Architekturen.

• Verhindern Sie, dass der Scope des Modernisierungsprojektes zu weit ist.

• Die initiale Version des Zielsystems sollte funktional nahe am Altsystem sein.

• Nutzen Sie dann die Möglichkeiten von SOA und POA, um Prozesse zu verbessern, beziehungsweise neue Prozesse und Dienste stufenweise hinzuzufügen.

Über Modelle zur SOA

Harvesting: Identifikation und Extraktion der fachlichen Assets im Altsystem. Abstraktion und Reduktion führen zu einem auf das Wesentliche reduzierten und daher beherrschbaren UML-Anwendungsmodell.

Optimierung: Das UML-Anwendungsmodell der Altanwendung wird restrukturiert und optimiert. Insbesondere werden Objekte und Services transformiert (OO- und SOAfizierung).

Forward Engineering: Verfeinerung des Anwendungsmodells um technische Aspekte wie beispielsweise Persistenz. Ausnutzung von Model Driven Architecture (MDA), um möglichst große Teile des Zielsystems automatisch zu generieren. MDA erlaubt genaue Kontrolle über die Auslegeordnung der fachlichen Modellelemente in die verschiedenen Schichten der SOA.

Praxisbeispiel

Bank Coop, die Schweizer Retail-Bank für Privat- und Firmenkunden, hat erfolgreich ihr Kreditverwaltungssystem von OS/2 auf eine moderne, Service-orientierte Architektur auf Basis der Java 2 Enterprise Edition umgestellt. Das Projekt wurde von CSC Schweiz mit Hilfe des Ansatzes "Model Driven Legacy Transformation" und dem Produkt "Arcstyler" von Interactive Objects umgesetzt.

Der modellgetriebene Transformationsansatz hatte zwei wesentliche Vorteile: Erstens konnte bei der Transformation ein sehr hoher Automatisierungsgrad erreicht werden, zweitens ließen sich die verbleibende manuelle Codierung effizient von CSC Indien in einem Mix-Shore-Ansatz umsetzen. Der modellgetriebene Ansatz lieferte einen wesentlichen Beitrag zur Kontrolle der klassischen Offshore-Risiken, da er die Zusammenarbeit zwischen dem On-Site und Offshore-Team optimierte und eine genauere Kontrolle der einzelnen Projektphasen ermöglichte. Außerdem wurde die durchgängige Konsistenz der Zielarchitektur sichergestellt und die vom Kunden geforderten Qualitätsmerkmale der Neuanwendung (Kostenreduktion für die langfristige Wartung unter anderem) erreicht.

Hier lesen Sie …

• wie sich Altsysteme in eine SOA einbinden lassen;

• welche Projektschritte dazu nötig sind;

• wie ein modellgetriebener Ansatz den Umstieg erleichtern kann;

• welchen Nutzen Process-oriented-Architectures (POAs) haben.

Es gibt keine Patentlösung für die Probleme des "Application Spaghetti" (Gartner). Allerdings kristallisieren sich heute Service-orientierte Architekturen (SOA), Business Process Management (BPM) und Enterprise Architecture (EA) als die elementaren Bestandteile eines langfristig tragfähigen Lösungsansatzes heraus.

Die Umsetzung einer SOA bedeutet dabei auf Dauer eine fundamentale Transformation der Anwendungslandschaft. Ziel ist die sukzessive Entwicklung von lose gekoppelten Komponenten, die als flexibel kombinierbare Bausteine (Dienste) verwendet werden können, um neue fachliche Anforderungen schnell und effizient zu erfüllen.

Web-Services nur eine Option

Der wesentliche Fokus einer SOA liegt damit auf dem fachlichen Zuschnitt der Anwendungskomponenten und der Schnittstellen, die den Zugriff auf die Anwendungskomponente ermöglichen. Eine wichtige Eigenschaft von SOA ist die Fähigkeit, Heterogenität und kontinuierlichen Wandel gezielt zu adressieren. Obwohl aus vielen Gründen sehr wünschenswert, ist die technische Standardisierung der Schnittstellen keine notwendige Voraussetzung für den Erfolg einer SOA auf Unternehmensebene. So sind beispielsweise Web-Services nur eine von mehreren möglichen Implementierungstechnologien.

Klare Verantwortlichkeiten

Wichtiger als die technische Standardisierung von Schnittstellen ist eine klare Aufgabenzuteilung für die einzelnen logischen Schichten. Die wesentlichen Elemente einer SOA umfassen Basisdienste (zum Beispiel datenzentrische oder funktionale Dienste), Zwischendienste (zum Beispiel Technologiebrücken oder Facaden) und prozessorientierte Dienste (etwa ein Business-Process-Management-System). Die fachliche Konfiguration der Dienste sollte durch die einheitliche Verwendung von Business Rules sowie zentralem Parameter-Management vereinfacht werden. Letztend-lich hat SOA eine saubere Strukturierung der Anwendungslandschaft auf höchster Ebene zum Ziel. Strukturierte Entwicklung ist kein neues Konzept in der Informatik, aber wurde bisher nur auf einzelne Systeme angewandt.

Die IT vieler großer Unternehmen ist heute unter starkem Druck, wirtschaftlich plausible Strategien für den Umgang mit ihren Altsystemen zu finden. Laut Forrester Research wollen allein europäische Banken in den nächsten zehn Jahren 100 Milliarden Euro in die Modernisierung ihrer Anwendungen investieren. Hersteller von Standardanwendungen wie Oracle und SAP werden hier eine führende Rolle spielen. Die konsequente Ausrichtung dieser Hersteller auf SOA wird es Kunden ermöglichen, flexiblere Lösungen umzusetzen, als das in der Vergangenheit mit monolithischen Anwendungspaketen möglich war.

Um zu klären, welche Optionen es für den Anwender gibt, muss zunächst die Frage nach dem Wert des Altsystems gestellt werden, also in welcher Weise es zur Wettbewerbsfähigkeit und Differenzierung des Unternehmens beiträgt. Zum anderen sollte man sich über die Anforderungen an Flexibilität und Agilität bei der zukünftigen Wartung und Weiterentwicklung klar sein. Abhängig von diesen Faktoren ergeben sich unterschiedliche Handlungsalternativen. So kann es Sinn haben, eine an ihr Lebensende kommende Systemplattform, die als zentral für das betriebliche Überleben bewertet wird, durch eine automatische Transformation zu verjüngen. Dieser Ansatz löst allerdings nicht die grundlegenden strukturellen Probleme. Bietet das Altsystem gegenüber einer modernen Standardlösung keine wesentlichen Vorteile, so ist die Migration sicher eine sinnvolle Alternative. Ist hingegen keine Standardlösung verfügbar, die den Anforderungen genügt, kommen eine Neuentwicklung beziehungsweise Reengineering in Frage. Allerdings wird bei der Neuentwicklung oft zu viel angestrebt, was häufig zum Scheitern führt. Im Gegensatz dazu hat ein Reengineering den Vorteil, dass es sich sowohl beim Scope als auch bei den konkreten Funktionen sehr nahe am Altsystem orientiert und aus diesem die fachlich wertvollen Elemente auf das neue System transformiert.

Schrittweise Entwicklung

Umfassende Eigenentwicklungen - insbesondere auf dem Mainframe - erfolgen häufig in mehreren Phasen. Zunächst erhält die vorhande Backend-Funktionalität Service-orientierte Schnittstellen, beispielsweise auf der Basis der Common Object Request Broker Architecture (Corba), durch EJB-Facaden, Queue-Wrapper oder Web-Services. Um das Backend besser warten zu können, folgt im zweiten Schritt seine Entflechtung, bei der die Module hinter den Interfaces optimiert werden. Entstehen dabei lose gekoppelte, unabhängig nutzbare und der Komplexität her beherrschbare Subsysteme, können diese oder Teile von ihnen in Reengineering-Projekten auf neue Plattformen migriert werden. Dabei steht der angestrebte Geschäftsnutzen im Vordergrund und erst in zweiter Sicht eine Optimierung aus IT-Sicht.

Legacy-to-SOA-Transformation

Gleichgültig, ob ein Modernisierungsprojekt auf eine Entflechtung oder Reengineering abzielt, muss sich der Anwender zunächst einen tieferen Einblick in Struktur und Zustand des Systems verschaffen. Dabei helfen Tools für Anwendungsanalyse und Portfolio-Management von Anbietern wie Blue Phoenix, Cast oder HAL KS. Diese Werkzeuge erlauben eine Inventarisierung und automatisieren grundlegende Aufräum- und Entflechtungsarbeiten. Oft zeigt sich dann bei einer genaueren Analyse der Altsysteme, dass nur 20 bis 25 Prozent des alten Codes aus fachlicher Sicht tatsächlich relevant sind. Der Rest sind Infrastruktur-Code oder Pseudo-Fachlogik, die sich nur mit der Verwaltung von Inkonsistenzen beschäftigt, die alte Batch-Architekturen aufweisen.

Der Legacy-to-SOA-Transformationsansatz versucht, die fachlich relevanten Teile des Altsystems so weit wie möglich in das neue System zu übertragen. Fachlich unwichtiger und proprietärer Legacy-Infrastrukturcode sollte hingegen nicht auf eine moderne SOA-Plattform überführt werden, da diese die meisten Infrastrukturfunktionen standardmäßig bereits enthält. Ferner sollte bisherige Pseudo-Fachlogik nicht mehr genutzt werden, da in einer SOA die Anwendungskomponenten in Echtzeit interagieren. Zwar werden Batch-Anwendungen auch in einer SOA vorkommen, allerdings wesentlich seltener als in der alten Welt und dann in erster Linie aus fachlichen Gründen, beispielsweise für den Jahresabschluss, jährliche Beitragsanpassung oder monatliches Reporting.

Model Driven Architecture

Nachdem die fachlich relevanten Teile des Altsystems identifiziert wurden, stellt sich die Frage, wie diese am effizientesten in eine SOA transformiert werden können. Hierzu bietet sich ein modellgetriebener Ansatz wie die Model Driven Architecture (MDA) an. Sie ist ein geeignetes Werkzeug für die Modernisierung, da sie das automatische Mapping zwischen den Modellebenen unterstützt sowie Modelle auf Technologieplattformen wie beispielsweise GUI-Frameworks, Applikations-Server, Datenbanken und BPM-Engines abbilden kann. Dieses ist insbesondere wichtig, da sich so die semantische Interpretation der fachlichen Modellelemente in der SOA optimal steuern lässt. "MDA Architecture Blueprints" geben außerdem dem Entwickler genauere Vorgaben, schaffen Orientierungspunkte für Projekt-Manager und erhöhen das gemeinsame Verständnis aller Projektparteien.

Legacy-to-POA-Transformation

Die Process-Oriented Architecture (POA) ist die letzte Ausbaustufe einer SOA. In einer POA werden Prozesse explizit modelliert. Sie werden damit besser kontrollier- und steuerbar. Dieser Ansatz erfordert eine frühe Einbindung der Fachabteilungen, um Modelle der vom Altsystem unterstützten Prozesse zu erhalten. Allerdings darf das Modernisierungsprojekt nicht zu weit gefasst sein. Besser ist es, zunächst die SOA-Transformation möglichst nahe am Originalsystem vorzunehmen und dann in weiteren Phasen die Vorteile von SOA/POA auszunutzen. Ist der erste Schritt getan, können die Geschäftsprozesse nachfolgend iterativ optimiert beziehungsweise neue Prozesse inkrementell hinzugefügt werden.

In der Regel braucht die Legacy-to-POA-Transformation einen höheren Abstraktionsgrad, als ihn die Unified Modeling Language (UML) bietet, die sich nicht für technisch wenig versierte Fachvertreter eignet. Diese bevorzugen vielmehr Prozessmodellierungswerkzeuge wie "Aris" oder "Adonis". Selbst Modelle, die mit Microsofts "Visio" erstellt wurden, können brauchbar sein. Der Bruch zwischen der technischen und der fachlichen Welt manifestiert sich zudem nicht nur in den unterschiedlichen Notationen, sondern häufig auch in der Perspektive. UML-Anwendungsmodelle beziehen sich meistens auf konkrete Systeme, während reine Prozessmodelle oft keine Annahme über zugrunde liegende Systeme machen. Der Legacy-to-POA-Ansatz sollte diesen Bruch zum Beispiel wie folgt adressieren:

• Für die Modellierung auf hoher Abstraktionsebene, mit Ereignis-Prozessketten mit Aris;

• das automatische Mapping auf technische Modellebene mit UML;

• die Aufarbeitung der resultierenden Modelle durch technische Fachexperten;

• die Auslegung verschiedener Modellsegmente auf die unterschiedlichen Schichten der SOA: GUI, BPMS, Rules Engine, Basisdienste etc.

Flexibel in die Zukunft

Dieses Vorgehen stellt sicher, dass von Nichttechnikern erstellte Prozessmodelle sauber auf die entsprechenden SOA-Schichten abgebildet werden.

Welche Optionen für den Umgang mit Altsystemen die richtige ist, hängt von zahlreichen Faktoren ab. In Zukunft wird man daher in Unternehmen wohl häufig Kombinationen dieser Ansätze sehen. Die Verfügbarkeit von Composite Application Frameworks wie "Oracle Fusion" oder "SAP Netweaver" ermöglicht hier innovative Ansätze. Beispielsweise kann ein Unternehmen entscheiden, diejenigen Teilsys- teme durch Standardsoftware zu ersetzen, mit denen es sich gegenüber dem Wettbewerb nicht differenzieren kann, während strategische Teilsysteme mittels Legacy-to-SOA auf die neue Zielplattform migriert werden. (as)