ISSN 1436-3011

02.09.2010

Enterprise-Portale & Enterprise Application Integration
Einwurf

Integration statt Migration

Warum es besser ist, alte IT-Systeme so zu lassen, wie sie sind

Die IT-Landschaft der meisten großen Anwender ist vollgestopft mit alten Anwendungssystemen - so genannte Legacy-Systeme. Als Legacy-System gelten alle Softwaresysteme, die mit einer früheren Softwaretechnologie als die gegenwärtige implementiert wurden. In Anbetracht der Tatsache, dass die gegenwärtige Technologie die Web-basierte ist mit Java, EJB, XML, WebSphere, Weblogic, One, .Net, mySAP und dergleichen Produkte, ist es so zu verstehen, dass auch die Client/Server-Systeme der 90er Jahre bereits Legacy- Systeme sind, ebenso wie die 4GL-Systeme, die mit Natural, ADS, Synon, Ideal oder APS realisiert wurden, ganz zu schweigen von den alten COBOL-, PL/I- und Assembler-Systemen auf dem Host. So gesehen sind fast alle in der Produktion befindlichen IT-Systeme zugleich Legacy-Systeme. Als solche werden sie ungerechterweise zu den Altlasten eines Unternehmens gezählt.

Früher waren die Anwender bemüht, sich von ihren Altlasten so früh wie möglich zu befreien. Migration war das Stichwort. Hier passt auch der Begriff "Software Reengineering". Die Altsoftware bzw. der Sourcecode wurde zunächst mal saniert und anschließend konvertiert. Als Ziel galt es, den fachlichen Inhalt in eine neuere technische Form, z.B. eine modernere Sprache, hinüberzuretten. Ein Alternativansatz war das "Reverse Engineering". Demnach wurden die Inhalte der alten Systeme, sprich Geschäftregel, Ablauflogik, Datenstrukturen und Datenverwendung, wiedergewonnen, aufbereitet bzw. nachdokumentiert und als Basis für eine Reimplementierung verwendet. In beiden Fällen sollte die neue Software bei gleich bleibender Funktionalität "besser" werden, was immer das heißt, leichter zu warten, weniger fehleranfällig, sicherer, transparenter, portabler usw. Leider konnte bisher niemand eindeutig beweisen, dass diese erhofften Verbesserungen tatsächlich eingetreten sind. Sogar die viel gepriesene Objekttechnik hat sich als ein Tausch alter Probleme gegen neue erwiesen. Inzwischen glaubt kaum jemand mehr an eine echte Qualitätsverbesserung. Aus der Sicht der Assembler-Programmierer ist ihr Assembler-Code genauso hochwertig wie der Java-Code ihres Nachbarn. Für sie ist er sogar lesbarer. Somit ist das Argument für höhere Qualität kaum ein Grund zur Migration der Software.

Ein anderes Argument ist der Einheitlichkeit wegen. Ein Anwendungsbetrieb soll möglichst wenig verschiedene Entwicklungsumgebungen haben, denn jede zusätzliche Umgebung verursacht Kosten und bindet Personal mit speziellen Kenntnissen. Am liebsten soll es nur eine Entwurfsmethodik, eine Programmiersprache, ein Datenbanksystem und eine Entwicklungsumgebung für alle Anwender geben. Inzwischen sind jedoch die meisten Anwenderbetriebe weit entfernt von diesem Ziel. Immer mehr neue Technologien, wie WAP, JSP, BizTalk, WebSphere, mySAP usw., breiten sich aus und sorgen dafür, dass die IT-Landschaften immer heterogener werden, denn die bestehenden Systeme werden noch gebraucht. Es ist insofern sinnlos, nach Einheitlichkeit zu streben. Es gelten die Worte von Mao tse Tung "lasse 1000 Blumen blühen". Es lebe die Vielfalt.

Die einzigen Argumente, um ein funktionierendes System abzulösen, sind jetzt:

1. Wenn es für diese Technologie kein Wartungspersonal mehr gibt, z.B. wenn der letzte Assembler-Programmierer in Pension geht.
2. Wenn die Hardware bzw. Basissoftware der Anwendung nicht mehr gewartet wird, z.B. wenn der Betreuer einer proprietären Entwicklungsumgebung aufgibt.
3. Wenn das Anwendungssystem nicht mehr die Mindestanforderungen der Benutzer erfüllt, z.B. die Performance nicht mehr zumutbar ist.

Wenn einer dieser drei Zustände eintritt, ist es Zeit, das Anwendungssystem abzulösen. Ansonsten gibt es heute andere Möglichkeiten, die bestehenden Systeme mit den neuen Technologien zu koppeln, ohne sie konvertieren oder reimplementieren zu müssen. Das jetzige Zauberwort heißt "Integration".

Mit den Mitteln der Integrationstechnologie werden bestehende Datenbanken, Transaktionen und Programme hinter einer Zugriffsschale gekapselt, die Nachrichten vom Web oder anderen Clientsystemen in Schnittstellen zum Serverobjekt umsetzen. Auf diese Weise können Legacy-Datenbanken, CICS, IMS und UTS-Transaktionen sowie Assembler-, PL/I-, C- und COBOL-Programme zugänglich gemacht werden. Ihre Informationen bzw. Funktionen werden weiterhin verwendet. Der Endanwender oder die Clientanwendung bekommt sie allerdings in einer anderen Form serviert, eine Form, die zur neuen Architektur passt, z.B. als XML-Dokument oder als CORBA-IDL- Schnittstelle. Die bestehenden Serverprogramme bleiben weitestgehend unverändert. Lediglich ihre Schnittstellen müssen angepasst werden - Interface Reengineering. Es ist nicht das Ziel, hier die Software besser zu machen, sondern sie nur wiederzuverwenden.

Eine wichtige Rolle bei derartigen Integrationsprojekten spielt die Sprache XML. Ursprünglich als Markup-Language gedacht, ist XML inzwischen eine universale Datenaustauschsprache geworden. Mittels eines XML-Dokumentes kann ein Java-Client Nachrichten an einen COBOL- oder gar einen Assembler-Server übergeben und Nachrichten wieder zurückbekommen. Die Kapselungsschale bzw. Wrapper parst das Dokument, holt die entsprechenden Eingabedaten heraus, konvertiert sie und überträgt sie in die Schnittstelle des Zielprogramms, die eine Parameterliste, eine Datei oder eine Maske sein könnte. Danach wird das Zielprogramm angestoßen und ausgeführt. Bei der Rückkehr vom Zielprogramm werden die Ausgabedaten abgeholt, konvertiert und in ein neues XML- Dokument samt Etiketten eingefügt, das anschließend an den Client als Rückgabenachricht zurückgeleitet wird. Für die Verarbeitung der Dokumente stehen die Methoden des Document Object Models - DOM - kostenlos zur Verfügung. Als Transportmittel für die Nachrichten werden mittlerweile jede Menge Middleware-Produkte von MQ-Series und bis zum SOAP angeboten. Es gibt inzwischen auch genügend Normen für die Gestaltung der Austauschdokumente, Standards wie cXML, XML/EDI mySAP und BizTalk.

XML mit ihrer erweiterbaren Syntax eignet sich hervorragend für den Datenaustausch entfernter Softwarekomponenten, auch wenn sie in unterschiedlichen Sprachen auf unterschiedlichen Plattformen implementiert sind. Anwenderbetriebe können eigene Untersprachen von XML ableiten und über XMLT transformieren lassen. Dadurch können besondere XML-Dialekte für unterschiedliche Programmarten eingesetzt werden, so z.B. ein Sprachsubset für COBOL und ein anderes Sprachsubset für C. Letztlich können XML-Dokumente als Transitobjekte über CORBA-Schnittstellen überreicht werden. Somit schließen sich IDL und XML nicht aus, sondern ergänzen sich gegenseitig.

Es ist zu erwarten, dass XML sich immer mehr durchsetzen wird, um Unternehmensportale in einer Web-basierten Systemintegration zu schaffen. Damit lässt der Migrationsdruck deutlich nach. Jetzt geht es darum, zu bewahren und zu integrieren. So wie die vielen alten Fachwerkhäuser und andere Baudenkmäler vergangener Architekturepochen die europäischen Städte bereichern, so werden die Legacy-Systeme vergangener Technologieepochen die europäischen IT-Landschaften bereichern. Es entspricht nicht dem europäischen Wesen, Wertgegenstände wegzuwerfen, bloß weil sie nicht mehr auf dem letzten Stand sind. Das ist ein wichtiger Unterschied zu den US-Amerikanern. Man wird sogar stolz sein, solche kostbaren Werke aus der Vergangenheit pflegen zu dürfen. In einer multikulturellen IT-Welt wird jedes Programm und jeder Programmierer einen gebührenden Platz finden. Es lebe die Vielfalt und die durch XML gewonnene Unabhängigkeit der Anwendungen.

Harry M. Sneed
Chief Technology Scientist
CaseConsult GmbH
Flachstr. 13
65197 Wiesbaden
pr@caseconsult.com
www.caseconsult.de

HMD, Heft 225, Juni 2002