Soll eine alte Systemumgebung durch eine neue ersetzt werden, so bieten sich drei Möglichkeiten an: Die 1:1-Migration alter Anwendungen, die komplette Neukonzeption und der Mittelweg zwischen diesen beiden Extremen. Reverse Engineering, Forward Engineering und Information Engineering sind die Fachgebiete, in denen sich nach Ansicht von Sixta Zerlauth und Jürgen de Haas* die sogenannten Migration Engineers zurechtfinden müssen.

Ein Wechsel der Systembasis stellt an sich einen normalen Vorgang in der DV-Geschichte eines Unternehmens dar. Aufgrund technischer, wirtschaftlicher oder politischer Einflußfaktoren sind historisch gewachsene Rechnersysteme eines Tages durch neue Systeme des gleichen oder auch anderer Hersteller abzulösen. Zumindest Teile der bestehenden Anwendungen könnten dabei in der Regel auch in Zukunft weiter eingesetzt werden.

Andere Komponenten dagegen müßten bei einem Rechnerwechsel neu überdacht werden. Dies haben die Unternehmen meistens natürlich schon seit langem vor, können es aber aufgrund anderer Prioritäten nie in Angriff nehmen. Wenn man jedoch durch den angestrebten Wechsel sowieso schon alles anfassen muß, könnte man dabei doch auch gleich ...

Mit solchen Überlegungen fängt in der Regel die unendliche Geschichte der Migrationen an, die für so manches Unternehmen viele negative Konsequenzen mit sich bringt. Daß dies jedoch kein Naturgesetz sein muß, sondern derartige Vorhaben durch den konsequenten Einsatz neuer Methoden und Vorgehensweisen durchaus in den Griff zu bekommen sind, soll im folgenden an einem konkreten Migrationsbeispiel dargestellt werden.

Die 1:1 Migration stößt häufig auf wenig Gegenliebe

Die Ausgangslage: Ein überaus komplexes, teilweise dezentrales, in zwei Jahrzehnten gewachsenes System mit einer Vielzahl von Einzelanwendungen soll auf eine neue Systembasis gestellt werden. Dies ist zwingend, da die alten Rechner vom Hersteller nicht mehr lange gewartet werden und sie auch die gestiegenen Anforderungen nicht mehr erfüllen.

Die Dokumentation ist wie so oft nur unzureichend. Selbst noch so große Disziplin reichte natürlich in der Vergangenheit nicht aus, alle Beschreibungen vollständig und konsistent zu halten, zumal hier keinerlei Werkzeuge Unterstützung boten. Die Anwendungen selbst sind, wie könnte es anders sein, zum großen Teil noch in Assembler geschrieben.

Eine 1:1-Migration stößt bei den Verantwortlichen auf wenig Gegenliebe. Ein solches Vorgehen wird als Unterbrechung des Software-Life-Cycles für den

Zeitraum der Migration empfunden und droht dadurch unangenehme Konsequenzen nach sich zu ziehen:

- WeiterentwickIungen werden vorübergehend gestoppt,

- der Anwendungsstau vergrößert sich,

- Änderungswünsche der Anwender bleiben berücksichtigt,

- flexible Reaktionen auf Wettbewerbsanforderungen werden erschwert,

- negative betriebswirtschaftliche Auswirkungen entstehen,

- Imageverlust intern wie extern ist zu befürchten.

Auch die Lösung, alles neu zu machen, erscheint nicht als gangbarer Weg.

Das Expertenwissen, das sich in ausgeteilter Funktionalität niedergeschlagen hat, wäre bei einer Neukonzeption auf der "grünen Wiese" kaum zu berücksichtigen beziehungsweise neu zu gestalten.

Wen wundert es da, daß nach solchen Erwägungen ein goldener Mittelweg angestrebt wird, der die Vorteile von 1:1-Migration und Neukonzeption verbinden und ein Risiko möglichst minimieren soll. Die Herausforderung besteht nun darin, eine akzeptable Lösung für die folgenden Migrationsprobleme zu finden:

- mangelnde Kenntnis der Altanwendungen,

- Behandlung veralteter technischer und fachlicher Konzepte,

- Festlegung der passenden Migrationsstrategie,

- Berücksichtigung von Abhängigkeiten zwischen Anwendungen, falls Teilbereiche nacheinander migriert werden,

- Festlegung der Übergangstrategie: entweder Ad-hoc-Übergang mit Fallback-Möglichkeiten etc. oder sukzessiver Übergang mit Parallelbetrieb und Anforderungen wie dem Abgleich von Alt- und Neudaten und die Ermittlung von Konvertierungsregeln.

Hohe Anforderungen an die Mitarbeiter

Dieser angestrebte Mittelweg erfordert einen detaillierten Plan für eine methodisch und technisch unterstützte Migration mit Neukonzeption. In der anschließenden Planung werden Ziele dokumentiert wie:

- Verbesserung der Kenntnis von Altanwendungen und der Altdatenbasis,

- ldentifikation von Teilbereichen der Anwendungen, die für eine 1:1-Migration geeignet scheinen oder die entsprechend zu erneuern sind,

- Entwicklung von neu zu gestaltenden Anwendungen, die keinerlei Entsprechung im Altsystem haben,

- Optimierung der dezentralen Anwendungsteile mit Erweiterung des Komforts für die Anwender.

Werden diese Ziele in den Vordergrund gestellt, so zeigt sich, daß hohe Anforderungen an die Mitarbeiter zu stellen sind, die das Migrationsvorhaben abwickeln sollen. Diese "Migration-Engineers" müssen Generalisten auf dem Gebiet der Methoden sein und auch über Fachkenntnisse verfügen, um bei den Neukonzeptionen beratend tätig zu sein. Kenntnisse über Reverse-, Forward- und Information Engineering sind unabdingbar. Nur durch einen in dieser Richtung ganzheitlichen Ansatz ist es möglich, das anspruchsvolle Vorhaben wie gewünscht in die Realität umzusetzen.

Die Vorgehensweise läßt sich nun in aufeinanderfolgenden Einzelschritten planen und abwickeln. In einem ersten Schritt werden die dezentralen Anwendungsteile auf eine neue Systembasis gestellt. Für die Benutzer ist dort eine moderne, komfortable Oberfläche zu konstruieren, die künftige Anforderungen erfüllt und mit dezentralen Komponenten unabhängig von dem übrigen Vorgehen, erweitert werden kann.

Die Kommunikation mit dem alten Host wird zunächst 1:1 nachgebildet. Auf diese Weise läßt sich erreichen, daß in kurzer Zeit Bedürfnisse der Benutzer im Rahmen einer "Runderneuerung" der Altanwendung zum Teil befriedigt werden. Gleichzeitig enthält die dezentrale Seite damit bereits die künftigen Steuerungsmechanismen, was eine später erforderliche Anpassung stark erleichtert. Der durch diesen Schritt kurzfristig beim Anwender erzielbare Erfolg verschafft den Verantwortlichen insgesamt bereits einen beträchtlichen Imagegewinn.

Grundstein für das Gelingen gelegt

Parallel wird ein Reverse-Engineering-Projekt aufgesetzt. Zuerst ist ein Überblick über alle Anwendungen, Datenbasen und deren Zusammenspiel zu erstellen. Aus dieser Übersicht lassen sich die Abhängigkeiten zwischen den Anwendungen ablesen. Damit ist die Basis für die Planung geschaffen, welche Anwendungen 1:1 migriert und welche unabhängig voneinander behandelt werden können. Diese Erkenntnisse sind von Bedeutung für die Gestaltung des geplanten Parallelbetriebes und stellen sicher, daß ein Datenabgleich während dieser Zeit nur so selten wie nötig erfolgen muß.

Als nächstes wird die Altdatenmodellierung in Angriff genommen. Dort müssen alle Datenfelder mit ihren Namen, Kurzbeschreibungen, Formaten, Standortregeln, Redundanzverweisen und Klassifikationen, wie technisch, fachlich, migrationsrelevant etc., erfaßt werden. Neben der Dokumentation in einem Datenlexikon erfolgt dabei eine Zuordnung zu dem gleichzeitig entstehenden neuen Datenmodell. Zusätzlich ist die Definition von Konvertierungsregeln für die Datenübernahme (Initial Load) und von Rekonvertierungsregeln für einen späteren Abgleich notwendig.

Der Weg zur neuen Datenbasis wird auf diese Weise geebnet - sie kann nun definiert, installiert und geladen werden. Damit ist die Voraussetztung geschaffen, neue Anwendungen zu entwickeln und zu testen.

Für ausgesuchte Anwendungen kann die 1:1-Migration beginnen. Zu diesem Zweck wird eine Datenzugriffs-Schicht zur neuen Datenbasis erstellt. Die alten Anwendungen können mit ihrer alten Sicht der Datenwelt vorerst weiterarbeiten. Im Zuge dieser Aktivitäten wird darüber hinaus eine Abgleichmöglichkeit zwischen alten und neuen Datenbeständen geschaffen.

Als nächster Schritt, ist nun die Analyse von solchen Altanwendungen ins Auge zu fassen, die nicht 1:1 migriert werden können. Die Analyse bezieht sich zunächst auf die technische (physische) Ebene und befaßt sich mit Aufgaben wie:

- Beschreibung aller Module und Programme mit Entries,

- Analyse der Datenaustauschverfahren (Common Areas, temporäre Dateien, Messages),

- Analyse des Datenbedarfs der Module und Programme,

- Klassifikation der Module und Programme (technisch, fachlich, veraltet, aktuell etc.).

Diese Analyse wird maschinell durch Auswertungsprogramme unterstützt und hat eine technische Nachspezifikation der Anwendung zum Ergebnis. Darauf aufbauend folgt eine fachliche Nachspezifikation. Diese enthält Beschreibungen jeder relevanten Funktion mit Ein- und Ausgabedaten, Plausibilitätsprüfungen, gelesenen oder geschriebenen Daten

aus der Datenbasis sowie ihrer fachlichen Verarbeitung.

Da man die Zuordnung von Altdaten zum neuen Datenmodell bereits erarbeitet hat, kann dies bei den Beschreibungen des Datenbedarfs der Funktionen schon mitaufgeführt werden. Nach der ergänzenden Beschreibung fachlichen Konzepte, die bei der Analyse der Funktionen deutlich wurden, liegt als Ergebnis ein umfassendes Altpflichtenheft vor.

Von nun an wandelt sich das bisherige Reverse-Engineering-Projekt in ein Projekt, das den Prinzipien des Forward Engineering gehorcht. Das Altpflichtenheft wird durch Überarbeitung sowie durch Ergänzung mit neuen Konzepten und Funktionen in ein Pflichtenheft für die neue Anwendung überführt. Hiermit ist nun sichergestellt, daß die Altanwendung vollständig und richtig abgelöst werden kann.

Obwohl noch ein steiniger Weg folgt, ist hiermit doch bereits der Grundstein für das erfolgreiche Gelingen des Gesamtvorhabens gelegt. Wie sich zeigt, kann durch die Kombination der richtigen Methoden und Vorgehensweisen ein auf den Einzelfall zugeschnittenes Rezept erarbeitet werden, das den Migrationsplänen viel von ihrem Schrecken nimmt.