Migration stellt einen Sonderfall des Re-Engineering dar

Eins-zu-eins-Übertragung ist oft eine vertane Chance

01.12.1989

Die Übertragung alter Anwendungen in eine neue Betriebssystemumgebung bietet die Gelegenheit, Unnötiges zu eliminieren und Chaotisches zu ordnen. Wer stur ein

automatisiertes Verfahren anwendet, so Nikolaus Niggemann und Klaus Schröder*, läßt die Gelegenheit zum Re-Engineering ungenutzt.

Ein Anwender der sich für eine wie auch immer geartete Migration entschieden hat, will selten alles, was irgendwie einmal in der Historie seiner DV-Abteilung entstanden ist, vorbehaltlos übernehmen. Die meisten würden die vorhandenen Anwendungen gern besser auf ihre gegenwärtigen Probleme und Möglichkeiten abstimmen. Von daher bietet es sich an, zumindest Teile des Systema neu zu implementieren. Ein Beispiel für eine sinnvolle Neuentwicklung ist die Strukturierung der Datenbasis.

Ein Aspekt, der heute immer stärker relevant wird, ist die Dezentralisierung. Ob der Anwender ein Konzept mit Abteilungsrechnern will oder nur Intelligenz am Arbeitsplatz--

beides führt dazu, daß zumindest die Dialoganwendungen anders konzipiert werden müssen.

Alte Datenbestände bei der Umstellung mitnehmen

Fast immer läßt sich ein Kompromiß zwischen der formalen Umstellung sowie einer

Neukonzeption und Neurealisierung schließen. Meistens versucht man, die Batch-Programme formal umzustellen. Dabei ergibt sich dann allerdings das Problem, daß man sich eigentlich auf eine neue Datenbasis bezieht.

AIso wird für die bestehenden Programm eine Schnittstelle eingezogen, die den Zugriff auf die neue Datenbasis dergestalt regelt, daß die Anwender glauben, sie würden noch mit den alten Daten arbeiten, während sie in Wirklichkeit auf die neuen Daten zugreifen.

Im wesentlichen neu zu konzipieren und auch neu zu realisieren sind die Dialog- oder Online-Teile. Wer hier eins zu eins umstellt, vergibt eigentlich die Chance, seine Software auch zu sanieren.

Systemnähe kann zu Problemen führen

Die alten Dialog-Anwendungen sind technisch wesentlich tiefer in die Systeme eingegraben worden, weil damals die Datenkommunikationsaspekte noch nicht so berücksichtigt werden konnten. Deswegen sind diese Applikationen viel schwieriger in den bestehenden Strukturen von A nach B zu bringen. Die Transaktionsmonitore von heute entsprechen eben nicht mehr denen von vor 15 Jahren - so überhaupt welche eingesetzt wurden.

Der Übergang von einem System A zu einem System B ist eine Neustrukturierung; insofern ist diese Aufgabenstellung als Spezialfall eines Problems zu betrachten, das heute eigentlich jeder Anwenderbetrieb hat, auch wenn er bei System A bleiben will. Dieses Problem heißt Weiterentwicklung von Altanwendungen. Da sind beispielsweise eine neue Datenbasis oder eine dezentrale Struktur einzuführen. Und hier stellen sich komplexe Aufgaben auch dann, wenn dieselbe Systembasis eingesetzt wird wie vorher.

Das Schlagwort hierzu heißt eigentlich Re-Engineering eines Anwendungssystems. Und die Tatsache, daß die Applikation auf eine andere Systembasis gehoben wird, ist dabei nur ein Teilaspekt. Die großen Anwender haben alle eine Datenverarbeitung, die in diesem Bereich gute 15 Jahre auf dem Buckel hat. Um die neuen Technologien hineinzubringen, müssen diese Anwender ihre Systeme umstrukturieren. Also ist das Grundproblem der Migration identisch mit dem des Re-Engineering. Die Migration ist ein Spezialfall des Re-Engineering.

Der Begriff Re-Engineering ist derzeit in aller Munde; aber kaum jemand weiß, wie man die Sache angehen soll. Auf jeden Fall gehört dazu ein Datenlexikon oder Data-Dictionary als Dokumentationsbasis der bestehenden Systeme.

Aufgebaut wird die Dokumentation anhand von maschinellen Untersuchungen der vorhandenen Quellen (mit Hilfe von CASE-Produkten) plus manuellen Recherchen, die sich auf Inhalt und konzeptionelle Strukturen beziehen.

Nachdem der Re-Engineer sich ein konzeptionelles Gerüst der gesamten Anwendungen erstellt hat, leitet er davon eine Strategie ab. Er muß sich überlegen, welche Teile er behalten will und was neu gemacht werden muß.

Für die Programme, die erhalten bleiben sollen, ist mit dem Re-Engineering eigentlich schon die entsprechende Dokumentation für die Weiterentwicklung vorhanden. Und für das, was man neu machen will, stehen zumindest bereits die Vorgaben aus dem alten System fest. Dazu kommen dann eine neue Technologie, neue Anforderungen und neue Anwendungen.

Re-Engineering macht Altsysteme fast wie neu

Auch der Teil der Anwendungen, der erhalten bleiben soll, sollte sich ohne größere Probleme weiterentwickeln lassen. Das ist keineswegs selbstverständlich; denn häufig weiß niemand in der Abteilung mehr, was und wie da genau entwickelt wurde. Erst mit Hilfe des Re-Engineering kann nachvollzogen werden, wie die Anwendung aufgebaut ist Aufgrund dieser Informationen läßt sich dann beurteilen wie an den richtigen Steilen die

Weiterentwicklung durchgeführt werden kann.

Auf einer solchen Basis kann dann optimal gemischt werden - zwischen dem, was nun wirklich neu gemacht werden muß, weil es nicht mehr dem Stand der Zeit entspricht, und den Dingen, die beibehalten werden können. Das bedeutet eine weitgehende Sicherung der Investinonen.

Das Re-Engineering-Problem haben alle Anwender von Großsystemen. Manche haben es allerdings noch nicht erkannt und plagen sich immer noch mit den berühmt-berüchtigten Rucksäcken - hier einen dazwischen und da einen, dort ein. Modul mit

dezentralen Komponenten etc. So sieht das System dann auch aus; es wird dadurch

nicht besser und nicht schöner.

Für die Dokumentation sind Tools unerläßlich

Selbstverständlich ist es sinnvoll, für das Re-Engineering geeignete Software-Werkzeuge

einzusetzten. Ansonsten würde man beispielsweise an dem Aufwand, um 70 000

Datenelemente zu dokumentieren, zwangsläufig scheitern. Aber das eigentliche Denken können die Werkzeuge uns nicht abnehmen. Die Entscheidungen müssen wir letztendlich selbst treffen.

Die Grenzen zwischen automatisiertem und manuellem Teil sind dabei durchaus fließend, je nachdem, wie gut das, was man analysiert, strukturiert ist. Deswegen muß man die Tiefe des Sumpfes, in dem man herumwaten muß, zunächst einmal ausloten. Und das geschieht auf jeden Fall von Hand. Ob ein Honeywell-Bull-Assembler oder IBM-Probleme zu

analysieren ist, macht einen Unterschied. Nicht immer paßt derselbe Schraubenschlüssel.

Eins-zu-eins-Umstellungen empfehlen sich nur selten

Natürlich kann es für bestimmte Kunden auch eine richtige Entscheidung sein, ihr

gesamtes Anwendungssystem und modifiziert von A nach B zu bringen. Aber es gibt meistens auch gute Gründe, zu sagen Höchste Zeit, das umzustrukturieren, damit es auch andere Mitarbeiter verstehen. Irgendwann fällt ein Anwender mit solch einem System nämlich auf die Nase, weil er es nicht mehr versteht; und der Mann, der das gemacht hat, ist auch in Pension gegangen .

Auf der anderen Seite ist eine Eins-zu-eins-Umstellung immer noch die schnellste Möglichkeit von einer Situation in eine andere zu kommen.

Und wenn jemand als primäres Ziel erkannt hat, möglichst schnell

hinüberzukommen dann muß er diesen Weg eben wählen.

Aber falls irgend möglich sollte er die Sache - wenn er sie schon anfaßt - richtig anfassen. +

* Dr. Nikolaus Niggemann ist Abteilungsleiter Kommerzielle Systeme bei der Softlab GmbH, München. Klaus Schröder arbeitet in demselben Unternehmen als Chefberater.