Nicht alles läßt sich bei einer Umstellung vorausschauend planen. Die Modifikationsphase bietet eine Vielzahl überraschender Fallen. Es ist wichtig, sich weder Illusionen über die Effizienz von Tools noch einer Verzweiflung über das scheinbar wachsende Ausmaß des Projekts hinzugeben.
Wo es sich anbot, haben wir versucht, Aufgaben mit anderen laufenden IT-Projekten zu kombinieren. Das ist zum Beispiel dann sinnvoll, wenn ein anderes Projekt ohnehin Änderungen an oder Tests von großen Teilen eines bestimmten Systems vornimmt. Das andere Projekt kann dann zumindest in der Vorbereitungsphase kleinere Codeänderungen oder Testcodeänderungen selbst erledigen, notfalls mit Unterstützung von Mitarbeitern aus dem Projektteam. Das reduziert den Gesamtaufwand und macht es unnötig, das System ein zweites Mal für die Umstellung einzufrieren.
Die Puristen unter den Jahr-2000-Experten fordern, alle Datumsfelder zu erweitern. Dadurch gerät jedoch der rechtzeitige Abschluß des Projekts in Gefahr, und der notwendige Aufwand wächst noch mehr.
Unsere Entscheidung über die anzuwendende Umstellungsstrategie ist pragmatischer und lautet: maskieren. Alle Schlüssel und Sortierparameter, die ein Datum enthalten, werden jedoch erweitert. Diese generelle Entscheidung sollte man aber flexibel handhaben, da jedes System unterschiedliche Anforderungen stellt.
Nach der Vorbereitungsphase, in der der Ansatz für die Systemumstellungen definiert wurde (siehe Teil 1 in CW 44/1997 ab Seite 47), hat unser Projektteam eine Pilotphase gestartet, um den gewählten Ansatz zu bewerten. Dies war nützlich, um unvorhergesehene Probleme und gleichzeitig spezielle Stärken zu identifizieren. Das System, das wir für den Pilotversuch ausgewählt haben, war hinsichtlich Architektur, Vielzahl der Programmiersprachen und Codelänge repräsentativ für die zur Umstellung vorgesehenen Programme.
Die Pilotphase lieferte wie erwartet einige für weitere Arbeiten wichtige Erkenntnisse. Die Ergebnisse aus der werkzeuggestützten Auswirkungsanalyse und Code-Umstellung fielen erstens schlechter als erwartet aus. Allerdings waren nicht alle Schwächen ausschließlich auf die Qualität des Werkzeugs zurückzuführen. Zweitens ist der hauptsächliche Engpaß im Umwandlungsprozeß das "Markieren" der möglichen Datumsfelder während der Auswirkungsanalyse und der Tests. Wir entdeckten drittens bislang unbekannte Schnittstellen zwischen dem zu testenden System und anderen Systemen. Und viertens dauerte es länger als gedacht, Dateien und die JCL einzurichten.
Um diesen Defiziten entgegenzuwirken, boten sich zwei Maßnahmen an. Zum einen galt es, kleine Hilfsprogramme zu erstellen, um die auf Werkzeuge basierende Umstellung zu unterstützen und einige der damit verbundenen manuellen Aktivitäten zu automatisieren. Zum anderen waren die Rollen einiger Entwicklungsmitarbeiter neu zu definieren.
Ursprünglich gab es ein Umstellungs- und ein Testteam, letzteres sollte gegebenenfalls besondere Unterstützung bekommen. Dies führte dazu, daß das Testen ineffektiv wurde, weil Dateien oder die JCL nicht richtig eingerichtet waren und der Zeitaufwand, um diese Probleme zu beheben, zu groß war.
Jetzt existiert ein zusätzliches Team für Analyse und Support. Es ist mit Mitarbeitern besetzt, die aus dem Umstellungsteam und anderen Bereichen stammen. Ihre Aufgabe ist es, festzustellen, was für die Einrichtung, die Ausführung und den Test der Systeme vor Beginn des Umstellungsvorgangs notwendig ist. Außerdem werden einmal eingerichtete Systeme kontrolliert, um sicherzugehen, daß sie richtig funktionieren und die Dateien synchronisiert sind.
Bald zeigte sich, daß die Rolle von Umstellungswerkzeugen, auch wenn sie unverzichtbar sind, nicht überschätzt werden sollte. Es lohnt sich nicht, viel Zeit damit zu verschwenden, Tools zu bewerten. Der Markt für Jahr-2000-Werkzeuge ist noch unreif, jeden Tag erscheinen neue Tools auf dem Markt. Eine schlüssige Bewertung hätte wahrscheinlich sechs bis neun Monate wertvoller Zeit gekostet.
Noch wichtiger ist es, das Kosten-Nutzen-Verhältnis zu betrachten. Die reine Code-Umstellung macht erfahrungsgemäß etwa 30 Prozent des gesamten Projektaufwands aus. Die meisten Werkzeuge unterstützen aber vor allem klassische CICS-, Cobol-, IMS- oder DB2-Systeme; nur wenige eignen sich für andere Sprachen wie SAS und Easytrieve. In unserer Umgebung machen erstere etwa 70 Prozent des gesamten Codes aus. Ein Jahr-2000-Tool kann ergo theoretisch den Gesamtaufwand also nur um etwa 20 Prozent reduzieren.
Einsparungen dieser Größenordnung wären angesichts der großen Budgets, die Jahr-2000-Projekte benötigen, eine Menge Geld. Dieser Anteil verringert sich jedoch noch weiter: Im wesentlichen basiert die Fähigkeit des Werkzeugs, falsche Datumsfelder korrekt zu finden und umzustellen, auf der Qualität des Sourcecodes. Der alte Spruch "Garbage in, garbage out" bestätigt sich hier.
Viele Mainframe-Portfolios enthalten in der Regel schlecht geschriebenen Code. Wenn Programmierer bei Datumsfeldern Konventionen für die Benennung nicht eingehalten haben, läßt es sich nur schwer feststellen, ob sie ein Datum enthalten oder nicht. Schlimmer noch: Wir haben Fälle gefunden, in denen Teile von Datumsfeldern in Zeitfelder oder sogar Dezimalfelder bewegt wurden. Derlei beeinträchtigt die Effektivität des Tools erheblich und reduziert die erhofften 20 Prozent Aufwandseinsparung noch weiter.
Wir wählten also ein Tools aus, das die meisten unserer Anforderungen zu erfüllen schien, und verbrachten zwei Monate damit, es in der Pilotphase zu bewerten. Natürlich sind eine Reihe von Schwierigkeiten mit dem Werkzeug aufgetreten; die meisten konnte der Hersteller lösen.
Ein interessantes Problem deckte die Herkunft des Werkzeugs auf: Es zeigte die Neigung, automatisch das amerikanische Datumsformat (MM/TT/JJJJ), anstatt die europäische Nomenklatur TT/MM/JJJJ zu verwenden. Unsere Mitarbeiter entwickelten zusätzlich einige Hilfsprogramme für Bereiche, in denen das Werkzeug nicht den Anforderungen entsprach. Diese Lösung funktioniert sehr gut, und die Konvertierung von Cobol- und CICS-Code ließ sich fast vollständig automatisieren.
Wir verfolgen jedoch einen sehr pragmatischen Ansatz: Wenn das Werkzeug bestimmten Programmcode nicht automatisch umstellen kann, wird keine Zeit darauf verschwendet, mit dem Tool herumzuexperimentieren. Denn es ist effektiver, derartigen Code per Hand umzustellen. Außerdem ist es illusorisch, zu glauben, daß ein Werkzeug 100 Prozent der Aufgabe automatisch erledigt - auch wenn ein Anbieter das immer noch behaupten sollte.
Darüber hinaus sollte man nicht annehmen, daß ein Tool sämtliche Schnittstellen identifizieren wird. Einflüsse von Systemen auf anderen Plattformen oder in anderen Unternehmen, mit denen Datenaustausch erfolgt, kann ein Umstellungswerkzeug keineswegs einfach ermitteln.
Nach unseren Erfahrungen ist es richtig, ein Tool speziell für die Bedürfnisse des Jahr-2000-Projekts und für nichts anderes auszuwählen. Es ist verführerisch, die Investition dadurch zu rechtfertigen, daß das Tool sich auch für andere Projekte, beispielsweise die Euro-Umstellung, nutzen läßt.
Natürlich würde ein Tool dieser Art die allgemeine Aufgabe, Code zu durchsuchen und zu analysieren, erfüllen. Die Hauptarbeit eines Umstellungswerkzeugs liegt jedoch im Markieren der zu konvertierenden Felder, damit die Auswirkungsanalyse und die Code-Umstellung erfolgen kann. Diese weitgehend von Hand vorzunehmende Aufgabe ist sehr stark auf Datumsfelder und datumsverwandte Felder bezogen und wäre für andere Zwecke nicht sinnvoll zu verwenden.
Eine der größten Herausforderungen eines Jahr-2000-Projekts ist es, seinen Umfang zu bewältigen. Das Ausmaß der Wechselwirkungen zwischen den Systemen trat erst zutage, als wir die ersten Systeme umgestellt hatten. Ein Data Dictionary liefert, falls es immer auf dem aktuellen neuesten Stand gehalten wurde, ebenso wie eine Inventurliste einige Informationen. Doch normalerweise ist dies bei Mainframes mit 20 oder 25 Jahren alten Anwendungen nicht der Fall.
Es gibt eine Reihe zu berücksichtigender Wechselwirkungen; nämlich Schnittstellen zu gleichen, verschiedenen und externen Systemen. Das Wissen um diese Schnittstellen ist wichtig, weil bei der Umstellung eines bestimmten Systems Daten-Bridges zu implementieren sind. Diese sind notwendig, damit ein System, das Jahr-2000-taugliche Datumsformate verwendet, nach seiner Einführung in den Betrieb weiter mit Systemen korrekt kommunizieren kann, die noch nicht umgestellt sind.
Außerdem sind derartige Schnittstellen-Systeme erforderlich, um die Tests richtig vorzunehmen. Das schließt auch solche Systeme ein, in denen der Datenaustausch von Hand erfolgt. Je früher dies bekannt ist, desto mehr Zeit läßt sich sparen, weil das Einrichten dieser Systeme nicht immer einfach ist.
Wo Datenaustausch mit externen Systemen stattfindet, ist mit den betroffenen Geschäftspartnern oder Kontrollgremien ein Übereinkommen darüber zu erzielen, in welchem Umfang und Zeitrahmen die Tests stattfinden. Wir beschränken solche Tests jedoch nicht ausschließlich auf datumsbezogene Daten, da eine Rückwirkung in einem umgestellten System schlimmstenfalls zu Fehlfunktionen der Schnittstellen zu den anderen Systemen führen kann. Da einige der betroffenen Geschäftspartner Banken sind, die Zahlungen und andere Transaktionen verarbeiten, hätten Probleme auf diesem Gebiet erhebliche Auswirkungen auf den Geschäftsbetrieb.
Die bisher besprochenen Anwendungen sind nur Teil der IT-Infrastruktur. Außerdem wären noch Betriebssysteme, Sprachen-Compiler, Datenbankprogramme, Leistungsverwaltungs-Tools, Entwicklungswerkzeuge etc. zu berücksichtigen. Während die meisten Anbieter Jahr-2000-taugliche Produkte angekündigt haben, ist der Zeitpunkt, an dem diese Versionen verfügbar sein werden, ein entscheidender Faktor in der Planung des Projekts.
Denn die Implementierung einer neuen Version eines Betriebssystems wie MVS beispielsweise ist kein einfaches Unterfangen, besonders wenn die derzeit laufende Version nicht das letzte Release des Anbieters ist. Für die Installation, die Tests und die Inbetriebnahme der neuen Version ist Zeit einzuplanen.
Es gibt ferner Abhängigkeiten zwischen verschiedenen Produktversionen der Basissoftware, die die Migration zu neuen Versionen verkomplizieren. So ist etwa ein spezielles CICS-Release nur mit einem bestimmten IMS-Release kompatibel.
Diese beiden Faktoren bedeuten, daß eine sorgfältige Koordinierung von größter Wichtigkeit ist. In unserem Projekt haben wir Verbindungen zu anderen Projekten, die für die Migration zu Jahr-2000-tauglichen Versionen von MVS, Cobol, CICS und IMS verantwortlich sind. Dies sind nur einige der Produkte auf der IBM-Mainframe-Plattform, die zu berücksichtigen sind.
Aufgrund des Zeitmangels bis zum Jahr 2000 müssen zahlreiche Migrations- und Umstellungsprojekte parallel erfolgen und zu vereinbarten Zeitpunkten miteinander verknüpft werden. Obwohl wir zum Beispiel im Augenblick mit der Migration unserer Anwendungen für den Einsatz unter der Cobol II Version befaßt sind, werden wir sie anschließend nach Cobol-MVS migrieren, sobald diese Version installiert, getestet und eingeführt ist.
Berechtigt ist die Frage, ob es wirklich wichtig ist, daß die Systemsoftware Jahr-2000-tauglich ist oder nicht, solange es die Anwendungssysteme selbst sind. Weitet man die Vorbereitungen für das Jahr 2000 nicht unnötig aus? Der kritische Punkt ist hier, daß die Gefahr einer Betriebsunterbrechung aufgrund eines Jahr-2000-Problems besteht, solange nichttaugliche Systemsoftware läuft. Sollte dieser Fall eintreten, wäre das betroffene Unternehmen vom juristischen Standpunkt her haftbar oder der Versicherungsschutz eingeschränkt.
Auch wenn ein Jahr-2000-Projekt viel Zeit und Arbeit verlangt, haben wir festgestellt, daß es möglich ist, diesen Aufwand zu verringern. So ist es effezienzsteigernd, vor der Code-Umstellung jedes System auf redundan- te Jobs und Programme zu untersuchen, die nicht mehr verwendet werden. Kandidaten hierfür sind insbesondere 4GL-Programme zur Erstellung von Berichten.
Wir haben Subsysteme entdeckt, in denen mehr als 80 Prozent des Codes nicht mehr verwendet wurden. Diese werden jedoch nicht vor Ende 1998 physikalisch vom System entfernt, sondern solange mit einem Verfahren archiviert, das eine rasche Wiederherstellung erlaubt, falls sie wider Erwarten dringend benötigt werden. Entscheidene Zeitgewinne entstehen, weil solche Programme zunächst weder umzustellen noch zu testen sind.
In unserem Projekt hat gute Vorbereitung viel Zeit eingespart: Sollten beispielsweise die Umstellung oder die Tests nicht termingerecht beginnen, kann jeder verlorene Tag zehn oder 20 Manntage kosten. In einer kritischen Situa- tion lassen sich nicht einfach plötzlich alle Anstrengungen auf ein anderes System verlagern, weil es sein kann, daß ein anderes Projekt gerade daran arbeitet.
Es gibt einige Gebiete, die frühzeitige Vorbereitungen erfordern:
-Umstellungsumgebungen, beispielsweise CICS-Regionen und Datenbanken, sind richtig und vollständig einzurichten.
-Die JCL ist mit korrekten Parametern und synchronisierten Dateien für jedes umzustellende Einzelsystem einzurichten und zu testen. Sollte das nicht erfolgen, wird es unmöglich sein, anspruchsvolle Qualitätstests für die Module oder das System durchzuführen.
-Die Teammitglieder müssen angemessene Zugriffsrechte für das System haben, wie es ihre Aufgabe erfordert. Obwohl das selbstverständlich klingt, haben wir festgestellt, daß zum Teil ein verändertes System von Zugriffsrechten erforderlich ist. Unser Jahr-2000-Projekt bewegt sich an der Grenze zwischen einem klassischen Entwicklungsprojekt und dem Support im laufenden Betrieb, weil wir auch die Überführung in die tägliche Anwendung betreuen.
-Es muß ausreichend Plattenspeicher (in unserem Fall DASD) zur Verfügung stehen. Wir hatten den Bedarf hauptsächlich aufgrund mangelhafter Kenntnisse über die Architektur der Anwendungen unterschätzt. Abgesehen davon ist es effektiver, ausreichend Massenspeicher - rechtzeitig - zu kaufen, um Kopien der Arbeitsdaten halten zu können. Denn das Einrichten und Synchronisieren von Subsets der Arbeitsdaten zu Testzwecken ist eine sehr zeitraubende Arbeit.
-Angemessene Rechenkapazität muß vorhanden sein. In unserer Situation nimmt das Compilieren und Testen, verglichen mit herkömmlichen Entwicklungsprojekten, eine andere Größenordnung an. So war es notwendig, sehr große Jobs zu planen, um andere Entwicklungsprojekte nicht zu beeinträchtigen.
-Realitätsnahe Tests verlangen eine gewisse separate Umgebung. Sie lassen sich nicht immer auf der Maschine im laufenden Betrieb vornehmen, da sie unter einem anderen Systemdatum laufen. Es gibt hierfür Test-Tools.
Forderungen der Puristen gefährden Projekte
*Rahoul Bhasin, München und London, ist bei der Deutsche Perot Systems GmbH, Frankfurt, angestellt und hat bisher verschiedene Projekte in Deutschland und im europäischen Ausland geleitet. Kontakt per Web-Site http://www.perotsystems.com oder E-Mail an rahoul.bhasinqps.net.