Noch vor fünf Jahren war der Begriff "Data Dictionary" in Deutschland auch für Insider der Datenverarbeitungsbranche eher ein Fremdwort. Heute ist dagegen vielen bewußt, daß Data Dictionary (DD) nicht einfach ein "Datenlexikon", sondern die zentrale Basis für ein EDV-gestütztes Dokumentationssystem, ja für eine ganze Dokumentationsmethodik ist. Dies hat sich nicht zuletzt in den laut Isis-Katalog beachtlichen Installationszahlen solcher Systeme niedergeschlagen.

Aus der Sicht der Anbieter solcher standardisierter Dokumentationssysteme sind diese Erfolge, gemessen am Marktpotential, erst die Spitze des Eisbergs, und es bleibt weiterhin schwer, die Kunden vom Vorteil und Nutzer, die ein solches System dem Unternehmen bringt, zu überzeugen. Hauptsache dafür ist

- die Mächtigkeit eines solchen Werkzeuges,

- die Schwierigkeit, den Gewinn zu quantifizieren,

- die Tatsache, daß ein Nutzen erst langfristig sichtbar wird.

Nutzen schwer zu quantifizieren

Zum einen geht ein Data Dictionary in seinen Einsatzmöglichkeiten und Auswirkungen über die klassischen EDV-Bereiche Systemanalyse - Programmierung - Rechenbetrieb hinaus. Auch die Fachabteilungen, das Controlling, die Administration, das Management werden tangiert und werden mitsprechen wollen. Technisch gesprochen ist ein Data Dictionary eine Mischung aus Basissystemen (wie Datenbank), aus Standard-Software (für die EDV-Abteilung) und aus Tool (wie Generatoren, Analysatoren), in jedem Fall aber ein Mittel für "Software Engineerer", die in den Kampf gegen die Software-Krise aufgebrochen sind.

Auf der anderen Seite liefern die Anbieter zwar viele gute und richtige Argumente, mitunter auch Beweise, die den Einsatz eines Data Dictionary geradezu herausfordern. Es fällt jedoch schwer, diese Vorteile so zu quantifizieren, daß sie den Nachteilen - und das sind in erster Linie Kosten; die durch Einsatzvorbereitung, Anschaffung und Pflege des Data Dictionary entstehen - gegenübergestellt werden können.

Außerdem muß man dazu eine Plankalkulation durchführen, denn abgesehen von kleineren, kurzfristig wirksam werdenden Vorteilen zahlt sich der Einsatz eines Data Dictionary erst nach einigen Jahren aus, dann, wenn die meisten Daten erfaßt sind.

Im folgenden soll deutlich gemacht werden, warum Zeit für die Einsatzvorbereitung aufgebracht werden muß, und was sich in Personalkosten niederschlägt. Damit sollen niemandem Steine in den Weg geworfen, sondern den zukünftigen Anwendern geholfen werden, diese Steine, die mit der Anschaffung eines Data Dictionary zwangsläufig erworben werden, leichter wegzuräumen.

Sorgfältige Einsatzvorbereitung

Gehen wir also davon aus, daß es einem Anbieter gelungen ist, einen EDV-Leiter für den Einsatz eines Data Dictionary zu gewinnen. Dieser wiederum konnte sein Management und seine Mitarbeiter überzeugen, und das Produkt wurde ausgewählt. (Wer will, kann bereits die dafür notwendigen und sicher nicht wenigen Diskussionsrunden auf der Kostenseite eines DD verbuchen.)

Bei jedem Standard-Software-System müssen - zumeist im Wege einer interdisziplinären Arbeitsgruppe - System und Umfeld aneinander angepaßt werden. Das bedeutet: In der Einsatzvorbereitung muß geklärt werden, wie die zuvor für den DD-Einsatz gesteckten Ziele mit den Unternehmens-Gegebenheiten (bestehende Aufbau- und Ablauforganisation für Projektentwicklung, vorhandene konventionelle und EDV-gestützte Richtlinien, Methoden, Basissysteme und Tools, schließlich Einsatzumfang und Qualität der EDV-Unterstützung) in Einklang zu bringen sind.

Daten-Bestandsaufnahme

Da das zentrale Problem beim Einsatz eines Data Dictionary darin besteht, Informationen in das "Lexikon" hineinzubekommen, um daraus dann den erwarteten Nutzen zu ziehen, ergibt sich, daß folgende Kernfragen beantwortet und gegebenenfalls in Maßnahmen umgesetzt werden müssen:

- WAS gehört alles in das Data Dictionary hinein (und was nicht)?

- WIE sollen die Informationen dokumentiert werden?

- WER übernimmt welche Dokumentationsaufgabe hinsichtlich des Data Dictionary?

- WANN sind welche Informationen einzugeben?

Dabei können aufgrund der Flexibilität der angebotenen Produkte deren jeweilige Spezifika erst in zweiter Linie die Beantwortung dieser Fragen beeinflussen.

Beginnen wir beim "WAS", so muß definiert werden, welche Datenarten in das Data Dictionary aufgenommen werden sollen (s. Bild 1). Man kann diese nach unterschiedlichen Aspekten gliedern, beispielsweise in "reine Daten" und "Prozesse" und/oder nach Anwendungsschwerpunkten:

- Fachabteilung,

- Systemanalyse,

- Programmierung,

- Rechenzentrum.

Dabei kommt es wesentlich darauf an, diese Begriffe thematisch genau zu definieren und gegeneinander abzugrenzen (beispielsweise Programm: Modul, Aufgabe: Teilaufgabe). Andernfalls besteht die Gefahr, daß unter dem gleichen Begriff Unterschiedliches dokumentiert wird. Unterstützung bei der Definition bekommt man, wenn man dabei gleich festlegt, welche Beziehungen zwischen den Datenarten dokumentiert werden sollen (vgl. Bild 2).

Es wird empfohlen, bei den Beziehungen so wenig Doppeldeutigkeiten wie möglich zuzulassen. Beispiel: Für die Datenart "Programm" gibt es eine Relation zur Datenart "Datei", während es für die Datenart "Modul" eine Beziehung zur Datenart "Datensatz", aber nicht zur "Datei" gibt. Damit wird Redundanz vermieden und die Pflege erleichtert.

Datenarten-Raster

Hat man so die Datenarten untereinander strukturiert, muß nun das "Innere" einer Datenart mit Fleisch gefüllt, also ebenfalls strukturiert werden. Dabei gibt es Angaben, die in jeder Datenart vorkommen müssen - sogenannte Standardangaben -, die von allen abfrageberechtigten Stellen zu vergleichenden Auswertungen herangezogen werden können. Solche Angaben sind etwa identifizierender Name, Kurzdefinition, Deskriptoren, eingebende Stelle, Datum, Klassifikationsschlüssel oder Bemerkungen.

Diese Angaben gliedern sich wiederum in sogenannte Mußfelder, wo eine Angabe zwingend erforderlich ist, und Kannfelder, bei denen eine Eingabe fakultativ ist. Für jede Datenart gibt es zusätzlich ein mehr oder weniger umfangreiches individuelles Raster, das auch wiederum hinsichtlich Muß- und Kannfeldern unterschieden werden kann. Beispiele sind für die Datenart "Job"

- durchschnittliche CPU-Zeit,

- Maßnahmen bei Jobabbruch,

- Maßnahmen bei Systemabbruch oder

- Voraussetzung für Jobstart.

Setzt man nun die Detaillierung weiter fort, so ist festzulegen - und hier versuchen wir bereits, Anregungen dafür, "WIE zu dokumentieren ist", zu geben -, welche Syntax und gegebenenfalls Semantik die einzelnen Angaben haben sollen. Dies ist besonders wichtig, um Standards einhalten, automatische Kontrollen durchführen und Inhaltsabfragen stellen zu können. Auch für die Nutzung der Generierungsfunktionen spielen diese Inhalte eine große Rolle.

Einigungszwang

Am gebräuchlichsten sind sogenannte Namenskonventionen (wobei eine Diskussion darüber, ob sprechende oder nicht sprechende Namen verwendet werden sollen, unumgänglich ist), Längenbegrenzungen für Übersichten sowie Wertetabellen. Letztere sind zum Beispiel auf der Basis von Deskriptoren sehr zu empfehlen, um bei Quereinstiegen (das sind nicht auf Relationen beruhende Abfragen) fündig zu werden.

Es soll aber an dieser Stelle nicht diskutiert werden, ob ein automatisches Indexierverfahren einem reinen Deskriptorverfahren vorzuziehen ist. Die Lösung des ersteren ist zumindest technisch aufwendiger, wenn auch vordergründig einfacher zu handhaben. Deskriptorverfahren verlangen entsprechende Thesauri, die die Klassifikation strukturieren. Allein die Erarbeitung eines solchen Thesaurus kann viel Zeit in Anspruch nehmen.

Nachdem man sich nun auf ein gültiges Dokumentationsschema geeinigt hat, müssen die Anpassung an die äußeren Gegebenheiten sowie die ablauforganisatorischen Maßnahmen festgelegt werden.

Was die Abwicklungsart betrifft, so ermöglicht eine Online-Eingabe durch vorgeschaltete Benutzerführung ein leichteres Einarbeiten, was deshalb wichtig ist, weil von den meisten diese Tätigkeit nur gelegentlich durchgeführt wird und somit vieles in Vergessenheit gerät. Andererseits kann damit eine bessere Kontrolle hinsichtlich Muß- und Kann-Eingaben und ihrer Inhalte (Syntax, Semantik) erfolgen. Auch kann damit das Instrument DD in die gewohnten Arbeitsmittel eingepaßt werden.

Elementare Datenadministration

Dabei kann es trotzdem sinnvoll sein, gewisse Datenarten über Belege zu dokumentieren, weil entweder die technische Voraussetzung für die Online-Eingabe nicht vorhanden ist (und ein ausschließlicher Einsatz dafür zu teuer käme) oder weil eine intellektuelle Prüfung vor Eingabe in das DD notwendig ist, um beispielsweise Redundanzen zu vermeiden. Dies gilt insbesondere für die Datenart "Datenelement", da hier dem Einzelanwender selbst kaum zugemutet werden kann, zu prüfen, ob vielleicht sein Element schon syntaktisch - mit der gleichen Bezeichnung - oder semantisch - mit der gleichen Bedeutung - im DD vorhanden ist.

Hier muß eine von der Projektorganisation unabhängige Datenadministration aufgebaut werden, die auch mit den nötigen Kompetenzen auszustatten ist. Jedem potentiellen Anwender eines DD sollte klar sein, daß ohne eine solche Funktion das DD früher oder später nichts mehr wert ist. Doch dies gehört bereits in den Teil "Pflege des Data Dictionary" und soll hier nicht weiter behandelt werden. Zum organisatorischen Umfeld gehört es ebenfalls, sich Gedanken zu machen, wie der Gleichklang zwischen Dokumentation und Wirklichkeit hergestellt werden kann. Dabei muß man sich sowohl der vorhandenen technischen Möglichkeiten (beispielsweise Precompiler) wie auch konventioneller Maßnahmen (Abzeichnungen, Stichproben) bedienen.

Dienen die Angaben im DD als Programmiervorgabe, so müssen eventuell Verknüpfungen zu zeichnerisch dargestellten Informationen hergestellt werden. Insgesamt besitzen die DDs einige explizite Schnittstellen zu anderen Tools oder gar zu Benutzerprogrammen, die man nutzen kann, und implizite Schnittstellen, die man konventionell lösen muß.

In der Frage "WER soll was dokumentieren?" haben wir bezüglich des Aufbaus eines Datenmanagements schon einige Ausführungen gemacht. Ansonsten gilt der triviale Grundsatz, daß die Arbeit möglichst gleich zu verteilen ist, und nicht diejenigen, die den meisten Input liefern, am wenigsten davon profitieren. Es wird deshalb davor gewarnt, die Dokumentation auf dem Rücken der Programmierer, die sowieso bisher die einzigen waren, die dokumentiert haben, auszutragen.

Programmierer-Rücken und Dokumentations-Mühle

Nicht zuletzt deshalb wird die Auslagerung der aufwendigen Datendokumentation empfohlen. Manchmal kann es auch notwendig sein, die dokumentierte Information vor Mißbrauch zu schützen. Dann sind andererseits entsprechende Dokumentationsklassen wie auch Benutzerberechtigungsprofile zu definieren. Hier kann unterschieden werden, wer was eingeben, wer korrigieren und wer löschen darf, wer Eigentümer seiner Datenartausprägung ist etc. (vgl. Bild 3).

Bleibt noch zu diskutieren, WANN eine Eingabe oder eine Abfrage zu erfolgen hat. Auch hier wieder nur ein paar Empfehlungen: Mit dem Projektbeginn sollte eine erste Dokumentationsphase einhergehen. Allerdings wird entschieden davor gewarnt, nun alles und jedes "Einmalprogramm" durch die Dokumentations-Mühle zu drehen. Der Aufwand würde in keinem Verhältnis zum Nutzen stehen. Andererseits ist der Zeitpunkt so zu wählen, daß der Änderungsaufwand möglichst gering ist.

Vor der Formulierung der Programmiervorgabe könnte im Sinne eines datenbezogenen Vorgehens die Datenstruktur bis auf Elementebene festgelegt und damit auch ins DD eingebracht werden. Dies hat zudem den Vorteil, daß eine eventuell durchgeführte Generierung für Programm oder Umgebung (Datenbank, Bildschirm) ausgenutzt werden kann, ohne daß all dies noch einmal niedergeschrieben werden muß. Zur Übergabe an das Rechenzentrum oder an die systembetreibende Stelle (etwa Fachabteilung) muß die Dokumentation vollständig im DD vorhanden sein.

Ein besonderes Problem stellt immer wieder die Nachdokumentation sowie die Dokumentation von nicht vom Anwender selbst geschriebenen Programmen (Systemteile, Standardprogramme, Tools) dar. Es gehört deshalb mit in die Einsatzvorbereitung, genau zu klären, für welche Projekte welche Teile nachzudokumentieren sind. Dabei wird man sich vom Grundsatz leiten lassen, nur soviel wie gerade zumutbar und beispielsweise nicht alle "Datenelemente" nachzudokumentieren.

In diesem Zusammenhang wird ausdrücklich vor dem Einsatz der oft mit den DDs angebotenen Analysatoren gewarnt. Es gibt nur wenige Ausnahmen, wo die so gewonnene automatische Eingabe bezüglich der Bereinigung des DDs von Redundanzen und Unvollständigkeiten oder Fehlern am Ende nicht mehr Aufwand kostet als eine intellektuelle Erschließung und Eingabe.

Betrachtet man die aufgeführte Menge von Problemen, die - und dies sei noch einmal ausdrücklich betont - unbedingt vor der Aufnahme der "Produktion" gelöst werden sollten, so leuchtet ein, daß ein erheblicher Aufwand unvermeidlich ist. Dieser erhöht sich noch dadurch, daß man einige Zeit braucht, um mit dem jeweiligen Produkt vertraut zu werden - von den nicht zu vermeidenden Grundsatzdiskussionen über Sinn und Unsinn eines DD, die mit jeder Änderung des bisherigen Arbeitsablaufes eines betroffenen Anwenders hochkommen, einmal abgesehen.

Mit Herausgabe eines Benutzerhandbuches und entsprechender Unterweisung der Anwender endet formell die Aufgabe der Einsatzvorbereitung und geht dann in die Pflege und den Betrieb des DD über. Richtig zufrieden kann man aber erst sein, wenn die Benutzer aus gewonnener Einsicht heraus erklären, im DD etwas nicht Erwartetes gefunden und dadurch Arbeit eingespart zu haben.

Alexander von Stülpnagel ist Mitarbeiter der Münchener gfs Organisationspartner GmbH; die ihre Kunden beim Einsatz eines Data Dictionarys nach eigenen Angaben als "unabhängige Instanz" berät, da keinerlei Bindungen zur Anbieterseite hin bestehen.