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:
Wenn es für diese Technologie kein Wartungspersonal mehr
gibt, z.B. wenn der letzte Assembler-Programmierer in Pension
geht.
Wenn die Hardware bzw. Basissoftware der Anwendung nicht
mehr gewartet wird, z.B. wenn der Betreuer einer proprietären
Entwicklungsumgebung aufgibt.
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.
Einwurf
von Harry M. Sneed
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:
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