Das vergessene Versprechen

von Sascha Frick (Januar 04)

Als Objektorientierung sich langsam den Weg in das Bewusstsein einer breiten Öffentlichkeit bahnte, war einer ihrer oft genannten Vorzüge die Eingänglichkeit der zugrundeliegenden Konzepte wie Klassen und Objekte und die damit verbundene Nähe zur natürlichen Art des menschlichen Denkens; schliesslich ist unser Alltag ja voll von Objekten, mit denen wir irgend etwas anstellen: Vom Wecker beim Aufstehen, über die Kaffeemaschine über unsere Zahnbürste bis hin zum Auto oder einem simplen Kugelschreiber – ständig verwenden wir Objekte, die zu einer bestimmten Kategorie (Klasse) gehören, die über Eigenschaften verfügen und mit denen wir etwas tun können. Zweifellos sind Objekte eine wunderbare Sache, und so könnten wir heute einstimmig erklären:

Der Methodenstreit ist vorbei, die Objektorientierung hat gewonnen, und wir alle sind die Sieger.

Oder etwa nicht? Leider nein.

Denn obwohl Objektorientierung heute in aller Munde ist und in der Sofwareentwicklung auf breiter Front eingesetzt wird, ist einer der wesentlichen Vorzüge dieses Paradigmas auf der Strecke geblieben: Die einfache Bedienbarkeit unserer Anwendungen auf der Basis von Objekten. Zwar gehören grafische Bedienoberflächen mit Maus, Menus, Fenstern und Symbolen seit längerem zu unserem Computer-Alltag. Doch bei den meisten Programmen merken wir als Anwender nicht einmal, dass wir es mit Objekten zu tun haben. Stattdessen werden wir mit prallvollen Symbolleisten und riesigen Menubalken bombardiert, die uns schnell vergessen lassen, dass uns die Objektorientierung eigentlich erlauben würde, unsere Objekte direkt zu manipulieren. Diese Form der unmittelbaren Bedienung findet sich höchstens in Grafikprogrammen oder – fast noch häufiger – in Computerspielen; in den so genannt unternehmenskritischen Anwendungen dominieren dagegen funktionsorientierte Benutzerschnittstellen, welche die von der Objektorientierung versprochene Vereinfachung Lügen strafen: Keine Spur von direkt manipulierbaren Objekten, die Daten und Verhaltensweisen zusammen führen und so eine intuitive und der Aufgabe angemessene Arbeitsweise erlauben würden. Viel häufiger wird die Anwenderin oder der Anwender entmündigt, und sie oder er muss einem vorgegebenen Ablauf folgen, auch wenn dies der anstehenden Aufgabe völlig zuwider läuft. Das ist nicht nur für die Anwenderinnen unbefriedigend. Wer einmal erleben musste, wie der Anruf in einem Callcenter zum Spiessrutenlauf mit der Technik wird, der weiss, was moderne Informationstechnik anrichten kann: Skript-gesteuerte menschliche Einheiten müssen machtlos einem kosten-optimierten Ablauf folgen , der nicht selten das Kundenanliegen im wahrsten Sinne des Wortes erledigt ohne freilich für den Kunden zum gewünschten Ergebnis zu führen. Wie oft haben wir als Entgegnung auf unsere Frustration als Kunde den Satz eines nicht minder frustrierten Callcenter-Mitarbeiters gehört: „Ich kann leider nicths tun - Sie wissen schon: Der Computer !„ So geniesst der Computerspieler einen Vorzug, der den meisten Computeranwendern im beruflichen Alltag verwehrt bleibt: Die Möglichkeit als Problemlöser dem Computer zu sagen, was er tun soll anstatt zur menschlichen Einheit an der technischen Systemgrenze zu verkommen, die im vorgegebenen Ablauf den richtigen Knopf zu drücken hat.

Viel ist von der ursprünglichen Idee der direkt manipulierbaren Objekte heute wirklich nicht mehr übrig. Die Ursachen dafür sind vielfältig, wobei mir aber vorallem zwei wesentliche Punkte dafür verantwortlich scheinen, die zu dieser Entwicklung geführt haben: übertriebene Ablauforientierung und Misstrauen gegenüber Menschen. Ersteres folgt aus letzterem und führt zu einem Optimierungswahn, der meistens mit der Möglichkeit, Kosten zu sparen begründet wird. Dabei wird selten über die Opportunitätskosten geredet, die durch optimierte EDV-gestützte Abläufe verursacht werden, da sie dem denkenden Menschen keine Einflussmöglichkeit mehr lassen und ihm dadurch verunmöglichen, situativ zu reagieren. Der Mensch wird dabei nicht als Problemlöser sondern als mögliche Störung betrieblich und technisch optimierter Abläufe gesehen, die es möglichst auszuschalten gilt. Und so feiert Taylors Scientific Management fröhliche Urstände, freilich in modernerem Gewand und unter neuen Namen wie Business Process Reengineering (BPR) und Value Chain. Und auch in den Entwicklungsmethoden findet sich diese ablauforientierte Sicht mit den Use Cases wieder. Dabei leiden sowohl BPR als auch Use Cases unter dem gleichen Problem: Die starke Fokussierung auf Prozesse und Skripte in Form von Ablaufszenarien bei der Abbildung betrieblicher Aktivitäten führt zu einer Fragmentierung in den Daten und Verhaltensweisen. Damit wird letztlich genau dem Vorschub geleistet, was mit der Objektorientierung verhindert werden soll: die Zersplitterung der abzudeckenden Verantwortlichkeiten in den Geschäftsobjekten. Solche Systeme sind in der Regel stark transaktionsorientiert und bestehen aus einer Reihe von ablauf-optimierten skriptbasierten Prozeduren, die dem Anwender wenig Spielraum für eigenes Handeln lassen. Demgegenüber stehen Anwendungen, die - wie bereits erwähnt - den Anwender als Problemlöser betrachten und entsprechend grosse Freiräume ohne starre Ablaufvorschriften bieten. Eine Verschmelzung dieser beiden Konzepte scheint dringend nötig. Dabei geht es nicht darum, die heutigen Geschäftsanwendungen mit objektorientierten Benutzerschnittstellen aufzuwerten. Das Ziel muss es vielmehr sein, die Ausdrucksstärke künftiger unternehmenskritischer Anwendungen bezüglich der zu manipulierenden Objekte wesentlich zu verbessern. Idealerweise wird die Benutzerschnittstelle vollkommen transparent und lässt echte Geschäftsobjekte an die Oberfläche treten, die als vollständige Schlüsselabstraktionen verstanden und manipuliert werden können. Dass dies nicht einfach eine Utopie ist, zeigen viel versprechende Projekte und Produkte wie zum Beispiel BlueJ, Squeak und NakedObjects. Für Geschäftsapplikationen bedeutet dies, dass es einen generischen Mechanismus gibt, der die Benutzerschnittstelle auf der Basis der Geschäftsobjekte automatisch generiert. Diesen Ansatz haben wir übrigens bereits 1996 mit metagenic 1.0 für ein bedarfsgerechtes Datenmanagement erfolgreich umgesetzt. Dabei stellt aber die von metagenic zur Verfügung gestellte objekt-basierte Datenmanipulation lediglich den ersten Schritt auf dem Weg zu vollständig manipulierbaren Geschäftsobjekten dar. Java und .NET-basierte Sprachen bieten heute aufgrund der zur Laufzeit verfügbaren Metainformationen das ideale Sprungbrett für die nächste Generation echter objektorientierter Anwendungen.

Viele stehen der Idee äusserst skeptisch gegenüber, dem Anwender mehr Verantwortung zu überlassen. Sie befürchten, dass die Effizienz unter der erhöhten Ausdrucksstärke der Geschäftsobjekte und der fehlenden ablauforientierten Aufgabenstrukturierung spürbar leidet. Im engeren Kontext von Standardaufgaben mag das sogar zutreffen, doch in einem breiteren Kontext dürfte die gewonnene Freiheit in der Aufgabenbewältigung die Effizienz letztlich erhöhen. Anwendungen, die direkte Objektmanipulation ermöglichen, um anstehende Aufgaben zu lösen, befähigen die Benutzer, ihre Arbeit entsprechend ihres sachstrukturellen Entwicklungsstandes zu erledigen. Dies fordert und fördert das kontinuierliche Lernen durch die Mitarbeitenden, und erlaubt ihnen, das erworbene Wissen gewinnbringend für das Unternehmen einzusetzen. Diese Selbstbefähigung ist eine nicht zu unterschätzende Komponente. Das sollten jene bedenken, die gerne über das Thema Mitarbeitermotivation reden und allerlei Motivationsschlaumeiereien auf Lager haben - denn man kann Menschen letztlich nicht motivieren (das Gegenteil ist dagegen sehr leicht möglich), man kann lediglich dafür sorgen, dass sich die Motivation entfalten kann.

Die Umsetzung heutiger Anwendungen scheint mir in einem Teufelskreis gefangen: Anwender haben nicht gelernt, ihre Arbeit mit Hilfe des Computers problemorientiert zu lösen. Sie sind es vielmehr gewohnt, durch eine Anwendung geführt zu werden. U.a. auch darum werden Systeme ablauforientiert entworfen. Dies wiederum verhindert, dass Anwender einen auf die direkte Manipulierbarkeit von Objekten ausgerichteten Arbeitsstil beherrschen, was letztlich den Hang zu ablauforientierten Lösungen erhöht. Nur wenn wir uns an das ursprüngliche Versprechen der Objektorientierung erinnern, wird es uns gelingen, aus diesem Kreislauf auszubrechen und Anwendungen zu entwerfen, die ihre Anwender befähigen anstatt sie zu entmündigen.

Über diesen Artikel diskutieren.