Die verschiedenen Change-control- und Quellbibliotheks-Programme sind bei der Markierung von Software, die zu modifizieren ist, womöglich nützlich. Allerdings können etliche von ihnen Codekonflikte nicht identifizieren und somit bei der Versionsabstimmung nicht behilflich sein.

Viele der Jahr-2000-Serviceanbieter, unter anderem Cap Gemini, Computer Horizons, Coopers & Lybrand, HCL James Martin und KPMG Peat Marwick, haben auf diesen Bedarf bereits reagiert. Entsprechend sind Werzeuge zur Versionsabstimmung (siehe Kasten) Teil ihrer jeweiligen Methoden der Umstellung von zwei- auf vierstellige Jahreszahlen.

Theoretisch sollte keine Anpassung notwendig sein, jedoch sind in der Praxis Fremdanwendungen fast immer kundenspezifisch modifiziert. Obwohl die Softwarelieferanten in der Regel bereinigte Programme auf den Markt bringen, müssen die Anwender, um eine umgebungsgerechte Neuversion zu erhalten, ihre spezifischen Änderungen auf die Modifikationen des Anbieters abstimmen. Und das kann sehr zeitaufwendig sein.

Vor der Aktualisierung Zwischen-Releases

Dieses Problem nimmt noch größere Ausmaße an, sollten die Anwender nicht die jeweils neuesten Versionen der Anbieter erworben und bereits installiert haben. In einigen Fällen werden sie nicht umhinkommen, vor der Aktualisierung Zwischen-Releases zu installieren.

Viele Großrechnerkunden ziehen neue Client-Server-Lösungen als Alternative zur Aktualisierung einer Fremdanwendung in Betracht. Dies kann sich als vorteilhaft erweisen, wenn die Client-Server-Lösung bereits Jahr-2000-kompatibel ist und das alte System ohnehin zur Disposition steht.

Allerdings muß die neue Lösung die Funktionalität des bestehenden Systems in einem Schritt vollständig ersetzen. Andernfalls müßten das alte und das neue System parallel laufen. Anstatt das Problem zu vermeiden, hätten diese Unternehmen im ungünstigsten Fall ihre Arbeitsbelastung verdoppelt.

Andererseits können Anwender durch Werkzeuge zur Ver- sionsabstimmung schnell und exakt feststellen, welchen Arbeitsumfang die Abstimmung der Problem-2000-Änderungen des Anbieters mit den betriebseigenen Modifikationen hat. Durch diese Information sind sie in der Lage, die Kosten entweder für eine Aktualisierung oder einen Wechsel zu rechtfertigen.

Die wichtigste Frage bei der Jahr-2000-Aktualisierung ist, ob ausreichend Personal für den Abschluß des Projekts verfügbar ist. Natürlich verfahren alle Unternehmen in etwa nach dem gleichen Zeitplan. Aus diesem Grund sind bei Umstellungstools, Dienstleistungen und freien Programmierkapazitäten Engpässe zu erwarten.

Mit Kostenexplosionen ist zu rechnen, und es wird nicht ausreichend Personal vorhanden sein, um alle Unternehmen zu bedienen. Unter Berücksichtigung dieser Entwicklung, die sich in den USA schon klar abzeichnet, erscheint die Schätzung der Gartner Group, nach der sich die Kosten für die Jahreszahlenumstellung weltweit auf 300 bis 600 Milliarden Dollar belaufen, nicht mehr so übertrieben.

Auch stellt sich die Frage, ob es überhaupt genügend Programmierer gibt. Ein Großteil der Anwendungen wurde während der letzten 20 Jahre entwickelt und modifiziert. Bereits jetzt steht fest, daß die verbleibende Zeit bis zum Stichtag Silvester 1999 einfach nicht ausreicht, um den gesamten Datumswechsel über die Bühne zu bringen.

In den meisten Unternehmen geht es um Hunderte von Eigen- und Fremdsystemen mit tausendfachen Datenänderungen. Aus diesem Grund ist es nur schwer vorstellbar, daß ein Unternehmen über ausreichend Programmierer verfügt, um manuell alle laufenden Verbesserungen und anwenderspezifischen Programme mit der korrigierten Software unter einen Hut zu bringen.

Gewöhnlich läßt sich im Falle einer nicht funktionierenden Anwendung deren Implementierung zurückstellen. Und selbst dann, wenn die Störung nicht vorher eingetreten ist, könnten die Unternehmen immer auf die alte Anwendung oder die alte Methode zurückgreifen.

Sollte die Jahr-2000-Aktualisierung nicht rechtzeitig abgeschlossen sein, ist die alte Anwendung auch nicht lauffähig. Es bleibt im Störungsfall also nichts anderes übrig, als die Anwendung ungeachtet der dafür notwendigen Zeit zu reparieren. Sicher wird dies den laufenden Geschäftsbetrieb beeinträchtigen.

Bisher dauerte es bei einer Anwendungsstörung nur ein oder zwei Tage, um den Fehler zu beseitigen. Bei der Jahreszahlenmodifikation handelt es sich jedoch um die einzige Aktualisierung, bei der alle Anwendungen am selben Tag aktiviert werden.

Natürlich werden die Unternehmen vor dem 1. Januar 2000 Anwendungen fertigstellen und in Betrieb nehmen. Allerdings könnten viele dieser aktualisierten Anwendungen nicht mit zukünftigen Datumsangaben arbeiten, so daß sie es bis zum 31. Dezember 1999 mit Daten zu tun haben, die mit "19" beginnen. Damit sind sie fein heraus.

Spätestens am Neujahrstag 2000 dürfte sich weltweit jeder Manager dieses Problems bewußt sein. Weil es ständig aus den verschiedensten Gründen zu Systemstörungen kommt, haben sich DV-Experten ohnehin ein ziemlich dickes Fell zugelegt. Anwendungsstörungen im Januar 2000 werden jedoch im höchsten Maße augenfällig sein. Jeder Chef wird nach den Nullen Ausschau halten. Viele Programmierer lernen ihren Vorgesetzten wahrscheinlich erstmals im Januar des Jahres 2000 kennen. Aber dann so richtig.

Es gibt keine einfache "Rückfall"-Position

Die Datumsumstellung läßt sich nicht umgehen und die Frist nicht aufschieben. Um den Übergang zum Jahr 2000 problemlos vollziehen zu können, müssen Unternehmen Versionsabstimmungen bei Parallelentwicklungen in ihren Projektplan einbeziehen.

Die Jahr-2000-Herausforderung bedarf umfangreicher Planungsarbeiten. Sie unterscheiden sich von allen anderen Datenverarbeitungsprojekten dadurch, daß Abstimmungen verschiedenster Softwareversionen notwendig sind. Es gibt keine einfache "Rückfall"-Position, Fristverlängerungen entfallen.

Jeder Monat, der sich bei der Versionsabstimmung durch Einsatz eines Werkzeugs an Personal einsparen läßt, reduziert nicht nur die Kosten. Viel wichtiger ist, daß solche Tools eine ungleich bessere Chance bieten, den Zeitplan einzuhalten und Risiken möglichst zu vermeiden.

Renoviert oder neu?

Aber nicht nur Zeit, Arbeitsaufwand und Kosten entscheiden darüber, ob Anwender ein System aktualisieren oder auswechseln sollten. Folgende Fragen sind außerdem zu berücksichtigen:

- Wann liefert der bisherige Anbieter eine Jahr-2000-kompatible Version?

- Ist der Personalbedarf gedeckt, oder sind wichtige Mitarbeiter in anderen Projekten unabkömmlich?

- Welche und wie viele Programme des vom Anbieter gelieferten ursprünglichen Quellcodes hat der Anwender nach eigenen Bedürfnissen geändert?

- Wird für die Versionsabstimmung ausreichend Zeit vorhanden sein?

- Kommt es zu zeitlichen Engpässen beim Test aller Modifikationen?

Werkzeuge

Ein Werkzeug zur Versionsabstimmung hat mehrere Effekte:

- Es wird dadurch möglich, die abzustimmenden Programme zu vergleichen und in einer einzigen zusammengesetzten, bearbeitbaren Version zu konsolidieren.

- Es hilft, Konflikte zwischen Versionen mittels eines intelligenten Online-Editors zu identifizieren und abzustimmen.

- Es vereinfacht die Überprüfung aller Änderungen.

- Es gestattet die Revision irrtümlich vorgenommener Änderungen.

Angeklickt

Alle Software-Anpassungen - sei es aufgrund von Gesetzes- und Organisationsänderungen oder seien es Fehlerkorrekturen - führen unweigerlich zu Parallelversionen. Bei der Jahr-2000-Modifikation, dem größten aller Aktualisierungsprojekte, ist dies nicht anders. Das "Einfrieren" von Produktionssystemen während des Umstellungsprozesses ist allerdings keine ernsthaft praktikable Lösung. Die zwischenzeitlichen Neuerungen sind auf die korrigierte Version abzustimmen. Ein Aufwand, der ohne Software-Unterstützung höchst zeitaufwendig und fehlerintensiv ist.

*Bernd Röhrs ist Geschäftsführer von Cleversys in Elbtal-Hangenmeilingen.