Der Einsatz neuer Methoden in der kommerziellen Datenverarbeitung ist notwendig. Ob diese Methoden nun unter der Bezeichnung Software der vierten Generation oder Software der fünften Generation oder welcher Generation auch immer laufen, ist im Prinzip nebensächlich. Die benötigten Werkzeuge müssen bestimmte Funktionen und Anforderungen an ein System erfüllen, um die gestellten Aufgaben in der kommerziellen Datenverarbeitung lösen zu können.

Die Software der 4. Generation hat beim DV-Fachmann dann Akzeptanzprobleme, wenn diese Software non-prozedural ist, und zwar deshalb, weil sie dem DV-Fachmann tatsächlich nicht hilft. Aus diesem Grund ist ein wesentliches Kriterium für eine vernünftige Software der 4. Generation eine prozedurale Mächtigkeit, um es dem Unternehmen zu ermöglichen, alle Anwendungen, die mit Cobol programmiert werden können, auch mit diesem neuen Tool zu programmieren. Hier liegt ein Plus in der größeren Produktivität und Wartungsfreundlichkeit, um nur zwei wesentliche Vorteile der Software der 4. Generation zu nennen.

Zu Beginn der kommerziellen Datenverarbeitung erwartete man von den Computern, daß sie alle Probleme im geschäftlichen Bereich schnell und effizient lösen könnten. Sicherlich haben die Computer in dieser Beziehung enorme Hilfe gebracht; dies hat aber einen wesentlich längeren Zeitraum in Anspruch genommen, als allgemein erwartet wurde.

Die enormen Fortschritte in der Softwaretechnologie, insbesondere der Sprachen beziehungsweise Tools der 4. Generation, haben zusammen mit verbesserten Managementmethoden und größeren Budgets die DV-Situation einigermaßen stabilisiert.

In einer Vielzahl von Studien wurde auch sehr eindrucksvoll dargestellt, daß nur diejenigen Unternehmen in dem immer härter werdenden Wettbewerbsmarkt erfolgreich bestehen können, die modernste und fortschrittliche Methoden, Werkzeuge und Technologien für ihre DV-Problemlösung einsetzen.

Aus diesem Sachverhalt läßt sich folgende Ausgangs-These ableiten:

These 1:

Effiziente und kostengünstige Problemlösungen von heute und morgen sind mit den Methoden, den Werkzeugen und den Technologien von gestern nicht machbar.

Die vielen Einzelprobleme aus der Praxis sprechen eine deutliche Sprache:

- Zu hohe Komplexität der Anwendungslösung, wobei oftmals nicht das Problem selbst komplex ist, sondern erst durch eine unzulängliche Problemlösung komplex wird.

- Verschiedene inkompatible Hardware- und Softwarekomponenten, die quasi als Fremdkörper in einem Gesamtsystem wirken.

- Zu geringe Produktivität des DV-Personals und der Endbenutzer wodurch hauptsächlich der sogenannte Anwendungsstau entsteht.

- Singuläre Lösungen, die keine firmenübergreifende Informationsverarbeitung ermöglichen.

- Geringer Systemdurchsatz (sowohl systemintern als auch an der Benutzerschnittstelle) .

- Ungünstiges Preis/Leistungs-Verhältnis der Gesamtlösung (eine Teiloptimierung einer Systemkomponente ist möglich, nicht aber der Gesamtlösung).

- Technologiewechsel in immer schneller werdenden Zeitzyklen.

- Veraltete Denkmentalität (hardware-orientiert anstatt anwendungs- und softwareorientiert).

Selbst wenn sich eines oder auch mehrere der angeführten Einzelprobleme lösen lassen, fehlt mit dem Integrationsdefizit die entscheidende Qualität einer modernen, integrierten Informationsverarbeitung.

Dies ist um so tragischer, als sich die Experten einig sind, daß "Information" bereits heute als "neuer Rohstoff" gilt und damit als "Produktionsfaktor" zu berücksichtigen ist.

Aus diesen Einzelproblemen leitet sich als Hauptproblematik folgende These ab:

These 2:

Bei der oftmals üblichen Schnittstellenadaption von singulären Anwendungslösungen ist eine vollständige Integration des Gesamtsystems zur integrierten Informationsverarbeitung nicht möglich.

Wie muß denn nun eine vollständige Integration des Gesamtsystems aussehen? Die Auswirkungen der integrierten Informationsverarbeitung umfaßt alle DV-Ebenen (= vertikale Integration):

- Strategische DV-Ebene

Firmenübergreifende Informationsverarbeitung mit einem Großrechner auf einem zentralen Datenpool.

- Taktische DV-Ebene

Bereichsübergreifende Informationsverarbeitung mit mittelgroßen Rechnern auf einer dezentralen Datenmenge oder auf einem zentralen Datenpool.

- Lokale DV-Ebene

Informationsverarbeitung durch Endbenutzer mit kleinen Rechnern (leistungsfähige Mikros) auf einer dezentralen Datenmenge oder auf einem zentralen Datenpool.

Ein technologisch und ökonomisch zukunftsorientierter Lösungsansatz ist nicht mit einer Schnittstellenadaption, sondern nur mit einem vollständigen Software-Integrations

Konzept (= horizontale Integration) möglich.

Die Architektur selbst muß also das entscheidende Merkmal der vollständigen Integration aufweisen. Hierbei ist für alle Arten von Benutzer (vom DV-Profi bis hin zum DV-Neuling) die "gleiche logische Benutzersicht" der Daten in "Form von Relationen" von entscheidendem Vorteil. Die Benutzer beschreiben ihre Daten nicht mahr auf einer physischen Speicherstruktur, sondern auf einer logischen, abstrakten Ebene, die den gewünschten Ausschnitt der Realität widerspiegelt. Damit sieht der Benutzer die Daten so, wie er sie aus der Realität kennt und auch versteht.

Neben dem großen Vorteil einer für alle Systembenutzer einheitlichen, relationalen logischen Benutzersicht ist die Qualität der Beschreibung und der integrierten Kontrolle der Daten von entscheidender Bedeutung.

Dieses notwendige Qualitätsmerkmal bieten nur die integrierten Datenbanksystem-Konzepte der neuen Generation, bei denen ein "Inline-Directory" für eine integrierte Steuerung und Kontrolle auch während der Verarbeitungsphase von Programmen sorgt.

These 3:

Eine kostenmäßig effiziente und technologisch zukunftsorientierte Problemlösung ist nur mit einem architektonischen Integrationskonzept möglich.

Daraus folgt organisatorisch, ökonomisch und technologisch eine Anwendungs-Integrations-Lösung mit dem Software-Integrations-Konzept:

- Information Center Concept (ICC)

- Decision Support Center Concept (DSC)

- Development Center Concept (DCC)

- Production Center Concept (PCC).

Die Entwicklung von längerfristig einzusetzender Anwendungssoftware kann auf einem leistungsmäßig mittelgroßen bis großen Hostrechner oder nur an einigen wenigen, dedizierten Systemen (DDP) durchgeführt werden. Die Informationsverarbeitung entspricht hierbei der strategischen und/oder der taktischen DV-Ebene.

Natürlich läßt sich auch die Entwicklung von kurzfristiger Anwendungssoftware (zum Beispiel die sogenannten Tages- oder Wegwerfprogramme) an leistungsfähigen Mikrosystemen vor Ort durchführen, wobei dann die Informationsverarbeitung nur noch der taktischen und/ oder lokalen DV-Ebene entspricht.

Die semantisch korrekten und leistungsmäßig effizienten Umsetzungen von Anwendungslösungen mit hoher Produktivität sind nur mit Sprachen beziehungsweise Software-Entwicklungssystemen der 4. Generation erreichbar, wobei ein "Rapid Prototyping" für die Entwicklung und den Test von Anwendungen eine elementare Voraussetzung ist. Moderne Entscheidungshilfen, wie zum Beispiel "What-if"-Fragemöglichkeit, sind ebenfalls Bestandteil dieses Konzepts.

Ein Software-Entwicklungssystem der 4. Generation sollte verschiedene Anforderungen erfüllen.

Ein Inline-Directory zur Steuerung des gesamten Systems empfiehlt sich, so daß keine Aktionen ohne dieses Directory (bei der 3. Generation spricht man noch von "Data Dictionary") möglich sind. Zugriffsregelungen für Read/Write/Update bis auf Feldebene (Domains) müssen definierbar sein.

Ein Relationales Datenbanksystem sollte vorhanden sein, welches sowohl für die Online-Abfragen als auch für die Verarbeitung von Massendaten (Bildung von Strukturen) geeignet ist, ebenso eine 24-stündige Verfügbarkeit (Sicherung im Tagesablauf) mit ausreichenden Recovery- und Restart-Möglichkeiten.

Die Portabilität der Software (System und Anwendungen) ist wichtig. Die mit diesem Software-Entwicklungssystem entwickelten Anwendungen sollten portabel sein zwischen DOS-, VM/CMS- und MVS/ XA-Systemen. Zusätzlich zu dieser IBM-inneren Portabilität sollte es möglich sein, die Anwendungen auch auf DEC/VAX- und Wang/VS-Anlagen zu portieren, um eine unternehmensweite Softwareportabilität für die am weitesten verbreiteten Hardwareprodukte zu bieten.

Online- und Batch-Anwendungen (einschließlich Update) müssen konkurrent ablaufen können.

Eine Update-Möglichkeit in der Abfrage und Hochsprache unter Gewährleistung der Datenintegrität

(Löschungen mit Berücksichtigung von Fehlinhalten anderer Relationen) gehört ebenfalls in Entwicklungssysteme dieser Generation. Die Möglichkeit eines Gruppen-Updates sollte vorhanden sein.

Der Zugriff auf andere Datei-Organisationsformen wie VSAM, BDAM und QSAM ist gefragt. Auch die Verbindungsmöglichkeit (JOIN) von Datenelementen, die in unterschiedlichen Relationen (Dateien und Datenbanken) gespeichert sind, wird gefordert. Dual-Logging/Recovery für besonders sensitive Anwendungen steht auf der Wunschliste.

Ausreichend mächtige Hochsprache mit einer CALL-Schnittstelle zu anderen Programmiersprachen gehören zum Katalog; Elemente strukturierter Programmierung sowie Syntaxprüfungen sollten enthalten sein. Diese Hochsprache muß es dem Unternehmen ermöglichen, alle Anwendungen, von einfachen bis komplexen, sowohl im kommerziellen als auch im technisch-wissenschaftlichen Bereich zu programmieren, was per Definition mit non-prozeduralen Sprachen nicht möglich sein kann.

Eine Abfragesprache mit Einbindung der Datenmanipulationssprache (DML) ist wichtig. Eine weitere Verarbeitung auf Basis bereits selektierter Daten muß möglich sein.

Und letztlich ist ein Report-Generator für standardisierte und individuell gestaltbare Bereiche vonnöten.

KIaus Amann ist Geschäftsführer der Cincom

Systems GmbH & Co. oHG, Frankfurt.