In den kommenden Jahren wird sich der Markt fuer Software-Applikationen tiefgreifend veraendern. Objektorientierte Infrastrukturen wie zum Beispiel Corba, Opendoc und OLE schaffen die Voraussetzung fuer ein Geschaeft mit kleineren und groesseren Softwarekomponenten, die auf lange Sicht die heute ueblichen Anwendungspakete - von der Textverarbeitung bis hin zur Produktionsplanung und -steuerung (PPS) - ueberfluessig machen koennten. Der Unternehmensberater und Querdenker Peter Eichhorst erlaeutert, wie der jahrzehntelange Traum von der massgeschneiderten Standardanwendung schliesslich doch noch Wirklichkeit werden koennte. Mit dem Vater des PC-Pakets "Open Access" und des objektorientierten Entwicklungswerkzeugs "Enfin 3" sprach CW-Redakteurin Karin Quack.

CW: Den Trend bei den Anwendungsentwicklungs-Werkzeugen bestimmt derzeit Client-Server. Was macht eigentlich ein Client-Server-Tool aus?

Eichhorst: Client-Server wird heute zumeist so verstanden, dass die Anwendung auf dem PC laeuft und die Datenbank auf dem Server liegt. Die entsprechenden Tools ermoeglichen es, auf der Client-Seite grafische Benutzer-Schnittstellen und auf der Server-Seite Datenbanken zu entwickeln. Die Ausgabe besteht im Normalfall aus SQL-Statements. Ich halte das jedoch fuer eine zu enge Betrachtungsweise. Im eigentlichen Sinn besteht das Client-Server- Prinzip in verteilten Anwendungen. Ein Client kann also einen anderen - zumindest temporaer - als Server nutzen. Hier sind die herkoemmlichen Tools nicht mehr verwendbar. Es gibt heute so gut wie keine Produkte, die das koennen.

CW: Inwieweit koennen objektorientierte Werkzeuge hier Abhilfe schaffen?

Eichhorst: Es gibt einen natuerlichen Zusammenhang zwischen Objektorientierung und Client-Server. In der Objekttechnik ist ein Programm nichts anderes als die Kommunikation zwischen Objekten, also eine Sequenz von Nachrichten. Und eine solche Nachricht hat allein den Zweck, einen Service anzufordern. Damit fungiert immer ein Objekt als Client und das andere als Server. Objektorientierte Anwendungen sind also per se Client-Server-Applikationen.

CW: Unter dem Sammelnamen Objekttechnik werden heute die unterschiedlichsten Werkzeuge angeboten. Was muss ein Tool koennen, damit es die Bezeichnung objektorientiert verdient?

Eichhorst: Es gibt viele Kriterien dafuer, aber ich will nicht allzusehr ins Detail gehen. Grundsaetzlich muss der Anwender fragen: Lassen sich Daten und Services in einer Kapsel einschliessen? Kann ich Klassen definieren und echte Unterklassen bilden - also nicht nur Code duplizieren? Und stehen mir Moeglichkeiten fuer eine polymorphe Handhabung von Nachrichten zur Verfuegung? Es gibt nur ganz wenige Produkte, bei denen alle Antworten positiv ausfallen. Dass so viele andere ebenfalls unter dem Etikett Objekttechnik vermarktet werden, haengt mit den grafischen Benutzer- Schnittstellen zusammen, die heute fast jedes Tool unterstuetzt. Ein grafisches "Objekt" bedeutet aber noch keine Objektorientierung.

CW: Gibt es Ihrer Definition zufolge ueberhaupt Client-Server- Systeme, die nicht objektorientiert entwickelt wurden?

Eichhorst: Ja, schon - in dem eingeschraenkten Sinn, wie ich es vorhin beschrieben habe. Allerdings wird die Datenbank in diesen Anwendungen aehnlich einem Objekt behandelt, naemlich als Black-box. Aber die Tools, die darauf zugreifen, muessen nicht objektorientiert sein. Objekttechnik ist erst dann notwendig, wenn ich verteilte Anwendungen im eigentlichen Sinn erstellen will.

CW: Solange es um die Analyse und das Design geht, leuchtet das ein. Aber implementieren lassen sich solche Anwendungen sicher auch konventionell.

Eichhorst: Sie haben recht. Mit Remote Procedure Calls koennte man das sicher auch implementieren - ungeachtet aller Probleme, die sich ergeben, weil Vererbung, Polymorphismus etc. fehlen.

CW: Wie sehen diese Probleme aus?

Eichhorst: Die mit RPCs entwikkelten Applikationen sind nicht wiederverwendbar beziehungsweise durch Vererbung multiplizierbar.

Sie haben dann wieder monolithische Applikationen, mit denen Sie nicht auf Aenderungen reagieren koennen.

CW: Wiederverwendbarkeit und Flexibilitaet sind zweifellos die Hauptvorteile objektorientierter Applikationen. Aber vergessen Sie nicht, welchen Beitrag die Objekttechnik leistet, wenn es darum geht, Komplexitaet ueberschaubar zu machen.

Eichhorst: Richtig. Die Systeme der Zukunft werden keine Applikationen im konventionellen Sinn sein, sondern Komponenten, also objektorientierte Substrukturen, die Sie von der Stange kaufen. Allerdings muessen Sie auch in der Lage sein, die Komponenten an Ihre spezielle Umgebung anzupassen, also zu veraendern und durch Subclassing zu multiplizieren.

CW: Solche Komponenten gibt es doch heute schon, beispielsweise die Microsoft Foundation Classes ...

Eichhorst: Ja, aber im naechsten Schritt werden wir nicht nur Klassen haben, sondern Kombinationen von Klassen mit einem definierten Interface. Auf diese Weise erhalten wir Bausteine - etwa in der Art von Lego-Steinen. Ich spreche hier nicht von kleinen Einzelobjekten, sondern von objektorientierten Subsystemen, die sich moeglicherweise aus 50 Objekten, 200 Methoden und den entsprechenden Interface-Strukturen zusammensetzen. Mit solchen Einheiten zu arbeiten ist sehr viel einfacher, so dass Anwendungsprogrammierer oder sogar Endbenutzer relativ problemlos ihre Software zusammenstellen koennen.

CW: Wer stellt solche Bausteine her? Werden das Unternehmen wie IBM und Microsoft sein?

Eichhorst: Die Unternehmen, die diese Bausteine erstellen, sind in der Regel sehr klein, aber aeusserst innovativ. IBM und Microsoft liefern die Systemgrundlagen dafuer, dass die Komponentensoftware ueberhaupt arbeiten kann - Opendoc beziehungsweise OLE 2.0. In diese Richtung bewegt sich die gesamte Industrie. Und das laesst sich ohne Objekttechnik gar nicht machen. Denn die Komponenten von der Stange werden niemals alle Wuensche der Anwenderfirmen erfuellen. Auch wenn das System im grossen und ganzen passt, weicht es doch an der einen oder anderen Stelle von den Gegebenheiten des jeweiligen Unternehmens ab. Frueher hat der Anwender dann lieber gleich alles selbst entwickelt.

Bei einem objektorientierten System hingegen kann er moeglicherweise 80 Prozent der Funktionalitaet uebernehmen, wie sie ist. Dort, wo die Fertigkomponente von seinen Vorstellungen abweicht, bildet er durch Vererbung eine Subkomponente, in die er nur die jeweiligen Aenderungen hineinzuschreiben braucht.

CW: Wo liegt hier fuer den Anwender der Unterschied zu dem, was SAP mit seiner Parametrisierung anbietet?

Eichhorst: Das, was ich gerade beschrieben habe, bekommen Sie mit einer Parametersteuerung nicht hin. Denn Sie muessen alle Parameter im voraus bedacht haben, um ueberhaupt auswaehlen zu koennen. Mit einem objektorientierten System hingegen sind Sie in der Lage, alles zu machen, was Sie gerade wollen. 30 Jahre lang haben wir uns Anwendungen von der Stange ertraeumt, aber sie haben nicht funktioniert. Mit Hilfe der Objekttechnik laesst sich dieser Traum verwirklichen.

CW: Dann sind also die Anwendungsprogramme, wie sie heute vermarktet werden, demnaechst obsolet?

Eichhorst: Bei diesen Paketen verwenden Sie doch immer nur einen Bruchteil der angebotenen Funktionalitaet. Heute muessen die Hersteller in die Breite gehen, um alle Ansprueche ihrer Kunden zu erfuellen. Aber mit Komponentensoftware ist das nicht mehr notwendig. Die gesamte Software-Industrie steht vor einem Umbruch, der sich voraussichtlich innerhalb der kommenden fuenf Jahre vollziehen wird.

CW: Was macht Sie da so sicher?

Eichhorst: Es gibt eine Parallele in der Geschichte der PC- Hardware: Die PC-Industrie im eigentlichen Sinn entstand erst, nachdem der Bus-Standard S100 auf der Bildflaeche erschienen war. Denn jetzt konnten ploetzlich Hunderte von kleinen Firmen ihre Boards und Karten einem grossen Markt anbieten. Die gerade erst im Entstehen begriffenen Infrastrukturen wie Opendoc oder Corba sind die Software-Analogie zu den Standard-Bussen auf der Hardwareseite. Und wir werden zusehen koennen, wie sich Tausende von kleinen Softwarefirmen in vertikalen Maerkten spezialisieren.

CW: Wie werden die einzelnen Komponenten beim Anwender miteinander verbunden?

Eichhorst: Dafuer gibt es die Scripting Languages. Damit muss man sich nicht mehr in die Niederungen des Codierens begeben, sondern man schreibt Anwendungen auf einer sehr hohen Ebene. Solche Sprachen sind sowohl in OLE als auch in Opendoc enthalten.

CW: Was sich im Innern dieser Komponenten abspielt, bleibt dem Anwender also verborgen?

Eichhorst: Er bekommt den Source-Code ueberhaupt nicht zu sehen.

CW: Jetzt versetzen Sie sich bitte einmal in die Lage eines deutschen Entwicklungsleiters, der von einem kleinen Software- Unternehmen eine Komponente kaufen soll, in die er nicht hineinsehen kann!

Eichhorst: Das ist eines der Probleme, die in diesem Zusammenhang auftauchen. Die Loesung dafuer koennte so aussehen, dass die kleinen Software-Unternehmen ihren Kunden den Source-Code mitgeben - nur zur Sicherheit. Um Subklassen zu bilden, ist dieser Source-Code naemlich nicht notwendig. Da liegt der Unterschied!

CW: Selbst wenn der Anwender den Source-Code hat - wie gross ist seine Chance, ihn auch zu verstehen?

Eichhorst: Die Herausforderung besteht in einer sauberen Dokumentation, damit der Code in kuerzester Zeit verstanden werden kann. Und da sind sicher noch einige Probleme zu loesen - gerade bei kleineren Firmen. Wie gesagt: Es wird sich eine voellig neue Software-Industrie herausbilden.

CW: Brauchen die Anwenderunternehmen dann noch eine Entwicklungsabteilung?

Eichhorst: Nicht im herkoemmlichen Sinn. Es werden weniger Systemprogrammierer benoetigt, aber mehr Leute, die etwas vom Business beziehungsweise von Analyse und Design verstehen.

CW: In vielen Unternehmen tritt die zeitaufwendige Analyse-und- Design-Phase heute in den Hintergrund - zugunsten eines Rapid- Prototyping-Ansatzes.

Eichhorst: Ja, das ist ein Trauerspiel.

CW: Aber es ist doch nachvollziehbar. Schliesslich handelt es sich meist um solche Unternehmen, die auch mit dem CASE-Ansatz gescheitert sind.

Eichhorst: Das heisst doch nicht, dass man vor dem Neuen die Augen verschliessen darf. Die Moeglichkeit zur Vererbung schaffe ich nur, indem ich ein sauberes Modell erstelle. Wenn ich mich jetzt auf das Rapid Prototyping verlege, fange ich bei der naechsten Aenderung wieder beim Nullpunkt an. Meiner Erfahrung nach gibt es uebrigens nur wenige Entwicklungsabteilungen, die sich davon nicht ueberzeugen lassen; und die werden ihren Laden bald dichtmachen koennen. Sie muessen heute in der Lage sein, ein Informationssystem aufzubauen, mit dem Sie Geschaeftsprozesse nicht nur leicht aendern, sondern auch im Vorfeld simulieren koennen. Das schaffen Sie nur mit Hilfe eines objektorientierten Modells. Unternehmen, die das praktizieren, werden ueber kurz oder lang einen nicht aufholbaren Wettbewerbsvorsprung haben.

Vom Anwendungspaket zur OT-Beratung

Peter Eichhorst studierte Physik und Computerwissenschaften in Hamburg. Mit einem staatlichen Stipendium in der Tasche ging der junge Informatiker 1973 in die USA, um seine Ausbildung in Berkeley und Santa Barbara fortzusetzen. 1974 erwarb er den Grad eines Master of Science. Drei Jahre spaeter erhielt er die Doktorwuerde, die er sich mit einer Dissertation ueber stochastische Grammatik sowie Sprach- und Programmverifikation verdiente. Nach mehrjaehriger Lehrtaetigkeit - unter anderem in Rio de Janeiro - gruendete Eichhorst 1980 in San Diego das Unternehmen Software Products International (SPI), das mit dem PC-basierten Programmpaket "Open Access" auf den Markt ging. Im Maerz 1986 gab Eichhorst die Firmenleitung ab und gruendete ein zweites Unternehmen: die ebenfalls in San Diego beheimatete Enfin Software Corp. Unter der Bezeichnung "Enfin 3" betrieb er die Entwicklung eines der ersten objektorientierten Development-Tools. 1992 wurde Enfin von Easel akquiriert, und Eichhorst gruendete ein nach ihm benanntes Beratungsunternehmen mit Sitz in Stuttgart. Heute beraet er grosse Anwenderunternehmen in Sachen Objekttechnologie.