"Es war immer schon alles relativ relational"

26.05.1989

Nur wenige Softwarehäuser haben die Krise im Markt für Mainframe-System-Programme bislang ohne größere Schäden überstanden. Zu den Überlebenden gehört die Darmstädter Software AG - trotz oder möglicherweise wegen einer bislang eher konservativen Produktpolitik. Mit der Propagierung des objektorientierten Datenbankansatzes betritt das deutsche Softwarehaus jetzt Software-Neuland. CW-Redakteurin Karin Quack sprach mit Vorstandsmitglied Peter Pagé über die Hintergründe dieses Schritts und die künftige Strategie des Unternehmens.

þADR wurde übernommen Cullinet und Cincom melden Verluste... Auch die Software AG entwickelt hauptsächlich Systemsoftware für IBM-Großrechenanlagen. Mit welcher Strategie wollen Sie die momentane Stagnation in diesem Markt überleben?

Es gibt natürlich keine Garantie dafür, daß es der Software AG für alle Zeit gut gehen wird. Aber unsere Umsätze und Gewinne haben niemals solche Höhenflüge unternommen wie die anderer Anbieter. Deshalb hat es uns auch nicht so hart getroffen.

þLäßt sich beispielsweise mit einem DBMS-Produkt wie Adabas noch Geld verdienen?

Aber selbstverständlich! Es ist doch keineswegs so, daß ein Anwender nur ein einziges Datenbanksystem einsetzt. Einige unserer Adabas-Kunden haben daneben auch DB2 im Haus.

þIn der Branche wird gemunkelt, die Software AG schaffe sich im Bereich Anwendungssoftware ein zweites Standbein. Wollen Sie SAP Konkurrenz machen?

Ich habe gehört, daß SAP etwas dergleichen vermutet. Das ist aber nicht ganz richtig. Wir entwickeln seit etwa vier Jahren kundenspezifische Anwendungslösungen, aber keine Standardsoftware.

þWie viele solcher Lösungen hat die Software AG denn bislang entwickelt?

Ich kann die Anzahl nicht exakt benennen. Aber es waren sicher über hundert.

þDa haben Sie doch nicht jedesmal von vorn angefangen!

Doch, bislang haben wir tatsächlich jedesmal von Scratch angefangen. Aber ich will nicht ausschließen daß wir künftig bestimmte Teile mehrfach verwenden.

þWerden Sie diese wiederverwendbaren Teile Ihren Kunden anbieten?

Ja, aber das sind dann keineswegs fertige Lösungen sondern nur Grundbausteine für individuelle Software-Entwicklungen.

þIm Vergleich mit der SAP AG, die ihren Kunden mehr Software liefert, als diese tatsächlich brauchen, gehen Sie also den umgekehrten Weg. Wo sehen Sie den Vorteil Ihrer Politik für den Anwender?

Die Frage ist, was mehr Aufwand bedeutet: auf einer 60-Prozent-Lösung den Rest aufbauen oder aus einer 300-Prozent-Lösung die benötigten Programme herausfiltern.

þZurück zu Ihrem ersten Standbein: Sie haben bekanntgegeben, daß Sie an einem objektorientierten Datenbanksystem arbeiten. Wie definieren Sie den Unterschied zwischen einem objektorientierten und einem relationalen System?

Der erste Schritt zur Objektorientierung ist, zuzulassen, daß in einem Objekt Strukturen enthalten sind. Die relationale Theorie sagt, die Welt ist flach, oder andernfalls muß sie flachgeklopft werden. Aber was passiert in einem solchen System, wenn beispielsweise ein Mensch fünf Vornamen hat? Dann wird eine zusätzliche Tabelle benötigt. Aber das ist doch immer noch derselbe Mensch! Wieso soll ich ihn denn zerstückeln? - Es geht darum, daß ich multiple Felder zulasse und das so entstehende Gebilde immer noch als datenmäßige Repräsentation des Objekts Mensch begreife. Objektorientiertes Denken läßt das zu, relationales Denken nicht.

þUnd was bedeutet das für die Anwendung?

. . . daß ich nicht mehr die Daten, die ich vorher zerstückelt habe, zusammenklauben muß, sondern über eine Schnittstelle beispielsweise von einem Text die Zeile 170 bis 220 anfordern kann. Außerdem kann ich über eine logische Verknüpfung Objekte als Attribute anderer Objekte definieren.

þIst ein solches System endbenutzergeeignet?

Für den Endbenutzer wird die Sache dann interessant, wenn aus dem Datenobjekt ein sogenanntes aktives Objekt wird, wenn also zum Beispiel als ein Attribut eines Mitarbeiters ein Vorgang "Einstellung" verwaltet wird. Das bedeutet, nicht nur "Daten", sondern auch "Funktionen" werden als "Objekte" begriffen. Und damit wird der Endbenutzer in die Lage vesetzt, Funktionen zu komplexeren Abläufen zusammenzustellen, ohne dabei im eigentlichen Sinn zu programmieren. Eine passende Analogie ist der Lego-Baukasten: Die Datenfunktion entspricht dem Baustein; die Noppen sind definierte Parameter-Übergaben.

þUnd wer sorgt dafür, daß diese Noppen zueinander passen?

Das ist Sache der DV-Abteilung. Da muß ein wenig Systemsoftware geschrieben werden. Wir liefern nur die Werkzeuge, um das verwalten zu können.

þVon den relationalen Systemen wurde behauptet, sie seien in besonderem Maße endbenutzergeeignet. Teilen Sie diese Ansicht?

Die relationalen Systeme sind geeignet, dem Endbenutzer die Daten in einer verständlichen Form zu präsentieren. Denn der Enduser versteht in der Tat solche Tabellen am besten.

þTrotzdem haben wir wiederholt gehört, daß die Endanwender damit nicht zurecht kommen.

Das liegt aber nicht am relationalen System, sondern an der Sprachschnittstelle. Einem Endbenutzer SQL an die Hand zu geben und zu behaupten, jetzt habe er ein geeignetes Werkzeug, ist gemein.

þWann wird es eine lauffähige Version Ihres objektorienten Datenbanksystems geben?

Die Anwender unseres Anwendungsentwicklungssystem Predict arbeiten bereits mit objektorientierten Funktionen. Bis wir tatsächlich ein vollkommen objektorientiertes Datenbank-Management-System haben, werden wir noch eine Weile brauchen ich rechne mit fünf Jahren. Aber dann werden wir über die Programmierung von Anwendungen ganz anders reden als bisher. Im übrigen stehen wir kurz vor einer offiziellen Ankündigung in diesem Bereich.

þWenn Sie bereits objektorientierte Funktionen implementiert haben - wieso benutzen Sie den Begriff "objektorientiert" erst jetzt für Ihr Marketing?

Bis dato war die Zeit noch nicht reif für eine solche Ankündigung. Noch vor kurzem sprach alle Welt ausschließlich vom relationalen Modell.

þBedeutet der objektorientierte Ansatz das Ende des relationalen Modells?

Andere Hersteller, die weiterhin unter der relationalen Flagge segeln, werden langsam, heimlich und von innen heraus immer mehr objektorientierte Funktionalität in ihren Systemen ansiedeln. Sie werden einfach den Begriff "relational" verändern. Schließlich war schon immer alles relativ relational.

þHeißt das, Sie halten das Etikett "relational" für beliebig ...

Es ist gut, daß wir aus der Phase des Schlagwortabtausches herauskommen. Es wird künftig wieder darum gehen, rational - nicht relational - Funktionalität zu diskutieren und zu erfüllen.

þTrotzdem verwenden Sie den ebenfalls zum Reizwort avancierten Begriff "objektorientiert".

Wir benutzen dasselbe Wort, das auch die anderen benutzen. Aber das ist nicht als Schlagwort gemeint, sondern als Ausdruck dessen, was dort passiert. Dies ist der ernsthafte Versuch, Objekte wie sie in der realen Welt existieren, abzubilden, ohne unnatürliche Transformationen dazwischenzuschalten.

þDiese Funktionalität ist möglicherweise auch für Ihre langjährigen Adabas-Kunden attraktiv. Erwarten Sie, daß diese Anwender auf ein neues Produkt umsteigen?

Keineswegs. Wir werden doch nicht all das wegwerfen, was wir bisher gedacht und getan haben. Vielmehr ist Adabas nach wie vor die Basis für die Datenverwaltung; und darauf aufbauend gibt es dann Zusätze wie Text, Objekte etc.

þWas wird es den Adabas-Kunden kosten, wenn er die objektorientierten Funktionen haben will?

Eine bestimmte Gebühr für die Erweiterung des Basissystems.

þWir wissen seit mehr als einem Jahr, daß auch die IBM an einem objektorientierten Datenbanksystem arbeitet. Der Leiter des Forschungsprojekts, Peter Dadam, sagte damals, daß seine Ergebnisse nicht für den Markt bestimmt seien. Wie kommentieren Sie diese Aussage?

Wenn Sie Herrn Dadam jetzt nochmals fragen, bekommen Sie wahrscheinlich eine ganz andere Antwort.

þWieviel Vorsprung hat die Software AG vor dem Forschungsteam der IBM?

Aufgrund unserer bisherigen Erfahrungen wage ich zu behaupten: sieben Jahre.