CC-REPRINT. Integration statt Migration. Warum es besser ist, alte IT-Systeme so zu lassen, wie sie sind. Harry M. Sneed CC GmbH, Wiesbaden

Transkript

1 CC-REPRINT Integration statt Migration Warum es besser ist, alte IT-Systeme so zu lassen, wie sie sind Harry M. Sneed CC GmbH, Wiesbaden Published in: HMD 225, Praxis der Wirtschaftsinformatik,

2 Copyright No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the written permission of CC GmbH. Information in this document is subject to change without notice and does not represent a commitment on the part of CC GmbH. This document and the referenced software described in this document is furnished under a license agreement or nondisclosure agreement. The document and the referenced software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the document or the software on any medium except as specifically allowed in the license or nondisclosure agreement. Copyright 2002 CC GmbH. All rights reserved

3 Harry M. Sneed CC GmbH, Wiesbaden 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/l- 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. rü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 orm, z. B. eine modernere Sprache, hinüberzuretten. Ein Alternativansatz war das "Reverse Engineering". Demnach wurden die Inhalte der alten Systeme, sprich Geschäftsregel, Ablauflogik, Datenstrukturen und Datenverwendung, wiedergewonnen, aufbereitet bzw. nachdokumentiert und als Basis für eine Reimplementierung verwendet. In beiden ällen sollte die neue Software bei gleich bleibender unktionalitä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. ür sie ist er sogar lesbarer. Somit ist das Argument für höhere Qualität kaum ein Grund zur Migration der Software. Reprint aus HMD 225, Praxis der Wirtschaftsinformatik, Seite 1

4 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: a) Wenn es für diese Technologie kein Wartungspersonal mehr gibt, z. B. wenn der letzte Assembler-Programmierer in Pension geht. b) Wenn die Hardware bzw. Basissoftware der Anwendung nicht mehr gewartet wird, z.b. wenn der Betreuer einer proprietären Entwicklungsumgebung aufgibt. c) 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/l-, C- und COBOL-Programme zugänglich gemacht werden. Ihre Informationen bzw. unktionen werden weiterhin verwendet. Der Endanwender oder die Clientanwendung bekommt sie allerdings in einer anderen orm serviert, eine orm, 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 ab- Reprint aus HMD 225, Praxis der Wirtschaftsinformatik, Seite 2

5 geholt, konvertiert und in ein neues XML-Dokument samt Etiketten eingefügt, das anschließend an den Client als Rückgabenachricht zurückgeleitet wird. ü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 MO 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 achwerkhä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. Reprint aus HMD 225, Praxis der Wirtschaftsinformatik, Seite 3