Die objektorientierte Systementwicklung wird, darin sind sich die meisten Marktbeobachter einig, die gesamte Softwarebranche revolutionieren. Moeglicherweise schon in naechster Zukunft, spaetestens aber zum Ende dieses Jahrhunderts koennen die Anwenderunternehmen komplette oder zumindest halbfertige Software- Objekte mit genormten Schnittstellen vom Markt beziehen und nach eigenen Beduerfnissen zusammenstoepseln. Was nicht konfektioniert zu haben ist, wird dann, so die Prognosen, mit vergleichsweise geringem Aufwand selbst erstellt und - da es gegen dieselben Schnittstellen entwickelt ist - problemlos an die zugekauften Objekte angeschlossen. Die Konsequenzen, die ein solches Szenario fuer Organisation und Ablaeufe innerhalb der IV-Abteilungen haben koennte, sind Gegenstand dieses Beitrags. Er schliesst thematisch an das "Thema der Woche" in der COMPUTERWOCHE Nr. 4 vom 28. Januar 1994 an, das die Erfahrungen einiger Pionieranwender widerspiegelt.
Einen kleinen Vorgeschmack auf das, was uns in den kommenden Jahren erwarten koennte, gab die Next Inc., Redwood City, Kalifornien, auf der Object World '92 in San Franzisko: Unter der Bezeichnung "Objectware" praesentierte die Steven-Jobs-Company einen Katalog von Softwarepartikeln, die als Bausteine fuer individuell zusammengestellte Anwendungen dienen koennen (vgl. CW Nr. 32 vom 7. August 1992, Seite 11: "Next bietet einen Katalog von 100 Third-Party-Komponenten an").
Das Next-Konzept krankt allerdings an seinem proprietaeren Ansatz: Damit die Softwareteilchen tatsaechlich "steckerkompatibel" sind, muessen sie naemlich in der bislang wenig populaeren Sprache Objective C geschrieben sein.
Eine aehnliche Entwicklung ist jedoch auch fuer C++ und Smalltalk zu beobachten. Zumindest hat sich bereits eine Reihe von Anbietern darauf spezialisiert, Klassenbibliotheken fuer die beiden am weitesten verbreiteten OO-Sprachen zur Verfuegung zu stellen. Optimisten wie der amerikanische Analyst Brad Cox sprechen bereits von integrierten Softwareschaltkreisen ("Software-ICs", IC = Integrated Circuit), die die heute ueblichen - nur sehr grob modularisierten - Anwendungspakete ersetzen werden.
Esther Laun, Geschaeftsstellenleiterin Frankfurt der Stuttgarter Integrata AG, gehoert zu denjenigen, die der Objekttechnik-Euphorie eher reserviert gegenueberstehen. Doch ungeachtet ihrer Skepsis raeumt sie ein, dass die Softwarebranche langfristig vom Handel mit vorgefertigten Programmrohlingen bestimmt sein duerfte: "In etwa zehn Jahren werden Sie in den Laden gehen und Halbfertig-Programme kaufen koennen, die Sie nach Ihren eigenen Kriterien zusammenbasteln. Daran koennen Sie dann irgendwelche Subobjekte mit Zusatzregeln haengen - und innerhalb relativ kurzer Zeit haben Sie Ihr System."
Ihre vorsichtige Zeitschaetzung begruendet Laun mit der fehlenden Investitionsbereitschaft in den Anwenderunternehmen, die bereits enorme Summen in die "klassische" Datenverarbeitung gesteckt haetten: "Und die sollen jetzt ihren Host wegwerfen, huebsche kleine Unix-Rechner oder PCs kaufen und sich fertige Objekte besorgen, um von vorn anzufangen? Nein, das geht nicht in zwei Jahren!" Auch fuer Raymund Vorwerk, geschaeftsfuehrender Gesellschafter des Beratungs- und Serviceunternehmens VC Software Construction in Braunschweig, ist das Geschaeft mit den Software-ICs bislang Zukunftsmusik. Seine Skepsis gruendet sich auf zwei Kriterien: Zum einen seien die fuer die Realisierung steckerkompatibler Softwarekomponenten notwendigen Standards noch nicht vorhanden. Zum anderen fehle ein Honorierungsschema fuer die Nutzung von Objekten.
Vom Standpunkt des Lieferanten aus betrachtet, sei die Entwicklung von Standardobjekten ein Verlustgeschaeft. "Sicher, uns gelingt es auch ab und zu, eine Klassenbibliothek fuer 50000 Mark zu verkaufen, aber das ist ein Einzelfall", klagt Vorwerk. Folglich zeigten die Software-Unternehmen kaum Interesse, in diesen Markt einzusteigen.
In den USA bereits Realitaet ist laut Vorwerk jedoch ein anderer Trend: Die Objekte werden nicht als Fertigprodukte auf dem Markt angeboten, sondern kundenindividuell von darauf spezialisierten Softwareschmieden erstellt. Wie der Unternehmensberater erlaeutert, waren die Systeme in der Vergangenheit oft derart miteinander verwoben, dass sie sich nicht "vernuenftig" voneinander trennen liessen. Im Zuge der Objektorientierung seien die Unternehmen hingegen in der Lage, ihre Aufgabenstellungen klar zu umreissen, ein Szenario zu entwerfen und die Objektinteraktionen zu definieren. "Und diese eindeutige Beschreibung kann man dann nach draussen geben."
Das Fazit aus dieser Entwicklung zieht Vorwerks Kollege Martin Roesch, Geschaeftsfuehrer der Roesch Consulting GmbH in Kaarst bei Duesseldorf: "Die Leistungstiefe in der DV nimmt ab. Die Entwickler sitzen nicht mehr inhouse, sondern in Softwarebueros, vergleichbar den Architekturbueros in der Bauwirtschaft." Folglich koennten die DV-Abteilungen in den Anwenderunternehmen verkleinert werden. Personalreduzierungen sind ein Stichwort, das haeufig auftaucht, wenn von objektorientierter Entwicklung die Rede ist. Die Betroffenen, also Entwickler und IV-Verantwortliche, koennen hier zwar nicht direkt widersprechen, fuehren allerdings eine Reihe von Argumenten ins Feld, um derartige Prognosen zu relativieren. So beispielsweise Friedhelm Fritzen, Abteilungsleiter Datenverarbeitung und Organisation bei der Metallgesellschaft AG (MG), Frankfurt am Main: "Die Entwicklung kann zwar zurueckgeschraubt werden, wird aber nicht ueberfluessig; es ist schliesslich jemand noetig, der die Klassen und Methoden zusammensetzt." Die Schnittstellen zwischen den Objekten zu versorgen, werde nach wie vor Sache der Anwenderunternehmen sein.
Hoechstwahrscheinlich schlagen sich auch die bei Eigenentwicklungen erzielbaren Produktivitaetsvorteile objektorientierter Entwicklungswerkzeuge nicht unmittelbar in schrumpfenden Entwicklungsabteilungen nieder. Fuer die unmittelbare Zukunft ist im Gegenteil damit zu rechnen, dass der Personalbedarf in den Unternehmen steigt.
Warum das so ist, verraet Wolfgang Leiendecker, Entwickler Methoden und Verfahren bei der Deutschen Wertpapierdaten-Zentrale GmbH (DWZ) in Frankfurt am Main: "Wenn man das, was auf dem Grossrechner prozedural programmiert wurde, jetzt objektorientiert entwickeln will, muss man parallel zur Grossrechnermannschaft ein Objektorientierungsteam aufbauen", gibt Leiendecker zu bedenken. "Man kann die bisherigen Anwendungen ja nicht ploetzlich vergraben." Ein weiteres Argument gegen die kurzfristige Verkleinerung der unternehmensinternen Entwicklungsabteilungen sind die wachsenden Ansprueche der Endanwender. Dazu Alfred Hoeffgen, bei der zum Koelner Gerling-Konzern gehoerenden Gesellschaft fuer Informations-Management und Organisation mbH fuer den Bereich Anwendungsentwicklung Erstversicherung zustaendig: "Sie werden objektorientiert nicht eins zu eins den Funktionsumfang realisieren, den Sie konventionell entwickelt haetten; denn beim Anwender kommt der Appetit mit dem Essen."
Beispielsweise muteten alte Host-Oberflaechen dem Sachbearbeiter zu, die Entschluesselung codierter Werte in einem Handbuch oder in einer komplizierten Hilfefunktion nachzuschlagen. In einer objektorientierten PC-Welt hingegen erwarte der Anwender Auswahlmenues. "Dieses Mehr an Funktionalitaet ist wiederum mit einem etwas groesseren Aufwand verbunden", konstatiert Hoeffgen.
Aber selbst wenn die Anzahl der in einem Unternehmen beschaeftigten Entwickler dieselbe bleibt, so werden sich die anstehenden Aufgaben nicht mit der vorhandenen Mannschaft erledigen lassen - jedenfalls nicht ohne einen Schulungsaufwand, den Unternehmensberater und erfahrene Anwender mit einem halben Jahr pro Mitarbeiter ansetzen. Bestaetigt Leiendecker: "Der Ausbildungsbedarf ist erheblich - vor allem fuer Leute, die prozedural vorbelastet sind."
Die Wirkung, die der vielzitierte Paradigmenwechsel auf einen konventionell ausgebildeten Programmentwickler haben kann, umschreibt Vorwerk mit dem Begriff des horror vacui. Wie sich dieser konkret darstellt, schildert der Berater folgendermassen: "Wir hatten hier mal Kunden, die lagen total am Boden. Sie sagten, sie wuessten gar nicht mehr, was sie tun sollten, weil sie keine Begrenzungen mehr haetten."
Objektorientierte Entwicklungswerkzeuge geben den Entwicklern die Mittel an die Hand, Systeme im Dialog mit dem Endanwender zu erstellen. Der wortkarge, vergeistigte Typus, der bislang als das Sinnbild eines Programmierers galt, ist demzufolge nicht mehr zeitgemaess. "Ein introvertierter Superprogrammierer kann in der objektorientierten Welt nichts werden", urteilt beispielsweise Leiendecker.
Wer bereits erstellte Softwarebausteine wiederverwenden wolle, muesse sich zudem staendig mit den Kollegen abstimmen. Ansonsten werde er eben doch alles selbst entwickeln. Konsequenterweise bricht der Frankfurter Methodenexperte denn auch den Stab ueber die Starentwickler der vergangenen Jahre: "Die Programmierer, die sich unentbehrlich gemacht haben, darf es nicht mehr geben."
Die Nachfrage nach reinen Codierern wird bei den Anwenderunternehmen ohnehin rapide nachlassen - in dem Masse, wie sie auf das Tiefen-Know-how von Objektanbietern und Softwarebueros zurueckgreifen koennen. Gefragt sind Inhouse-Entwickler mit ausgepraegten analytischen Faehigkeiten. Leiendecker: "Wer objektorientiert entwickelt, muss systemweit denken koennen." (Vgl. hierzu auch die Stellungnahme des britischen Analysten Martin Butler in CW Nr. 14 vom 3. April 1992, Seite 11: "OO-Techniken wirken sich auf die Entwickler-Arbeitsplaetze aus".)
Nach Leiendeckers Ansicht findet in den IV-Abteilungen langfristig eine Verlagerung der Schwerpunkte statt - "weg von der reinen Doing-Entwicklung hin zu Servicestellen". Eine dieser Dienstleistungsfunktionen muss sich, so die einhellige Meinung der Befragten, der Klassenadministration widmen. Die Verwaltung von Klassen und Methoden spielt innerhalb einer objektorientierten Softwarewelt eine noch wichtigere Rolle, als es die Datenadministration in einer konventionellen Umgebung tut. Auf den ersten Blick scheint es also, als ob mit der Objektorientierung die Aufgaben der Datenzentrale zunaehmen. Tatsaechlich duerfte die neue Technik jedoch dazu fuehren, dass die zentralen Funktionen in Art und Umfang exakt definiert und schliesslich reduziert werden. Hingegen bestreiten die Experten, dass es moeglich sei, den Fachabteilungen das Kommando ueber die Informationsverarbeitung zu uebergeben.
Dazu noch einmal Leiendecker: "Sie brauchen ein vernuenftiges Objektdesign. Das kann nicht jeder machen, wie er moechte." Nichtsdestoweniger werden sich die Ablaeufe und Strukturen innerhalb der IV-Abteilungen dramatisch aendern.
Unterhalb der Konsolidierungsebene findet das objektorientierte Paradigma seine Entsprechung in kleinen Teams mit viel Eigenverantwortlichkeit. Die Arbeitsteilung im klassischen Sinn weicht zunehmend einem ereignisgesteuerten Workflow-Management, das viele bislang nicht hinterfragte Berichtswege als ueberfluessig kennzeichnen wird. Der Trend geht also in Richtung Lean-Software- Production.
Ein Anwender berichtet aus Erfahrung: "Schauen Sie sich doch einmal ein Objektmodell fuer ein Unternehmen oder einen Unternehmensbereich an und versuchen Sie, daraus sachbezogene Systeme zu etablieren! Wenn Sie ein traditiertes Organisations- und Prozessmodell dagegenhalten, sind die Schnittmengen wie ein Puzzlespiel ueber das gesamte System verstreut."
Die Objektorientierung fungiert aber nicht nur als Ausloeser fuer diesen Trend. Vielmehr stellt sie auch die Hilfsmittel bereit, um neue Modelle der Arbeitsorganisation in die Realitaet umzusetzen. Als Bestandteil einer objektorientierten Oberflaeche lassen sich die einzelnen Stationen einer Vorgangsbearbeitung flexibler gestalten, als das in einem prozeduralen System moeglich waere. Nicht von ungefaehr unterstuetzen die neuen Workflow-Management- Systeme von IBM und Digital Equipment eine objektorientierte Software-Architektur. Integrata-Managerin Laun sieht die Objektorientierung folglich als Teil eines Umbruchs in der Betriebsorganisation, der den Umstieg von grossen auf kleine Rechner, die Automatisierung von Buerotaetigkeiten mit Workflow- Management-Tools sowie ein neues Konstruktionskriterium fuer Softwaresysteme einschliesst. "Wenn man diese drei Dinge zusammen betrachtet, kann man sich vorstellen, dass die Betriebsorganisation kuenftig nicht mehr so aussehen wird wie bisher."
Da nimmt es nicht Wunder, dass die Mehrzahl der deutschen IV- Manager das Thema Objektorientierung mit zwiespaeltigen Gefuehlen betrachten. Sie sehen die Gefahr, dass die durch 20- oder 30jaehrige Praxis etablierten Organisationen unter Umstaenden komplett neu strukturiert werden muessen. Als Unternehmensberater ist Vorwerk bei den IV-Verantwortlichen denn auch haeufig auf Widerstand gestossen: "Im deutschen DV-Management sitzen oft Leute, die 50 Jahre oder aelter sind. Und die sagen sich: Ich habe gerade meinen letzten Fuenfjahresvertrag bekommen, also keine Experimente." Bei diesen Unternehmen sei davon auszugehen, dass waehrend der kommenden fuenf Jahre ueberhaupt nichts passiere. Begruendet ist die beschriebene Haltung aber auch, so Vorwerk, durch die Angst vor Rechtfertigungszwaengen.
Schliesslich seien die objektorientierten Werkzeuge bereits seit Ende des vergangenen Jahrzehnts auf dem Markt. Wenn sich jetzt herausstelle, dass ein Problem, in dessen Loesung vor drei Jahren zehn Mannjahre investiert wurden, auch mit einem halben Mannjahr zu loesen ist, muesse sich der Verantwortliche fragen lassen, warum er damals eine Fehlentscheidung getroffen habe. Vorwerk: "Die DV- Leiter fuerchten regelrecht den Erfolg eines Pilotprojekts."
Erschwerend kommt hinzu, was jede neue Technologie zunaechst einmal suspekt macht: Das angesammelte Know-how erscheint ploetzlich obsolet, neue Kenntnisse muessen erworben werden. Ein Grossteil der deutschen IV-Chefs hat seine Erfahrungen - und seine Karriere - vor allem in der Welt prozeduraler Grossrechnersoftware gemacht. Jetzt sehen sich diese Fuehrungskraefte mit einer voellig neuen Technik konfrontiert, in der sie nicht mehr zu Hause sind.
Gluecklicherweise betrachten aber nicht alle deutschen IV-Manager die Chancen der Objektorientierung als Bedrohung. Die erfolgreich abgeschlossenen Pilotprojekte legen dafuer Zeugnis ab. Zudem ist das Thema Objekttechnik dort auf offene Ohren gestossen, wo bislang kaum Verstaendnis fuer die Belange der Informationsverarbeitung herrschte, naemlich in den Vorstandsetagen. Allerdings steht zu befuerchten, dass die Unternehmensleitungen das Interesse bald verlieren - spaetestens dann, wenn sich statt der Kostenreduzierungen zunaechst einmal Investitionsbedarf einstellt.