Die Aufgaben der IT-Verantwortlichen sind klar abgesteckt: Es sind nicht weniger als sämtliche DV-Systeme auf das Problem 2000 hin zu überprüfen und gegebenenfalls zu modifizieren. Also Mainframes, verteilte PC- und Unix-Systeme, Tools und Anwendungen für Endbenutzer ebenso wie anwenderspezifische Programme und vom Anwender geschriebene Makros oder Software, Datenaustauch mit Geschäftspartnern, Behörden etc.

Außerdem wäre da noch Gebäude-Infrastruktur wie Zutrittskontrolle, Belüftungstechnik, Feuermeldesysteme oder Aufzüge - um nur einiges zu nennen. Diese Beispiele gehören zwar eigentlich in die Zuständigkeit anderer Abteilungen, aber wer sonst als die DV-Spezialisten soll die dortigen Mitarbeiter auf ein Problem aufmerksam machen, das aus Computern resultiert?

Für all diese Gebiete wird der erste Schritt darin bestehen, eine Inventur für jedes System oder Werkzeug vorzunehmen, das datumsbasierte DV verwendet. Dabei ist einzuschätzen, wie geschäftskritisch jeder erfaßte Gegenstand ist. Wäre der Betrieb des Unternehmens ernsthaft beeinträchtigt, wenn ein System oder Werkzeug nicht korrekt funktionieren würde?

Diese Frage ist sehr wichtig für Unternehmen, die gerade beginnen, sich mit dem Problem zu befassen. Die Umstellung der Systeme auf ihre Jahr-2000-Tauglichkeit sollte bis Ende 1998 abgeschlossen sein, um wenigstens ein Jahr für den Testbetrieb zu haben, bevor es ernst wird. Innerhalb der noch verbleibenden 14 Monate wird eine komplette und gründliche Bewertung aller fraglichen Programme und Geräte für größere Unternehmen nicht mehr möglich sein. Daher sind bereits jetzt Prioritäten zu setzen.

Es gibt drei Optionen, an das Problem 2000 heranzugehen: Nichts tun, Re-Engineering oder Umstellen. Die erste Möglichkeit ist, auch wenn viele Unternehmen darauf setzen, viel zu riskant. Einige Unternehmen bewältigen das Jahr-2000-Problem durch Re-Engineering (Option 2), also eine komplette Neuentwicklung der Systeme. Das bedeutet oftmals, bestehende "Legacy Systems" ganz oder teilweise durch Standardsoftware zu ersetzen. Dies kann eine Option für kleinere Unternehmen und für solche mit begrenzter Abhängigkeit von IT-basierten Systemen sein.

Normalerweise aber ist für ein größeres Unternehmen das Risiko zu groß, mit Spezifizierung, Erstellung, Customizing, Integra- tion, Test etc. neuer Systeme nicht rechtzeitig fertig zu werden. Für viele Unternehmen und besonders für solche, die ihre eigene Software seit Jahrzenhten entwickelt haben, besteht der gangbarste und risikoärmste Weg darin, ihre Systeme auf Jahr-2000-Tauglichkeit umzustellen.

25 Jahre alte Programme sind eine Herausforderung

Entsprechend geht es hier um die Umstellung gewachsener Systeme, in diesem Fall um die in einer Mainframe-orientierten DV-Landschaft. Die vorgestellten Erfahrungen und Beobachtungen beziehen sich auf ein Jahr-2000-Projekt in der Finanzindustrie. Die Großrechner laufen unter MVS, unter anderem mit CICS, IMS und DB2. Etwa 70 Prozent der Software ist mit Cobol geschrieben, aber es gibt auch 14 andere Sprachen, viele davon 4GLs wie SAS, Mantis oder Easytrieve.

Das zu konvertierende Portfolio besteht aus etwa 40 Anwendungssystemen, viele davon geschäftskritisch. Einige Programme sind bis zu 25 Jahre alt. Die Legacy-Systeme wurden an verschiedenen Stufen ihrer Entwicklung gewartet und modifiziert, etliche dabei bis zur Unkenntlichkeit verändert.

Schon vor einer Änderung von Programmcodes fielen unserem Projektteam mehrere wesentliche Punkte auf: Es gibt sehr wenig aktuelle Dokumentation zu den Systemen, insbesondere zur JCL. Naturgemäß sind ältere Systeme in dieser Beziehung schlimmer, und einige Tätigkeiten können unerwartet zeitraubend sein. Eine der unangenehmen Überraschungen bot die Definition der Parameterkarten für die JCL, sofern diese nicht schon in einer Test- oder Entwicklungsumgebung existierte.

Des weiteren war es nicht möglich, auf Testskripts für Regres- sionstests des Systems zurückzugreifen. Es existierte kein Testbereich, in dem alle Systeme mit synchronisierten Testdaten konfiguriert waren. Es gab nur noch wenige, in manchen Fällen gar keine Personen mehr im Unternehmen, die detaillierte Kenntnisse einzelner Anwendungssysteme besaßen.

Eine oft vorhandene Schwierigkeit ist die fehlende Unterstützung durch das Management. Zum Glück für uns engagieren sich alle Ebenen des Managements in hohem Maße, und einer der Direktoren sponsort das Projekt. Dadurch waren wir in der Lage, alle Konflikte konstruktiv zu lösen, und konnten uns auf unsere Projektziele konzentrieren.

Es gibt viele Prozeßmodelle und Methoden für ein Jahr-2000-Projekt. Sie ähneln sich ziemlich in dem, was sie für die Arbeitsabschnitte Werkzeugauswahl, Inventur, Auswirkungsabschätzung, Renovierung, Tests und Implementierung für erforderlich halten.

Die meisten dieser Methoden erfordern recht lange Phasen für Inventur und Auswirkungsabschätzung und setzen voraus, daß ausreichend Zeit zur Verfügung steht. Es ist nicht effektiv, viel Zeit dafür aufzuwenden, bevor das erste System tatsächlich in Angriff genommen wird. Wir sind daher pragmatischer vorgegangen.

Nach einer Eingangsstudie haben wir darauf geachtet, sicherzustellen, daß alle Systemkomponenten - zum Beispiel Source- code, Copybooks, JCL etc. - mit einem einzigen Konfigurations-Management-System verwaltet werden. In unserem Fall sind jetzt etwa 90 Prozent aller Komponenten unter einheitlicher Kontrolle.

Das hat eine Reihe von Vorteilen: Es reduziert den Aufwand, festzustellen, welche Komponenten zu einem bestimmten System gehören. Daß dieses Konfigurations-Management-System von Anfang an nutzbar ist, führt im weiteren Verfahren zu deutlich weniger Konflikten zwischen unterschiedlichen Systemversionen. Die Umstellungen können früher beginnen.

Wir haben uns dafür entschieden, Jahr-2000-taugliche Systeme kontinuierlich in die Arbeitsumgebung zu überführen, um die Nachteile eines "Big Bang" zu vermeiden.

Der allgemeine Ansatz ist iterativ: Der gleiche Umstellungsprozeß wird für jedes System wiederholt. Die Systeme sind in logischen Clustern angeordnet. Diese Gruppierungen basieren auf Abhängigkeiten zwischen den Systemen und dienen dazu, die Umstellungs- und Testzeiten sowie die Zahl der Daten-Bridges zu verringern.

Schon in der Planung ist es wichtig, die unterschiedlichen Entwicklungs- und Testumgebungen und das Übergabeverfahren zu berücksichtigen. Wir verwenden Entwicklungslinien (sogenannte "Development Streams"), bestehend aus einer Anzahl von Umgebungen innerhalb einer hierarchischen Struktur:

-für die Entwicklung, wo Codeänderungen und Einzeltests stattfinden,

-für Systemtests, in denen das umgestellte System mit in Bezug stehenden getestet wird,

-für Benutzertests, wo Tests auf Benutzerebene stattfinden,

-für Akzeptanztests, in denen vor der Implementierung in der Arbeitsumgebung die Benutzertests in einer simulierten Arbeitsumgebung wiederholt werden sowie

-für die Freigabe.

Neben der Umstellung gibt es auch noch andere Entwicklungsprojekte. Auch sie laufen am Ende auf einen Akzeptanztest und eine Freigabe für die Verwendung hinaus. Dies ist uns möglich, weil alle Streams und ihre einzelnen Teilabschnitte unter Kontrolle eines Konfigurations-Management-Systems stehen. Ohne ein solches Werkzeug würden wir eine Vielzahl von Systemausfällen aufgrund unterschiedlicher Versionen eines Programms oder unverträglicher Konfigurationen erleben.

Da bei der Vielzahl von Systemumgebungen verschiedene Programmversionen vorkommen können, läßt sich nicht voraussagen, ob nach dem Ende einer Umstellung und eines Einzeltests ein Übergang zur nächsten Ebene unmittelbar möglich ist. Falls in der Zielumgebung ein anderes Release vorliegt, kann eine Übergabe an diese Umgebung nicht stattfinden.

Da die Codeumstellung schneller erledigt ist als die Tests, ist es wahrscheinlich, daß eine Schlange von umgestellten Systemen entsteht, die auf den nächsten Testschritt warten. Dieses Problem läßt sich reduzieren, indem man schon in der Entwicklungsumgebung Tests auf Anwenderebene (meistens geht es um Batch-programme) durchführt. Im übrigen hilft dieser Ansatz, die Qualität des umgestellten Systems und die Benutzerakzeptanz zu erhöhen.

Während der Planung haben wir festgelegt, daß etwa zwei bis vier Releases modifizierter Systeme pro Monat für den Akzeptanztest und die Einführung zur Verfügung stehen sollten. Dies muß parallel zur Einführung weiterer Systeme aus anderen Projekten stattfinden und ist eine Herausforderung an die für Akzeptanztests und Betriebsunterstützung zuständigen Teams. Wir schieben daher manchmal die Freigabe eines umgestellten Systems für den Betrieb hinaus, um es parallel mit einem in Bezug stehenden System einzuführen.

In einem Jahr-2000-Projekt macht die unmittelbare Umstellung rund 30 Prozent des Gesamtaufwands aus. Etwa 50 bis 60 Prozent sind für Tests notwendig und zehn bis 20 Prozent für Projekt-Management und Koordinierung. Normalerweise beruhen Schätzungen des Aufwands auf der Anzahl der Programmzeilen. Solch ein Rechenverfahren zieht jedoch nicht die unterschiedlichen Programmiersprachen und die damit verbundene verfügbare Unterstützung durch Tools in Betracht.

Die Konversion von Cobol- und CICS-Code läßt sich beispielsweise weitgehend automatisieren, da für diese Programmiersprachen eine große Anzahl von Werkzeugen verfügbar ist. In anderen Sprachen (wie SAS oder Easytrieve) programmierte Subsysteme erfordern einen höheren Umstellungsaufwand, denn für sie gibt es nur wenige erprobte Werkzeuge. Wir sind noch immer dabei, verläßliche Schätzmethoden für den Aufwand mit diesen Sprachen zu entwickeln.

Lines of Code sind auch keine gute Basis zur Abschätzung des Prüfaufwands, weil die Zahl der erforderlichen Testfälle unter Umständen in keinem Verhältnis zur Anzahl der Programmzeilen in einem System steht. Eine nach Zeilen kleine Anwendung kann überraschend viele Funktionen oder Parameter enthalten, die die Untersuchung komplizieren.

Ein weiterer Gesichtspunkt ist, daß sich die Arbeitsdauer einiger Aktivitäten durch verstärkte Zuordnung von Ressourcen nicht immer verringern läßt. Das ist beispielsweise der Fall bei Batch-Programmen, die auf tägliche Aktualisierung von Daten angewiesen sind und in einer bestimmten Reihenfolge zu laufen haben, nicht immer möglich - jedenfalls nicht, wenn man ihr Verhalten in einem bestimmten Szenario analysieren muß. Die Lage wird noch komplizierter durch Wechselwirkungen zwischen den Systemen: Um das System C zu testen, sind Jobs in System A und dann in System B abzuarbeiten, um die richtigen Startparameter und Daten zu erhalten.

In einigen Fällen haben wir die Schnittstellen zu anderen Systemen erst entdeckt, nachdem die Benutzertests begonnen hatten. Die Fertigstellung mußte prompt hinausgeschoben werden, bis die anderen Systeme und deren Daten richtig eingestellt waren.

Teil 1 der Praxisserie

Es gibt kaum neutrale Reports aus der Praxis von Jahr-2000-Projekten. Hier ist der erste Teil des bislang umfangreichsten Berichts über Erfahrungen und Beobachtungen, der hierzulande erschienen ist, verfaßt von einem Projektleiter. Es geht dabei vor allem um Probleme und Lösungsverfahren bei der Umstellung von Mainframe-Systemen. Viele der hier vorgestellten Erfahrungen lassen sich jedoch auf die Umstellung von verteilten Client-Server-Systemen übertragen.

Der erste Teil des Praxisberichts befaßt sich primär mit der Projektvorbereitung und -konzeption. In den folgenden Ausgaben stehen die weiteren Schritte der Umstellung, eine Einschätzung der Möglichkeiten zur Automatisierung von Teilarbeiten und das oftmals unterschätzte Problem geringer personeller Ressourcen im Vordergrund.

*Rahoul Bhasin, München und London, ist bei der Deutsche Perot Systems GmbH, Frankfurt, angestelltund hat bisher verschiedene Projekte in Deutschland und im europäischen Ausland geleitet. Kontakt: Web-Site: http://www.perotsystems.com oder E-Mail an rahoul.bhasin ps.net