Nachdem sich die IBM vom Herzstück ihres AD/Cycle. Konzepts, dem Repository Manager/MVS, verabschiedet hat, rätselt ein Großteil der DV-Welt, woran das großangelegte Konzept eigentlich gescheitert ist. Im folgenden Kommentar werden der IBM sechs entscheidende Fehler nachgewiesen.

Jahrelang geisterte er durch die Argumentationsketten der IBM: das designierte Kernstück des Anwendungsentwicklungs-Konzepts AD/Cycle, der Repository Manager/MVS. Wie ein galaktisches schwarzes Loch sollte er alle Informationen zur Softwareproduktion beim Anwender aufsaugen. Namhafte Großkunden auf der ganzen Welt haben unter dem Siegel der Verschwiegenheit Vorabversionen zu Testzwecken erhalten; eine Vielzahl von "AD/Cycle-Partnern" wurden gewonnen, die sich verpflichteten, ihre CASE- und Re-Engineering-Werkzeuge darauf einzustellen. Alle warteten sie auf den großen Moment, in dem der Schleier gelüftet werden sollte.

Und was kam dann? Der Absturz! "IBM läßt den Plan von einem umfassenden Repository fallen" lesen wir auf der Titelseite der CW Nr. 30 vom 24. Juli 1992 - in ungewohnt zurückhaltender Diktion. Die Formulierung: "Ein Luftschloß stürzte in sich zusammen" wäre dem Sachverhalt angemessener gewesen.

Verfolgen wir die Geschichte doch einmal zurück: Die Anfänge waren überzeugend. Als im April 1987 die System-Anwendungs-Architektur (SAA) angekündigt wurde, galt sie als IBMs erster Versuch, unterschiedliche Plattformen für Anwendungssoftware portabel und interoperabel zu machen. SAA hat zwar nie alle heterogenen Systeme der IBM eingeschlossen. Ohne daß IBM dies wollte, gab SAA jedoch dem Trend zu offenen Systemen einen kräftigen Schub. Der drei Jahre später ausgegebene Slogan "Open Enterprise" hat dies bestätigt.

Eine Referenz an die entscheidende Bedeutung der Softwareproduktion für den Anwender stellte die AD/Cycle-Ankündigung im Herbst 1989 dar. Der auf der SAA-Plattform aufbauende -"Application Development Cycle" war nie wesentlich mehr als ein konzeptionelles Schema und keineswegs ein integriertes Werkzeug-Portfolio, wie der Markt es eigentlich erwartet hatte. Durch die bloße Ankündigung brachte das Marketing der IBM jedoch etwas fertig, das weder ändere Anbieter noch die CASE-Gurus geschafft hatten: Die Anforderungen an die Softwareproduktion wurden zum Thema für die Unternehmensleitung. In dem Maße, in dem die Vorstände ja zu- AD/Cycle sagten, standen die DV-Chefs unter dem Druck, sich an die Richtlinien des IBM-Konzepts zu halten.

Diese Strategie war also durchaus tauglich, die bis dahin eher empirisch orientierte Produktion kaufmännischer Softwaresysteme auf ingenieurmäßige Verfahrensweisen und Methoden umzustellen..

Dabei war AD/Cycle im Kern nie eine Erfindung der IBM, sondern ein geschickter Marketing-Rahmen, mithin eine kompakte und damit für Manager handhabbare Strukturierung des Wissens über Softwareproduktions-Anforderungen, wie es seit mehr als 20 Jahren in der CASE-Literatur von Ed Yourdon, Roger Pressman, Tom DeMarco und anderen gesammelt wurde.

Leider machte die IBM hier bereits den ersten Fehler: Sie stützte sich allein auf die strukturierten Schemata der Softwareproduktion, nämlich auf das Wasserfallmodell und die relationalen Datenstrukturen, anstatt zu erkennen, daß sie erst spät in den Markt eingetreten war und andere Experten sowie Partnerunternehmen längst neuere Schemata wie Objektorientierung und Spiralmodell diskutierten.

Der zweite Fehler der IBM war folgender: Sie übersah, daß mit CASE ß la AD/Cycle nur zwischen fünf und 20 Prozent der Aufgaben gelöst werden können, denen sich der Leiter der Anwendungsentwicklung typischerweise stellen muß. Auf die Frage, wie die "alten" Anwendungen am Leben erhalten und weiterentwickelt werden sollen, gab AD/Cycle keine Antwort, wenn man einmal von einigen Bachman-Werkzeugen zur Restrukturierung von Daten absieht.

Der dritte Fehler war die exklusive Zuordnung des Repository Managers zum MVS-Mainframe. Für CASE-Experten stellte es von Anfang an einen Widerspruch dar, daß IBM einerseits - dem weltweiten Trend folgend - die CASE-Werkzeuge auf Workstations und lokale Netze auslagerte, andererseits aber den Repository Manager auf MVS belassen wollte.

Zugleich passierte der vierte Fehler: Die IBM verfolgte vorrangig das Ziel, mit Hilfe des Repository Managers den Mainframe vor der Erosion durch Unix und offene Systeme zu bewahren. Darüber vergaß sie, ihren Kunden zu erklären, daß die Einrichtung von Repositories zunächst eine methodische Aufgabe ist - genau wie die Datenmodellierung, die strukturierte Analyse etc.

Kein DV-Verantwortlicher kommt auf Dauer darum herum, die sogenannten Metadaten, also alle Informationen, die für die Produktion von Anwendungssoftware bedeutsam sind, zu sammeln, sowie verfügbar und recherchierbar zu halten. Ehe diese Daten in einer Metadatenbank wie dem IBM-Repository gespeichert werden können, müssen zunächst einmal die verfahrensmäßigen und methodischen Bedingungen sowie die Management-Kompetenz dafür aufgebaut werden. Und dieser Prozeß ist bis heute unbewältigt. Fragen Sie doch einmal einen Software-Entwickler, welche Unternehmensziele er mit seiner Arbeit unterstützt oder welche Auswirkungen sein Anwendungssystem auf Nachbarsyteme hat oder...

Natürlich gibt es in vielen Unternehmen Gruppen von Entwicklern, die moderne Methoden und Verfahren anwenden und sich sogar der notwendigen Aufmerksamkeit durch Unternehmensleitung und Fachabteilung erfreuen. Diese Leute sind durchaus reif dafür, Repositories einzusetzen, und das tun sie auch; nur heißen die Metadatenbanken dann Datamanager, Enzyklopädie oder Data-Dictionary und stammen von Firmen wie James Martin Associates, MSP, R&0 oder SAP.

Die ganze Zunft in den Wartestand versetzt

Manche Leser werden jetzt sagen: Aber das ist doch noch nicht das Repository! Mag sein, aber wie bei jeder komplexen Aufgabe, so ist es auch hier wichtig, mit kleinen Schritten anzufangen. IBM hingegen hat versucht, die ganze Zunft der Software-Ingenieure in den Wartestand zu versetzen - solange, bis endlich der Repository Manager/MVS als eine Art allumfassender Erlöser erschien. Wer aber konnte ernsthaft glauben, daß damit der schwierige Weg zur Bewältigung der Repository-Aufgabe einfacher werden würde?

Nun ist der Repository Manager/MVS tot. Besinnt sich IBM also auf den pragmatischen Weg der kleinen Schritte? Nein, sie versucht erneut, die CASE-Fachleute auf der Hoffnungsschiene zu parken. Anläßlich einer Beratertagung, die am 12. August dieses Jahres in Frankfurt stattfand, verkündete IBM, jetzt komme ein LAN-Repository. Gerüchteweise hört man auch, daß mit dem Alliance-Partner Bachman daran gearbeitet werde.

Die IBM-Strategie für all diese Entwicklungen Partner hinzuzuziehen, ist verständlich; denn weltweit wurde die Erfahrung gemacht daß CASE-Entwickler in so großen Organisationen, wie sie IBM oder andere Hersteller verkörpern, einfach nicht erfolgsorientiert arbeiten können. Das ist ja auch kein Problem. Schließlich hat in allen Industriebereichen die Wahl der richtigen Partner strategische Bedeutung gewonnen. Jeder soll sich auf seine eigenen Stärken besinnen. Auch das ist ein strategischer Aspekt der Lean Production.

Aber anstatt jetzt die Anwender und die Softwarepartner zu ermutigen, die notwendigen Vorkehrungen zum Sammeln der Metadaten zu treffen und die Metadatenbanken in dem Umfang zu nutzen, in dem sie heute verfügbar sind, wirft IBM mit der lauen Ankündigung eines LAN-Repositories wieder Nebelkerzen.

Auf der oben erwähnten Tagung wurde auch gesagt, daß für das LAN-Repository objektorientierte Techniken berücksichtigt werden sollen. Weiterhin werde das Informationsmodell des Repository Managers/MVS, das jetzt ohne Basis frei im Raum schwebt, in der neuen Metadatenbank abgebildet. Das hört sich gut an. Aber wie, bitteschön, kann ein Informationsmodell, das methodisch nach dem Entity-Relationship-Schema entwickelt wurde, in einem objektorientierten Repository abgebildet werden? Fachleute sind da sehr skeptisch.

In die technische Ecke abgeschoben

Im Zusammenhang mit Unix beziehungsweise AIX sei ein weiterer Blick in die Vergangenheit erlaubt: in der frühen SAA-Zeit wurde Unix von IBM strikt in die Ecke der technischen Anwendungen (CAx) abgeschoben. Das war der fünfte Fehler. Inzwischen stellt Unix nämlich die Plattform für alle offenen Standards dar, die künftig für technische wie für kaufmännische Anwendungen maßgebend sind.

Zwar rüsten die Hersteller ihre proprietären Systeme wie MVS und OS/400 (beide IBM), MPE (HP) und VMS (DEC) mit Standardschnittstellen nach und machen sie auf diesem Umweg ebenfalls zu offenen Plattformen. Doch zum einen werden immer mehr Verarbeitungsfolgen von diesen Server-Systemen auf Workstations (Clients) ausgelagert, zum anderen steht für die großen Server der

Sprung auf massivparallele Rechner bevor. Diese Systeme werden, unter Unix eine Leistung bieten, die für MVS wohl kaum mehr erreichbar ist.

Mögen auch die Fachleute die Nachteile von Unix aufzählen; die riesigen Investitionen vieler Hersteller auf der ganzen Welt - auch der IBM - in Unix-Entwicklungen führen zwangsläufig dazu, daß die Bedeutung von Unix steigt, gleichgültig, welche Rolle auf der Client-Seite MS-DOS, Windows NT oder OS/2 spielen mögen.

Viele Solisten ohne gemeinsame Partitur

In puncto CASE zog die IBM aus dieser Entwicklung interessante Konsequenzen: 1991 gab sie die Partnerschaft mit der Firma Softlab bekannt, die mit "Maestro" bereits ein Repository-Produkt anbietet. Außerdem erwarb IBM von Hewlett-Packard eine Lizenz für "Softbench", einen Software-Bus zur Werkzeugintegration. Beide Produkte laufen ausschließlich unter Unix.

In Softbench können beliebige Werkzeuge hineingesteckt werden wie Toastscheiben in einen Toaster. IBM hat die AIX-Version der Software-Umgebung stillschweigend in SDE Workbench/6000 umgetauft. Diese Workbench soll gemäß dem PCTE-Standard der ECMA weiterentwickelt, mit einem Repository versehen und um die Microfocus-Workbench erweitert werden, die bekanntlich hervorragend für Cobol-Entwicklungen geeignet ist. Damit wäre dann die AIX-Plattform für die Entwicklung kaufmännischer Anwendungen gerüstet.

Bleibt die Frage, warum eigentlich Maestro von Softlab nicht zum Repository aufgewertet wird, obwohl es doch alle dazu erforderlichen Merkmale aufweist. IBM hat das damit begründet, daß die Maestro-Architektur in sich geschlossen sei. Richtig! Aber welches Instrument spielt das Softlab-Produkt dann im AD/Cycle-Konzert?

Insgesamt ist fraglich, wie in Zukunft das Zusammenspiel der unübersehbaren Zahl von IBM-Partnern funktionieren soll. Was machen die vielen Solisten, wenn sie sich nicht auf eine gemeinsame Partitur einigen können? Dies zu erklären wäre eine dringend notwendige Aufgabe, die der Orientierung von Beratern und Anwendern dienen würde. Bislang blieb IBM die Antwort darauf schuldig.

Anwender greifen selbst zum Taktstock

Und darin besteht der sechste Fehler. Verweigert IBM die Rolle des Konzertmeisters, so muß der Anwender selbst den Taktstock in die Hand nehmen. Dabei hat er verschiedene Möglichkeiten:

1. Die Betriebe, die für den Einsatz eines Repositories reif sind (im Sinne des Reifegrad-Modells von Watts Humphrey), können Metaspeicher wie Datamanager, Maestro und Rochade einsetzen.

2. Wer vorrangig auf die schnelle Produktion von Anwendungen zielt, wird sich mit Werkzeugen wie Sapiens, Hyperwork, Delta oder Natural helfen - beziehungsweise mit IBMs neuestem AD/Cycle-Joker HPS von Seer, der bei, der Schweizerischen Kreditanstalt gerade den Beta-Test bestanden hat.

3. Unternehmen, die an der Last ihrer Altanwendungen ersticken, profitieren hoffentlich von Viasoft, IBMs neuem Partner für Re-Engineering, der von der Cap Debis GEI vertrieben wird.

4. Hat die Werkzeugintegration den Vorrang, sollten entweder geschlossene Systeme wie IEF von James Martin oder offene Plattformen wie SDE Workbench/6000 beziehungsweise Softbench eingesetzt werden.

5. Für diejenigen, die heute schon Client-Server-Architekturen einsetzen möchten, stehen R/3 von SAP oder Entire von der Software AG zur Verfügung. Eine Kombination der verschiedenen Möglichkeiten ist natürlich denkbar. Wer will, kann also den IBM-Nebel hinter sich lassen Dahinter eröffnen sich genügend Lösungswege. Die orthodoxe Kraft von AD/Cycle ist geschwächt. Jetzt können die Anwender die Kompetenz des AD/Cycle-Modells in bezug auf seine Offenheit erproben.