Die Software-Entwicklungskultur hat in den vergangenen Jahren eine Kehrtwendung um 180 Grad miterlebt. Ende der 80er hatte sich die Idee einer zentralen Entwicklungsdatenbank zu voller Bluete entwickelt, um dann rasch zu verwelken, nachdem die IBM ihr im Juli 1991 den Ruecken gekehrt hatte. Heute arbeiten die Entwickler lieber mit kleinen Tool-eigenen Projekt-Repositories, die nur zum Teil in der Lage sind, auf konventionelle Metadatenbanken zuzugreifen. Nach Ansicht von Peggy Ledvina, Program Director fuer Anwendungsentwicklungs-Strategien bei der Meta Group Inc., Stamford, Connecticut, eignen sich die zentralen Repositories weniger fuer die Neuentwicklung als fuer Maintenance-Aufgaben. Im Gespraech mit CW-Redakteurin Karin Quack bewertet die Analystin die derzeitigen Trends in der Anwendungsentwicklung.

CW: Frau Ledvina, bevor Sie zur Meta Group kamen, waren Sie Produkt- und Marketing-Managerin beim ehemaligen IBM-Partner Intersolv. Woran ist das "AD/Cycle"-Konzept der IBM Ihrer Ansicht nach gescheitert?

Ledvina: IBM wollte, dass alle Beteiligten ihre Umgebungen oeffnen und die internen Metamodelle ihrer Produkte preisgeben. Dadurch fuehlten sich die Partner blossgestellt. Denn es haette bedeutet, dass sie alle Geheimnisse ihrer Werkzeuge offenlegen muessten. Die Idee bestand darin, wirkliche Interoperabilitaet zu erreichen, indem die Daten- und Prozessinformationen uneingeschraenkt zur Verfuegung stuenden und zwischen den einzelnen Tools hin- und hergereicht werden koennten. Dazu sollten alle Informationen an einem Ort zusammengefasst sein. Aber die Anbieter haben diese Informationen nicht vollstaendig herausgegeben, sondern ein Gutteil davon versteckt gehalten. Folglich waren die Informationen, die tatsaechlich ausgetauscht wurden, sehr begrenzt. Ausserdem veraenderten sich die Dinge viel schneller, als IBM reagieren konnte.

CW: Wie sieht die Alternative aus?

Ledvina: Es gibt eigenstaendige Repositories, zum Beispiel von R+O, Reltech, Brownstone und MSP. Diese Anbieter bauen entweder selbst die Bruecken, ueber die sich Informationen aus den Entwicklungswerkzeugen in das Respository und umgekehrt schicken lassen. Oder sie geben Toolkits aus, mit denen die Werkzeuganbieter diese Verbindung herstellen koennen. Jedenfalls muss der Tool-Hersteller seine Informationen nicht den Mitbewerbern preisgeben.

CW: Dennoch bleibt die zentrale Speicherung aller Unternehmensinformationen problematisch. Bisweilen entsteht der Eindruck, als habe sich die Idee eines zentralen Repository ueberlebt.

Ledvina: Nun ja, in gewisser Weise hat sie das. Diese Repositories eignen sich gut dafuer, das zu katalogisieren, was sich in den Informationssystemen eines Unternehmens befindet. Aber sie werden keineswegs genutzt, um den Entwicklern einen aktiven Check-in- check-out-Zugriff beim Software-Entstehungsprozess zu gewaehren.

CW: Aber genau das propagieren die Hersteller.

Ledvina: Ja, sie haetten gern, dass es so waere. Aber das Problem besteht darin, dass die Anwender in eine proprietaere Umgebung hineingezogen werden. Wir sind jedenfalls der Ansicht, dass es nicht produktiv ist, alle Entwicklungsinformationen in ein aktiv genutztes, zentrales Repository hineinzustecken. Fuer Maintenance- Zwecke sind diese Systeme besser geeignet, sie hinken halt immer einen Schritt hinter dem aktuellen Stand her. Ausserdem gibt es fuer die neuen Werkzeuge - Powerbuilder, SQL Windows, Visual Basic etc. - derzeit kaum Moeglichkeiten, ihre Daten in diesen Systemen abzulegen.

CW: Diese Desktop-Werkzeuge werden eingesetzt, um Anwendungen schnell und ohne grossen Aufwand zu erstellen. Offenbar bildet sich hier eine neue Entwicklungskultur heraus, die - so scheint es - mit den unternehmensweiten Daten- und Prozessmodellen nichts zu tun hat.

Ledvina: Wenn Sie mit solchen objektbasierten 4GL-Tools arbeiten, dann ist jede Arbeit an einem Prozessmodell Zeitverschwendung. Denn die Art und Weise, wie die Informationen mit diesen Tools ausgetauscht werden, konzentriert sich fast vollstaendig auf die Daten. Bisweilen koennen Sie Geschaeftsregeln aus Datenflussdiagrammen uebernehmen, meistens aber auch das nicht. In den neuen Entwicklungsumgebungen beschaeftigen Sie sich nicht mehr mit prozeduraler Programmierung. Also bauen Sie auch keine Aktionsdiagramme, sondern Libraries - kleine Einheiten, die innerhalb dieser neuen, ereignisgesteuerten Umgebung zum Ablauf gebracht werden koennen.

CW: Was ist mit dem Datenmodell?

Ledvina: Nun, das muessen Sie auf jeden Fall erstellen. Schliesslich wollen Sie doch wissen, wie Ihre Datenbanken aussehen sollen. Und um die Informationen daraus in die neuen Entwicklungs-Tools einzuspeisen, koennen Sie durchaus die traditionellen Datenmodellierungs-Werkzeuge nutzen. Vor allem fuer Powerbuilder, aber auch fuer Visual Basic und Gupta gibt es Bridge-Software, die von den Anwendern bereits genutzt wird.

CW: Inwiefern lassen sich diese objektbasierten 4GLs gebrachen, um objektorientierte Anwendungen zu erstellen?

Ledvina: Wenn Sie objektorientierte Analyse und objektorientiertes Design machen wollen, dann brauchen sie Objektmodellierungs-Tools. Am Ende haben Sie beispielsweise einen Satz von C++- Klassenbibliotheken, den Sie dann um handcodierte Methoden ergaenzen. Und diese Informationen wollen Sie nun in Ihr Toolkit hineinbringen. Aber dabei gibt es ein Problem: In Powerbuilder, SQL Windows und Visual Basic werden die Libraries jeweils in einer proprietaeren Scripting-Sprache geschrieben. Keines dieser Tools kann direkt auf eine C++-Klassenbibliothek zugreifen. Also lassen sich die Informationen aus dem Modell nicht an die Libraries vererben, die ich mit dem 4GL-Werkzeug erstellt habe. Hier ist ein Bruch. Die OO-Analyse- und -Design-Tools arbeiten nicht mit diesen Produkten.

CW: Software-Re-Engineering war jahrelang ein heisses Thema. Heute gilt dieser Ansatz als gescheitert. Stimmen Sie dem zu?

Ledvina: Ja - zumindest, was den Versuch angeht, alle Programminformationen in ein Modellierungswerkzeug einzuspeisen und daraus eine grafische Anwendung zu generieren. Dabei stossen Sie naemlich auf zwei Probleme: Zum einen erhalten Sie am Ende sicher kein brauchbares Programm, wenn das, was Sie einsetzen, nichts als Kraut und Rueben ist. Garbage in, garbage out, heisst es. Folglich wird eine Menge Restrukturierungsarbeit notwendig sein. Zum anderen kann kaum ein Generator den Output solcher Modellierungswerkzeuge nutzen - zumindest nicht auf der Prozessseite. Da stossen wir auf aehnliche Schwierigkeiten wie bei den objektbasierten 4GLs. Die Sache wird derart muehselig, dass die Leute einfach keinen Vorteil mehr darin sehen.

CW: Wie sollen die Anwenderunternehmen denn Ihrer Ansicht nach mit ihren Software-Altlasten umgehen?

Ledvina: Wenn jemand eine Anwendung umgestaltet, will er sicher nicht dasselbe noch einmal entwickeln. Die meisten der Extrahier- und Remodellierarbeiten sind folglich umsonst. Sie bringen uns der angestrebten Portabilitaet keinen Schritt naeher. Also haben die Leute die traditionellen Re-Engineering-Konzepte ad acta gelegt. Statt dessen verfolgen sie einen Recycling-Ansatz, der darin besteht, Teile der existierenden Anwendungen inkrementell auf Client-Server-Plattformen zu uebertragen. Das ist

etwas langwieriger, fuehrt aber dafuer zu vernuenftigen Ergebnissen. Mit der Neugestaltung von Software verhaelt es sich eben wie mit Fast Food: Die schnellste Moeglichkeit, satt zu werden, ist meist nicht die gesuendeste.