Früher schrieb man Programme - und war froh, wenn sie endlich, meist ohnehin zu spät, dann liefen. Automation von Massenarbeiten rechtfertigte die Kosten. Sollte doch die Revision selber sehen, wie sie das prüfen konnte. Datensicherheit oder gar Datenschutz waren noch nicht als Problem erkannt. Das Ziel war "Effizienz": Minimierung des Hauptspeicher-Bedarfs, Minimierung der Laufzeiten, Minimierung der restlichen Ressourcen. Schließlich war man so ausgebildet. Schließlich war EDV nicht gerade billig. Der Rest (Sicherheit, Prüfbarkeit, Portabilität, Adaptabilität) galt als Komfort, auf den man leider, leider verzichten mußte: Aus Sicht der Gesamtunternehmung war das Subsystem-Optimierung. Aber die anderen Abteilungen - und firmenextern die anderen Kollegen - machten es ebenso. Früher? Oder noch heute?

Bei der Hardware haben wir längst die dritte Generation, vielleich schon die dreisiebenachtelste. Bei der Anwendungs-Software wäre die zweite Generation: Höhere Sprachen, Standardisierung mit Makros und im Fall der kommerziellen, sequentiellen Stapelverarbeitung die normierte Programmierung. Die dritte Generation hieße: Strukturierte Programmierung, Top-down-Modularisierung, Chief-Programmer, Team-Konzept, unterstützt durch Software-Tools, möglichst interaktiv. Damit kündigt sich bereits die vierte Software-Generation an.

Aber es geht nicht nur darum, wie man programmiert (für welche Art von Maschinen), sondern mehr noch darum, was man programmiert. Von dritter oder gar vierter Generation in der Phase des System-Designs kann in der Praxis heute wohl kaum die Rede sein. Früher (früher?) entwarf man Programme, die. . . wie oben dargestellt. Hauptsache, sie schafften den Job. Ein Generationensprung - wenn man sich an das von der Hardware-Entwicklung vorgegebene Muster hält - war die Einbeziehung abteilungs-/anwendungsübergreifender Aspekte unter dem Schlagwort "integrierte Datenverarbeitung" und auch eine kritische Prüfung der Wirtschaftlichkeit. Maxime: Rationalisierung für die Gesamt-Unternehmung. Weniger die bisherige verbilligte Automation der Massenarbeiten, sondern zusätzlich erhöhte Auskunftsbereitschaft, Entscheidungshilfen für das Management - und damit auch neue Kriterien für die Wirtschaftlichkeits-Betrachtung, insbesondere bei stark gesunkenen Hardware-Preisen. Soweit ist man heute - zumindest bei den großen Installationen: Zweite Generation beim System-Design.

Und wie sähe die dritte Generation aus? Ebenso und zusätzlich wären a priori bereits bei System-Design neuer Anwendungen vier Aspekte zu beachten: Ordnungsmäßigkeit, Sicherheit, Prüfbarkeit und fernere Auswirkungen auf das Verhalten der Mitarbeiter - etwa ergonometrische Aspekte bei Online-Anwendungen oder Vorausschau auf mögliche Widerstände gegen neue Verfahren und entsprechendes rechtzeitiges Gegensteuern.

In der System-Design-Phase wäre nicht nur der Informationsfluß zu organisieren, sondern auch Prüfpfade und Risikostrecken zu beachten - und zwar von vornherein, denn das Reparieren hinterher kommt teurer.