Mit zunehmendem Integrationsgrad der Anwendungen und verstärkter Nutzung von Datenbanken stellt jeder Anwender einmal fest, daß er mehr Informationen über die Daten selbst, ihre Verwendung und ihre klare Bedeutung benötigt. Spätestens jetzt wird ihm die Existenz von Data Dictionaries bewußt, die Informationen über Daten - sogenannte Meta-Daten - speichern und verwalten. Hans Jürgen Mährländer, Marketingleiter der Sysware GmbH aus Frankfurt wirft in seinem Beitrag die Frage auf, was von Data Dictionaries zu erwarten sei und welche Anforderungen vorab an ein solches Hilfsmittel gestellt werden müssen.
Ziemlich bald nach dem "Entdecken" der Problematik stellt sich aber die Frage, wo bekomme ich die Informationen über Daten eigentlich her? Wer bringt Ordnung in das Chaos der Meta-Daten? Denn eins ist inzwischen klar: Die Einführung von Data Dictionaries durch Ist-Erhebung der Meta-Daten ist ein Kraftakt, dem nur wenige Unternehmen gewachsen sind. Allzu bekanntes Ergebnis sind Data Dictionaries, deren Informationen nicht stimmen, die daher immer weniger genutzt und bald schon nicht mehr gepflegt werden. Dann heißt es, Data Dictionaries seien unbrauchbare Werkzeuge, was natürlich nicht stimmt.
Es bleibt alles beim alten, saubere Definitionen von Daten stehen am Ende der Analysephase des funktionalen Systems und sind nicht der Beginn allen Tuns. Die Moleküle des Informationsprozesses müssen herausgefiltert werden. Wenn wir uns auch noch so sehr sträuben, die Systementwicklung muß von A bis Z gut sein - mittendrin anzufangen, lohnt nicht.
Also sind Dokumentationssysteme die Zubringersysteme für Data Dictionaries, da sie die Anlaysephase und ein geordnetes Vorgehen unterstützen können?
Jetzt haben wir das Gebiet Begriffsvielfalt erreicht. Natürlich gehören auch Data Dictionaries zur Klasse der Dokumentationswerkzeuge. Wir müssen ihre Funktionalität daraufhin untersuchen, ob sie einen vollgefüllten Datenkatalog voraussetzen oder auch den Entwurfsweg dorthin unterstützen. Umgekehrt müssen wir von Dokumentationssystemen erwarten, daß sie auch Data-Dictionary-Funktionen erfüllen können, denn schließlich sind die Daten eine wichtige Zielgröße des Dokumentationsprozesses. Damit scheidet ein noch so schickes Textverarbeitungssystem als Dokumentationssystem aus.
Neben Daten und Prozessen in ihrer funktionalen und DV-technischen Ausprägung sollten wir mit einem solchen System auch unser eigenes planvolles Vorgehen zur Systementwicklung (Vorgehensmodell) dokumentieren und interaktiv am Bildschirm anbieten können. Denn "Schrank-Ware" hat bekanntlich keine Aussicht auf Akzeptanz.
Somit lassen sich wichtige Anforderungen an ein Dokumentationssystem mit Data-Dictionary-Funktionen (oder wie sollen wir in Zukunft sagen?) formulieren:
1. Unterstützung von Netzstrukturen
Daten und Prozesse müssen in ihrer funktionalen und DV-technischen Ausprägung, unterschiedlichen Detaillierungsebenen und ihren Beziehungen und Verwendungen zueinander dokumentiert werden. Der automatische Aufbau und die Verwaltung dieser. Beziehungen verlangt ein System zur Unterstützung von Netzstrukturen. Da es kein verbindliches Dokumentationsmodell gibt, muß die Struktur vom Benutzer frei definierbar sein.
2. Fertige Auswertfunktionen
Dazu gehören Verwendungsnachweise, Strukturen, Schnittstellenanalysen, Entwurfshilfen, Unterstützung der Erstellung fertiger Handbücher.
3. Ad-hoc-Auswertungen
4. Dialog-System
Neben Kommandotechnik mit und ohne Prompting muß Menü- und Help-Technik unterstützt sein.
5. Kundenindividuelle Gestaltung der Benutzeroberfläche
Die Akzeptanz hängt wesentlich davon ab, daß die Funktionalität des Systems kundenindividuell erweitert werden kann. Geeignetes Mittel dafür ist Prozedurfähigkeit.
Unterteilung in zwei Klassen
Die am Markt angebotenen Systeme lassen sich grob in zwei Klassen unterteilen:
1. Datenbankabhängige Systeme Diese Systeme sind in der gleichen Technologie wie die Datenbank implementiert. Sie haben einen hohen Integrationsgrad mit der Datenbank und erhöhen den Komfort der Benutzung der Datenbank beträchtlich. Bezogen auf das spezifische Datenbanksystem ist ihre Funktionalität im allgemeinen realisierungsorientiert und sehr hoch. Für die Entwurfsphase wird meist wenig geboten.
Aufgrund des hohen Integrationsgrades verlangen solche Systeme den totalen Ansatz bei der Einführung. Sie setzen daher einen hohen Organisationsstand voraus. 2. Datenbankunabhängige Systeme
Ihnen liegt die Überlegung zugrunde, eine klare Schnittstelle zwischen den Informationen über die Systementwickung (= Dokumentation Daten und Prozesse) und deren technische Realisierung zu haben. Beim Übergang auf eine neue Datenbanktechnologie sind die Investitionen für das Data Dictionary und Dokumentationssystem nicht gefährdet.
Solche Systeme sind in einer Basis-Technologie (ISAM, VSAM) realisiert, die als für die Zukunft gesichert gelten kann. Die Funktionalität im Hinblick auf Datenbanken wird durch Generierungsfunktionen angestrebt, wobei bei Änderung der Datenbanktechnologie lediglich diese Generierungsfunktionen auszutauschen sind. Darüber hinaus sind konventionelle Datenverwaltungen unterstützt.
Eine schrittweise Einführung ist bei solchen Systemen einfacher als bei den integrierten.
Ob Dokumentationssystem, Data Dictionary oder rechnergestütztes Vorgehensmodell, wir brauchen die Funktionalität von allen drei Systemen. Es gibt auch keinen Grund, daß der Markt uns das nicht liefern könnte: Denn die technischen Anforderungen aller Systeme sind gleich.
Auch hier gilt also: Erst festlegen, welche Anforderungen man hat, dann aussuchen, egal wie das System sich nennt.