In der Welt der Informationsverarbeitung ist es üblich geworden. mit der Vergabe einer "neuen Generation von . . ." schnell bei der Hand zu sein. Häufig sucht man dahinter vergebens nach tiefgreifenden Neuerungen. Alexander von Stülpnagel, Vertriebsleiter der MSP GmbH, eines Anbieters im Bereich von computergestützten Entwicklungs- und Wartungswerkzeugen, durchleuchtet im folgenden Beitrag die Geschichte von Data-Dictionary-Systemen.
Große EDV-Abteilungen erkannten schon vor geraumer Zeit in ihrer vorhandenen Datenunordnung und der fehlenden Dokumentation eine Ursache für die schlechter werdende Produktivität. Abhilfe erhoffte man sich von methodischen Ansätzen - meist mit Papier und Bleistift - und isolierten Werkzeugsystemen, wie zum Beispiel einem NP-Generator.
Organisatorisch wurde die Datenbankadministration institutionalisiert; sie hatte zumindest aus technischer Sicht die in Datenbanken abgespeicherten Daten projektübergreifend zu verwalten, Hier setzte auch zuerst der Ruf nach einem maschinellen Ordnungssystem für diese Verwaltung ein - die ersten Data-Dictionary-Systeme waren geboren. Mit ihnen konnten stücklistenartig die DV-technischen Bestandteile eines Software-Systems separat vom Endprodukt dokumentiert und abgefragt werden.
Zur Vermeidung von Doppelarbeit und Inkonsistenz wurden Datendefinitionssprachen für höhere Programmiersprachen und Datenbanksysteme aus der Dokumentation generiert. Doch die Experimente der ersten Stunde mußten manche Anwender mit hohem Lehrgeld bezahlen. Der Zwang zur "neuen" Ordnungssystematik - ohne die kein DV-Hilfsmittel auskommt - förderte fehlende Richtlinien und Konventionen zutage, stellte Zuständigkeiten in Frage und behinderte die freies Arbeiten gewohnten DVler.
Weil darüber hinaus diejenigen die das Data-Dictionary mit Leben füllen sollten, oft nicht diejenigen waren, die einen entsprechenden Nutzen daraus zogen, verendeten gutgedachte Ansätze auf Projektebene oder blieben auf der Goodwill-Ebene einzelner überzeugter Progressiver stehen.
Die Forderung nach aktiver Unterstützung, insbesondere bei der Informationsaufnahme und -bereitstellung in das und aus dem Data-Dictionary, bekam außerdem durch weitere Werkzeuge, zum Beispiel für die Programmerstellung (Listgeneratoren, ET-Generatoren, Editiersysteme), zusätzliches Gewicht.
Dabei entbrannte in der "2. Generation" von Dictionaries ein Streit um die wahre Philosophie. Aus der Sicht Datenbankhersteller sollten integrierte Data-Dictionaries/-Direktories die bislang passiven Systeme ablösen - die datenbankunabhängigen Dictionary-Anbieter setzten auf aktive Read-/Write-Schnittstellen, Statuskomponenten und Flexibilität bezüglich der im Dictionary zu speichernden Informationen und Strukturen.
Dabei handelte es sich nur um eine folgenrichtige Spezialisierung auf die
- operationalen, laufzeitorientierten Systeme, die den Zugriff einer Datenbank aktiv steuern, wahrend des laufenden Betriebes Änderungen ermöglichen und Verwaltungsabfragen zulassen;
- logische, administrativ-orientierte Systeme, die die gesamte Dokumentation aktiv verwalten, Konstistenzprüfungen übernehmen und vereinzelt bereits mit anderen Werkzeugen integriert
wurden den.
Beide Systeme hatten zwei Ziele, zum einen die Pflege der Dictionary-Inhalte obligatorisch zu machen, weil nur so andere Systeme (Datenbanken, Werkzeuge) ihre notwendigen Informationen bekommen, und zum anderen Informationen aus anderen Systemen (zum Beispiel Datenbank-Compiler) autornatisch mit dem Inhalt im Dictionary zu verbinden.
Bei genauerer Untersuchung wurde allerdings festgestellt, daß Anspruch und Wirklichkeit nicht immer übereinstimmten. Datenbanksysteme liefen auch ohne ihre integrierten Dictionaries/Directories. Aus dem Data-Dictionary generierter Code (zum Beispiel für Datenstrukturen) konnte syntaktisch fehlerhaft zein, oder ein direkter Update des Dictionary aus einem anderen Programm heraus war nicht möglich.
Überall dort, wo die Datenbankadministration zugunsten der umfassenderen Datenadministration abgelöst wurde, bekam der Einsatz von Data-Distionary-Systemen ein anderes Gewicht. Nicht die Betreuung der Datenbank stand im Vordergrund, sondern der Gedanke, die Daten selbst als betriebswirtschaftliche Produktionsfaktoren anzusehen.
Daraus ergibt sich die Notwendigkeit, die Datenbestände statt projektbezogen unternehmensbezogen zu planen, zu verwalten und zu kontrollieren. Spezielle Richtlinien für die betriebswirtschaftliche Beschreibung von Datenfeldern und ihr Wiederauffinden im Data-Dictionary stellte entsprechende Anforderungen an die Systemfunktionen - nicht die Zugehörigkeit zu einer physischen Datei, sondern zu einer unternehmensbezogenen Semantik war entscheidend.
Die Directory-orientierten Systeme verknüpften im folgenden die 4th-Generation-Language-Systeme des gleichen Herstellers und schafften so neue aktive Komponenten, wie die automatische Dokumentation von Bildschirmlayouts oder die Generierung von Plausibilitätskontrollen. Im Zuge des Software-Engineerings konzentrierte sich dagegen die Entwicklung vom datenbankunabhängigen Dictionary auf die Integration von methodischem Vorgehen und aktiver Werkzeugunterstützung vorwiegend für den Systementwurf.
Erstmalig wurde dabei der Data-Dictionary-Einsatz selbst wie eine komplexe Datenbankanwendung behandelt - in die Rolle der Fachabteilung schlüpfte die DV-Abteilung. Daß die eigene Medizin nicht immer süß ist, mußte derjenige erkennen, der Methoden lehrt, ohne sie selbst je angewendet zu haben.
Anstatt die Data-Dictionary-Struktur intuitiv festzulegen, wurden die Datenzusammenhänge des Software-Entwicklungsprozesses mit dem Verfahren der Datenanalyse angegangen. Das Ergebnis war ein Konzept für eine Software-Produktionsumgebung, basierend auf einer komfortablen Benutzeroberfläche auf einer einheitlichen (Meta)-Datenbasis und auf aktiven Werkzeugen für die einzelne methodische Unterstützung im Software-Life-Cycle .
Der Entwickler teilt dem System durch "Positionen" mit, was er tun will (Phase, Aktivität, Sub-Aktivität). Auf jeder Ebene steht ihm ein kompletter Befehlssatz zur Verfügung,
den er auf dem jeweils zu bearbeitenden Ausschnitt aus der Entwicklungsdatenbank (Subschemaprinzip) einsetzt. Eine kontextabhängige Help-Funktion führt den Anwender
in eine Methodenbank, die ihm das "Wie" sofort erläutert. Alle Werkzeuge arbeiten aktiv auf der Entwicklungsdatenbank und werden entweder explizit durch den Entwickler oder implizit bei Durchführung von bestimmten Aktivitäten aktiviert.
Ein Projektmanagementsystem überwacht die Aktivitätendurchführung und -vergabe mit Hilfe seiner Projektdatenbank. Bei Integration mit der Entwicklungs- und Methodendatenbank können automatisch Konsistenzprüfungen bezüglich geplantem Projektfortschritt und Projektergebnis hergestellt werden.
Das Einbinden von möglicherweise gar unterschiedlichen Directoryorientierten Systemen ist dabei abhängig von dem Einsatz und Umfang der entsprechenden 4th Generation Language im Rahmen des Software Engineering. Für einige Anwender
wird das kurzfristige Erreichen operativer Ziele wichtiger sein als ein langfristiges Software-Engineering-Konzept. Sie wird deshalb der Vorteil eines Data-Dictionary als Entwicklungsdatenbank vorläufig weniger überzeugen als die schnellere Programmerstellung durch die 4th Generation Language.
Andere Anwender werden den Vorteil des Prototypings insbesondere für die Erarbeitung einer angemessenen Benutzeroberfläche nutzen und an einem "friedlichen Nebeneinander" von Directory und Dictionary, von Prototypingdatenbank und Entwicklungsdatenbank interessiert sein. Jegliche Datenredundanz muß dabei konsistent gehalten werden, das heißt ein Update im Dictionary muß einen Update im Directory und umgekehrt automatisch nach sich ziehen.
Wegen der noch wenig verbreiteten aktiven Directories von 4th Generation Languages ist heute meist eine Generierung von Directory-Informationen aus den Data-Dictionary-Systemen ausreichend. Die Zukunft wird zeigen, ob sogar eine Integration beider Systeme wieder möglich ist - wenn zum Beispiel durch eine standardisierte Schnittstelle datenbankunabhängige 4th-Generation-Language-Systeme aus einem Dictionary gesteuert werden können.
Neue Aufgaben für die Datenorganisation, wie zum Beispiel das Aufstellen und die Pflege eines unternehmensweiten Datenmodells im Sinne einer strategischen Informationsplanung, führten zur Institutionalisierung des Datenmanagements. Für manchen aufgeschlossenen ehemaligen Datenbankadministrator wurde hier eine der DV-Leitung direkt unterstellte Stabsfunktion geschaffen, die die operativen Tätigkeiten der Datenadministration und Datenbankverwaltung mit den strategischen Aufgaben einschließlich methodischer Richtlinien verbindet.
Derzeit vollzieht sich ein gedanklicher Wandel von der Datenverarbeitung zur Informationsverarbeitung. Unterschiedliche Gründe sind dafür maßgebend, so unter anderem die dynamische und unübersichtliche Entwicklung auf dem PC-Markt, die auf den Markt drängenden neuen Kommunikationstechniken und die immer stärker werdende Verkettung komplexer Applikationen.
Der Wert von der Information als Ressource bekommt langsam Konturen. Glücklich derjenige, der schon ein funktionierendes Datenmanagement eingerichtet hat. Vorbei sind die Zeiten, wo nach operativen Gesichtspunkten allein die Prioritäten für die Realisierung von DV-Systemen vergeben wurden.
Software-Engineering muß sich an Erkenntnissen aus strategischen Überlegungen orientieren - wie sie zum Beispiel in dem Ansatz des "Business System Planning" aus den siebziger Jahren bekannt sind. Copymanagement und Informationslocation stellen neue Anforderungen an Software-Entwicklung, -betrieb und -benutzer, das 3-Center-Konzept der IBM benötigt eine Koordinierungsstelle, die die Aufgaben des Information Resource Management -übernimmt.
Das Arbeiten mit intelligenten Workstations für die Systementwicklung wird die Aufgaben, die einer Software-Produktionsumgebung zukommen, neu verteilen. Grafische Ein-/Ausgabefunktionen werden als CAD/CAM-Anwendung der Systementwicklung entstehen. Dabei werden wohl auch die (Meta-)Daten der Entwicklungsdatenbank dezentralisiert, eine gemeinsame Integration in einer "Information-Engineering-Datenbank" ist aber unerläßlich. Ähnlich dem Prinzip der verteilten Datenbanken wird es verteilte Dictionary- oder Metadatenbanken geben müssen.
Gleichzeitig wird die Entwicklungsdatenbank "nach vorn", das heißt in den projektvorgelagerten Bereich der unternehmensweiten Planung und Strategie ergänzt werden müssen. Bestehende Auf und Ablauforganisationen müssen durch neue Informationswege und Informationsbedürfnisse in Frage gestellt werden dürfen. Basis dafür können Auswertungen über Kommunikationswege und -inhalte, über DV-Einsatz und Nutzen oder Zuordnungen von Funktionen zu aufbauorganisatorischen Einheiten sein. Ein entsprechend strukturiertes Dictionary übernimmt dabei gleichzeitig die Schnittstelle zu den nachfolgenden DV-Projekten, die zum Beispiel das grobe Entity-Modell direkt verfeinern werden.
Der Gefahr, daß Unternehmensmodell und Projektabwicklung auseinanderklaffen und somit die Erkenntnisse der strategischen Informationsplanung nicht in die Projektarbeit einfließen, kann nur durch einen einheitlichen Methodenrahmen begegnet werden. Das bedeutet, daß auch die Methodendatenbank aus der Software-Produktionsumgebung entsprechend ergänzt werden muß.
Wir können heute den ersten Anwendern von Data-Dictionary-Systemen dankbar, sein, die missionarhaft die Richtung in eine geordnete DV-Welt wiesen. Sie haben nicht nur zur Weiterentwicklung der Data-Dictionary-Systeme selbst wesentlich beigetragen - was ihnen selbst manchmal nichts mehr nützte, wenn sie bereits ihre eigene Lösung implementiert hatten -, sondern auch das methodische und organisatorische Umfeld entscheidend geprägt. Etwas anders sieht es mit der geschilderten Software-Produktionsumgebung aus. Ein komplettes System, bestehend aus durchgängigen Methoden, aktiven Werkzeugen, flexiblen Dictionaries mit entsprechendem Schulung angebot und Einführungsunterstützung ist Wunsch jedes DV-Leiters. Dafür wird er auch gerne seine halbfertigen pflegeaufwendigen Eigenentwicklungen, handgestrickten Interfaces zwischen verschiedenen stemen und inkonsistenten Dictionary-Inhalte wegwerfen.
Beneiden wird er diejenigen Unternehmen jedoch nicht, die mangels Standardangebot alleine oder mit externer Unterstützung eine Software-Produktionsumgebung implementieren (müssen). Diese können zwar auf eine Reihe von mehr oder weniger praxisbewerteten Methodenkonzepten und einsatzerprobten Werkzeugen und Dictionary-Systemen zurückgreifen - für die Integration zu einer geschlossenen Oberfläche unter Einbeziehung von strategischer Planung und Projektmanagement wird viel Geld und Köpfchen benötigt.