WASHINGTON (je) - "Im März 1978 wurde mir die Aufgabe zugeteilt, als Datenbank-Administrator sicherzustellen, daß Auswahl und Installation eines Datenbanksystems mit einem Minimum von Problemen zu erreichen sei." So schildert Daniel A. Nolan vom amerikanischen Luftfahrtministerium den Beginn des Vorhabens, diese als entbehrlich befundene Behörde in geordnetem Rückzug aufzulösen. Seine auf dem Houstoner Software AG-Anwendertreff vom Juni dieses Jahres angestellte Retrospektive kommt zu der Erkenntnis, eine bessere Auswahl als die von Adabas und Natural habe nicht getroffen werden können, "obwohl wir nicht alle gefundenen Ergebnisse für unfehlbar halten".
Der 1978 in Kraft getretene "Airline Deregulation Act", ein Gesetz zur Verminderung der staatlichen Kontrolle über Luftfahrtgesellschaften, sah unter anderem vor, daß das zuständige Ministerium, der "Civil Aeronautics Board" (CAB), bis 1985 aufzulösen sei. Die bisher vom CAB wahrgenommenen Funktionen sollten zum Teil von anderen Regierungsstellen übernommen werden.
Damit stellte sich die Aufgabe, alle Aktivitäten zu dokumentieren und die verfügbaren Daten in aufbereiteter Form an die anderen Dienststellen zu übergeben. Die Verantwortung für das Gelingen dieses Vorhabens wurde Dan Nolan übertragen. Nolan, ein DV-Fachmann der ersten Garnitur, hat im Verlauf früherer Arbeiten bereits Anwendungssysteme implementiert für Versicherungen, Banken, Werbung, Schulung, Produktionsprozesse und Verwaltungen.
Er hält Vorlesungen für Datenverarbeitung an der "Graduate School USDA". In bisherigen Anwendungs-Implementierungen war Nolan ein Verfechter der Strukturierten Programmierung. Für die Zukunft hat er sich vorgenommen, die Methode des "heuristischen Entwicklungsprozesses" in praktischer Anwendung zu verfeinern. Über die einzelnen Vorgänge bei der DV-gestützten Amtsauflösung berichtet Nolan im folgenden.
Die Planung für einen kontrollierten Abschluß der Arbeit des CAB startete 1978. Als wesentliches Problem für die Zukunft stellte sich die Verfügbarkeit qualifizierter Mitarbeiter dar. Wegen fehlender Zukunftsaussichten war zu erwarten, daß Neueinstellungen gestoppt und dem Ersatz ausscheidender Mitarbeiter nur unwillig zugestimmt würde.
Personalnöte aller Art
Mitarbeiter, die dennoch neu gewonnen werden könnten, würden keine oder nur minimale Schulung erhalten können. Es mußte von ihnen erwartet werden, daß sie sofort produktiv arbeiten konnten. Daneben sah man sich mit dem Problem konfrontiert, daß neben der laufenden Arbeit mit weniger Personal noch zusätzliche Dokumentationsarbeit für die kontrollierte Schließung des CAB anfallen würde.
Trotz und wegen der bevorstehenden Schließung des CAB wurde 1978 entschieden, ein Datenbankverwaltungs-System einzusetzen. DBMS-Systeme gelten allgemein als der letzte Stand der Software-Technologie. Unglücklicherweise haben sie den Ruf, daß es schwer ist, das richtige System zu wählen und zu installieren.
Für das Auswahlverfahren wurde ein Plan aufgestellt:
- Entwicklung eines Konzeptes und Erlangung der formalen Zustimmung durch das Management.
- Ermittlung der Benutzer-Anforderungen zur Festlegung der absoluten, nicht der theoretischen, Bedürfnisse.
- Sammeln von Hersteller-Informationsmaterial.
- Vergleich der vom Hersteller beschriebenen Funktionen mit den Benutzer-Anforderungen. Wenn notwendig, Einholen von Hersteller-Detailinformation.
- Eliminierung der Hersteller, die den Anforderungen nicht genügen konnten.
- Auswahl des Herstellers, der die gestellten Anforderungen am besten und mit den geringsten Problemen erfüllen kann.
Definition der Umgebung
Während der ersten drei Monate (März - Mai 1978) wurde die Arbeitsumgebung festgelegt. Ergebnis: Gegenüber der Arbeit ohne DBMS waren keine wesentlichen Veränderungen möglich. Die verfügbare 2MB-/370-155 mit 3330-11 Platten, 1600 bpi-Bändern und 3270-kompatiblen Terminals sollte nicht erweitert werden. Für den TP-Betrieb war CICS im Einsatz mit Roscoe (von ADR) als Interface von TP zu Batch. Das neue DBMS mußte zusammen mit existierenden Systemen ohne gegenseitige Beeinflussung betrieben werden können. Eine Vergrößerung des Mitarbeiterstabes von zwei Dutzend Leuten war nicht möglich.
Die Einführung des DBMS mußte ohne umfangreiche Programmierung über die Bühne gehen. Das DBMS mußte einen möglichst vollständigen Satz von Werkzeugen als Standard bieten. Die Implementierung neuer Anwendungen sollte innerhalb einer Woche möglich sein. In diesem Zeitraum war Konzeptentwurf, Entwicklung, Installation und sogar Schulung der Endbenutzer eingeschlossen. Danach sollte die neue Anwendung vollständig an die Endbenutzer unter eigene Kontrolle übergeben werden. Diese waren damit verantwortlich für Fehlerbeseitigung, Datenintegrität und Erzeugung von Ad hoc-Reports.
Wie in den meisten Installationen bestand auch beim CAB ein Zeitverzug von zwei Wochen bis zu sechs Monaten zwischen einer Benutzeranforderung und der Lieferung der fertigen Anwendung. Man konnte beobachten, daß die Zahl der Probleme mit einem Anwendungssystem mit der Dauer der Implementierung anstieg. Diese Beobachtung führte zu dem absurden Schluß: Man verkürze die Dauer der Implementierung und vermindere damit die Zahl der Probleme.
"Leeres Blatt" als Ansatz
Um noch einmal die Regeln klarzulegen: Es gab keine Standards. Punktum. Strukturierte Programmierung? Nein! Entwicklungsteams? Nein! Aber es gab die Chance, daß man das CAB als "leeres Blatt" benutzen konnte und daß das Fehlen von konventionellen Methoden die Möglichkeit bieten würde, mit einem völlig neuen Ansatz zum Erfolg zu kommen.
Mit dem unverrückbaren Endtermin von 1985 und nur einem Dutzend Programmierern war klar, daß nur wenige Anwendungssysteme von Null bis zur Produktion würden erstellt werden können, bevor die "Lichter ausgingen". Um einen Überschlag für die zu erreichende Implementierungszeit zu bekommen, wurde die Anzahl der "angeforderten" Anwendungen der letzten sechs Monate mit der Zahl der "freien" Programmierer in Beziehung gebracht, mit dem Ergebnis von einer Woche pro Anwendung.
Im Verlauf der Definition des idealen DBMS für CAB wurden 18 der zuletzt implementierten Anwendungen in bezug auf ihren Erfolg beim Endanwender und eine Implementierung mit einem DBMS untersucht. Da es keine Standards gab, konnten keine Ähnlichkeiten zwischen den einzelnen Systemen erwartet werden. Jedes System war "einzig", als ob es auf einem anderen Planeten geschrieben wurde.
Idealkonzept als Meßlatte
Sieben DBMS-Systeme verschiedener Hersteller wurden in die Evaluation einbezogen. Jedes DBMS wurde gegen die Anforderungen des "idealen" DBMS bewertet. Die Anforderungen an das "ideale" DBMS waren folgendermaßen definiert:
- eine einfache Datendefinitionssprache (DDL) ermöglicht den kurzfristigen Aufbau neuer Dateien;
- ein Ladeprogramm erlaubt es, eine DBMS-Datei direkt von einer sequentiellen Datei zu laden, wenn die Definition in DDL formuliert ist;
- Cobol-Programme können vom Standard-Ladeprogramm als Exit aufgerufen werden, um Datenbereinigungen durchführen zu können;
- absolute Sicherheit, daß keine Daten in der Datenbank gespeichert werden können, die nicht dem angegebenen Format entsprechen;
- integrierter Daten-Diktionär, der von der DDL gesteuert wird und alle Programme, die auf die Datenbank zugreifen, mit der Datendefinition versorgt;
- keine "Reorganisation";
- Möglichkeit, den Feldaufbau einer Datei erweitern zu können, ohne die Datei neu laden oder Benutzerprogramme ändern zu müssen;
- Möglichkeit, dieselben Daten mit verschiedenen "User views" verarbeiten zu können;
- eine Abfragesprache, die direkt die Definitionen des Daten-Diktionärs benutzt und Abfragen in einer "Prosa"-Sprache erlaubt; Abfragen sollten dabei für eine spätere Benutzung gespeichert werden können.
- eine interaktive Programmiersprache, die nicht nur Abfragen erlaubt, sondern echte Verarbeitung mit der Möglichkeit, Daten in der Datenbank zu verändern oder neu aufzunehmen; dabei sollten keine Cobol-Unterprogramme nötig sein
- Datenschutz auf Dateiebene und Feldebene mit der Möglichkeit, bestimmte Felder zu schützen, wenn sie bestimmte Daten enthalten;
- automatische Datensicherung mit Restart-Möglichkeit, die auch von der internen Programmiersprache unterstützt wird.
Für die Anbieter wurden die oben beschriebenen Funktionen klar beschrieben. Als letzte Bedingung wurde gefordert, daß sechs der wichtigsten Anwendungen als Benchmark zu implementieren waren. Diese Anforderung verschreckte drei der sieben Anbieter, so daß sie es vorzogen, von weiteren Aktivitäten abzusehen. Für jedes angebotene DBMS wurden technische Gespräche mit dem Anbieter und Benutzern des Systems geführt.
Informant aus erster Hand: der Hintergrund-Mitarbeiter
Danach wurden die vergleichenden Ergebnisse den Anbietern vorgelegt. Es stellte sich heraus, daß diese jeweils schnell bei der Hand waren, eventuell fehlende Funktionen als "in der Entwicklung befindlich" anzubieten. Jede dieser Aussagen wurde überprüft und nur ignoriert, wenn keine Anzeichen für eine echte Entwicklung zu erkennen waren.
Folgende Quellen wurden ausgeschöpft, um Informationen über den Anbieter und das DBMS zu erhalten:
- Marketing-Präsentationen;
- Gespräche mit technischen Mitarbeitern, um herauszufinden, wie ein bestimmtes Anwendungsproblem (dasselbe für alle) gelöst werden sollte
- Gespräche mit anderen Benutzern, wobei sowohl die "politische" Situation bewertet wurde wie auch der gemachte Fortschritt und die Zufriedenheit;
- Besuch bei Benutzern ohne Begleitung durch Verkäufer;
- Technische Dokumentation;
- Besuch einführender Schulungskurse;
- Besuch von Benutzergruppentreffen;
- Besuch des Firmensitzes. Bei diesen Gelegenheiten lieferte ein Gespräch mit einem der Mitarbeiter aus dem Hintergrund manchmal mehr Information als das mit den Managern.
Die Auswertung aller verfügbarer Information dauerte von Juni bis August 1978. Bereits in der theoretischen Bewertung - gemessen an unseren Anforderungen - konnte Adabas, das Datenbankverwaltungs-System der Darmstädter Software AG, einen Vorsprung vor den Mitbewerbern erreichen.
Es zeigte sich, daß die "Designer"-orientierten Systeme für die tatsächlichen Anforderungen wesentlich weniger Vorteile zu bieten hatten als "Benutzer"-orientierte Systeme, die die "Mechanik" des Systems durch geeignete Werkzeuge in den Hintergrund drängen konnten. Als letzter Schritt der Evaluation stand die praktische Erprobung aus. Eine Präsentation der sechs ausgewählten Anwendungen mit dem ausgewählten DBMS wurde für Mitte November angesetzt.
Ein Techniker des Herstellers installierte das System in etwas mehr als einem Tag. Der Aufwand, zusätzlich zum Systemprogrammierer und dem DBA für jede der zu implementierenden Anwendungen einen Programmierer abzustellen, erwies sich als unnötig. Obwohl die Zahl der Programmierer von acht auf drei reduziert wurde, konnten wir nach zwei Wochen wie geplant die fertigen Anwendungen den Benutzern mit ihren eigenen Daten "online" vorführen.
Als letzte Komponente des Systems wurde Software AGs "Natural, language for instant online applications" im Juni 1979 installiert. Nach den Anfangsschwierigkeiten, wie man sie von einem brandneuen Produkt erwarten konnte, fingen wir an uns in die neuen Möglichkeiten einzuarbeiten. Da wir die ersten Anwender von Natural waren, konnten wir auf keinerlei Erfahrung zurückgreifen.
Natural ist ein interaktives System für Programmierung, Maskengenerierung, Compilierung und interaktiven Test, welches integriert mit dem Daten-Diktionär, eigenem Editor und einer "datengetriebenen" Programmiersprache alle Funktionen des DBMS zur Verfügung stellt.
Die erste Mitarbeiterin, die wir mit Natural konfrontierten, war eine Werkstudentin mit fast keinerlei Erfahrung. Nach drei Stunden konnten wir sie alleine am Terminal arbeiten lassen, ohne daß sie sich in schwierigen Fehlern verfing, und nach sechs Stunden mußten wir sie vom Terminal regelrecht wegzerren, da ihr Programm fertiggestellt war.
Nach diesem Erfolg dachten wir, daß unsere Programmierer folglich noch wesentlich schneller mit Natural umgehen könnten. Unglücklicherweise unterlief uns dabei der Fehler, Natural mit konventionellen Programmiersprachen zu vergleichen, und so gerieten wir auf den falschen Weg. Es dauerte ungefähr zwei Wochen, bis die Programmierer bereit waren, all die komplizierten Werkzeuge, die sie zu beherrschen gelernt hatten, zu vergessen und in Natural zu denken.
Natural ist kein Super-Cobol. Cobol erfordert Dateizugriffssteuerung und Logik zur Kontrolle der Daten und des Programmflusses. Natural hat diese Funktionen in der Sprache integriert, und jeder Versuch, gewaltsam eine cobolartige Logik in das Programm zu bringen, resultiert in umständlichen, aufwendigen Programmen.
Ein besserer Ansatz, um Natural zu beschreiben, ist der Vergleich mit leistungsfähigen Editorsystemen wie TSO oder Roscoe. Im Vergleich zu ihnen bietet Natural eher eine Erweiterung der Funktionen als - wie im Vergleich zu Cobol - völlig andere Funktionen. Natural compiliert jedes Programm Zeile für Zeile zu ausführbarem Code. Jeder Fehler wird sofort gemeldet.
Wenn beispielsweise ein Feld aus der Datenbank falsch verwendet wurde, wird die fehlerhafte Zeile zur Korrektur angezeigt. Wenn der Programmierer in dieser Zeile keine Korrektur anbringt, wird automatisch der Editor aufgerufen zur Anbringung von Korrekturen in anderen Zeilen. Der Programmierer kann mit der Erzeugung seines Programmes erst fortfahren, wenn der Fehler korrigiert ist.
Natural benutzt für den Datenzugriff die mit Adabas verfügbaren Funktionen. Damit ist eine direkte Datenselektion auf Feldebene ohne Datendefinition im Programm möglich. Die Verarbeitung wird weitgehend automatisch von den Daten gesteuert. AT START/END OF DATA (Beginn/ Ende Verarbeitung), AT BREAK (Gruppenwechsel), AT TOP/END PAGE (Seitenanfang/Ende) etc. sind Standardbedingungen für die Steuerung von Anweisungen.
Natural benötigt keine künstlichen Standards, um eine strukturierte Programmierung zu erreichen. Es ist in der Tat schwieriger, die vorgegebene Programmstruktur in Natural zu umgehen, als ihr zu folgen. Insgesamt bietet Natural Adabas die Funktionen eines ganzen Programmiererteams bestehend aus Ein/Ausgabe-Spezialist, Dateiverwalter, Bibliotheksverwalter, Maskengenerierungs-Spezialist und einem Teamführer, der bestimmte Standards festlegt.
Es ist alles vorhanden bis auf den Anwendungsprogrammierer; und für diesen wird auch noch wesentliche Arbeit eingespart: Ein Cobol-Programm von 2000 Zeilen kann mit rund 200 Zeilen Natural-Code gleichwertig formuliert werden. Für erfahrene Programmierer stellte sich anfangs das Problem, daß sie alte "Gewohnheiten" aufgeben mußten. Programmierung, ausgehend von "Flowcharts", ist kaum möglich, wohingegen die Programmierung nach dem Konzept strukturierter Programmierung wie HIPO oder Top-Down gute Ergebnisse liefert.
Benutzeranforderungen heuristisch ermittelt
Ein Umdenken war auch erforderlich in bezug auf den "Entwicklungszyklus". Eine Vorgehensweise: zuerst vollständiges Design, danach Programmierung, danach Installation und Training war einfach nicht flexibel genug, um den Anforderungen der Benutzer und Programmierer gerecht zu werden. Es erwies sich, daß es mit den gegebenen Möglichkeiten wesentlich effektiver war, eine "heuristische" Entwicklung durchzuführen, die mit dem Design und dem Einrichten von Testdatenbeständen begann und dann sofort überging in die Einarbeitung der Endbenutzer, während parallel Programme erstellt wurden. Da sowohl das Design wie die Programme bei diesem fließenden Übergang Veränderungen zuließen, ohne daß vollständig in eine bereits abgeschlossene Entwicklungsphase zurückgegangen werden mußte, wurde in der frühzeitigen direkten Kommunikation mit dem Endbenutzer eine wesentlich bessere Anpassung an die Anforderungen erreicht.
Eine Unterrichtung anderer potentieller Benützer über die Erfahrungen des CAB bei der Auswahl eines Datenbankverwaltungs-Systems kann nur auf ein Plädoyer für das von uns gewählte Verfahren hinauslaufen, obwohl wir nicht alle gefundenen Ergebnisse für unfehlbar halten.