Es gibt heute genuegend Werkzeuge fuer objektorientiertes Vorgehen, und der Umgang mit ihnen ist erlernbar. Dass sich die Mitarbeiter damit vielerorts dennoch schwertun, liegt meist nicht an der Technik, sondern an der Einstellung dazu. Die Technik spiegelt naemlich nur den betriebswirtschaftlichen Trend zu offenen und weniger hierarchischen Unternehmensstrukturen. Aus nachvollziehbaren Gruenden werden sich die Mitarbeiter zunaechst gegen diesen Quantensprung im Denken straeuben.

Von Christian Selle und Manfred Kroh*

Kommt ein DV-Spezialist alter Garde mit der Objektorientierung in Beruehrung, so fuehlt er sich einem Chaos konfrontiert. Selbst ein Programmierer, der C beherrscht und meint, er koenne deswegen bereits mit C++ umgehen, erlebt eine gewaltige Ernuechterung. Jahrzehntelang eintrainiertes Vorgehen greift ploetzlich nicht mehr. Es geht um die Orientierung in einer voellig unbekannten Welt.

Eine normale Reaktion ist die, zunaechst nach Gemeinsamkeiten mit der altbewaehrten Vorgehensweise zu suchen, um das Neue in eine wiedererkennbare Struktur einzuordnen. Aber ploetzlich ist alles anders - als waeren bislang mit einem Meissel Loecher in die Wand gehauen worden, und nun stuende eine Bohrmaschine zur Verfuegung. Die Folge ist, dass mit der Bohrmaschine umgegangen wird wie zuvor mit dem Meissel.

Um die Idee zu verstehen, die hinter der Objektorientierung liegt, und den richtigen Umgang damit zu finden, ist Zeit noetig. Die Entwickler brauchen mindestens ein halbes Jahr theoretischer Beschaeftigung mit dem neuen Konzept, um ueberhaupt verstehen zu koennen, um was es geht. Darauf folgt intensive Arbeit an konkreten Aufgaben, um richtig mit den neuen Methoden vertraut zu werden. Ein Trost: Nach einer gewissen Zeit der Beschaeftigung mit Objektorientierung setzt der Erkenntnisprozess ein, und es erschliessen sich rasch Umgebungszusammenhaenge.

Die Zelle enthaelt den Code des Gesamtorganismus

Das wesentliche Kennzeichen der strukturierten Programmierung ist, dass ein Element innerhalb einer Hierarchie nur genau an der Position, wo es steht, seine Funktion erfuellt. Der Programmierer muss sich explizit um den Nachrichtenaustausch zwischen den einzelnen Elementen kuemmern. Will er eine andere Subroutine verwenden, definiert er Datentypen. Beim strukturierten Ansatz weiss immer nur die darueberstehende Instanz ueber alles Bescheid.

Bei der Objektorientierung hingegen wird ein ganz anderer Weg verfolgt. Ein einmal definiertes Objekt traegt in sich die Information ueber das Ganze - aehnlich wie die Koerperzelle, die zwar eine bestimmte Funktion hat, aber den genetischen Code des Gesamtorganismus enthaelt. Analog dazu muss auch ein Objekt so beschrieben sein, dass es in sich weitere kleine Objekte enthaelt.

Heisst dieses Objekt zum Beispiel "Rechnungswesen", so tragen die "Zellen", die es enthaelt und die alle eine bestimmte Funktion haben, in sich auch die Information des Gesamtobjekts. Sie wissen alle: "Ich mache Rechnungswesen."

Nehmen wir zum Beispiel ein im Rechnungswesen enthaltenes Objekt mit der Bezeichnung "Rechnung". Es ist in der Lage, gleichzeitig verschiedenen Abteilungen zur Verfuegung zu stehen. Das ist das Interessante und Neue an den objektorientierten Systemen. Bildlich ausgedrueckt, schweben viele eigenstaendige Objekte umeinander.

Nun wird die Nachricht durch das System geschickt: "Ich suche jemanden, der fuer mich eine Rechnung schreiben kann." Das betreffende Objekt reagiert mit einer Meldung: "Verstehe, ich kann das." Daraufhin tritt es in Aktion und schickt die Loesung zurueck. Das ist in einem strukturierten, funktional orientierten System undenkbar.

Programmierer muessen sich also nicht mehr um den Nachrichtenaustausch zwischen verschiedenen Objekten kuemmern. Der dazu notwendige Mechanismus ist im System fest implementiert. Alles passt bereits mit allem zusammen, ist sozusagen steckerkompatibel.

Beide Vorgehensweisen - die strukturierte wie die objektorientierte - stehen jedoch im Grunde nur fuer verschiedene Moeglichkeiten zur Problemloesung, die beide ihre Berechtigung haben.

Die Objektorientierung ist fuer ganz bestimmte Anwendungsbereiche geeignet, fuer andere wiederum nicht. So erlaubt sie zum Beispiel eine wesentlich staerkere Ausrichtung an der Anwendung. Aber sie hat auch ihre Schwachstellen.

Beispielsweise herrscht eine gewisse Euphorie, was die Wiederverwertbarkeit und die Vererbbarkeit angeht. Wiederverwertbarkeit ergibt sich aber nicht allein durch Objektorientierung. Das Problem besteht darin, den Ueberblick ueber Verfuegbares zu bewahren. Der dazu notwendige Verwaltungsaufwand kann im Laufe der Entwicklungsarbeiten immens werden. Zudem ist der strukturierte Ansatz besser zur Beschreibung von Ablaeufen geeignet.

In der heutigen Praxis wird noch ueberwiegend strukturiert vorgegangen, selten objektorientiert, und noch seltener wird eine Verbindung der Verfahren gesucht. Bei der Komplexitaet heutiger Anwendungen ist jedoch das alte Vorgehen an eine Grenze gelangt. Erst jetzt, wo es nicht mehr anders geht, setzen Vereinfachungsprozesse ein.

Die technische Entwicklung ist ein Spiegel der Neustrukturierungsprozesse, die derzeit in vielen Unternehmen im Gange sind. Organigramme verkoerpern ebenso wie die Block- und Abhaengigkeitsdiagramme der Informatiker das strukturierte Denken, die alte Ordnung. Im Bestreben, den Arbeitsablauf von oben zu planen, zu steuern und zu kontrollieren, wurden festgelegte Strukturen mit einer grossen Zahl von Fuehrungsebenen, mit vielen Vorgesetzten und Untergebenen geschaffen.

Diese Strukturen werden den heutigen Anforderungen nicht mehr gerecht. Das betriebliche Zusammenspiel zeichnet sich durch eine immer groesser werdende Komplexitaet von Produkten, Projekten, Technologien und Wertvorstellungen aus.

Teilautonome Arbeitsgruppen

Weitere Kennzeichen der bestehenden Strukturen sind die zunehmende Durchdringung aller betrieblichen Funktionsbereiche mit informationstechnischen Anwendungen sowie eine fortgeschrittene Spezialisierung von Mitarbeitern, deren Arbeitsergebnisse zunehmend weniger von oben kontrolliert werden koennen.

Heute treten daher an die Stelle der hierarchisch strukturierten Betriebe gewissermassen objektorientierte Unternehmen. Herkoemmliche Hierarchien loesen sich auf in flexible Netzwerke, multidisziplinaere Teams und teilautonome Arbeitsgruppen, die sich weitgehend durch Selbst-Management steuern.

Kuenftig wird sich die Zuordnung von Mitarbeitern zu Fuehrungskraeften und Organisationseinheiten haeufig aendern. Die Arbeit in immer neuen Projekten mit staendig wechselnden Projektleitern wird zum Normalfall. In einem fliessenden Prozess fungiert der Chef von heute als Mitarbeiter von morgen und umgekehrt.

Es entstehen chaotische Strukturen, die sich jedem Versuch widersetzen, sie in Organigrammen alter Praegung abzubilden. Chaotisch sind diese Strukturen nicht im Sinne von totaler Verwirrung und voelligem Durcheinander, sondern von konstruktiver Aufloesung ueberkommener Ordnungen, Selbststeuerung und prozessorientierter Entwicklung.

Uebertraegt man das Prinzip der Objektorientierung auf ein Unternehmen, so bedeutet dies, dass im Idealfall nichts organisiert werden muss, aber alles trotzdem laeuft. Wenn Menschen oder Objekte gut zusammenarbeiten, dann greift alles reibungslos ineinander. Jede "Zelle" des Unternehmens ist in der Lage, in ihrem Bereich Entscheidungen zu treffen, die im Einklang mit dem Ganzen stehen - auch wenn sie nicht im Detail ueber die jeweiligen Taetigkeiten in allen anderen Teilen der Organisation informiert sein kann. Ob im Zuge der Neustrukturierung in Unternehmen oder der Einfuehrung der objektorientierten Programmierung - die auftretenden Schwierigkeiten sind dieselben: Die neue Arbeitsweise verlangt eine Abkehr von Ellenbogenmentalitaet und Profilierungsneurose.

Ploetzlich ist ein voellig veraendertes Denken gefragt: Optimale Arbeitsergebnisse koennen nur dann erzielt werden, wenn sich die Einzelleistungen der Beteiligten zu einem Teamerfolg zusammenfuegen. Dies setzt allerdings die Bereitschaft voraus, sich entbehrlich zu machen.

Wissen wird noch eifersuechtig gehuetet

Wie sieht das aber in der Praxis aus? Die meisten Projekte fuehren zu dem Ergebnis, dass die Menschen, die daran gearbeitet haben, unersetzbar geworden sind. Der Entstehungsprozess der Einzelleistung bleibt dabei zumeist im dunkeln.

Wissen wird als Macht empfunden, Abgabe von Wissen als Machtverlust - dieses Denken beherrscht vielerorts noch die Unternehmenskultur. Warum sollten Mitarbeiter bestrebt sein, ihr Wissen transparent zu machen, ihr eigenes Machtmonopol zu unterhoehlen, wo sie doch gerade im Wissensvorsprung ihre Sicherheit vor Verlust des Arbeitsplatzes und unliebsamer Konkurrenz sehen? Daher wird Wissen eifersuechtig gehuetet.

Ist ein Objekt einmal optimal definiert, so kann es immer wieder verwendet werden. Wenn das Rad statt dessen doch noch einmal erfunden wird, gleicht dies einer - im Grunde ueberfluessigen - Arbeitsbeschaffungsmassnahme.

Objektorientiertes Vorgehen verlangt viel von Menschen. Im Vordergrund darf nicht laenger das Bestreben stehen, sich nicht in die Karten schauen zu lassen, sondern allein die Aufgabe, die optimal geloest werden will. Anschliessend wendet man sich einer neuen Arbeit zu. Der Prozess der Software-Erstellung wird damit zu einer Summe aus anonymen Einzelleistungen.

Ueber die menschlichen Aspekte beim Umgang mit Objektorientierung gibt es viel mehr zu sagen als ueber die technischen. Denn das Wichtigste wird zumeist uebersehen: die "Peopleware", die Beschaeftigten, die mit den Werkzeugen arbeiten. Das Gelingen eines Projektes haengt weniger vom Werkzeug ab als davon, dass die Beteiligten optimal miteinander kommunizieren koennen.

Diese Faehigkeit ist bei Mitarbeitern, die sich jahrzehntelang innerhalb traditioneller Hierarchien bewegt haben, Befehlsempfaenger waren und ueber wenig Entscheidungsfreiraeume verfuegten, oft verkuemmert. Qualifizierungsmassnahmen muessen dieser Tatsache Rechnung tragen und duerfen sich nicht laenger allein an der Technik orientieren.

Vom Kaestchendenken

zum konstruktiven Chaos

Evolutionaere Software-Entwicklung und Workflow-orientierte Ablauforganisation sind zwei Auspraegungen desselben Trends: weg von deterministischen, hin zu ereignisgesteuerten - mithin "chaotischen" - Strukturen. DV-technisch umsetzen laesst sich dieser Trend durch die Objekttechnik.