Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

26.04.1991

Datenbankanbieter zwischen Mainframe- und Massenmarkt

Die klassischen Datenbankanbieter stecken fast alle in Schwierigkeiten. Dieter E. Jenz zeigt die Zwickmühle aufs, in der Informix, Oracle und Co. stecken: Zum einen werden sie durch IBMs DB2 aus dem Mainframe-Markt gedrängt, zum anderen finden sie sich nur schwer mit den geringen Margen im Massenmarkt auf PC-Ebene zurecht.

Der Strukturwandel in der Softwarebranche vollzieht sich für viele überraschend. Vormals blühende Unternehmen haben plötzlich mit wirtschaftlichen Schwierigkeiten zu kämpfen. Wer verfolgte es nicht: Informix schloß das letzte Geschäftsjahr mit Verlust ab, Ingres wurde "geschluckt", Oracle fuhr im letzten Jahr einen bedeutenden Quartalsverlust ein, Hersteller erreichen ihre Umsatzziele nicht. Neue Softwareversionen werden mit "heißer Nadel gestrickt" und eilig ausgeliefert, um noch schnell Umsätze zu generieren.

Andererseits vergeht zwischen Produktankündigung und Verfügbarkeit oft mehr als ein Jahr. Ankündigungen erfolgen vorzeitig, um Entscheidungen für Mitbewerber zu blockieren. Gibt es da nicht einen Datenbankhersteller, der bereits sehr laut über die qualitativen Merkmale einer Version 8 seines Datenbanksystems nachdachte, aber noch rund ein drei viertel Jahr vor Auslieferung der Version 7 steht?

Kurzum: Die wirtschaftliche Zukunft auch der bisherigen, "Festungen" unter den großen Softwareherstellern ist in Frage gestellt.

Welche Konsequenzen sind daraus zu ziehen, insbesondere für den strategischen Bereich des Daten-Managements? Teilt man nach Hardware-Größenklassen ein, so ergibt sich folgendes Bild:

- In der Klasse der Großsysteme hat DB2, gemessen an der Zahl der Neuinstallationen, mittlerweile keine ernsthafte Konkurrenz mehr.

- Die Mini- und Supermini-Klasse ist die eigentliche Domäne der Datenbankhersteller Informix, Ingres, Oracle, Sybase, Unify etc.

- Der Bereich der Kleinsysteme ist nach wie vor stark heterogen geprägt. Viele Datenbankhersteller, davon viele mit bewährten Vertriebskanälen über PC-Händler, tummeln sich auf diesem Sektor.

Diese drei "Welten" waren bisher durch eine relativ strikte Abschottung gegeneinander gekennzeichnet. Nur Oracle ist als einziges Datenbanksystem auf allen Ebenen verfügbar. Den Datenbankherstellern mit Schwerpunkt im Mikrocomputerbereich fehlt der Direktvertrieb. Ebenso ist festzustellen, daß den Herstellern im darüberliegenden Segment meist die Vertriebskanäle über Händler fehlen.

Wie läßt sich die aktuelle Situation beschreiben? Die offensichtlichen funktionalen Differenzierungsmerkmale zwischen den verschiedenen Datenbanken werden zusehends weniger. Welcher Hersteller brüstet sich nicht damit, ein "Online-Backup-Feature" anbieten zu können? Außerdem sind die Datenbanksysteme der Hardwarehersteller, dabei, die herstellerneutralen DBMS funktional zu überholen. Kurz: Es ist für die unabhängigen Datenbankhersteller wesentlich schwieriger geworden, sich im Markt zu behaupten. Wenn, wie schon seit geraumer Zeit, über den Preis beziehungsweise mit Hilfe von Nachlässen verkauft wird, fallen Sachargumente unter den Tisch.

Unsere Untersuchungen haben gezeigt, daß die Einsatzdauer eines Datenbanksystems etwa dem Lebenszyklus einer Individualanwendung (also etwa zehn bis 15 Jahre) entspricht. Ein Datenbanksystem muß somit drei bis fünf Hardwaregenerationen überstehen. Jede Entscheidung ist daher intensiv zu durchdenken damit die immensen Investitionen in diesem Zeitraum in die richtigen Bahnen gelenkt werden.

Dazu gehört, daß die Anwender auch mit der Möglichkeit eines wirtschaftlichen Scheiterns des Softwareherstellers rechnen.

Nach wie vor hat die Entscheidung für ein Datenbanksystem absolut strategische Qualität. Das in jüngerer Zeit oft ins Feld geführte Argument, durch einen einheitlichen SQL-Standard für die Datenbankabfrage würde es möglich, ein Datenbanksystem quasi ohne signifikante Änderungen in der Anwendungssoftware auszutauschen, hat noch keine Bestätigung gefunden. Im Gegenteil: In der jüngeren Vergangenheit war eher festzustellen, daß sich die SQL-Dialekte auseinanderentwickelten. Die jetzt aktuelle Festlegung auf SQL2, birgt jedoch das Potential, einigen Schaden durch Nachstandardisierung wieder gutzumachen.

Nach Schätzungen der IBM dürfte es allerdings noch etwa sieben bis zehn Jahre dauern, bis das, was heute im SQL2-Rahmen feststeht, vollständig implementiert sein wird. Wer sich aber vergegenwärtigt, wie sich die DV-Landschaft in den letzten sieben bis zehn Jahren verändert hat, für den steht außer Frage, daß das SQL-Normungsgremium damit hoffnungslos hinterherhinkt.

Versucht man, sich vorzustellen, wie die Datenbankwelt in fünf Jahren aussehen könnte, wird besonders deutlich, welch schmale Brücke SQL eigentlich darstellt. Über folgende Aspekte müssen wir in dieser Zeitspanne sicherlich ernsthaft nachdenken:

- Echt verteilte Datenbanken: In etwa zwei bis drei Jahren werden auch für Produktionsumgebungen unter Sicherheitsaspekten einsatzfähige Lösungen zur Verfügung stehen.

Wie können aber Datenbanksysteme unterschiedlicher Hersteller zusammenwirken? Dazu bedarf es eines verbindlichen Standards ("Remote-Database-Access"-Standard), der aber erst für Mitte 1992 zu erwarten ist. Was nach bisherigen Informationen von diesem Standard festgeschrieben wird, genügt bereits heute nicht mehr den Anforderungen. Liegt es dann nicht nahe, unter strategischen Gesichtspunkten das Datenbanksystem des "Meta"-Servers im Unternehmen als Bezugspunkt festzulegen?

- Objektorientierte Erweiterungen relationaler Datenbanksysteme. Zunehmend werden Datenbankhersteller objektorientierte Erweiterungen wie zum Beispiel vom Benutzer definierte Funktionen in ihre Software integrieren. Dies geschieht aber auf nicht-standardisierter Basis. Ein ANSI-Standardisierungsgremium konstituiert sich jetzt erst. Es wird mit Sicherheit noch bis 1993/1994 dauern, bis eine stärkere Akzeptanz zu verzeichnen sein dürfte.

- Ansätze zur besseren Integration mit CASE-Tools- Die CASE-Philosophien der dominierenden Hardwarehersteller (insbesondere IBM und DEC) werden sich in den nächsten Jahren aufgrund ihrer konzeptionellen und funktionalen Breite weiter in den Vordergrund schieben. Hier stellt sich die Frage, ob Fremd-Datenbanksysteme überhaupt ausreichend mit Schnittstellen unterstützt werden. Kann sich ein unabhängiger Datenbankhersteller überhaupt noch profitieren, wenn die funktionalen Merkmale, die den "unique selling point" ausmachen, gar nicht oder nur noch unzureichend genutzt werden können?

Als Fazit bleibt: SQL alleine ist nur ein Stein im Mosaik einer Datenbankstrategie. Insgesamt gesehen sind Standards keine tragfähige Basis. Hardwarehersteller mit entsprechender Marktmacht werden immer versuchen, Standards zu spalten - so auch im Fall von SQL, wo die Anwender fast ausnahmslos die DB2-Implementierung der Abfragesprache als Industriestandard bewerten.

Auch der Remote-Database-Access-Standard, der das Zusammenwirken unterschiedlicher Datenbanksysteme regelt, wird in einen offiziellen und in einen Industriestandard gespalten werden.

Das Potential, sich als Industriestandard zu etablieren, hat zweifellos das im Juni 1990 veröffentlichte IBM-SAA-"Distributed-Relational-Database-Architecture"-Konzept (DRDA). IBM übergab dem ANSI-Normungsgremium im Mai 1990 die bereits existierenden DRDA-Spezifikationen und schlug diese zur Übernahme als internationalen "RDA"-Standard vor. Wird dieses Ansinnen der IBM abgelehnt, kommt es mit Sicherheit zu einer Spaltung bei den Standardisierungsbemühungen.

Ähnliches - man hat es schon erraten - wird mit dem künftigen IRDS-Standard (kurz "Repository"-Standard) geschehen, wo IBM - ebenfalls bereits eigene Spezifikationen erarbeitet hat.

Aus Sicht eines Hardwareherstellers gehört es zu den lebensnotwendigen Strategien, Standards zu spalten. Nur so kann die eigene Installationsbasis gesichert werden. Jeder Hardware-hersteller muß Eckpunkte definieren, an denen er seine Kunden festhalten und auch zukünftige Hardwareverkäufe absichern kann. Ein Bereich ist der des Daten-Managements, ein anderer der des Netzwerk-Managements. Beide Bereiche müssen für die Zukunft als zusammenhängend, zumindest in bezug auf verteilte Datenbankumgebungen, gesehen werden (zum Beispiel koordinierte "Alerts"). Gelingt es dem Hardwarehersteller, Kunden hier an sich zu binden, nützt ein neutrales Betriebssystem wie Unix rein gar nichts mehr.

Unterstützt wird die Durchsetzung dieser Herstellerstrategien aber nicht nur durch die Etablierung von Industriestandards, sondern auch durch Bundling-Maßnahmen. Die kostenlose Draufgabe von Datenbanksoftware oder sehr günstige Lizenzpreise sind nicht als Maßnahmen zur Stützung eines schwachen Produkts gedacht wie die unabhängigen Datenbankhersteller gerne glauben machen wollen -, sondern Teil wohldurchdachten Strategie zur Bindung des Anwenders an den Hersteller.

Ergänzt wird diese Herstellerstrategie durch eine immer enger werdende Verzahnung der Datenbanksysteme mit anderen Softwareprodukten. Genannt sei hier nur AD/Cycle, das DB2 bereits voraussetzt. Auf der DEC-Seite läßt sich entsprechendes feststellen, denn dort ist die CASE-Strategie ebenfalls auf Rdb ausgerichtet. Wie kann ein DV-Chef unter diesen Umständen Finanzmittel für ein Fremd-Datenbanksystem rechtfertigen?

Die unabhängigen Datenbankhersteller werden heute von unten und von oben bedroht - von oben, weil die Hardwarehersteller das finanziell ertragreiche Geschäft mit den Großsystemen an sich reißen und dominieren wollen. Sie tun dies - wie bereits erwähnt - mit verschiedenen, letzten Endes erfolgreichen Maßnahmen.

Die Bedrohung von unten resultiert aus den ständig leistungsfähiger werdenden Mikrocomputersystemen. Softwarelizenzen erbringen auf dieser Plattform aber bei nahezu gleicher Funktionalität nur eine geringe Wertschöpfung, die die zur Zukunftssicherung erforderlichen Erträge nicht einbringt.

Außerdem gibt es im PC-Bereich Hersteller, die bisher ausschließlich auf das MS-DOS und OS/2-Segment ausgerichtet waren (zum Beispiel Gupta) und Preismaßstäbe setzen. Übrig bleibt ein in der Zukunft immer schmäler werdendes Segment in der "Mitte". Langfristig droht den unabhängigen Herstellern deshalb die finanzielle Aushungerung.

Die unabhängigen Datenbankhersteller befinden sich in einer Zwickmühle. Hardware-Anbieter, die sich mit ihrem eigenen Datenbanksystem auf dem "Meta"-Server des Unternehmens festgesetzt haben, werden versuchen, auch die darunter liegenden Ebenen direkt oder indirekt in den Griff zu bekommen. Sie werden den Versuch unternehmen, das eigene Datenbanksystem auch für andere Plattformen verfügbar zu machen, und bedrohen damit das Marktpotential der unabhängigen Datenbankhersteller zusätzlich.

IBM verfolgt Pläne, den OS/2. Database-Manager, ein auf der SQL-Ebene weitgehend mit DB2 identisches Produkt von der OS/2 Extended Edition abzukoppeln und für OS/2-Systeme generell verfügbar zu machen. Dieselben Ziele werden mit dem künftigen, wahrscheinlich 1993 verfügbaren AIX-Datenbanksystem verfolgt, das ebenfalls den SAA-Normen entsprechen soll. Nach Verlautbarungen soll dieses Datenbanksystem generell für Unix-Systeme angeboten werden. DECs Rdb läßt sich deshalb schlecht portieren, weil es in der nur für VAX/VMS verfügbaren Sprache Bliss geschrieben wurde.

Wenn also DB2 oder Rdb als Datenbank des "Meta"-Servers im Unternehmen eingesetzt wird und sich mittelfristig eine homogene Datenbankumgebung realisieren läßt, werden sich Anwender unter diesen Umständen wohl überlegen, ob sie den durch Interaktion von Datenbanksystemen unterschiedlicher Hersteller entstehenden Reibungsverlust, das heißt die Einschränkungen durch Einsatz von Datenbank-"Gateways", hinnehmen wollen.

Die unabhängigen Datenbankhersteller stehen in den nächsten Jahren vor enormen Herausforderungen, die eine solide finanzielle Basis voraussetzen. Sie müssen, um gegenüber den Implementierungen der Hardwarehersteller bestehen zu können, die Integritätsregeln des bisherigen SQL-Standards implementieren und ein Unterlaufen der Datenbankintegrität verhindern.

Außerdem sind sie gezwungen, echt verteilte Datenbanken mit ihrer inhärenten Komplexität zu unterstützen. Sie müssen hier technisch sehr anspruchsvolle Lösungen (Two-Phase Commit, verteilter Systemkatalog, erweiterter Optimizer, etc.) mit hohem Personaleinsatz für einen begrenzten, insgesamt gesehen nicht sehr ertragreichen Markt entwickeln. Ferner haben sie für eine Konformität mit Herstellerstandards (zum Beispiel IBM-SAA-DRDA entsprechend den von IBM veröffentlichten Schnittstellen) zu sorgen. Tun sie das nicht, so bringen sie sich gegenüber den Hardwareherstellern ins Hintertreffen und disqualifizieren sich vorzeitig.

Sinkende Gewinnmargen führen Datenbankhersteller zu der Überlegung, die Vertriebsstrukturen zu reorganisieren. Ein eigener Vertriebsapparat ist allerdings aufwendig und teuer. Was läge also näher als die Verlagerung von Vertriebsaktivitäten auf Händler (im unteren Leistungssegment) und Hardwarehersteller? Zwar können auf diese Weise die Vertriebskosten gesenkt werden, doch ein fremder Vertriebsapparat läßt sich nicht so effizient steuern wie ein eigener.

Wie sieht insgesamt gesehen die Zukunft für die unabhängigen Datenbankhersteller aus? In zunehmendem Maße werden sie sich ab 1992 auf Unix-Plattformen und Nischenanwendungen konzentrieren müssen.

Hardware-Anbieter, die sich mit eigenen Betriebssystemen am Markt behaupten können (DEC mit VAX/VMS und IBM, mit OS/400, VSE, VM und MVS), werden Code zunehmend in die Hardware verlagern und hardwarespezifische Leistungsmerkmale konsequent ausnutzen. Dieser Weg bleibt den unabhängigen Datenbankspezialisten wie Informix, Ingres oder der Software AG aber verschlossen.

Insbesondere DB2 und Rdb werden ihre Rolle als Datenbank-Server der oberen Leistungsklasse besser ausfallen können. So rechnen IBM-Beobachter damit, daß es gelingen wird, die DB2-Performance durch verschiedene Maßnahmen bis 1993 um etwa 50 Prozent zu steigern. Ähnliches gilt auch für DECs Rdb. Damit ist für die unabhängigen Hersteller nach dem MVS- auch der VMS-Markt sehr bedroht.

Um eine Ballung im zwar stark wachsenden, für alle aber dennoch zu engen Unix-Sektor zu vermeiden und sich vor baldigem finanziellen Kollaps zu schützen, müssen die unabhängigen Datenbankhersteller zu offeneren Lösungen kommen. Ihre Aufgabe ist es zunächst, die Front-end-Produkte (zum Beispiel 4GL-Anwendungsentwicklungs-Werkzeuge) für die "kleinen" Betriebssysteme MSDOS, OS/2 und Unix verfügbar zu machen. Dies gilt um so mehr, da Client-Server-Konzepte zunehmend an Bedeutung gewinnen. Unabhängige DB-Hersteller können auf diesem Weg aber noch wesentlich mehr gewinnen, denn gerade auf dem Sektor der 4G-Anwendungsentwicklungs-Werkzeuge können sie derzeit auf einen Vorsprung gegenüber den Hardwareherstellern bauen.

Diese Chance, ihr Terrain zu verteidigen, werden die unabhängigen Datenbank-Hersteller nutzen. Damit können sie SAA-, NAS- und Unix-Umgebungen mit ihren eigenen "offenen" Architekturen zusammenführen und gewinnen gleichzeitig eine echte Möglichkeit, Kunden über die Werkzeuge an ihre Architekturen und Produkte längerfristig an sich zu binden.

Der Anwender kann sich angesichts dieser Entwicklungen den Rücken freihalten, indem er sich für Entwicklungswerkzeuge entscheidet, die ihm eine hohe Code-Stabilität über verschiedene Betriebssystem-Umgebungen, Datenbanksysteme und grafische Bedieneroberflächen hinweg ermöglichen. Damit begibt er sich allerdings in die Abhängigkeit vom langfristigen wirtschaftlichen Erfolg des Werkzeugherstellers. Doch es kommt darauf an, die Abhängigkeit auf möglichst wenige kritische Schnittstellen zu reduzieren.

In jedem Fall: Die heile Welt werden wir auch in Zukunft nicht haben, dafür aber die Möglichkeit, mit vernünftigen, über den Tag hinausblickenden Strategien viel Geld zu sparen.