Mit ihrem Anwendungsentwicklungs-Konzept AD/Cycle entwirft die IBM die Vision einer integrierten Software-Erstellung. Die Wirklichkeit hinkt diesem Entwurf jedoch hinterher. Unter anderem hapert es, so Ernst Kelting*, an einer Beschreibung des Informationsmodells sowie an Werkzeugen, die mit dem Repository-Manager zusammenarbeiten können.

*Ernst Kelting ist Geschäftführer der MSP GmbH, Pinneberg. Der hier veröffentlichte Beitrag basiert auf einem Artikel, der in der Ausgabe 2/90 der Vierteljahres-Zeitschrift "Information Management" veröffentlicht wurde.

Die Entwicklung von Anwendungssystemen befindet sich im Umbruch: Wurden in den 70er Jahren im wesentlichen isolierte Lösungen für einzelne Abteilungen erstellt, so traten in den 80er Jahren durch den verstärkten Einsatz von Datenbanksystemen integrierte Applikationen in den Vordergrund.

Damit stieg gleichzeitig die Komplexität der Entwicklung; die verwandten Werkzeuge blieben aber häufig die gleichen und hielten deshalb den gestiegenen Anforderungen nicht stand. Methodisches Vorgehen beschränkte sich auf den Kauf von Vorgehensmodellen und Methoden in Ordnerform, die bald im Schrank verstaubten.

Mit allerlei Werkzeugen wurde versucht, des Anwendungsstaus Herr zu werden. Aber heute noch findet man nur schwer Anwender, die CASE-Werkzeuge bereits erfolgreich im Einsatz haben. Es zeigte sich, daß diese Werkzeuge nur dann auf lange Sicht erfolgreich einzusetzen sind, wenn sie durch eine gemeinsame Datenbasis über alle Projekte integriert werden.

Wer sich auf die Anwendungsentwicklungs-Probleme der 90er Jahre umfassend vorbereiten will, kann sich dieses Themas nicht allein durch den Erwerb weiterer Werkzeuge entledigen, die häufig die nicht mehr tragfähigen Methoden der Vergangenheit unterstützen. Vielmehr müssen den Mitarbeitern, die Anwendungssysteme entwickeln, unterstützen und pflegen sollen, die notwendigen Fachkenntnisse für die künftig einzusetzenden Methoden und Werkzeuge vermittelt werden.

Eine komplette Information-Engineering-Umgebung besteht aus drei Bausteinen: Datenmanagement, strategische Informationsplanung und Software-Engineering. Niemand wird alle drei Bereiche zum selben Zeitpunkt einfuhren können; doch sollte jedes Unternehmen einen Plan aufstellen, wie diese Ziele zu erreichen sind.

Die Basis für eine Information-Engineering-Umgebung ist dabei eine stabile Anwendungsentwicklungs-Plattform. Hier hat IBM mit dem Produkt Repository Manager/MVS ein Werkzeug in petto, das nach den bisher vorliegenden Informationen technisch als State of the Art zu bezeichnen ist. Basierend auf einem Entity-Relationship-Modell, kann der Anwender alle Informationen über sein Unternehmen speichern und dabei nicht nur Daten, sondern auch die zwischen ihnen bestehenden Beziehungen beschreiben.

Für den User dürfte der größte Vorteil langfristig der sein, daß die Schnittstelle zum Repository - im Rahmen von SAA - künftig von allen Software-Anbietern als ein genormtes Interface eingesetzt wird. Leider ist dieser Standard aber nur eine IBM-Norm, da das Repository den ANSI/IRDS-Standard nicht voll erfüllt. Höchstwahrscheinlich wird es kurzfristig nicht zu einer von allen Herstellern akzeptierten Repository-Schnittstelle kommen, so daß die Portabilität von Werkzeugen in verschiedene Software-Umgebungen schwierig bleibt.

Mit dem Repository ist bisher nur das Fundament für eine Anwendungsentwicklungs-Umgebung angekündigt worden. IBM war bisher nicht sehr großzügig in bezug auf die technischen Daten des Repository; doch scheint eine leistungsstarke Hardware erforderlich zu sein, um das notwendige Anwortzeit-Verhalten zu erreichen. Dem Vernehmen nach besteht das Standard-Informationsmodell, das von IBM mitgeliefert wird, aus mehr als 500 DB2-Tabellen, und pro TSO-Benutzer sind zusätzlich zwölf MB Hauptspeicher erforderlich.

Da das Repository selbst auf einem Entity-Relationship-Modell basiert, ist kein direkter SQL-Zugriff möglich. Benutzeranfragen wie: "Welches Programm benutzt die Kundendatenbank?", müssen also anscheinend über QMF gestartet werden. Es gibt eine lange Liste von Software, die allein für den Einsatz des Repository erforderlich ist. Das reicht bis hin zu einer Pascal-Bibliothek, die Voraussetzung für die SCLM-Komponente des ISPF ist.

Bisher wurde die Datenbank für das Repository, nämlich DB2, im allgemeinen nur auf der Produktionsmaschine gefahren. Beim Einsatz des Repository kommt der Anwender höchstwahrscheinlich nicht mehr um eine zusätzliche Investition in die gesamte Datenbanksoftware für die Test- und Entwicklungsmaschine herum.

Allein auf der Mainframe-Seite wird das Repository sehr leicht Investitionen in einer Größenordnung von über zwei Millionen Mark verursachen, ohne daß hierbei schon irgendeine Hard- und Software auf der Workstation-Ebene berücksicht wäre. Die Ausbildung der Mitarbeiter dürfte zusätzlich Kosten in der gleichen Größenordung verursachen.

Investitionskosten in gewaltiger Höhe

Neben den gewaltigen Investitionskosten dürfte aber während der ersten Jahre vor allen Dingen das Fehlen von Werkzeugen, die mit dem Repository arbeiten, der Haupthinderungsgrund für den Einsatz sein. Nur IBM hat bislang - mit dem Produkt Developmate - ein Werkzeug angekündigt, das direkt mit dem Repository zusammenarbeiten soll und für das auch ein Verfügbarkeitsdatum angegeben ist.

Um eine möglichst allgemeine Nutzung des Repository zu erreichen, hat IBM mit 35 ausgewählten Unternehmen vereinbart, daß diese ihre Werkzeuge dem Repository anpassen werden. Doch selbst diejenigen Unternehmen, mit denen IBM eine besonders enge Zusammenarbeit vereinbart hat, nennen bis heute keine Verfügbarkeitsdaten (außer für eine OS/2-Version).

Einer der Hauptgründe hierfür ist das Fehlen einer Beschreibung für das von IBM zu liefernde Informationsmodell, das aus etwa 160 Entitäten und 360 Beziehungen zwischen diesen Entitäten besteht. Nachdem IBM 1989 die Dokumation - bestehend aus Business-, Design-, und Technology-Modellen - für das erste Quartal 1990 angekündigt hatte, ist inzwischen von Verzögerungen zu hören, so daß das gesamte Modell jetzt wohl erst im vierten Quartal dieses Jahres zur Verfügung stehen wird.

Das Technology-Modell, das die physische Abbildung der Daten beschreibt (zum Beispiel DB2-Tabellen und -Views), ist verhältnismäßig einfach zu definieren. Diese Aufgabe wird jedoch schwierig beim Design-Modell, weil es von den für die Analyse und das Design der Softwareprojekte angewandten Methoden abhängig ist.

Da IBM nicht beabsichtigt, eine Methode zur Software-Entwicklung vorzuschlagen, wird sich das Informationsmodell auf solche Entitäten beschränken müssen, die im allgemeinen von allen Methoden verwendet werden. Vielleicht wäre es sogar am besten, wenn das Design-Modell von dem Methodenlieferanten geliefert würde, weil es in wesentlichen Teilen von den verwendeten Methoden bestimmt wird.

Die größte Schwäche des AD/Cycle-Konzepts ist vielleicht durch den Entwicklungsort USA begründet. Da dort alle drei Monate der nächste, noch mehr Gewinn ausweisende Unternehmensbericht publiziert werden muß, ist in den Firmen oft nur kurzfristiges Erfolgsdenken vorhanden.

In Europa findet man sehr viel häufiger integrierte Anwendungen, die über einen langen Zeitraum hinweg entwickelt wurden; hat ein Unternehmen sich erst einmal für Methoden und Standards entschieden, so werden diese meist für alle Projekte eingesetzt.

Erst die Methoden, dann die Werkzeuge

Daher finden sich in Europa heute viele Firmen, die IBMs AD/Cycle-Vision de-facto bereits einsetzen und wesentliche Schritte wie die Einführung eines unternehmensweiten Dictionary oder Repository schon vor zehn Jahren begonnen haben. In den USA hingegen sind häufig nur projektweise eingesetzte Dictionaries vorhanden, die oft von verschiedenen Herstellern stammen. Eine Konsolidierung dieser Informationen ist genauso schwierig wie die von Enzyklopädien, die pro User oder Teilprojekt auf verschiedenen Workstations angelegt wurden.

Ein Anwender, der sich eine Information-Engineering-Umgebung schaffen will, sollte sich zunächst für eine Entwicklungsmethode oder einen Methodenverbund entscheiden. Nur wenn bekannt ist, welche Methoden eingesetzt werden sollen, kann über die notwendigen Werkzeuge entschieden werden - nicht umgekehrt.

Fundament für Engineering-Umgebung

Ein weiterer wichtiger Schritt ist die Einführung eines Datenmanagements; es ist die Basis für erfolgreiches Software-Engineering und für strategische Informationsplanung, denn alle Prozesse benötigen oder erzeugen Daten. Mit der Qualität der Daten wird das Fundament für eine Information-Engineering-Umgebung gelegt.

Weiter ist zu entscheiden, was mit den schon vorhandenen Informationen geschehen soll. In Job-Control, Datenbankbeschreibungen und Programmen sind heute viele Daten und Beziehungen vorhanden.

Es muß allerdings geprüft werden, wie verläßlich die oft maschinell gewonnenen Informationen sind. Beispielsweise ist zu fragen, ob alle in einer Bibliothek vorhandenen Jobs Oberhaupt noch genutzt werden.

Bezüglich des Erwerbs von Werkzeugen sollte ein Anwender, der mit dem IBM-Repository arbeiten will, überprüfen, wann das jeweilige Tool - falls Oberhaupt - mit dem Repository zusammenarbeiten kann. Häufig erteilt IBM selbst den Rat, die ersten Erfahrungen nicht mit AD/Cycle-Werkzeugen zu sammeln, sondern später umzusteigen. Dieser Vorschlag betrifft beispielsweise das bereits etablierte Prozeßmanagement-Produkt ADPS.

Repository wird zentrale Rolle spielen

Zu fragen ist hier aber, wer sich eine Software-Investition von rund 400 000 Mark plus Schulung leistet, nur um Erfahrungen zu sammeln - zumal mit Sicherheit nach einiger Zeit die Umstellungskosten auf eine neue Version dazukommen. Mag auch der Kauf von einigen preiswerten Workstation-Produkten das Gewissen beruhigen, so kann dieses Vorgehen ohne Gesamtstrategie doch eher negative Folgen für das Unternehmen haben. Denn Ziele die man nicht kennt, kann man nicht erreichen.

Langfristig wird das Repository sicherlich für alle Unternehmen, die selbst Anwendungsentwicklung betreiben, eine zentrale Rolle spielen. Entscheidend ist dabei aber, daß es genügend Werkzeuge gibt, die die dort gespeicherten Informationen verarbeiten können beziehungsweise sie erst dort hineinstellen. Außerdem wird AD/Cycle solange eine Vision bleiben, wie die Entwicklungsmethode für das Unternehmen nicht festgelegt und eingeführt wurde.