Die größte Herausforderung der Informationstechnologie besteht in der Integration der vorhandenen Anwendungssysteme. Einige dieser Systeme sind in den letzten Jahren mit neuen Technologien wie C++, Enterprise Javabeans und Corba entwickelt worden, viele entstanden mit so genannten alten Techniken wie C, Cobol und Cics, während andere wiederum als Standardprodukte gekauft wurden. Sie alle benutzen unterschiedliche Datenhaltungs- und Datenkommunikationsmittel, unterschiedliche Sprachen - und sie binden Personal mit unterschiedlichsten Kenntnissen und Fähigkeiten.
Das wäre an sich nicht so schlimm, wenn die heterogenen Systeme zusammenwirken würden. Denn von außen wird die betriebliche IT als Ganzes betrachtet beziehungsweise als allumfassendes Informationssystem. Die diversen Anwendungen müssen Informationen nahtlos austauschen können, zwischen dem Output unterschiedlicher Systeme dürfen keine Widersprüche auftreten. Es soll auch möglich sein, alle Anwendungen von der gleichen Oberfläche aus zu erreichen: End-to-End-Integration heißt das Schlagwort.
Die AlternativenIn der Vergangenheit wurde allzu oft versucht, das Ganzheitsprinzip über die Vereinheitlichung der Anwendungssysteme zu verwirklichen. Statt sie so zu lassen, wie sie sind, waren Anwender bemüht, die Systeme entweder alle in einer Technologie neu zu entwickeln oder sie in eine Technologie zu integrieren.
Im ersten Fall gab es wiederum zwei Möglichkeiten: mit einem komplett neuen Geschäftsmodell von vorne anzufangen, oder das bestehende System nachzudokumentieren und ein neues auf der Basis des alten Geschäftsmodells zu entwickeln.
Auch der zweite Fall bot zwei Alternativen: ein "Reverse Engineering" und Reimplementieren der alten Programme, oder die bestehenden Programme einfach eins zu eins in die neue Technologie zu konvertieren. Für die erste Alternative wird ein Repository als Umsetzer, für die zweite ein Transformationswerkzeug benötigt.
Beide Ansätze zur Vereinheitlichung der betrieblichen Informationssysteme, die Neuentwicklung wie auch die Migration, bergen Gefahren in sich. Bei der Neuentwicklung sind die Kosten nicht überschaubar und die Ergebnisse nicht sicher. Vor allem gibt es das Stigma des zweiten Systems: Anwender erwarten, dass das neue System Gleiches und mehr leistet wie das alte. Fehlt etwas, wird dies sofort bemerkt und reklamiert. Bei einer Neuentwicklung tut man sich jedoch äußerst schwer, das Alte wieder zu 100 Prozent abzubilden. Hinzu kommt die Schwierigkeit, die neue Technologie einzuführen und die alten Entwickler umzuschulen, während sie noch die alten Systeme betreuen - ein fast hoffnungsloses Unterfangen. Es sollte daher niemanden wundern, dass laut "Standish Report" zwei Drittel der Neuentwicklungen von Ablösesystemen scheitern.
Beim Migrationsansatz ist die Gefahr gegeben, dass das neue System nur eine schlechte Kopie des alten darstellt. Nach dem Prinzip vom alten Wein in neuen Schläuchen wird der Inhalt der Altsoftware in eine neue Form gebracht, die in der Regel gar nicht zum Inhalt passt. Die Syntax der Programme ist vielleicht Java, aber die Semantik noch Cobol. Weder der Cobol- noch der Java-Programmierer sind darüber besonders glücklich und der Benutzer am allerwenigsten. Denn er sieht nur die alte Funktionalität in einem neuen, fremden Rahmen, der alles viel umständlicher macht.
Problem der Wartung bleibtMigrationen sind zwar billiger und weniger riskant, aber die Ergebnisse sind auch dementsprechend mager. Rund 75 Prozent gelingen, am Ende ist jedoch keiner so recht zufrieden. Die Umschulungsproblematik bleibt. Das Märchen von der besseren Wartbarkeit moderner Sprachen ist nie bewiesen worden. Bisherige Studien belegen dem "Journal of Software Maintenance" zufolge, dass objektorientierte Systeme noch mehr Wartungsaufwände verursachen als die bisherigen.
In Anbetracht der offensichtlichen Kosten und Risiken einer Neuentwicklung sowie des marginalen Nutzens einer rein technischen Migration haben es viele Anwender vorgezogen, neue Systeme zu kaufen. Statt die IT der Organisation anzupassen, wird die Organisation der von außen vorgegebenen neuen IT angepasst. Gerade daraus ergeben sich nicht wenige neue Probleme. Anwender trennen sich nur ungern von liebgewonnenen Funktionen, die gekauften Produkte decken jedoch nur einen Teil der bisherigen Funktionalität ab. Hinzu kommt, dass sie nicht zu den anderen, eigenen Anwendungssystemen passen. Das Resultat ist auch eine große Abhängigkeit, aus der man sich nicht so leicht wieder lösen kann.
Es gibt im Grunde genommen nur zwei echte Zwänge zur Ablösung einer existierenden Anwendung:
- der Entzug der technischen Umgebung, wenn also die Hardware oder Software, auf der die Anwendung basiert, nicht mehr unterstützt werden, oder
- der Mangel an Personal mit Kenntnissen der Legacy-Technologie, wenn etwa der letzte Assembler- oder Cobol-Programmierer in Pension geht.
Die billigste und risikoärmste Lösung, auch die mit der geringsten sozialen Härte, ist aber, prinzipiell alles so zu belassen, wie es ist. Das gilt für Cobol- und PL/I-Programme, für VSAM-Dateien oder IMS-Datenbanken. Die Erhaltung des Status quo wird zum Ziel der betrieblichen IT, denn nur so kann man allen neuen Problemen aus dem Weg gehen.
Der KompromissDoch was geschieht dann mit den Forderungen mancher Endanwender nach modernen Oberflächen oder nach eigenen individuellen Lösungen? Was ist mit der Notwendigkeit, die bestehenden Systeme an das Internet anzuschließen oder mit neuen Systemen zu koppeln? Was passiert mit den aktuellen Anforderungen, die sich meist nur innerhalb neuer Architekturen erfüllen lassen?
Die Lösung liegt in einem Kompromiss zwischen Vergangenheit und Zukunft. Die alten Programme und ihre Daten werden in einer Art wiederverwendet, für die sie ursprünglich nicht gedacht waren. Sie werden gekapselt und in eine neue Gesamtarchitektur eingebunden. Dabei bleiben sie weitgehend in ihrer alten Form, nur die Schnittstellen nach außen werden verändert. Wichtig ist, dass die Entwickler nicht umlernen müssen. Jüngere Programmierer, die neue Satellitenanwendungen entwickeln, können die Funktionalität und Daten der alten Kernanwendungen wiederverwenden.
Normierte DatenbeschreibungDer Schlüssel zu diesem Kompromiss lautet Extensible Markup Language (XML). Die Sprache verspricht das uralte Bedürfnis nach einer normierten Datenbeschreibung zu erfüllen. Mit XML kann ein Java-Client Nachrichten an einen Cobol- oder gar Assembler-Server senden. Statt einer Maske oder einer Datei liest das Server-Programm das XML-Dokument. Die Struktur des Dokuments ist in einer begleitenden Dokumententypdefinition oder in einem getrennt abgelegten Schema vorgegeben. Über das Schema lassen sich der Typ und die Position einzelner Felder spezifizieren. Manche XML-Prozessoren benutzen lokale Datenstrukturen wie PL/I-Includes oder Cobol-Copys, um das Schema zu generieren.
Inzwischen gibt es genügend Prozeduren auf dem Markt, um das Schreiben und Lesen von XML-Dokumenten zu unterstützen. SAX, DOC, Java-Eb, XML 4J, Cobol, XML 4PLI und XML Wrap stehen stellvertretend für viele andere. Das Problem des XML-Parsing und der XML-Generierung ist gelöst, ebenso das der Dokumentenübergabe etwa in Form eines Soap-Umschlags oder als Message in einem Message-Queuing-System. Übrig bleibt die Anpassung der bestehenden Programme, aber auch dafür gibt es Tools.
Mit solchen Werkzeugen wird der Code des Zielprogramms geringfügig geändert, um den XML-Prozessor aufzurufen. Dieser liefert anschließend den Inhalt des XML-Dokuments als Maske, Satz oder Parameterliste. Am Ende einer Transaktion beziehungsweise zum Schluss eines Verarbeitungszyklus wird aus der Ausgabemaske, dem Satz oder der Parameterliste ein neues XML-Dokument erzeugt, das als Antwort an den Auftraggeber zurückgeht.
Können die Programme untereinander über XML kommunizieren, sind die Voraussetzungen für Enterprise Application Integration endlich gegeben. Die Anwendungssysteme sind nur noch Knoten im Netz einer gesamtbetrieblichen IT. Selbst große monolithische Anwendungen lassen sich in mehrere Teilanwendungen als kollaborierende Komponenten zerlegen, die über Unternehmensportale Aufträge auch mit neuen Anwendungen erteilen und erfüllen.
Große Reengineering-Projekte sind dann ein Relikt der Vergangenheit. Reengineering beschränkt sich auf die Restrukturierung beziehungsweise Refakturierung einzelner Module (Klassen). Es besteht weder ein Bedarf an einer Massentransformation, noch die Notwendigkeit, ganze Systeme auf einmal abzulösen. Die Epoche der Migration geht zu Ende, die der Integration beginnt. (ue)
*Harry Sneed ist der internationalen IT-Branche als Pionier im Bereich Reengineering von Softwaresystemen bekannt. Seit Anfang 2000 arbeitet er als Chief Technology Scientist bei der Case Consult GmbH (CC) in Wiesbaden.
Abb: Kapselung
XML-Prozessoren benutzen lokale Datenstrukturen wie PL/I-Includes oder Cobol-Copys, um das Schema zu generieren. Quelle: CC GmbH