Leistungsstarke Datenbank-Software ist notwendig, will man die Daten in einer DV-Großinstallation wirtschaftlich und geschützt "organisieren". Ausgelöst durch Probleme mit dem alten Datenbanksystem DBOMP erfolgte im Hause Hilti in der Zeit von Anfang 1977 bis Mitte 1979 eine Datenbank-Evaluation mit anschließender Umstellung. Dieser Bericht zeigt zusammenfassend die wichtigsten Überlegungen und Erfahrungen aus diesem Projekt und gibt einen Ausblick auf zukünftige Aktivitäten.

Der Anstoß zur Evaluation eines neuen Systems erfolgte wegen sehr vieler ständig sich verstärkender Probleme. Im Vordergrund standen folgende: Die Nutzung moderner Großraumspeicher war mit DBOMP nicht mehr gewährleistet (Adressierungskonzept). IBMseitig erfolgte keine DBOMP-Weiterentwicklung. Die Online-Fähigkeit war eingeschränkt, da ein Batch-Konzept vorlag (speziell auch Recovery/Restart). Die Datenbank-Administration war sehr aufwendig. Der Multi-Partition-Betrieb war eingeschränkt. Die Reaktion auf Ad-hoc-Informationsbedürfnisse war unbefriedigend (keine Abfragesprache). Wegen der Abhängigkeit von der Datenbank war programmseitig der Unterhaltsaufwand erheblich: keine Datenschutzmöglichkeiten und kein Data Dictionary. Und nicht zuletzt waren die Zugriffsmöglichkeiten und die Datenstrukturierung stark beschränkt .

Im Rahmen unserer Evaluationsarbeit wurden die Datenbanksysteme Total (Cincom), DL/1 (IBM) und Adabas (Software AG) geprüft. Für die Berücksichtigung dieser Alternativen waren die Gründe ausschlaggebend, wie sie in Tabelle 1 zusammengestellt sind. Die zugrundegelegten Entscheidungskriterien und deren Gewichtung wurden aus der Hilti-lnformationsstrategie abgeleitet. Die möglichst weitgehende Quantifizierung der Zielerreichung pro Alternative und Entscheidungskriterium erfolgte anhand eines detaillierten Kriterienkatalogs (Tabelle 2). Dieser lehnte sich weitgehend an den in (1) vorgeschlagenen Katalog an.

Zusätzlich wurde versucht, die wichtigsten Einflußgrößen bezüglich der gesamten Informatikkosten zu quantifizieren, um im Sinne einer Kostenvergleichsrechnung eine zusätzliche Entscheidungshilfe bereitzustellen, nämlich: Kosten der Datenbank-Software, Aufwand der Datenbank-Administration, Aufwand für Programmentwicklung und Unterhalt sowie Hardware-Kosten (Leistungs- und Speicherbedarf).

Die Evaluation erfolgte in Schritten:

1. Januar 1977: Definition der Anforderungen und der Kriterien

2. Februar 1977: Grobevaluation mit: DL/1, Total, Adabas

3. März 1977: Selektion DL/1 und Adabas für Detailevaluation

4. August 1977: Detailevaluation (Studium Unterlagen, Referenzen, Testinstallation mit Pilotumstellung)

5. September 1977: Entscheid für Adabas

Die Entscheidung wurde zugunsten Adabas getroffen, weil dieses System aus unserer Sicht vor allem wesentliche Vorteile in den Kriterien "Flexibilität" und "Benutzerfreundlichkeit" aufweist und ein zukunftsorientiertes Datenmodell verwendet. Dieses Datenmodell unter Verwendung "invertierter Listen" entspricht in wesentlichen Punkten den Anforderungen des Relationenmodells.

Die Umstellung erfolgte im Zeitraum Oktober 1978 bis Juli 1979 mit einem Aufwand von rund 800 Manntagen. Für die Umstellung waren folgende Ziele gesetzt:

Die Umstellung muß mit minimalen Risiken erfolgen.

Der laufende RZ-Betrieb muß zur vollen Zufriedenheit der Benutzer aufrechterhalten werden.

Der Umstellungsaufwand soll minimal sein.

Neue DBMS-Funktionen sollen möglichst ausgenutzt werden.

Bereits laufende Projekte dürfen nicht gestoppt werden.

Erschwerende Einflüsse bei der Umstellung waren einmal der dreischichtige Systembetrieb mit intensivem Online-Betrieb von 07.00-17.00 Uhr. Hinzu kam die Umstellung von insgesamt 800 produktiven Programmen (davon etwa 200 Online-Programme) und etwa 70 permanenten Dateien. Und schließlich wies der gesamte Anwendungskomplex einen hohen Integrationsgrad mit entsprechend hohem Daten-Programm-Verknüpfungsgrad auf.

Welche Überlegungen haben wir zur +Umstellungsplanung angestellt? Die Festlegung des DB-Designs hat einen entscheidenden Einfluß auf das Umstellungskonzept. Einerseits soll die Leistungsfähigkeit und Funktionalität des neuen Systems bereits in der Umstellung genutzt werden. Dies resultiert in vielen Fällen in DB- und Programm-Redesign (hohe Umstellungskosten und -risiken). Andererseits ist man bestrebt, Umstellungsaufwand und -risiken möglichst klein zu halten, das heißt, Programme und Daten möglichst automatisiert zu konvertieren. Dies bedingt eine 1:1-Umstellung und damit eventuell einen eingeschränkten Systemeinsatz.

Wir haben uns grundsätzlich für eine 1:1 -Umstellung mit Abweichungen in Datei-Layouts und Zugriffspfaden entschieden. Die wichtigsten Grunde dazu waren folgende: Die bestehende Datenorganisation läßt sich ohne wesentliche Einschränkungen mit Adabas abbilden. Zweitens lassen Flexibilität und Benutzerfreundlichkeit des neuen Systems eine sukzessive Optimierung des DBMS-Einsatzes in vernünftiger Zeit zu, und drittens wären Risiko und Aufwand bei einem DB-Redesign zu groß gewesen.

Bei der Wahl des +Umstellungsteams war anfänglich ein Spezialteam vorgesehen. Aufgrund des großen Kapazitätsbedarfs (rund 800 Manntage) und der notwendigen Programmkenntnisse wurde jedoch die gesamte Programmierabteilung eingesetzt.

Bezüglich des +Vorgehens wurden zwei Varianten in Betracht gezogen. Einmal die Zeitpunktumstellung: Hier erfolgt die Umstellung der gesamten Programme/Daten zu einem bestimmten Zeitpunkt beziehungsweise in mehreren Stufen (Zeitpunktumstellung je Stufe). Die andere Variante ist jene im Rahmen von Neuentwicklungen: Das neue DBMS wird schrittweise mit neuen Projekten eingeführt, wobei jeweils tangierte, bereits vorhandene Datenbestände ebenfalls neu organisiert und betroffene alte Programme angepaßt werden. Das Problem der Umstellung aller Programme/Daten wird durch bewußtes Halten von redundanten Daten (mit Abgleichsfunktionen) reduziert.

Wir haben uns aus den nachgenannten Gründen für eine þZeitpunktumstellung entschieden: Erstens möglichst frühzeitige Nutzung der Vorteile des neuen DBMS und zweitens die Vermeidung von Problemen aus einer längerfristigen Parallelführung von zwei verschiedenen DBMS.

Zur +Absicherung der Umstellung wurden folgende Sicherheitsmaßnahmen getroffen: Reduktion des Unterhaltsaufwandes auf ein absolutes Minimum, da über längere Zeit pro Programm zwei Versionen existieren. Sodann war die Umstellung als Top-Priorität-Projekt" in der gesamten Informatikplanung (während der Umstellung möglichst keine Projekte mit Programmierbedarf) zu berücksichtigen. Ferner wurde eine Schnittstelle für Programme ohne Chain-File-Verarbeitungsfunktionen (Reduktion (...) Umstellungsaufwandes) entwickelt. Es wurde eine spezielle Testdatenbank aufgebaut und unterhalten. Wir haben zudem spezielle Vergleichsprogramme DB-alt/neu entwickelt. Auch erfolgte der Einsatz zusätzlicher Disk-Spindeln für Testbetrieb mit möglichst wenig Einschränkungen. Und schließlich mußten bestimmte Wochenenden für ausgedehnte Parallelläufe reserviert werden; während der Betriebsferien l979 war der Computer ausschließlich für die Umstellung eingesetzt!

Im August 1979 war die Umstellung abgeschlossen. Die wichtigsten Erfahrungen aus Evaluation, Umstellung und DB-Einsatz seien nachstehend zusammengefaßt.

Insbesondere aufgrund der aufgetretenen Schwierigkeiten in der Umstellung sind bei einer künftigen Evaluation einige Punkte besonders (...)beachten:

- Einer Testinstallation mit einer repräsentativen Pilotumstellung (Programme, Daten) sollte größte Bedeutung beigemessen werden. Warum? Eine Pilotumstellung vermittelt Wissensvertiefung, konkrete Informationen bezüglich des Umstellungsaufwandes und der Umstellungsaktivitäten. Sie vermittelt Informationen über Leistungsvermögen, Systembelastung und Hardware-Bedarf, über die Einsatzbereitschaft des Herstellers, über System-Qualität, über die Tauglichkeit von Schulung und Dokumentation sowie die Handhabungsfreundlichkeit.

- Die Pilotumstellung sollte möglichst durch jene Personen vorgenommen werden, welche die effektive Umstellung durchführen.

- Schon während der Evaluation ist eine detaillierte Analyse bestehender Programme und Daten vorzunehmen, damit der Umstellungsaufwand realistisch abgeschätzt werden kann. Speziell zu beachten sind dabei alte und schlecht dokumentierte Programme.

- Dem Kriterium "Flexibilität" muß eine hervorragende Bedeutung beigemessen werden. Dabei spielen vor allem die DBMS-Einrichtungen eine Rolle, welche eine größtmögliche Programm/Daten-Unabhängigkeit gewährleisten.

- Das Kriterium "Leistungsfähigkeit" läßt sich nicht im Rahmen einer Papierevaluation erhärten. Falls sich die Leistungsfähigkeit als kritischer Faktor herausstellt, sind ausgedehnte Simulationen und Benchmarks notwendig! Aufgrund der zusätzlich notwendigen Maschinenkapazität für Paralleltests und der schwer abschätzbaren Belastung durch das neue DBMS ist es bei bereits kritischer Auslastung der CPU vorteilhaft, den Umstellungsbeginn mit einem Hardware-Upgrade zusammenfallen zu lassen.

- Falls sich der zum Teil in der Literatur und in der Realität aufgezeigte Trend "DBMS- und Betriebssystemfunktionen stärker integriert" bewahrheitet, könnte der Einsatz von "DBMS-Fremd-Software" problematisch werden.

Erfahrungen bei der Umstellung

Aus heutiger Sicht kann die Wahl der Alternativen bezüglich Design, Team und Vorgehen als richtig eingestuft werden. Relativ problematisch ist die Durchführung des notwendigen Unterhalts (2 Versionen). Aus diesem Grund sollte eine möglichst abgestufte Vorgehensweise angestrebt werden.

Der Einsatz der gesamten Programmierkapazität für die Umstellung bedingt eine Zurückstellung von Benutzerwünschen. Die frühzeitige Information aller betroffenen Stellen ist sehr wichtig.

Wegen der relativ uninteressanten Umstellungsarbeiten während längerer Zeit ist der Motivation des Umstellungsteams große Aufmerksamkeit zu schenken.

Trotz der gewählten " Zeitpunktumstellung" mußte der Computer während drei Wochen ausschließlich für die Übernahme benutzt werden (Betriebsferien) .

Der Aufwand für Tests, Parallellaufe und nachfolgenden Vergleich der Datenbanken ist beachtlich und darf nicht unterschätzt werden.

Bei Hilti werden momentan noch nicht alle Adabas-Funktionen benutzt. Aufgrund der bisherigen Erfahrungen laßt sich sagen, daß die in der Evaluation ermittelten Leistungserwartungen erreicht wurden. Viele zusätzliche Möglichkeiten des neuen Systems können allerdings wegen der 1:1-Umstellung erst jetzt und schrittweise genutzt werden, wie zum Beispiel Datenschutzeinrichtungen und Zugriffsflexibilität.

Das Antwortzeit-Verhalten, der Systemdurchsatz und die resultierenden Systembelastungen sind zufriedenstellend und auch ohne Optimierungen besser als mit dem alten System. Trotzdem steht im kurzfristigen Bereich das DB-Tuning im Vordergrund: richtige Auslegung von Ein- und Ausgabepuffern, physische Verteilung der Datenbank und Beseitigung von Sorts durch Sekundärschlüssel.

Eine Sofortverbesserung für die Benutzer ist vor allem die leistungsstarke Recovery/Restart-Funktion (praktisch keine Kalt-Restarts mehr). Für die Programmierung hat sich die Verfügbarkeit einer guten Abfragesprache als zeitsparender Faktor herausgestellt.

In den nächsten 1-2 Jahren stehen vor allem folgende Schwerpunkte im Vordergrund:

Die Unabhängigkeit zwischen Programmen und Daten soll verbessert werden, da sich ein bedeutender Teil von Unterhalts- und Weiterentwicklungskosten reduzieren läßt. Durch die von den Anwendungsprogrammen getrennte Definition von Daten und Zugriffsprozeduren (einschließlich Plausibilitätskontrollen) sollen Auswirkungen auf Programme, die sich aus Änderungen der Datenbank ergeben, möglichst reduziert werden. Zusätzlich wollen wir eine weitgehende Unabhängigkeit von der Datenbank-Software erreichen. Dies mit Hilfe eines oder mehrerer Interface-Module und eines Data Dictionary.

- Datenschutz:

Die an sich sehr guten Datenschutzmöglichkeiten von Adabas sind für unseren Praxiseinsatz ungenügend und müssen durch eine Eigenprogrammierung ersetzt werden.

- Abfragesprache (Query Language):

Teilfunktionen der bis jetzt ausschließlich informatikintern eingesetzten Abfragesprache sollen dem Benutzer verfügbar gemacht werden. Damit wird die Reaktionszeit auf Ad-hoc-Informationsbedürfnisse verkürzt.

- Data Dictionary:

Als wichtigsten Schwerpunkt betrachten wir den Einsatz eines Data Dictionary, mit dessen Hilfe Daten Prozesse und deren statische und dynamische Beziehungen untereinander und zu den Benutzern beschrieben werden können. In der Endstufe soll der Data Dictionary nicht nur für produktiv genutzte Systeme/Daten, sondern bereits im Rahmen der Systementwicklung als projektbegleitendes Dokumentationsinstrument eingesetzt werden.

Anpassungen an geänderte Verhältnisse: Das oben geschilderte Evaluationsverfahren wurde im September/Oktober 1980 ein zweites Mal in den USA angewendet. Dabei wurden die folgenden Anpassungen an die veränderten EDV-Verhältnisse vorgenommen:

- Bei den Entscheidungskriterien wurde wegen der billiger werdenden Hardware der Punkt Hardware-/Software-Bedarf von acht Prozent auf drei Prozent Gewichtung reduziert, dagegen wurde Datenschutz/Datensicherheit von zwölf Prozent auf zwanzig Prozent angehoben. Den amerikanischen Verhältnissen entsprechend wurde "Ease of Use" höher bewertet.

- Der in (1) vorgeschlagene Kriterienkatalog wurde durch Fragen bezüglich herstellerabhängiger Data Dictionaries ergänzt. Die Fragen bezüglich Datenschutz wurden den erhöhten Anforderungen angepaßt.

Literatur: 1. Datenbanken. Leitfaden zur Planung und Systemevaluation, Verlag Industrielle Organisation, Zürich. Peter Hanstein Verlag, Köln

2. Leo J. Cohen: Data Base Management Systems Q. E. D. Information Sciences, Wellersley/Mass.

* Peter Eschenmoser ist Leiter der Informatik-Systementwicklung, Dipl. Ing. ETH Bruno Tödtli ist Leiter der Systemsoftware bei der Hilti AG in Schaan, Liechtenstein. Die COMPUTERWOCHE veröffentlicht den Beitrag mit freundlicher Genehmigung der Management-Zeitschrift io - "Industrielle Organisation" -, herausgegeben vom Betriebswissenschaftlichen Institut der Eidgenössischen Technischen Hochschule (ETH), CH-8028 Zürich.