Erfahrungsbericht mit neuen Tools zur maschinellen Unterstützung des Datenbankdesigns:

Keine Angst vor Reorganisations-Projekten

23.09.1988

Thomas Baumbach und Jürgen Moessinger, Pylon Unternehmensberatungen GmbH, Hamburg.

Reorganisationen von DV-Systemen werden immer wieder hinausgezögert, da diese Projekte mit herkömmlichen Methoden nur schwer planbar und kontrollierbar sind. Thomas Baumbach und Jürgen Moessinger stellen ihre Erfahrungen bei der Reorganisation der Vertragsbestandsführung eines großen deutschen Versicherers vor.

Bei der Reorganisation nach den herkömmlichen Methoden sind insbesondere das Ausmaß der Bindung interner Ressourcen und der gewünschte Erfolg kaum zu kalkulieren, auch und gerade, weil bei den zu erwartenden langen Laufzeiten dieser Projekte permanent die Gefahr besteht, daß sich einmal festgelegte Anforderungen der Anwender im Laufe der Zeit ändern.

Die phasenweise vollzogene Entwicklung vom geforderten grünen Rechteck, über den spezifizierten gelben Kreis zum letztendlich mit vielen Hindernissen und Umwegen codierten blauen Dreieck ist allgemein bekannt. Es gilt also, andere und flexiblere Methoden und Verfahren zur Abwicklung und Durchführung von Reorganisationen zu finden und einzusetzen.

Anwendungsstau macht Gesamtlösung notwendig

Die diesem Bericht zugrunde liegende Reorganisationsmaßnahme wurde von der Unternehmensleitung unter anderem aus den dargestellten Gründen solange hinausgezögert, bis man aufgrund von Anforderungen des Gesetzgebers und dem sich intern aufgebauten Anwendungsstau gezwungen war, für die gesamte Sparte Leben ein neues EDV-System zu realisieren.

Den soliden technischen Ausgangspunkt bei der Reorganisation der Bestandsverwaltung bildete eine vom Kunden unter TSO/ISPF selbstentwickelte Software-Produktions-Umgebung (SPU) in Verbindung mit einem unternehmensspezifischen Vorgehensmodell. Mittelpunkt dieser SPU ist das Data-Dictionary (DDS).

Bei der Neugestaltung der Vertragsführung im Bereich Leben sollte keine neue Insel-Lösung mit den bekannten Problemen an den Schnittstellen zu anderen Systemen realisiert werden. Bevor die eigentliche Reorganisation in Angriff genommen werden konnte, führte das Projektteam im Vorfeld eine unternehmensweite Datenstrukturanalyse (DSA) durch. Weil aus den Fehlern der Vergangenheit leidvolle Erfahrungen gesammelt werden mußten, förderte die Unternehmensleitung dieses Projekt in allen Phasen in besonderem Maß.

Gerade für ein Versicherungsunternehmen sind Daten ein bedeutender Produktionsfaktor. Erst durch seine Transparenz ist er für die Bereiche Controlling, Marketing und Vertrieb verwertbar. Die Daten, dokumentiert in einem unternehmensweiten Datenmodell, bilden die Basis für ein flexibles Agieren des Unternehmens am Markt. Eine leistungsfähige Datenverarbeitung muß in die Lage versetzt werden, auf alle Anforderungen schnell und wirtschaftlich zu reagieren.

Die Ergebnisse der alle Bereiche des Unternehmens erfassenden Analyse bildeten die Ausgangsbasis auch für die Reorganisation der Vertragsverwaltung der Sparte Leben. Die umfangreiche Dokumentation aus dem DSA-Projekt lag, wenn auch elektronisch gespeichert, nur als Papier vor und beschränkte sich im wesentlichen auf die Definition und Beschreibung der Datengruppen (Entitäten) und deren Beziehungen.

Für das Lebenprojekt mußten die ursprünglichen Ergebnisse des DSA-Projektes durch Datenfelder (Attribute) vervollständigt, in ein (möglichst) unternehmensweites Datenmodell überführt, aus dem Datenmodell ein Datenbankmodell entwickelt, und das Daten- und Datenbankmodell im DDS dokumentiert werden. Es zeigte sich sehr schnell, daß dieses Vorhaben bei dem gegebenen Termin- und Kostenrahmen wirtschaftlich nur durch den Einsatz von geeigneten Tools durchgeführt werden konnte.

Allen Beteiligten war klar, daß insbesondere die Dokumentation im DDS nicht auf dem üblichen Weg erfolgen durfte. Die Pflege des Dictionaries erfolgte bisher durch mehrere am Projekt beteiligte Mitarbeiter. In der Vergangenheit hatte sich herausgestellt, daß durch dieses Vorgehen die Konsistenz der Informationen nur noch mit einem erheblichen organisatorischen Aufwand sichergestellt werden konnte. Es fehlte an Mechanismen und an der Motivation der Mitarbeiter, auch Änderungen im DDS zu dokumentieren.

Zudem war der formale Aufbau der Einträge im Dictionary individuell geprägt von dem jeweils verantwortlichen Mitarbeiter. Eine Abhilfe hätte nur geschaffen werden können durch die Erstellung einer unternehmensspezifischen Benutzeroberfläche für das DDS mit speziellen Prüfroutinen. Eine grobe Aufwandsschätzung ergab, daß dieser Weg für das laufende Projekt eine nicht unerhebliche Verzögerung mit sich gebracht hätte.

Aus Sicht des Projektes ergab sich zwingend, den manuellen Pflegeaufwand im DDS zu minimieren. Dazu mußte also ein Tool eingesetzt werden, das nicht nur den dargestellten Prozeß der Datenmodellierung vom Datenmodell zum Datenbankmodell weitgehend unterstützt, sondern auch dafür sorgt, daß die Ergebnisse in einheitlicher Form und maschinell im DDS gespeichert werden. Aus Sicherheits- und Revisionsaspekten sollte das Datenmodell der Kontrolle der Source-Code-Verwaltung unterliegen. Änderungen am Modell erfolgen dann nicht mehr manuell im DDS, sondern ausschließlich im Datenmodell und werden im Rahmen des Freigabeverfahrens an die Source-Code-Verwaltung übergeben und automatisch im DDS gespeichert.

Das im Projekt eingesetzte Tool besteht aus einem Compiler/Generator-System, das aus einem Datenmodell ein relationales Datenbankmodell erzeugt. Der Kern dieses Tools ist eine formale Sprache, die eine erweiterte Form des Entity-Relationship-Modells nach Peter Chen abbildet. Dieses Werkzeug generiert unter anderem aus einem Datenmodell einen physischen Datenbankentwurf, zum Beispiel für Adabas oder DB2. Daneben wird eine standardisierte Dokumentation erzeugt, die die Basis für die Kommunikation mit der Fachabteilung bildet.

Schulungsaufwand für die Pools liegt bei fünf Tagen

Ein wesentlicher Punkt für die Entscheidung, dieses Tool einzusetzen, war die Möglichkeit, automatisch alle relevanten Einträge für das DDS bereitzustellen. Dabei mußten und konnten die spezifischen Anforderungen des Unternehmens berücksichtigt werden. Auch die Einbindung in die vorgegebene SPU ließ sich durchführen. Durch die Integration des verwendeten Tools in die SPU wurde der gesamte technische Teil der Datenmodellbildung Bestandteil des Vorgehensmodells.

Der Einsatz des Tools zeigte, daß gute Kenntnisse des Entity-Relationship-Modelling (ERM) notwendig sind. Der Schulungsaufwand für die Methode liegt in einer Größenordnung von drei bis fünf Tagen. Mit diesem Wissen, das überwiegend bereits im Verlauf des DSA-Projektes erlangt wurde, bereiteten Syntax und logischer Aufbau der formalen Spezifikationssprache dieses Tools kaum noch Schwierigkeiten.

Es zeigte sich auch, daß die Ergebnisse aus der Datenstrukturanalyse in weiten Teilen direkt und ohne Verwendung von Hilfskonstrukten in der Sprache des Tools formuliert werden konnten. Als schwierig und hinderlich für den Anwender erwies sich die Benutzeroberfläche auf dem Mainframe. Die Entwickler wünschten sich hier eine einfache Bedienerführung durch eine PC-Oberfläche und eine weitgehende Unabhängigkeit von einem Mainframe-System.

Vor allem bei den alten EDV-Hasen mußten vom Projekt auch Akzeptanzprobleme gelöst werden. Die Distanzierung von diesem Tool ergab sich insbesondere aus der Tatsache, daß als Zielsystem nicht ein relationales DBMS eingesetzt wird, sondern das hierarchische IMS unter CICS.

Hier scheint zunächst ein Widerspruch zu bestehen zwischen den neuesten Methoden und Verfahren bei der Datenmodellierung und einem Datenbanksystem, dessen Ursprünge weit vor der Zeit des Relationen-Modells lagen.

Überzeugen konnte schließlich, daß durch einige wenige Modifikationen bei der Spezifikation des Datenmodells ein brauchbares, hierarchisches Datenbankmodell generiert werden konnte.

Neustrukturierung der Daten wurde vermieden

Entscheidend für den methodischen Einsatz des ERM in Verbindung mit dem gewählten Tool war die Tatsache, daß der zukünftige Wechsel vom hierarchischen IMS zu einem relationalen DBMS wie DB2, Adabas oder Oracle möglich ist, ohne den aufwendigen Prozeß der Neustrukturierung der Daten zu wiederholen. Der Aufwand reduziert sich aus heutiger Sicht dabei auf folgende Tätigkeiten:

* Modifizieren des Datenmodells im Hinblick auf die Beziehungen zwischen den einzelnen Objekten.

* Generieren des neuen Datenbankmodells mit Hilfe des Tools.

* Anpassen der zentralen Zugriffsmodule, die pro Datenbank realisiert wurden.

* Übernehmen der Daten aus dem IMS in das relationale DBMS.

Damit sind die heute getätigten Investitionen des Unternehmens auch langfristig gegen einen zukünftigen Technologiewechsel gesichert. Voraussetzung für einen solchen Wechsel ist allerdings die permanente Konsistenz von Datenmodell, Datenbankmodell - sowohl in physischer als auch in logischer Sicht - und deren Dokumentation im zentralen DDS. Diese Konsistenz konnte im wesentlichen durch organisatorische Regelungen gewährleistet werden.

Das Datenmodell, im Sinne eines Produktionsfaktors und als Basis für jede Systementwicklung, unterliegt einer revisionsfähigen Source-Code-Verwaltung, mit deren Hilfe alle Änderungen protokolliert und nachvollzogen werden können. Die Aufgaben der Daten- und Datenbankadministration werden durch den Tooleinsatz wesentlich unterstützt, da mit diesem Tool Datenmodelle in unterschiedlichen Phasen des Life-Cycles verglichen werden können.

Ergebnis dieses Modellvergleichs ist eine übersichtliche und vollständige Protokollierung aller Ergänzungen und Änderungen des generierten Datenbankmodells. Die Auswirkungen auf die Software können durch die vollständige Dokumentation der Daten und Programme im DDS unmittelbar erkannt, analysiert und in ihren Auswirkungen beurteilt werden. Da gleichzeitig mit der Freigabe einer neuen Version des Datenmodells automatisch eine neue Dokumentation und die Einträge für das DDS bereitgestellt werden, ist sichergestellt, daß jede Änderung am Datenmodell unmittelbar allen laufenden Projekten bekannt wird.

Neben diesen offensichtlich strategischen Aspekten für das Unternehmen ergaben sich eine Reihe von positiven Effekten unmittelbar für das Projekt. Beispielsweise wurde der Aufwand in der Systementwicklung reduziert, durch die automatische Generierung der logischen Datenstrukturen in Form von Copy-Membern für PL/I oder Cobol durch das verwendete Tool.

Die maschinell erzeugte Dokumentation erwies sich im Verlauf des Projektes als gutes Kommunikationsmittel im Dialog mit den Anwendern. Bereits nach kurzer Einarbeitungszeit hatten die Mitarbeiter der Fachabteilungen keine Verständnisschwierigkeiten mehr und waren in der Lage, aktiv an der Datenmodellierung mitzuarbeiten.

In dieser frühen Projektphase konnte über die Stammdaten hinaus der künftige Informationsbedarf der Endanwender berücksichtigt werden. Gleichzeitig wurde im Zuge der Altdatenbereinigung durch die Entfernung aller Synonyme und die Auflösung aller Homonyme der ursprüngliche Datenumfang von rund 700 Datenelementen auf etwa 300 reduziert. Die maschinelle Analyse des Datenmodells gewährleistet, daß unternehmensweit eine einheitliche Namensvergabe bei den Datenelementen erfolgt.

Die Qualitätssicherung bei der Überführung des Datenmodells in ein logisches Datenbankmodell wird durch die im Tool definierten Regeln automatisch sichergestellt. Die durchgeführten Reviews konnten sich auf Inhalte beschränken, da alle formalen Anforderungen maschinell erfüllt wurden.

Für das Projekt ergab sich durch den Einsatz eines geeigneten Tools für die Datenmodellierung eine erhebliche Einsparung an Ressourcen, die anderweitig genutzt werden konnten. Durch den Einsatz derartiger Tools auf intelligenten Workstations und die Nutzung deren spezieller Fähigkeiten, besonders im Bereich des Prototyping beim Datenbankdesign, kann die Laufzeit der Projekte weiter verkürzt werden. Daneben ergibt sich natürlich eine erhebliche qualitative Verbesserung der realisierten Systeme.

Es zeigte sich im Verlauf des Projektes, daß eine Unterstützung, wie sie auf der Datenseite erfolgte, auch für den Bereich der Funktionen wünschenswert und erforderlich ist. Ähnlich wie bei der Datenmodellierung müßte es möglich sein, ein Funktionsmodell zu spezifizieren und maschinell auf seine Konsistenz zu prüfen. Die Synthese von Daten- und Funktionsmodell bildet dann die Grundlage für einen Prototyp des Gesamtsystems, der dann in seiner Gesamtheit unmittelbar mit den betroffenen Fachabteilungen abgestimmt werden kann.

Nach Abschluß der ersten Teilprojekte hat sich gezeigt, daß durch den Einsatz von neuen Methoden und Verfahren, wenn sie durch geeignete Tools unterstützt werden, Reorganisationsprojekte termingerecht, kostengünstig und letztlich erfolgreich durchgeführt werden können.