Eine sehr zentrale Aussage zum Thema "Objektorientierung" fand sich kuerzlich in einem Beitrag von Harry Sneed in der COMPUTERWOCHE: "Objektorientierung ... ruettelt an den Fundamenten des klassischen Projekt-Managements und reicht tief in die Struktur der Unternehmen hinein"(vgl. CW Nr. 45 vom 6. November 1992, S. 43). Dieser Aspekt wird heute allgemein weit unterschaetzt.
Technologie-faszinierte OO-Gurus beschreiben mit betraechtlicher Ausdauer die technische Seite des neuen Paradigmas. Implementierungskonzepte wie Vererbung, Polymorphismus oder dynamisches Binden werden in unzaehligen Zeitschriften und Konferenzen dargelegt und sind inzwischen hinlaenglich bekannt.
Aeusserst selten aber erfaehrt man von den Auswirkungen des objektorientierten Ansatzes auf das Unternehmens- beziehungsweise Projekt-Management. Es ist naemlich ein gefaehrlicher Irrtum, zu glauben, dass die Einfuehrung der neuen Technologie allein mit dem Einsatz einer objektorientierten Programmiersprache, Datenbank oder Entwicklungsumgebung getan sei.
Objektorientierung ist nicht allein eine Sache der Entwickler. Das Management hat einen mindestens ebenso grossen Anteil zum Gelingen beizutragen. Der Einsatz von objektorientierten Techniken stellt fuer ein Unternehmen eine tiefgreifende strategische Entscheidung dar, die weitreichende Auswirkungen hat. Nicht nur von den Entwicklern, auch vom Management verlangt der objektorientierte Ansatz eine voellig neue Denkweise, einen "Paradigm shift".
Grundsaetzlich ist es bei der Einfuehrung einer neuen Technologie wichtig, mit realistischen Erwartungen an die Sache heranzugehen und nicht nur die oft zitierten Chancen, sondern auch die Risiken zu kennen. Die Vorteile des objektorientierten Paradigmas, die zu Qualitaets- und Produktivitaetssteigerungen fuehren, sind mittlerweile wohl jedermann bekannt. Allerdings sind diese Verbesserungen nur teilweise innerhalb von Wochen oder Monaten zu erreichen und kommen haeufiger erst nach etwa zwei bis fuenf Jahren voll zum Tragen.
Zu den Risiken des neuen Ansatzes gehoeren die bislang fehlenden Standards und der Mangel an umfangreichen Praxiserfahrungen. Es dauert in der Regel einige Monate, sich die neue Denkweise anzueignen, und die erstmalige Entwicklung eines objektorientierten Systems verlangt wesentlich mehr an Aufwand als bei herkoemmlicher Software.
In letzterem liegt aber keineswegs ein Widerspruch zu den von der Objektorientierung erwarteten Vorteilen, insbesondere der angeblich kuerzeren Entwicklungszeit. Es ist offensichtlich, dass der Entwurf wiederverwendbarer Systeme zunaechst einen hoeheren Aufwand erfordert als das Erstellen nur einmal verwendeter Programmteile. Klassen muessen so universell entworfen werden, dass sie auch fuer andere Probleme benutzt werden koennen.
Durch die nun moeglich gewordene Wiederverwendung von Software stehen organisatorische Probleme und komplexe Fragen der Leistungsverrechnung ins Haus. Aehnlich wie bei Standardsoftware koennen die hohen Entwicklungskosten fuer die erstmalige Erstellung nur teilweise dem ersten Projekt zugerechnet werden. Ebensowenig wird man bei nachfolgenden artverwandten Auftraegen die bereits vorhandenen Klassen zum Nulltarif wiederverwenden. Wie sollen nun die Kosten gerecht ueber die Projekte verteilt werden?
Viele Berufsbilder duerften sich wandeln, neue Aufgaben, beispielsweise die des Klassenverwalters, werden sich herausbilden. Der Klassenverwalter ist fuer die projektuebergreifende, am besten unternehmensweite Standardisierung und Verwaltung von Klassen zustaendig. Dadurch entstehen Gemeinkosten, die nicht direkt einem bestimmten Projekt zugerechnet werden koennen.
Die Auswirkungen der Objektorientierung auf die Unternehmensstruktur sind ebenfalls vielschichtig und werden oft unterschaetzt. Kurioserweise scheint die objektorientierte Denkweise Computeranfaengern weniger Probleme zu bereiten als eingefleischten Entwicklern strukturierter Systeme. Dies koennte zu Konflikten und Kompetenzgerangel fuehren.
Auch rechtliche Probleme sind mit der Wiederverwendung verbunden. Inwiefern erlaubt beispielsweise der Kunde eines Softwarehauses die Verwendung der fuer sein Problem erstellten Klassen in einem anderen Projekt?
Vor dem Hintergrund der derzeitigen wirtschaftlichen Gesamtlage ist es besonders schwierig, Vorinvestitionen fuer Schulungen und aufwendige Erstentwicklungen zu leisten. Die Folge koennte ein nur halbherziger Schritt Richtung Objektorientierung sein. Damit meine ich nicht, dass man sofort OO at it´s best anwenden muss - evolutionaere Wege zu objektorientierten Techniken sind gangbar. Unbedingt aber sollte die Umstellung von der technologischen und der organisatorischen Seite gemeinsam vollzogen werden.
Objektorientierung kann nur Fuss fassen, wenn mit realistischen Erwartungen an die Technologie herangegangen wird und sich das Management seiner Rolle bewusst ist. Nur wenn neben der Technik auch Unternehmensstruktur und Projektorganisation auf den objektorientierten Ansatz abgestimmt sind, ist der volle Erfolg moeglich. Dann bietet Objektorientierung die Chance zum Umstieg auf eine industrielle Software-Entwicklung.