Es Ist nicht alles Gold, was so genannt wird - zuviel liegt auch im Bereich der vierten Generation noch im argen. Teils weil die Entwickler auf der Basis einer "angegriffenen Gesundheit der dritten Generation operierten. teils weil auch heute noch "Schnellschüsse" ein Stück des Umsatzkuchens sichern sollen. Josef Kraus zieht (bissige) Bilanz.

"Stellt sich die Frage nach dieser Generation überhaupt?", möchte man provokativ fragen. Kann sie als definiert gelten, nach der Feststellung, sie läge zwischen der 3. und der 5. Softwaregeneration?

Die Forderungen nach der 4. Generation entstanden aus dem Bedürfnis, mit dem betriebswirtschaftlichen Unternehmensfaktor "Information" auch effizient im Unternehmen umgehen zu können. Dabei war zwar der Wert der Information an sich erkannt, nicht aber qualitativ definierbar. Die Problematik, Informationen entsprechend den Anforderungen innerhalb einer Organisation bereitzustellen, zu verwalten, zu verteilen und zu sammeln, führte zu übermäßigen Belastungen der DV-Abteilung. Die entsprechenden Spezialisten auf dem Markt waren gesucht und alsbald vergriffen.

Die Auswirkung: Anforderungen an die DV der Firma konnten aus Kapazitätsgründen, und weil vorhandene "Manpower" mit der Wartung bestehender Systeme gebunden war, nicht rechtzeitig oder nie realisiert werden. Man mußte zweierlei Forderungen aus dieser Tatsache ableiten: Es gibt einen Bedarf nach möglichst schneller Realisierung anstehender Applikationsanforderungen. Der Ruf nach sogenannten "VHLL" (very high level languages) wurde laut. Das, so meinte man, wäre der "Stein der Weisen": schneller mit weniger Entwicklern Anwendungssysteme zu erstellen. Bald jedoch folgte die ernüchternde Erkenntnis: Das Problem, erhebliche Entwicklerkapazitäten mit der Wartung bestehender Systeme zu binden, existierte immer noch.

Die Lösung: Von strukturierte Sprachen, die ohne die notwendige Betriebssystem- und TP-Monitor-Kenntnisse zur Problemlösung benutzt werden konnten.

Was lag näher, als diese Sprachebene weiter auszubauen und den ständigen Forderungen aus den Fachabteilungen so einen Riegel vorzuschieben. Man präsentierte den verdutzten Sachbearbeitern eine

VVHLL (very very high level language) mit der jeder, auch der DV-Unerfahrene, zuruchtkommen könnte: die Endbenutzersprachen.

Fazit: Der Endbenutzer kam nicht mit diesen Sprachgebilden zurecht, die nicht einmal annähernd die Syntax natürlicher Sprachen erreichten. Schlimmer noch: Das Problem des Anwendungsstaus wurde größer statt kleiner. Man hatte zuviel versprochen und Wunder erwartet.

Die zweite, der Sprachebene an Relevanz in der DV-Umgebung mindestens gleichwertige Komponente, war außer acht gelassen worden: die Datenbasis mit flexibler und gleichzeitig stabiler Struktur.

Was nutzten die schönsten Sprachen auf alten Datenorganisationsformen, die niemals für die Verwendung im Informationsverarbeitungszeitalter konzipiert waren? - Bei jeder neu projektierten Applikation, die beim ursprünglichen Design dieser Datenstrukturen noch nicht in Betracht gezogen worden war, verlangten diese Instrumente nun ihren Tribut an Zeit und Anpassungsaufwand an die neuen Gegebenheiten.

Also können 4th Generation Languages nicht die hohen Erwartungen, die in sie gesetzt werden, erfüllen? Genauso ist es; zumindest nicht mittel- und langfristig. Sicher bringen sie zunächst eine Produktivitätssteigerung in der Programmentwicklung, verhalten sich jedoch in ihrer Effizienzkurve ähnlich wie Cobol PL/1 und andere "höhere Programmiersprachen ".

Man betreibt mit ihnen Symptom-, nicht er Ursachenbekäpfung.

Das Datenmodell, das heute in der Lage ist Daten in beliebiger Zusammensetzung, Folge und Selektion ohne vorherige Planungsmaßnahmen zur Verfügung zu stellen, ist das Relationenmodell.

Erkannt - gemacht.

Aber wie!

Bei den wichtigsten DV-Anbietern hatte man niemals zuvor eine solche integrierte Umgebung auch nur diskutiert. Die Ergebnisse waren entsprechend:

- relationale DBMS mit Seitenblick auf die Vergangenheit (multiple Felder, Periodengruppen und so fort).

- relationale Systeme ohne relationale Umgebung, ohne Data-Dictionary . . .

- relationale Oberflächen ohne entsprechenden Unterbau (relationale DBMS auf der Basis interner Codasyl- oder anderer "alter" DO-Strukturen . . .) und so weiter und so weiter.

Das Ziel aber war vorgegeben und wurde für die Anbieter sehr schnell zur existentiellen Forderung: Informationsverarbeitung statt wie bisher Datenverarbeitung.

Aber schon tauchte ein neues Problem auf: Alle Unternehmensdaten, mit der Möglichkeit beliebiger Zusammenstellung und Verdichtung für alle Benutzer? - Ohne Kontrolle und Dokumentation der gesamten Datenstruktur durch ein Data-Dictionary? - Sehr gefährlich, und aus der Vergangenheit als äußerst negative Erfahrung präsent.

Der erste Schritt zur Informationsverarbeitung aber ist die Möglichkeit, strategische Maßnahmen planen zu können, die beim Einsatz von Software für die Zukunft eines Unternehmens maßgeblich und wichtig sind.

Dies bedingt ein Konzept "konfigurierbarer" Software. Und dann kann eine 4. Softwaregeneration nur auf der Basis einer gesunden 3. Sofwaregeneration existieren.

Es gibt nur wenige etablierte Software-Anbieter, die diese Konzeption über Jahre geplant und schließlich realisiert haben.

*Josef Kraus, Leiter Marketing Central Europe der ADR Applied Data Research (Deutschland) GmbH, Düsseldorf.