Sie wollen wissen, was das Jahr 1968 und die IT-Industrie gemeinsam haben? In diesem Jahr sang Bob Dylan uns allen aus dem Herzen: "The times they are a-changing". Wir dachten, wir hätten diesen Gedanken erfunden! Aber in Wirklichkeit ist er so alt wie die Menschheit - und wie der Glaube jeder Generation, dass nur sie selbst dies erkannt hat. Die Dinge entwickeln und verändern sich. Was sich nicht verändert, ist tot, wer sich nicht anpasst, stirbt aus. Charles Darwin lässt grüßen - auch uns Informatiker.

Die Nato Software Engineering Conference

Und was gab es 1968 in der IT? Bereits seit sechs Jahren existierten Programmiersprachen wie Cobol und RPG; Fortran begeisterte Mathematiker und Physiker; IBM hatte eine eigene Sprache kreiert, die sie in einem Anflug von Größenwahn Programming Language One (PL/1) nannte. Als ob es nie mehr eine andere geben würde - oder zumindest nie eine bessere. Denkste! Viele andere folgten: HOPL, die Enzyklopädie der Computersprachen, listet heute 8.512 dieser Sprachen. Das macht seit 1968 im Schnitt mehr als 200 neue Sprachen pro Jahr. Asterix würde sagen: "Ils sont fou les informaticiens." (Die spinnen, die Informatiker.) Und er hätte gar nicht so Unrecht. Wer was auf sich hält in der Branche, schreibt seine eigene Programmiersprache. Sanft errötend gesteht der Autor, dass auch er mit Rulaman/SPL eine neue Sprache entwickelt hat, die selbstverständlich völlig anders und unverzichtbar ist! Übrigens ist sie auch noch nicht bei HOPL gelistet; das macht dann also 8.513 Sprachen.

Getreu der Erkenntnis, dass der Krieg der Vater aller Dinge ist, hatte die Natodie Bedeutung von Software auch für militärische Zwecke früh erkannt. 1968 sponserte das NATO Science Committee erstmals eine Konferenz zum Thema Software Engineering (The Nato Software Engineering Conference). Damals wurde der Software-Engineering-Begriff "offiziell" aus der Taufe gehoben. An der Konferenz nahmen 50 Informatiker aus zwölf Ländern teil. Einer der beiden Protokollare dieser Konferenz war der Däne Peter Naur, dessen Name in der Backus-Naur-Notation ("BNF") verewigt wurde. Das Foto (links) zeigt ihn bei seiner damaligen Arbeit und erinnert uns daran, wie viel technologischer Fortschritt seitdem passiert ist. Schreibmaschine und Tonband stimmen fast wehmütig, die jüngeren Nutzerinnen und Nutzer dieser Site werden derartige Gerätschaften wohl nur noch aus dem Museum kennen.

Was nach vier Jahrzehnten geblieben ist

Seit 1968 wurden Hunderttausende von Personenjahren in Software investiert. Was ist daraus entstanden? Zuerst einmal eine Menge Code und Daten! Meist versunken und vergessen wie die alten Disketten. Die waren früher so groß wie Torten und hatten anfangs noch gestanzte Löcher, an denen sich die Schreibköpfe orientieren konnten; es gab Winchester-Platten, die locker drei Megabyte fassten, und ganze Schränke voll mit mehreren Kilogramm schweren Wechselplatten, die Ende der 1970er Jahre - sage und schreibe - 200 MB speichern konnten.

Die alten Daten sind Geschichte, ihre Aufbewahrungsfristen lange abgelaufen; das Daten-Layout hat sich verändert, die Speicherformate sind nicht mehr lesbar. Wäre es gesetzlich vorgeschrieben, dass alle Unternehmen die Lesbarkeit ihrer Altdaten nachweisen müssten, so entstünde sicher ein neuer und sehr lukrativer Geschäftsbereich in der Informatik.

Software hängt wie Klebstoff zusammen

Und was ist mit den Programmen? Hier haben zwei Dutzend Sprachen und Dialekten die Jahrzehnte überdauert. Schmerzhaft bewusst wurde uns das kurz vor der Jahrtausendwende, als die alten Recken der Softwareentwicklung aus dem Ruhestand geholt werden mussten. Damals erkannten wir schlagartig, dass Software wie Klebstoff zusammenhängt und sich die Sünden (oder Notwendigkeiten) vergangener Jahrzehnte deshalb wie Viren über Schnittstellen und Datensätze bis in die "moderne" Zeit fortpflanzen.

Die Welt der Informatik spricht immer noch zu mehr als 50 Prozent Cobol. Diese Sprache hat es vermocht, sich durch viele Häutungen hindurch an die jeweiligen IT-Landschaften anzupassen. Heute hat Cobol sogar objektorientierte Eigenschaften - auch wenn das ungefähr so sinnvoll ist wie ABS am Fahrrad. (Siehe auch: "Zombie goes E-Business")

Und was ist mit den anderen 8.511 Sprachen? Die meisten waren so proprietär, dass sie das Labor ihres Schöpfers gar nicht verließen und mit seinem nächsten Karrieresprung wieder verschwanden. Ein guter Teil der Sprachen starb mit der Hardware oder dem Betriebssystem, das den Compiler unterstützte. Wieder andere leben in ökologischen Nischen, steuern Waschmaschinen und Automobile.

Einige wenige Sprachen blieben uns erhalten. Würde man die heutigen Softwarebibliotheken auf das Wesentliche eindampfen, fände man bereits einiges an Java-, C++- und C#-Code. Aber das ist vergleichsweise wenig gegen den Rest. Neben ungeheuer viel Cobol kommt auch PL/1 vor (davon gibt es noch schätzungsweise 400 große Anwender im deutschsprachigen Raum). Ferner existiert viel Code in einer Reihe von Sprachen, die dem 4GL-Hype der frühen 1990er Jahre entsprangen; dazu gehören CSP, Visual Age, Delta und Natural. Last, but not least feiern - Sie werden es nicht glauben! - immer noch viele Millionen Zeilen Assembler fröhliche Urständ. Allein in den Öffentlichen Diensten Deutschlands dürften noch mehr als 40 Millionen Assembler-Zeilen im Einsatz sein; dasselbe gilt für viele Kernsysteme von Finanzinstituten und Versicherungen, weil diese lange vor den 1980er Jahren begannen, ihre DV hochzuziehen.

Wer soll den ganzen Code pflegen?

Diese Programme existieren nicht nur, sie sind sogar noch tagtäglich im Einsatz. Ein Albtraum! Wie kann man die Wartung der Altprogramme sichern? Zum Neuschreiben fehlen das Geld, die Zeit - und die Dokumentation. Niemand weiß mehr richtig, warum die alten Programme sind, wie sie sind. Also lassen wir sie lieber, wie sie sind, schreiben die neuen Anwendungen mit zeitgemäßen Mitteln und flanschen alles über Brücken und Interfaces zusammen. Informatiker, die noch Cobol sprechen, sind heute eher 50 als 40 Jahre alt; PL/1-Know-how findet man kaum noch auf dem Markt; aktive Assembler-Programmierer sind selten wie die Blaue Mauritius.

Das Thema Assembler haben wir bereits verschlafen; hier hilft nur noch eine intelligente funktionsidentische Modernisierung des Codes. Dasselbe gilt für PL/1. Bei den anderen 3GL- und 4GL-Sprachen haben wir noch einige Jahre Zeit. Aber auch hier brennt die Lunte. Wir sollten deshalb so schnell wie möglich eine harmonische Erneuerung vornehmen, die sich pragmatisch aus Modernisieren, Bewahren, Einsatz von Standardsoftware und Neuschreiben abmischen lässt.

Billionen Euro an versunkenen Schätzen

Niemand weiß, wie viel produktiver Code uns aus 40 Jahren Software-Engineering erhalten geblieben ist. Lassen Sie uns dennoch versuchen, eine Vorstellung von der Größenordnung zu bekommen. Nehmen wir an, dass es in Deutschlands Anwenderunternehmen 20 Millionen Softwareentitäten mit durchschnittlich 500 Zeilen gibt. Dann betreiben und pflegen deutsche Unternehmen insgesamt zehn Milliarden Zeilen Code. Dazu kommen noch einige Millionen Programme von Softwarehäusern. Wenn die Erstellung und Pflege einer Zeile 100 Euro gekostet hat - das geht schnell, wenn man in die Total Cost of Ownership auch den DB-Administrator, die Qualitätssicherung, die Mitarbeit der Fachabteilung beim Test, das mittlere Management und den Wartungsaufwand vieler Jahre einbezieht -, so kommen wir hinsichtlich der Gestehungskosten in die Billionen-Euro-Dimension.

Den ganzen Code "neu zu erfinden" würde zu Investitionen in ähnlicher Größenordnung führen, ist also für die meisten Unternehmen wirtschaftlich nicht vertretbar. Aber die in den Codes enthaltene Geschäftslogik ist ein Schatz, den es zu heben gilt. Er muss von den Krusten alter Technologie befreit und ohne funktionale Einbußen für eine Verwendung in heutigen Technikumgebungen zugänglich gemacht werden. Allmählich sollten wir uns vielleicht mal mit dem Begriff Software-Recycling anfreunden (siehe auch: "Web-Services öffnen Cobol").

Die Technik treibt das Design

Noch immer hat die einen Ingenieur umgebende Technologie großen Einfluss auf seine Arbeit, also auch auf das, was der Anwender als Ergebnis erhält:

• Die Pyramiden sähen anders aus, wenn es damals schon Beton gegeben hätte.

• Wer mit der Draisine fährt, käme nicht auf die Idee, einen Speisewagen zu suchen.

• Der Benutzer eines Dialogsystems, das auf einer Siemens PBS des Jahres 1970 entwickelt wurde, ist froh, wenn er eine "1" für das Geschlecht angezeigt bekommt; den Text "männlich" würde er bestimmt nicht erwarten.

• Ein Space Shuttle wäre eine Kugel von 50 Meter Durchmesser, wenn die Umpolung der Schwerkraft schon erfunden wäre.

Genauso hat ein Hauptspeicher von 12 KB, den der Autor in seinem ersten Mainframe, einer IBM 360/20, vorfand, oder auch die Notwendigkeit, den Online-Dialog über CICS abzuwickeln, dramatische Auswirkungen auf das Softwaredesign und die Anwendung selbst. Im Software-Engineering gilt also "Technology Drives Design". Aber dessen ist sich der Softwareingenieur selten bewusst, wenn er eine Anwendung entwickelt.

Auch Frameworks veralten irgendwann

Die vergangenen acht Jahre waren beherrscht vom Framework-Hype. Die Idee stammt eigentlich aus der Steinzeit: Lege alles in eine Ecke deiner Höhle, was du bei deiner Arbeit vielleicht einmal brauchen könntest, also Sehnen, Knochen, einen spitzen Stein etc. Wenn dann das Steinbeil bricht oder der Feuerbohrer nicht mehr funktioniert, findest dort vielleicht etwas, das dir hilft.

So alt die Idee auch ist - eigentlich ist sie immer noch ausgezeichnet. Aber wenn man beobachtet, wie Framework auf Framework gepackt und das Ganze mit wieder anderen Frameworks kombiniert wird, kann einem schon angst und bange werden. Die Softwareingenieure müssen aufpassen, dass sie nicht in die Falle ihrer Väter tappen. (Siehe dazu auch: "Ist Java das neue Cobol?") Denn der Feind des Guten ist das Bessere: Auch Frameworks veralten. In zehn Jahren werden die Frameworks von heute Geschichte sein. Und wie bitte soll dann der wirtschaftlich relevante Teil der Anwendungssysteme gerettet werden?

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.

Fazit

Angesichts vieler Milliarden Codezeilen, die weltweit im Einsatz sind, tut eine IT-Modernisierung not. Diesen Prozess zu automatisieren ist eine enorme Herausforderung, weil komplexe - nicht nur technische, sondern auch semantische - Transformationen bewältigt werden müssen. Deshalb sollte künftig schon das Software-Engineering Sorge tragen, dass die spätere IT-Modernisierung wirtschaftlicher und einfacher wird. (qua)