Immer wenn eine neue Technologie in den Mittelpunkt des Interesses rueckt, sind die Marketiers schnell mit Hochglanzbroschueren zur Hand, die den Kunden das Blaue vom Himmel versprechen. So schueren jetzt auch die Anbieter objektorientierter Entwicklungswerkzeuge bei den CASE-geschaedigten Anwendern die Hoffnung auf mehr Produktivitaet der Software-Erstellung sowie eine bessere Wartbarkeit der Systeme. Mittlerweile beschaeftigt sich eine Reihe von deutschen Anwenderunternehmen mit der objektorientierten Anwendungsentwicklung, und einige von ihnen haben ihre Pilotprojekte bereits abgeschlossen. Inwieweit sich ihre Erfahrungen mit den Marketing-Versprechen der Anbieter decken, ist Gegenstand dieses Beitrags. Mit den Konsequenzen der Objekttechnik fuer die Entwicklungsabteilungen und das Informations-Management beschaeftigt sich ein gesonderter Artikel, den die COMPUTERWOCHE in ihrer naechsten Ausgabe veroeffentlichen wird.
N icht nur in den USA, sondern auch im eher konservativen deutschen Informations-Management wird heftig mit der objektorientierten Anwendungsentwicklung experimentiert. Allein im Daimler-Benz-Konzern gibt es dem Vernehmen nach mehrere hundert Projekte, die auf der objektorientierten Programmiersprache Smalltalk aufsetzen.
Auch die Versicherungsbranche gilt als besonders aufgeschlossen fuer diese neue Technologie. Der Wettbewerbsdruck zwingt die Unternehmen allenthalten, die ausgetretenen Pfade zu verlassen und sich auf unsicheres, aber erfolgverheissendes Neuland zu wagen.
Die Herausforderung laesst sich mit dem Stichwort Time to market umreissen. Was darunter zu verstehen ist, erlaeutert Raymund Vorwerk, geschaeftsfuehrender Gesellschafter des Beratungs- und Serviceunternehmens VC Software Construction, Braunschweig: "Wenn eine Versicherung heute einen Sondertarif fuer Raucher, Nichtraucher, Beamte oder wen auch immer herausbringen will, dann braucht sie DV-Unterstuetzung, weil sie das anders nicht mehr verwalten kann. Aber dafuer kann sie sich in Zukunft nicht mehr fuenf Jahre Zeit lassen. Denn am 1. Juli kommen ihre Kollegen aus den anderen europaeischen Staaten, und die sind fixer."
Seit Jahren schon bieten sich Standardanwendungspakete als Antwort auf die sprichwoertliche Softwarekrise an. Doch ebenso lange klagen die Unternehmen, dass sie mit Software von der Stange nicht alle Bereiche ihres Geschaefts abdecken koennen. "Standardprodukte bieten nur Standardfunktionen", konstatiert Alfred Hoeffgen, bei der zum Koelner Gerling-Konzern gehoerenden Gesellschaft fuer Informations- Management und Organisation mbH fuer die Anwendungsentwicklung im Bereich Erstversicherung zustaendig.
Anwendungen, fuer die es bislang keine Standardprodukte gibt, muessen also nach wie vor inhouse erstellt oder als Individualentwicklung extern vergeben werden. Bis dato lebte ein grosser Teil der deutschen Software-Industrie davon, dass die Anwenderunternehmen mit ihren eigenen Entwicklungsmannschaften der Benutzeranforderungen nicht Herr werden konnten. Das Konzept des Computer-aided Software-Engineerings (CASE) hat daran nicht viel geaendert.
Doch wenn die objektorientierten Entwicklungskonzepte halten, was ihre Propagandisten versprechen, droht den Beratungs- und Serviceanbietern ein boeses Erwachen. Als Betroffener spricht Vorwerk ein finsteres Orakel: "Mit der Objektorientierung wird der Dienstleister ueberfluessig." Nach einem halben Jahr der Einarbeitung sei der Kunde seinen Kapazitaetsengpass los und habe folglich keine externe Unterstuetzung mehr noetig.
Vorwerk reagiert darauf, indem er seine Produktivitaetsvorteile nicht mehr weitergibt: Er arbeitet zunehmend gegen Festpreis und nicht mehr gegen Aufwandsentschaedigung. "Jemand, der Cobol macht, bekommt dasselbe Stundenhonorar, auch wenn er sechsmal weniger produktiv ist", lautet seine Begruendung.
Von einer gesteigerten Produktivitaet durch den Einsatz objektorientierter Entwicklungswerkzeuge berichtet auch Wolfgang Leiendecker, Entwickler fuer Methoden und Verfahren bei der Deutschen Wertpapierdaten-Zentrale GmbH (DWZ) in Frankfurt am Main. Sein Fazit: "Durch Objektorientierung wird die Eigenentwicklung erst wieder interessant."
Die DWZ hat bislang allerdings nur ein einziges Projekt mit Hilfe der Objekttechnik durchgezogen: Dabei wurde ein als prozedurale Grossrechneranwendung implementiertes Wertpapier-Leihe-System fuer den Deutschen Kassenverein mit einer objektorientierten grafischen Benutzeroberflaeche ueberzogen - immerhin ein Anfang, aber doch eigentlich nur ein Kompromiss. "Es kann nicht das Konzept sein, bestehende Anwendungen einfach mit einer neuen Benutzeroberflaeche zu versehen", urteilt denn auch Leiendecker. "Damit bin ich naemlich auf das beschraenkt, was mir die Host-Anwendung bietet."
Der Gerling-Konzern zeigte sich da schon etwas risikofreudiger. Dort konnte Hoeffgen ein neues System mit dem Smalltalk-basierten Entwicklungswerkzeug Enfin realisieren - und eigenen Angaben zufolge deutliche Produktivitaetsvorteile erzielen. Allerdings scheut sich der Koelner, diesen Zuwachs zu quantifizieren, da es sich um ein "Gruene-Wiese-Projekt" gehandelt habe und folglich der Vergleichsmassstab fehle.
Auf die Frage, wodurch die hoehere Produktivitaet verursacht werde, kommt fast immer dieselbe Antwort: durch die Wiederverwendung von Softwarebausteinen. Wie das konkret aussehen kann, beschreibt Esther Laun, als Geschaeftsstellenleiterin fuer die Frankfurter Niederlassung der Integrata AG, Stuttgart, verantwortlich: "Es ist einfacher, eine grafische Oberflaeche nach objektorientierten Kriterien zu bauen. Da muessen Sie den Push-Button halt nur einmal programmieren und nicht ein paar tausendmal."
Die meisten Software-Experten vertreten die einleuchtende These: Wiederverwendbarkeit ist erst ab dem zweiten Projekt moeglich. Leiendecker ist jedoch anderer Ansicht. "Wir haben im ersten Release schon wiederverwendet - und zwar ganz massiv", bruestet sich der Methodenspezialist. Ein Wiederverwendungseffekt lasse sich naemlich bereits durch eine objektorientierte Analyse, genauer: durch die Modularisierung der Anwendung, erzielen. Zwar erlauben auch konventionelle Methoden eine solche Modularisierung, doch die objektorientierte Vorgehensweise bietet auch die dafuer noetige Unterstuetzung.
Einen voellig anderen Blickwinkel nimmt Vorwerk ein. Fuer ihn erhaelt ein Unternehmen, das heute mit der Objektorientierung anfaengt, wirkliche Wiederverwendungseffekte fruehestens nach drei Jahren. "So lange brauchen die Anwender, bis sie erst einmal ihre Klassen haben."
Auch wenn seine Zeitvorstellung kaum Zustimmung findet, legt Vorwerk hier den Finger in eine offene Wunde. Das bestaetigt Friedhelm Fritzen, Abteilungsleiter Datenverarbeitung und Organisation bei der Metallgesellschaft AG (MG) in Frankfurt am Main: "Die Objekte und ihre Klassen zu finden ist das groesste Problem der Objektorientierung. Davor druecken sich die meisten Gurus."
Wie Fritzen ausfuehrt, kommt ein Unternehmen, das sich mit objektorientierter Entwicklung beschaeftigen will, um eine detaillierte Datenmodellierung nicht herum. Sie sei ein gutes Mittel, um Objekte zu finden. Allerdings ergeben sich auf diese Weise laengst nicht alle Objekte von selbst. Die Metallgesellschaft hat deshalb eine "Klassenkonferenz" installiert, ein Gremium, das gemeinschaftlich entscheidet, wie die fuer das Gesamtunternehmen nutzbaren Klassen definiert werden sollen.
Der Ende vergangenen Jahres wegen seiner Spekulationsverluste in die Schlagzeilen geratene Industriekonzern hat bereits eine ganze Reihe von objektorientierten Entwicklungsprojekten abgeschlossen. Eine Anwendung fuer das Warentermingeschaeft mit Oel befand sich, so versichert Fritzen, nicht darunter.
Vielmehr handelte es sich bei diesen Pilotprojekten um Handelssysteme fuer Erz, Methanol und die Metallboerse. Innerhalb des kommenden Monats soll eine Anwendung fuer den Fertigmetallhandel hinzukommen, parallel laeuft ein Vorhaben fuer den Schwefelhandel. Laut Fritzen arbeiten derzeit 200 bis 300 MG- Angestellte mit objektorientierten Anwendungen.
Bei der Metallgesellschaft hat sich eine Wiederverwendbarkeit erst nach Abschluss der drei ersten Projekte ergeben. Das lag vor allem daran, dass diese Entwicklungsvorhaben quasi unkoordiniert nebeneinander herliefen. Lediglich allgemeine Grundsaetze wurden im Vorfeld geklaert, beispielsweise die Frage, wie die "Methoden" (=Funktionen) zu finden seien.
Waehrend innerhalb eines Projektes zumeist noch ein Ueberblick ueber die vorhandenen Klassen und Methoden moeglich ist, stoesst die projektuebergreifende Wiederverwendung auf ein technisches Hindernis: Ein geeignetes Retrieval-System fuer Klassen und Objekte fehlt bislang. "Es hat noch niemand eine Loesung gefunden, wie man wirklich kontextabhaengig etwas suchen kann", klagt Vorwerk. Auch Hoeffgen bemaengelt, dass es in der objektorientierten Welt bislang kein Aequivalent fuer die aus der CASE-Welt bekannten Repository- Werkzeuge gibt.
Bei der Metallgesellschaft wurde dieses Problem zumindest ansatzweise geloest. Fritzen: "Seit Anfang letzen Jahres koennen wir aus einem Baukasten heraus Software bauen." Alle Bausteine - sprich: Methoden - sind dort dreifach beschrieben: durch eine Namenskonvention sowie durch eine Kurz- und eine Langbeschreibung. Mit Hilfe eines Klassen-Browsers lassen sich die Beschreibungen nach den jeweils benoetigten Methoden durchsuchen. Fritzen raeumt allerdings ein, dass die Beschreibungen oft erheblich umfangreicher ausfallen als die Methoden selbst.
Einen Vorsprung verschaffen objektorientierte Systeme ihren Anwendern allerdings nicht nur bei der Software-Erstellung - im Gegenteil. Fritzen streicht vor allem seine guten Erfahrungen bei nachtraeglichen Anforderungen heraus: "Bei Aenderungen ist der Einsparungsfaktor sehr viel hoeher einzuschaetzen als bei Neuentwicklungen."
Das wirkt sich auch dann positiv aus, wenn bestehende Anwendungen mit einem objektorientierten System interagieren muessen. Laut Helmut Braun, Systementwickler bei der Toyota Kreditbank in Koeln, lassen sich die prozeduralen Applikationen integrieren, indem ihnen ein Adapter vorgeschoben wird. Allerdings plaediert Braun dafuer, die alten Anwendungen langfristig durch objektorientierte Systeme zu ersetzen.
In den meisten Unternehmen beschraenken sich die Verbindungen zwischen prozeduralen und objektorientierten Systemen denn auch auf das notwendige Minimum.
Wie nuetzlich die leichte Erweiterbarkeit eines objektorientierten Systems sein kann, hat Braun bei der im Juli vergangenen Jahres erfolgten Postleitzahlen-Umstellung erfahren. In einem System, das objektorientiert implementiert ist, muessen solche Aenderungen naemlich nur noch an einer Stelle vorgenommen werden.
Das Konzept der strukturierten Programmierung scheiterte letztlich daran, dass sich die benoetigte Loesung als Moving Target erwies: Falls die Applikation ueberhaupt fertig wurde, entsprach sie mit Sicherheit nicht mehr den gegenwaertigen Beduerfnissen der Anwender.
Mit einem evolutionaeren Entwicklungsmodell hingegen ist es moeglich, die angeforderten Applikationen zunaechst in Form eines abgeschlossenen Geschaeftsvorfalls zu implementieren, der dann gemeinsam mit der Fachabteilung evaluiert und um weitere Vorfaelle ergaenzt werden kann. Zwar erlauben auch konventionelle Prototyping-Systeme eine Interaktion mit dem Benutzer, doch werden die damit erstellten Oberflaechen meist wieder weggeworfen, weil sie nicht erweiterbar sind.
Objektorientierte Entwicklungswerkzeuge unterstuetzen zumeist das evolutionaere Prototyping. Auf diese Weise schaffen sie zumindest die Voraussetzung dafuer, dass das fertige System dem entspricht, was die Endanwender tatsaechlich haben wollten. Und dieser Vorteil wiegt mit Sicherheit auch einen anfaenglichen Mehraufwand fuer Ausbildung und Einarbeitung auf. Fritzen: "Wenn die Anwender dem Vorstand volle Zufriedenheit berichten, dann wird nur noch sekundaer nach den Kosten gefragt."
Die haeufig vertretene Ansicht, dem Endanwender koenne es egal sein, ob sein System prozedural oder objektorientiert implementiert wurde, laesst sich also nicht halten.
Zudem weist Leiendecker drauf hin, dass eine objektorientiert erstellte Oberflaeche wesentlich flexibler in der Handhabung sei als eine prozedural programmierte. Waehrend der Endanwender bei einem konventionell entwickelten System in seinen Dialoganwendungen festen Ablaeufen folgen muss, ermoegliche es ihm eine objektorientierte Anwendung, die Reihenfolge von Bearbeitungsschritten seinen eigenen Vorlieben und Beduerfnissen anzupassen.
Nicht vergessen werden sollte dabei der Kostenaspekt. Tritt die Fachabteilung - wie in vielen Betrieben ueblich - quasi als Kundin der Software-Entwicklung auf, dann, so Leiendecker, sollte es ihr nicht egal sein, wie das System implemetiert ist. "Denn die Entwicklung ist prozedural teurer - zumindest die Weiterentwicklung."