CW: Worin unterscheidet sich Ihr Produkt "Poet" von den Mitbewerbern aus den USA?

Witte: Wir richten uns auf den Desktop aus, das heisst, wir besitzen technische Funktionalitaet, die uns fuer den PC geeignet macht.

CW: Welche denn?

Witte: Beispielsweise der "small footprint", also der geringe Bedarf an Systemressourcen. Zudem hat Poet eine portable Architektur, und es ist skalierbar. Demnaechst wird es sogar moeglich sein, mit einem Multithreaded Server zu arbeiten.

CW: Nicht alle OODBMS-Produkte sind Multiuser-faehig. Wie ist das mit Poet?

Witte: Es gibt tatsaechlich Architekturen, die den Multiuser- Betrieb erschweren, weil sie beispielsweise einen Page-Level- Ansatz verfolgen. Dort ist die kleinste verwaltbare Einheit eine Seite. Das fuehrt oft zu Sperrkonflikten, was in einem Multiuser- System sehr unangenehm sein kann. Poet hingegen liest, schreibt und sperrt auf Objektebene.

CW: Eine Seite laesst sich auch als Objekt definieren. Wie klein duerfen Ihre Objekte sein?

Witte: Beliebig. Fuer bestimmte Applikationen kann ein Objekt ein Punkt oder eine Koordinate sein. Die Frage ist allerdings, wie wirkungsvoll es ist, Objekte so klein zu machen.

CW: Anwendungen auf der Basis von objektorientierten Datenbanken beschraenken sich derzeit weitgehend auf den technischen Bereich, waehrend die sogenannten strategischen Systeme auf relationaler Technik basieren. Wie lange wird es dauern, bis dieser Vorsprung aufgeholt ist?

Witte: Das kann in einigen Jahren geschehen. Aber die objektorientierten Systeme werden die relationalen sicher nicht verdraengen. Diese Techniken sind faehig zu koexistieren. Unabhaengig davon waechst der Markt fuer objektorientierte Systeme aber sehr viel schneller. Und ich bin der Ansicht, dass die Hersteller objektorientierter Datenbanksysteme aehnliche Groessenordnungen erreichen koennen wie die relationaler.

CW: Wenn ich Sie recht verstanden habe, halten Sie es aber nicht fuer sinnvoll, dass ein Unternehmen seine gesamte Informationsverarbeitung auf einem objektorientierten Datenbanksystem aufbaut.

Witte: Denkbar ist das selbstverstaendlich schon. Und Sinn macht es besonders dann, wenn es sich um komplexe Unternehmensdaten handelt. Es waere aber wenig sinnvoll, beispielsweise die Kontenbewegungs-Daten einer Bank in ein objektorientiertes Datenbanksystem zu packen. Dafuer, also fuer grosse Mengen einfach strukturierter Daten, sind die relationalen Datenbanksysteme optimiert.

CW: Heisst das, solche Anwendungen sind mit einem objektorientierten System nicht handhabbar?

Witte: Grundsaetzlich schon. Aber hier bietet die Architektur objektorientierter Datenbanken keine speziellen Vorteile.

CW: Ist sie denn von Nachteil - beispielsweise wegen schlechterer Durchsaetze?

Witte: Die Performance-Frage laesst sich nicht generell beantworten. Das haengt stark von den Anforderungen und vom Datenmodell des Kunden ab.

CW: Welche Art von Anwendungen werden denn mit Poet erstellt?

Witte: Unsere Erfolge liegen vor allem dort, wo ISVs, also Hersteller von Branchenloesungen, Poet wie ein OEM-Produkt in ihre Applikationen einbinden.

CW: Ist es ueblich, dass diese Anwendungen mit relationalen Datenbanken zusammenarbeiten?

Witte: Nein, diese Loesungen setzen komplett auf Poet auf. Sie verwenden keinerlei andere Datenbanktechnik und sind durchgaengig objektorientiert programmiert.

CW: Mit anderen Worten: Es existieren keine Schnittstellen zwischen Poet und relationalen Datenbanksystemen.

Witte: Die gibt es derzeit tatsaechlich nicht. Man kann Daten importieren, aber es besteht noch keine Moeglichkeit, direkt auf relationale Strukturen zuzugreifen.

CW: Ihre Mitbewerber sind Ihnen da einen Schritt voraus.

Witte: Wir haben aehnliche Plaene.

CW: Sicher, denn schliesslich setzen Sie auf Kooperation statt Konfrontation.

Witte: Auch im Datenbankbereich macht es keinen Sinn, die eierlegende Wollmilchsau zu erfinden, also ein System, das sich fuer jedes Datenvolumen, jede Struktur und jede Anforderung eignet. Ich kann selbstverstaendlich versuchen, mit jedem Werkzeug alles zu machen, also mit einer relationalen Datenbank komplexe, objektorientierte Daten zu speichern und in einer objektorientierten Datenbank einfache Massendaten abzulegen. Die Frage ist nur, ob das effizient ist. Man wird in beiden Faellen einen gewissen Overhead in Kauf nehmen muessen - in bezug auf die Performance oder die Verwaltung.

CW: Was halten Sie eigentlich von der in den 80er Jahren weitverbreiteten Idee eines durchgaengigen Unternehmensdaten- Modells?

Witte: Der Versuch, ein solches Modell zu erstellen, ist sehr schwierig. Selbst wenn es gelingt, wird es wohl so starr sein, dass es mit der Schnellebigkeit der Anwendungen nicht mithalten kann. Der dezentrale Ansatz mit Objekten verspricht mehr Flexibilitaet.

CW: Ihr staerkster Konkurrent auf dem Markt fuer objektorientierte Datenbanksysteme war bis zum vorletzten Jahr unangefochten Object Design. Mittlerweile kriselt es dort etwas. Wer profitiert davon?

Witte: Alles in allem handelt es sich um einen schnell wachsenden Markt - auch wenn Object Design den riesigen Umsatzsprung von 1993 im Jahr darauf nicht wiederholen konnte. Im uebrigen sind wir der Marktfuehrer bei den Desktop-Systemen - nach Stueckzahlen und nach Technologie.

CW: Wie grenzen Sie diesen Desktop-Markt ab? Die Konkurrenzsysteme laufen schliesslich auch auf PCs.

Witte: Aber nur theoretisch. Sie koennen doch nicht sagen, dass Sie eine Loesung fuer den PC haben, und dann allein fuer die Datenbankmaschine 20 MB Hauptspeicher benoetigen. Zudem brauchen Sie eine intelligente Ressourcen-Verteilung zwischen Client und Server.

CW: Sind die anderen Systeme also ungeschickt programmiert?

Witte: Ein Grossteil der Probleme haengt damit zusammen, dass die anderen Hersteller von den Unix-Systemen herkommen. Da waren die Memory- und Ressourcen-Restriktionen eben andere als auf dem PC. Wir haben zwar parallel (zur DOS-Ausfuehrung, Anm. d. Red.) eine Unix-Version entwickelt, aber wir waren uns bei allen Architektur- und Design-Entscheidungen immer des Flaschenhalses PC bewusst.

CW: Aber das bedeutet sicher funktionale Einschraenkungen.

Witte: Es gibt Unterschiede in der Funktionalitaet - zum Beispiel bei verteilten Datenbanken mit komplett verteilten Servern sowie im Transaktionsbereich. Aber im allgemeinen zahlen die Kunden dafuer mit einem Overhead, der nur wenigen einen entsprechenden Gegenwert bringt.

CW: Welche Abstriche muss der Kunde konkret machen - beispielsweise bei seinen Transaktionen?

Witte: Wir haben selbstverstaendlich auch ein Transaktionskonzept, aber wir unterstuetzen keine langen Transaktionen. Sie koennen nicht ueber Tage oder Wochen unterschiedliche Objektversionen halten und dann wieder zusammenfuehren. Das ist fuer unsere Klientel nicht relevant.

CW: Poet Software ist eines der wenigen deutschen High-Tech- Unternehmen, das sich Venture-Kapital beschaffen konnte. Wie ist Ihnen das gelungen?

Witte: Bei BKS hatten wir existierende Produkte, die wir erfolgreich verkauften, sowie ein gutes, auf diesen Werkzeugen aufsetzendes Projektgeschaeft. Diese Kombination hat es uns gestattet, die Ueberschuesse aus den Projekten in die Arbeit an neuen Produkten zu investieren. Damit konnten wir die Entwicklung von Poet bis zum Release 1.0 komplett selbst finanzieren. Erst nach der Verfuegbarkeit der ersten Version haben wir uns um Venture-Kapital bemueht, weil wir Poet international vermarkten wollten.

CW: Wie haben Sie die Kapitalgeber gefunden?

Witte: Wir sind quasi ueber die (in Amsterdam beheimatete, Anm. d. Red.) Technologie Holding gestolpert - oder vielmehr, die gleichzeitig auch ueber uns. Hinzu kam die CAT (Compagnie Auxiliaire Telecommunication, Paris, Anm. d. Red.), eine Tochter der France Telecom. Die beiden Unternehmen arbeiten eng zusammen.

CW: Mit Sigma Partners und El Dorado Ventures haben sich mittlerweile auch US-Geldgeber beteiligt. Und es heisst, Sie wollen in den USA an die Boerse gehen. Wie fern ist dieses Ziel?

Witte: Einen Zeitraum von zwei bis drei Jahren halte ich fuer realistisch.

Kurz & buendig

Mittlerweile verfuegen die meisten OODBMS-Produkte ueber Schnittstellen zu relationalen Datenstrukturen, und die Protagonisten des RDBMS-Markts bemuehen sich, ihre Angebote mit objektorientierter Funktionalitaet auszustatten. Die sprichwoertliche eierlegende Wollmilchsau wird es aber, so Jochen Witte, Geschaeftsfuehrer der Poet Software GmbH, Hamburg, trotzdem nicht geben. Witte sucht seinen Markt dort, wo er die Vorteile seines Produkts ausspielen kann: Wie er beteuert, ist "Poet" ein von Anfang an fuer den Desktop ausgelegtes System mit relativ geringem Speicherbedarf. Dadurch unterscheide es sich von den Mitbewerbern, die ihre Produkte unter Unix entwickelt und erst auf den PC portiert haetten.

Das Unternehmen

Die Geschichte der Poet Software GmbH, Hamburg, geht zurueck auf das Berliner Unternehmen BKS Software, das Mitte der 80er Jahre gegruendet wurde und zunaechst C-basierende Entwicklungswerkzeuge fuer PCs und Unix hervorbrachte. Zum Jahreswechsel 1991/92 stellte BKS das objektorientierte Datenbanksystem Poet vor. Mitte 1993 wurde das Produkt in ein eigenes Unternehmen ueberfuehrt. Um den Sprung ueber den Atlantik zu finanzieren, hatten sich dieBerliner im Mai 1992 Risikokapital von zwei euroaeischen Venture-Kapital- Gebern beschafft. 1995 stiessen zwei US-amerikanische Gesellschafter hinzu, so dass mittlerweile 60 Prozent des Firmenkapitals aus VC-Fonds stammen. Weltweit nahm die Poet- Holding im vergangenen Jahr acht Millionen Mark ein, zu denen die im kalifornischen San Mateo beheimatete Poet Software Inc. mehr als die Haelfte beisteuerte.