Einmal hierarchisch und wieder zurück

Im Datenbankbereich gibt es derzeit eine Tendenz weg von relationalen und (erneut) hin zu hierarchischen Strukturen. Vielleicht kommen auch die Netzwerkdatenbanken wieder, die es schon Ende der 1970er Jahre gab. Oder vielleicht entwickelt sich eine völlig neue Datenhaltung, etwa die assoziative Speicherung? Was wird dann aus all den SQL-Programmen?

Was heute als Nonplusultra gilt, kann morgen schon Makulatur sein. Das Software-Engineering benötigt dringend eine neue qualitative Messgröße: eine, die sich auf die Minimierung der Auswirkung von technologischen Veränderungen bezieht.

Wenn sich Geschäfts- und Datenlogik automatisch erkennen und kapseln lassen, wenn Riesenprogramme in kleine Module aufteilbar sind, wenn die Semantik von Programmen ausgelesen und in beliebige andere Sprachen transponiert werden kann, dann erhält die Softwarezunft eine Flexibilität, die sie unabhängiger von technologischen Strömungen macht. Wer die Hilfsmittel dafür hat, verhilft der Software zu mehr Wert. Hier geht es selbstverständlich auch um einen wirtschaftlich interessanten Markt.

In den Jahren 1982 bis 1990 gab es weltweit viele Migrationen von VSE, dem "kleineren" IBM-Betriebssystem, nach MVS. Damals wurde eine Reihe von Konvertern entwickelt, die diese Aufgabe zumindest teilweise automatisieren sollten. Diesen Bemühungen waren jedoch Grenzen gesetzt - durch die leistungsschwachen Maschinen jener Zeit, durch die Notwendigkeit, Assembler zu nutzen, und durch das Fehlen von Hilfsmitteln, die man heute frei aus dem Internet laden kann.

Modernisierung geht nicht eins zu eins

Der Autor experimentierte damals mit CML, seiner ersten Sprache zur Erstellung von Sprachkonvertern. Eine IBM 4381, die damals etwa eine Million Mark kostete, arbeitete stundenlang, um ein paar Programme zu konvertieren; ein normaler Laptop würde heute zwei Minuten dafür benötigen. Zudem ist es mit Konversion und Migration nicht getan. Eine echte Modernisierung berücksichtigt die Eigenheiten der neuen Umgebung so, dass alles aussieht, als wäre es in der "neuen Welt" entwickelt worden (siehe auch: "IT-Modernisierung: die sieben Hürden").

• Es genügt beispielsweise nicht, den TP-Monitor Cics auf Unix oder Windows zu emulieren; der Code "läuft" zwar, aber man muss nach wie vor "in Cics denken", um die Anwendung zu verstehen.

• Wenn man Assembler-Programme in eine höhere Sprache hinüberretten will, dürfen die Instruktionen keinesfalls eins zu eins umgesetzt werden. Vielmehr ist es notwendig, Gruppen von Instruktionen zu bilden, sie unter Berücksichtigung der semantischen Umgebung zu verstehen und als Ganzes in die neue Welt mitzunehmen. Nur so entsteht verständlicher Code.

• Als Negativbeispiel mag das Ergebnis einer Testkonversion dienen: Ein 180 Zeilen umfassendes Cobol-Cics-Programm wurde vom Anbieter eines Cobol-nach-Java-Konverters in ein 4000-zeiliges Java-Monster verwandelt, das auch die fähigsten Köpfe nicht entschlüsseln konnten.

Die neue Code-Ausprägung muss harmonisch in die neue technologische Landschaft passt. Dabei wird selbstredend die Funktionalität vollständig erhalten. Darüber hinaus sollte sich der transformierte Code später leicht in andere technische Umgebungen einbetten lassen.