Planungsaufwand für ein Datenbankprojekt darf nicht unterschätzt werden - eine qualitative Kostenanalyse entscheidet im wesentlichen über Erfolg oder Mißerfolg. Sowohl bei der Gesamtkonzeption als auch bei der anschließenden Detailrealisierung fallen nämlich Personalkosten an, welche die Anlagekosten eines Systems schnell übersteigen können.

Zunächst muß ein spezielles Planungsteam gegründet werden, in welchem alle späteren Benutzergruppen - angefangen von informellen Benutzern (Management) über DV-Spezialisten (System-, Organisations-, Anwendungsprogrammierer) bis hin zu den Endbenutzern (Fachabteilungen) - integriert sind.

Die Kommunikationsfähigkeit innerhalb des Planungsteams darf weder personell noch informell bedroht sein. Nur so können Fehlentwicklungen, beispielsweise, die mangelnde Akzeptanz elektronischer Datenverarbeitung im allgemeinen und insbesondere von Datenbanksystemen, frühzeitig erkannt und abgewendet werden.

Die erste Aktivität der Planungsgruppe besteht darin, sich ein angemessenes Datenbank-Verständnis anzueignen, damit sich ein datenbankspezifisches Urteilsvermögen herausbilden kann. Als nächster Schritt kann ein Grobentwurf von Zielvorstellungen erstellt werden.

Er wird anschließend in ein realistisches Gesamtkonzept umgearbeitet, wobei alle theoretisch denkbaren Wunschvorstellungen (zum Beispiel Management-Informations-System auf der Basis einer betrieblichen Supra-Datenbank) auf ein praktikables Maß zu reduzieren sind. Dabei hat es sich nach James Martin ("Einführung in die Datenbanktechnologie") als vorteilhaft herausgestellt, das Gesamtkonzept als einen zukunftsgerichteten Stufen-Integrationsplan realisierbarer Einzellösungen aufzufassen.

Ein solcher Plan muß sukzessive verfeinert werden, wobei die Bestandsaufnahme betrieblich existierender Datenflüsse und deren Verdichtung zu inhaltlich zusammenhängenden Informationssegmenten notwendig wird (Stichwort: Informationsprofil).

Anschließend erfolgt eine Analyse, welche den Nachweis erbringen muß, ob die auf dem Markt befindlichen Datenbanksysteme den betriebsspezifischen Anforderungen gerecht werden.

Die Planungsgruppe beendet ihre Arbeit, indem sie

- einen budgetierten Stufen-Integrationsplan verabschiedet,

- ein Detailprojekt als Datenbankrealisation empfiehlt und

- einen betrieblichen Datenverwalter benennt.

Letzterer ist mit dem späteren Datenbankverwalter identisch, sofern nicht mehrere betriebliche Datenbanken aufgebaut werden.

Während der gesamten Planungsphase ist nach jedem Etappenziel zu überprüfen ob der betriebliche Einsatz von Datenbanktechnologie langfristig gesehen billiger, leistungsfähiger und akzeptabler als die vorhandenen Verwaltungsressourcen eingeschätzt wird.

Der hier vorgeschlagene Planungsaufwand ist zwar enorm personal- und zeitintensiv, sollte aber im Sinne der angesprochenen "typischen" Phasen eines Datenbankprojektes ernsthaft erwogen werden. Für alle Projekte gilt nämlich die Tatsache, daß sich unentdeckte Fehler bezüglich ihrer Korrektur um so kostspieliger auswirken, je früher sie begangen worden sind.

Zur Aufstellung des budgetierten Stufen-Integrationsplans sollen die weiteren Ausführungen dienen. Unter Anlagekosten sind die einmaligen Systemkosten (Hard- und Software) zu verstehen, welche die Ausgangsbasis einer Datenbankapplikation bilden.

In Zukunft kann damit gerechnet werden, daß spezielle Datenbankcomputer angeboten werden, das heißt, Rechner, Betriebs- und Datenbanksystem bilden eine optimal abgestimmte Kommunikationseinheit. Leider kann davon zur Zeit bei den meisten Systemen noch keine Rede sein.

Vielmehr ist es so, daß jedes Datenbanksystem als eigenständige Verwaltungseinheit auf der Basis vorhandener Hard- und Systemsoftware operiert. Dabei fallen zwei unterschiedliche Konzepte auf:

- Hardware-abhängige Systeme und

- Hardware-unabhängige Systeme.

Es hat den Anschein, als wenn abhängige Systeme besseren Durchsatz und unabhängige höheren Komfort bieten. (Gewißheit können erst umfangreiche Systemvergleiche inklusive überzeugender Benchmark-Tests ergeben.)

Bei der Beschaffung eines Datenbanksystems muß also berücksichtigt werden, ob vorhandene betriebliche Hard- und Systemsoftwareressourcen weiterhin genutzt werden sollen beziehungsweise können, oder ob sie durch Neu- und Ergänzungskäufe abzulösen sind.

Der Kaufpreis (Lizenz) muß dabei pro CPU entweder als Einmal- oder Mietpreis entrichtet werden. Dabei ist darauf zu achten, daß das Gesamtsystem (inklusive aller Generatoren, Utilities oder Tools) bewertet wird.

Der im folgenden diskutierte Ansatz über die Entwicklungskosten basiert auf der Annahme, daß die Softwareapplikation betriebsintern erstellt wird. Falls der Erwerb von Standardsoftware möglich ist, können die hier dargestellten Kosten eventuell wesentlich reduziert werden.

Bei der Erstellung einer betrieblichen Datenbank (Einzellösung einer Fachabteilung) fallen umfangreiche Entwicklungskosten an, welche im Normalfall wesentlich höher liegen als die Systemsoftwarekosten.

Zunächst muß ein Team gegründet werden, das funktional die Bereiche Informationsanalyse, Design, Datenbankadministration, betriebliche Datenverwaltung und Programmierung abdeckt. Die von der Planungsgruppe aufgestellten Informationsprofile müssen von diesem Team in Zusammenarbeit mit der entsprechenden Fachabteilung auf Korrektheit, Vollständigkeit und Realisierbarkeit geprüft und präzisiert werden.

Dabei ist die Realisierbarkeit sowohl prinzipiell (möglich/unmöglich) wie konditional (Budgetvorgabe, Programmierkapazität) zu entscheiden. Für diese schwierige Aufgabe können in jüngster Zeit Dienstleistungen der Prototyping-Centres (sofern sie über entsprechendes personelles und technisches Know-how verfügen) herangezogen werden. Ihre Funktion besteht darin ein rudimentäres Modell der eigentlichen Softwareapplikation zu erstellen, anhand dessen die konditionalen Fragen erörtert werden konnen.

Die Detail-Planungsphase wird beendet, indem

- der budgetierte Projektplan aufgestellt,

- der Administrator eingesetzt und

- der Designer benannt

werden. Der Designer entwirft die einzelnen Datenbankschematas, wobei konzeptionelles und externes Schema die Grundlage der Programmierung bilden.

Der Aufwand, den die Programmierabteilung zu leisten hat, ist beträchtlich. Bereits in der Planungsphase, an der die Programmierung beteiligt war, ist entschieden worden, welche Programme mit welchen Sprachmitteln zu erstellen sind (Prototyping).

Nun müssen die einzelnen Programme entworfen, codiert und getestet werden. Anschließend werden sie zur eigentlichen Softwareapplikation verkettet und vor ihrer endgültigen Freigabe im Zusammenhang getestet. Diese Tests (Einzel-, Kettentest) offenbaren normalerweise zahlreiche Fehler, was zur Wiederholung der einzelnen Arbeitsschritte (Entwurf /Codierung/Test) führt.

Wenn möglich, sollten bei der Programmerstellung spezielle, datenbankspezifische Werkzeuge eingesetzt werden (Stichwort: Software-Produktions-Umgebung). Solche tools unterstützen nicht nur die einzelnen Programmierphasen, sondern ermöglichen durch standardisierte Dokumentationsverfahren später notwendig werdende Programmwartungsarbeiten. Die Kosten der Software sind nämlich nicht nur durch Entwicklung, sondern wesentlich durch Wartung geprägt.

Bei der Einführung des Datenbanksystems, einschließlich Anwendungssoftware, fallen Installations- und Schulungskosten an. Sind die Instalationskosten im allgemeinen zu vernachlässigen, müssen die Schulungskosten unbedingt separat berücksichtigt werden.

Hier ist zunächst darauf zu achten, daß das Datenbanksystem vollständig dokumentiert ist und sowohl den Ansprüchen der Operateure und des Administrators als auch denen der Programmierer und Ad-hoc-Anwender gerecht wird. Ein Datenbanksystem kann nur so effizient sein, wie es die einzelnen Benutzergruppen in die Lage versetzt, mit ihm zu kooperieren.

Begleitend zum Selbststudium (Dokumentation) sind Schulungsseminare und User-Meetings, wie sie von einigen Herstellern veranstaltet werden, auszunutzen. Außerdem könnten betrieblich organisierte Schulungen stattfinden, was zumindest im Hinblick auf betriebseigene Software selbstverständlich sein sollte.

Der produktive Einsatz von Datenbanksystem/ Anwendersoftware verursacht weitere Anlage- und Personalkosten. Da ist zunächst der systemspezifische Aufgabenbereich des Datenbankadministrators zu nennen, der je nach Projektgröße und Kompetenz in Personalunion mit dem betrieblichen Datenverwalter, dem Designer und dem "Systemoptimierer" auftreten kann. Auf jeden Fall ist davon auszugehen, daß diese Tätigkeiten permanent anfallen und keinesfalls nur vor Aufnahme des Produktiveinsatzes.

Diese betriebsspezifischen Wartungsaufgaben werden ergänzt durch die Betreuung von Hersteller beziehungsweise Vertrieb. Hier müssen entsprechende Wartungsverträge abgeschlossen und garantiert werden (geographische Nähe, Personalbestand, Referenzadressen).

Darüber hinaus wird die Innovationsfreudigkeit der Computerindustrie den Datenbankbetreiber bald mit der Möglichkeit einer neuen Version (Release-Wechsel) seines Systems konfrontieren. Die fundamentalen Verbesserungen, insbesondere das Herstellerversprechen, alle bisher aufgetretenen Systemfehler beseitigt zu haben, machen oft die Kaufentscheidung unumgänglich.

Als Vorsichtsmaßnahme sollte man die Korrektheit solcher Versprechen unbedingt verifizieren, indem zum Beispiel ein Probelauf der betrieblichen Datenbankrealisation auf der Basis des neuen Systems vereinbart wird. Erst hierdurch läßt sich klären, in welchem Umfang das Herstellerversprechen eingelöst werden kann - insbesondere, was die Aufwärtskompatibilität der betriebseigenen Software anbelangt. Oftmals ist hier ein nicht zu unterschätzender Anpassungsaufwand erforderlich.

Aber auch ohne Release-Wechsel muß der Wartungsaufwand der eigenen Software berücksichtigt werden. Dieser wird einerseits durch die Unmöglichkeit vollständig ausgetesteter Programme und zum anderen durch veränderte Benutzeranforderungen hervorgerufen.

Der Beitrag ist dem Arbeitshandbuch "Relationale Datenbanksysteme und zugehörige Werkzeuge" der I.M.C.A. AG, Institut für moderne Computer Applikationen, CH-8117 Fällanden (Schweiz), entnommen. Die Autoren dieser Studie sind Reinhard Hellwig, Hans Kemnitz und Gerhard Vogel.