Oracle

• Einleitung
• Kapitel 1 Die Geburt einer Idee
• Kapitel 2 Von bescheidenen Anfängen: Die frühen Jahre von Larry Ellison
• Kapitel 3 Die Gründung von Relational Software, Inc.
• Kapitel 4 Der erste Großauftrag: Die CIA
• Kapitel 5 Der Namenswechsel: Oracle wird geboren
• Kapitel 6 Auf der Datenbankwelle reiten: Der Boom der 1980er
• Kapitel 7 Der Börsengang und der nahe Zusammenbruch
• Kapitel 8 Das Comeback-Kind: Restrukturierung und Erholung
• Kapitel 9 Die unerbittliche Vertriebsmaschine
• Kapitel 10 Die Datenbankkriege: Oracle gegen Informix und Sybase
• Kapitel 11 Der Aufstieg des Network Computer
• Kapitel 12 Ellisons überlebensgroße Persönlichkeit
• Kapitel 13 Die Eroberung des Unternehmensmarkts: Die E-Business Suite
• Kapitel 14 Die feindliche Übernahme von PeopleSoft
• Kapitel 15 Die Konkurrenz aufkaufen: Eine Wachstumsstrategie
• Kapitel 16 Das Sun-Microsystems-Wagnis: Hardware und Software vereint
• Kapitel 17 Die Cloud-Revolution meistern
• Kapitel 18 Die Rechtsstreitigkeiten: Auseinandersetzungen mit SAP und Google
• Kapitel 19 Die America's-Cup-Obsession
• Kapitel 20 Jenseits der CEO-Rolle: Ellison als CTO und Chairman
• Kapitel 21 Die nächste Generation der Führung
• Kapitel 22 Oracle im Zeitalter von KI und Big Data
• Kapitel 23 Die Kultur von Oracle: Aggressiv, ehrgeizig und beständig
• Kapitel 24 Der Philanthrop und der Inselbesitzer
• Kapitel 25 Das bleibende Vermächtnis eines amerikanischen Titans

Die Saga von Oracle ist nicht bloß eine Firmengeschichte; sie ist eine Erzählung, die in das Gewebe des Informationszeitalters selbst eingewoben ist. Sie beginnt nicht in einer Garage, in der nun geheiligten Tradition der Silicon-Valley-Lore, sondern mit einer akademischen Arbeit – einer theoretischen Untersuchung einer neuen Art, Daten zu organisieren. Im Jahr 1970 veröffentlichte ein IBM-Forscher namens Edgar F. Codd "A Relational Model of Data for Large Shared Data Banks", ein Dokument, das zum Stein von Rosette für eine neue Generation von Software werden sollte. Codds relationales Modell war elegant, mächtig und zu dieser Zeit weitgehend theoretisch. Es schlug ein System vor, in dem Daten in einfachen Tabellen gespeichert und die Beziehungen zwischen ihnen in einer flüssigen, logischen Weise verwaltet werden konnten – ein krasser Gegensatz zu den starren, hierarchischen Datenbanken jener Ära. Während der Gigant IBM das kommerzielle Potenzial der bahnbrechenden Arbeit seines eigenen Mitarbeiters nur langsam erkannte, sah ein 33-jähriger College-Abbrecher in Kalifornien nicht nur eine Theorie, sondern eine Revolution.

Larry Ellison nahm zusammen mit seinen Mitgründern Bob Miner und Ed Oates Codds abstrakten Konzept und schmiedete es zu einem kommerziellen Produkt, einem Werkzeug, das zum Fundament modernen Geschäfts werden sollte. Sie gründeten ihr Unternehmen 1977, zunächst als Software Development Laboratories, dann als Relational Software, Inc., bevor sie schließlich den Namen ihres Flaggschiffprodukts annahmen – Oracle. Der Name selbst war ein Verweis auf ein früheres Projekt, an dem sie für die CIA gearbeitet hatten, eine passend enigmatische Herkunft für ein Unternehmen, das zum Meister der Verwaltung der sensibelsten und wertvollsten Informationen der Welt werden sollte. Ihr Produkt, die Oracle Database, war das erste kommerziell erhältliche relationale Datenbankmanagementsystem (RDBMS), das die Structured Query Language (SQL) verwendete, die später zum Industriestandard werden sollte.

Die Geschichte von Oracle ist jedoch nicht die einer ruhigen Innovation. Es ist eine Geschichte erbitterter Konkurrenz, von "Datenbankkriegen", in denen Rivalen aufstiegen und fielen, von einer Unternehmenskultur, die für ihre kompromisslosen Verkaufstaktiken und ihren unentschuldigten Siegeswillen bekannt war. Ellison schuf eine Umgebung, die ebenso fordernd wie belohnend war, ein Ort, an dem Erfolg an Marktanteilen und besiegten Konkurrenten gemessen wurde. Diese aggressive Ethik trieb den meteorischen Aufstieg des Unternehmens durch die 1980er Jahre voran und etablierte es 1987 als weltgrößten Anbieter von Datenbankmanagementsoftware. Es war eine Phase explosives Wachstums, in der Oracles Software zum unsichtbaren Motor wurde, der Banken, Fluggesellschaften, Einzelhändler und Regierungen rund um den Globus antrieb.

Doch dieser unerbittliche Antrieb brachte das Unternehmen auch an den Rand des Abgrunds. Die Wende zum neuen Jahrzehnt sah Oracle mit einer Nahe-Pleite-Erfahrung konfrontiert, eine Krise, geboren aus einer übermäßig aggressiven Vertriebskultur, die zukünftige Einnahmen als gegenwärtige Gewinne verbuchte. Es war ein Schmelztiegel, der Ellisons Führung auf die Probe stellte und eine schmerzhafte, aber notwendige Restrukturierung des Unternehmens erzwang. Das folgende Comeback ist ein Zeugnis der in Oracles DNA verankerten Resilienz, eine Geschichte der Erholung und erneuten Fokussierung, die die Bühne für Jahrzehnte der Dominanz bereitete.

Kein Porträt von Oracle wäre vollständig ohne eine tiefe Erforschung der überlebensgroßen Persönlichkeit seines Gründers. Larry Ellison ist eine Figur immenser Komplexität und Widersprüchlichkeit. Ein selbstgemachter Milliardär, der konsequent zu den wohlhabendsten Menschen der Welt zählte, ist sein Leben ein Teppich extravaganter Leidenschaften – vom Wettbewerbssegeln und dem America's Cup bis zum Besitz seiner eigenen hawaiianischen Insel. Er ist ein visionärer Technologe mit einer unheimlichen Fähigkeit, die nächste große Welle zu erkennen, doch er ist auch ein berüchtigt harter und manchmal polarisierender Führer. Sein Führungsstil, oft als autokratisch und an Samurai-Prinzipien orientiert beschrieben, ist im Silicon Valley legendär. Es ist ein Stil, der sowohl fanatische Loyalität als auch scharfe Kritik inspiriert hat, aber dessen Effektivität beim Aufbau eines globalen Technologie-Machtzentrums unbestritten ist.

Die Entwicklung von Oracle ist auch eine Geschichte strategischer Anpassung, oft durch aggressive Übernahmen. Ellison erkannte früh, dass Oracle, um Wachstum und Relevanz zu erhalten, über sein Kerndatenbankprodukt hinauswachsen musste. Dies führte zu einer Reihe von Wagnissen mit hohem Einsatz, oft feindlichen Übernahmen, die die Enterprise-Software-Landschaft neu formten. Die Übernahmen von PeopleSoft, Siebel Systems, BEA Systems und Sun Microsystems waren nicht nur Geschäftstransaktionen; sie waren strategische Eroberungen, die Oracles Imperium in kritische Bereiche wie Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Middleware und Computerhardware ausdehnten. Der Kauf von Sun Microsystems war insbesondere ein monumentales Wagnis, das Oracle die Kontrolle über die populäre Programmiersprache Java und die MySQL-Datenbank gab und es in ein Unternehmen verwandelte, das – wie sein alter Rivale IBM – einen vollständigen, integrierten Technologie-Stack von Hardware bis Software anbieten konnte.

Als sich die Technologiebranche von On-Premises-Software zur Cloud hin bewegte, stand Oracle vor vielleicht seiner größten Herausforderung. Anfangs skeptisch gegenüber der Cloud-Revolution, galten Ellison und Oracle als Spätkommer in einem Markt, der von neuen Titanen wie Amazon Web Services dominiert wurde. Doch Oracle die Fähigkeit zur Anpassung abzusprechen, bedeutet, seine Geschichte nicht zu verstehen. Das Unternehmen hat seitdem immense Ressourcen in die Entwicklung seiner eigenen Cloud-Infrastruktur und einer umfassenden Suite cloudbasierter Anwendungen investiert und sein gesamtes Geschäftsmodell gedreht, um in diesem neuen Zeitalter zu konkurrieren. Jüngste, massive Deals mit großen KI-Unternehmen wie OpenAI signalisieren einen dramatischen und erfolgreichen Aufschwung in diesen kritischen neuen Markt und demonstrieren einmal mehr die Fähigkeit des Unternehmens, sich neu zu erfinden und seine Rivalen herauszufordern.

Die Erzählung von Oracle wird auch von prominenten Rechtsstreitigkeiten geprägt, insbesondere mit Konkurrenten wie SAP und Google. Diese Gerichtsschlachten bieten einen Einblick in die wild entschlossene Wettbewerbsnatur des Unternehmens und seine unerschütterliche Verteidigung seines geistigen Eigentums. Sie sind Kapitel in einer größeren Geschichte über die Natur von Innovation, Wettbewerb und die Spielregeln im digitalen Zeitalter.

Dieses Buch wird durch diese entscheidenden Momente führen, von der Genesis der Idee der relationalen Datenbank bis zu Oracles aktueller Position als Schlüsselakteur im Zeitalter von KI und Big Data. Wir werden das frühe Leben von Larry Ellison erforschen, die Kräfte, die seinen Ehrgeiz formten, und wie sein persönlicher Antrieb zur Unternehmenskultur wurde. Wir werden die Schlüsselerwerbungen sezieren, die seine Wachstumsstrategie definierten, die technologischen Innovationen, die es an der Spitze der Branche hielten, und die Kontroversen, die seinen Erfolg beschatteten.

Wir werden die unerbittliche Vertriebsmaschine untersuchen, die seinen Umsatz antrieb, die überlebensgroße Persönlichkeit seines Gründers und das anhaltende Erbe eines Unternehmens, das seit fast einem halben Jahrhundert eine konstante und furchteinflößende Präsenz in der Welt der Technologie ist. Es ist die Geschichte eines Titans der amerikanischen Industrie, eines Unternehmens, das ebenso oft verachtet wie respektiert wird, dessen Einfluss auf die Art und Weise, wie die Welt Informationen nutzt, jedoch schlichtweg unbestreitbar ist. Es ist die Geschichte von Oracle – und des Orakels, das es erschuf.

Jede Revolution beginnt mit einem einzelnen, oft widerspenstigen Gedanken. In der Welt der Informationstechnologie begann eine der tiefgreifendsten und lukrativsten Revolutionen nicht mit einem Produkt, einem Unternehmen oder einem charismatischen Gründer, sondern mit einer akademischen Arbeit. Bevor es Oracle gab, bevor es Larry Ellison gab, gab es Edgar F. „Ted“ Codd. Und bevor es Codd gab, gab es eine Welt, die sich abmühte, Daten auf eine Weise zu verwalten, die umständlich, unflexibel und grundlegend kaputt war. Um die Tragweite der Idee zu begreifen, die schließlich eine Milliarden-Dollar-Industrie hervorbringen sollte, muss man zunächst die starre, verworrene technologische Landschaft der 1960er Jahre wertschätzen.

Im Zeitalter des Mainframe-Computing war der Daten König, aber es war ein Monarch, gefangen in einem digitalen Kerker. Die dominierenden Methoden zur Organisation von Informationen waren das hierarchische und das Netzwerk-Datenbankmodell. Diese frühen Systeme waren Triumphe des Ingenieurwesens für ihre Zeit, aber sie waren berüchtigt dafür, schwer zu handhaben zu sein. Das hierarchische Modell, von IBM entwickelt, organisierte Daten in einer baumartigen Struktur. Stellen Sie sich ein Organigramm vor: ein einzelner Stammsatz an der Spitze, von dem Zweige zu „Kind“-Datensätzen führen, die wiederum ihre eigenen Kinder haben können. Um eine Information zu finden, musste man ganz oben beginnen und den korrekten Pfad nach unten navigieren, wie ein Höhlenforscher, der einem einzigen Gang durch eine Höhle folgt. Es gab keinen einfachen Weg, von einem Zweig zu einem anderen zu springen.

Das Netzwerkmodell war ein Fortschritt, da es einem „Kind“-Datensatz erlaubte, mehrere „Eltern“-Datensätze zu haben, wodurch eine netzartigere Struktur aus Zeigern und Verknüpfungen entstand. Entwickelt von Innovatoren wie Charles Bachman, bot dieses Modell mehr Flexibilität als die strengen Eins-zu-Viele-Beziehungen des hierarchischen Systems. Doch beide Modelle teilten einen kritischen Mangel: Die logische Struktur der Daten war untrennbar mit ihrer physischen Speicherung auf Magnetbändern oder -platten verbunden. Programmierer mussten den präzisen, vordefinierten Pfad zu den gewünschten Daten kennen. Das Abrufen von Informationen erforderte das Schreiben komplexen, prozeduralen Codes, der diese elektronischen Pfade navigierte. Eine einfache Anfrage nach einem neuen Berichtstyp konnte einen erheblichen und kostspieligen Programmieraufwand erfordern.

Dies war die Welt, in der Edgar F. Codd lebte, ein britischer, in Oxford ausgebildeter Mathematiker, der im San Jose Research Laboratory von IBM arbeitete. Codd war kein typischer Konzernmensch. Nachdem er seine Promotion mit einer Arbeit über selbstreplizierende Automaten abgeschlossen hatte, war sein Denken auf mathematische Eleganz und logische Reinheit ausgerichtet. Er blickte auf den Stand der Datenbankverwaltung und sah nicht eine ingenieurtechnische Herausforderung, sondern einen fundamentalen Verstoß gegen logische Prinzipien. Er glaubte, der Nutzer einer Datenbank sollte nichts darüber wissen müssen, wie oder wo die Daten physisch gespeichert sind. Die Anwendung sollte von der Speicherung getrennt sein. Dieses Konzept, das er „Datenunabhängigkeit“ nannte, war der Kern seiner revolutionären Vision.

Im Juni 1970 veröffentlichte Codd seine Vision in einer Arbeit, die jahrzehntelang durch die Hallen der Informatik hallen sollte: „A Relational Model of Data for Large Shared Data Banks“. Der Titel war unauffällig, aber der Inhalt seismisch. Codd schlug eine radikal einfache Art vor, über Daten nachzudenken. Anstatt komplexer Bäume oder Netzwerke von Zeigern konnten Daten in einfachen Tabellen organisiert werden, die er „Relationen“ nannte. Jede Tabelle würde aus Zeilen (die er „Tupel“ nannte) und Spalten („Attribute“) bestehen. Jede Zeile stellte eine einzelne Entität dar, wie einen Mitarbeiter oder ein Produkt, und jede Spalte ein Merkmal dieser Entität, wie einen Namen oder einen Preis. Das Modell war intuitiv; es sah aus wie eine Sammlung von Tabellenkalkulationen.

Der wahre Geniestreich von Codds Modell lag in der Art und Weise, wie es die Verbindungen zwischen Daten handhabte. Beziehungen wurden nicht durch physische Zeiger oder hierarchische Links definiert, die im Voraus programmiert werden mussten. Stattdessen wurden Beziehungen einfach durch die Daten selbst hergestellt. Wenn die Tabelle „Mitarbeiter“ und die Tabelle „Abteilungen“ beide eine Spalte „Abteilungs-ID“ enthielten, wurde eine Beziehung implizit gebildet. Um herauszufinden, welche Mitarbeiter in welcher Abteilung arbeiteten, musste man lediglich die Werte in diesen Spalten abgleichen. Das bedeutete, dass neue, ad-hoc-Fragen an die Daten gestellt werden konnten, ohne die Anwendung neu zu schreiben oder die Datenbank umzustrukturieren. Die Macht des Systems stammte aus seiner mathematischen Fundierung in der Mengenlehre und der Prädikatenlogik, die einen konsistenten und vorhersehbaren Weg bot, die Datentabellen zu manipulieren.

Codds Arbeit war im Wesentlichen eine Unabhängigkeitserklärung für Daten. Sie befreite die logische Repräsentation von Informationen von der physischen Implementierung. Ein Programmierer oder Nutzer konnte nun fragen, was er wollte, und nicht mehr diktieren, wie der Computer es finden sollte. Diese Unterscheidung zwischen deklarativen und prozeduralen Anweisungen war ein monumentaler Denkwechsel. Codds Arbeit war dicht, akademisch und mathematisch rigoros. Zu seiner Enttäuschung war ihr kommerzielles Potenzial für seinen Arbeitgeber, IBM, nicht sofort offensichtlich.

International Business Machines war der unbestrittene König der Mainframe-Welt, und sein Flaggschiff-Datenbankprodukt war das Information Management System (IMS), eine leistungsstarke, aber klassische hierarchische Datenbank. IMS war eine bedeutende Einnahmequelle, und das Unternehmen war stark in dessen Erfolg investiert. Codds relationales Modell wurde intern nicht als Chance, sondern als Bedrohung wahrgenommen. Man fürchtete, dieses neue, elegante Modell sei zu langsam, ein Performance-Fresser, der nicht mit dem fein abgestimmten IMS konkurrieren könne. Folglich zögerte IBM, die bahnbrechende Forschung des eigenen Mitarbeiters umzusetzen. Zwar startete man schließlich ein Forschungsprojekt namens System R, um das Konzept zu erforschen, doch es war ein zögerlicher Schritt statt eines enthusiastischen Sprungs.

Das System-R-Projekt, das 1974 im selben San-Jose-Labor begann, in dem Codd arbeitete, sollte sich als immens einflussreich erweisen. Das Team hatte die Aufgabe, einen Prototyp zu bauen, der beweisen sollte, dass eine relationale Datenbank gute Transaktionsleistung bieten kann. Entscheidend war, dass das verantwortliche Team nicht tief mit Codds Ideen vertraut war und von ihm isoliert blieb. Diese Trennung führte zu einer Schlüsselentwicklung. Codd hatte seine eigene mathematisch reine Sprache namens Alpha vorgeschlagen, aber das System-R-Team empfand sie als zu schwierig für normale Anwender.

Zwei Forscher im Team, Donald D. Chamberlin und Raymond F. Boyce, machten sich daran, etwas Zugänglicheres zu schaffen. Ihr Ziel war eine Abfragesprache, die dem einfachen Englisch ähnelte und von Personen ohne formale Programmierausbildung genutzt werden konnte. Ihr erster Versuch hieß SQUARE, erwies sich aber als unhandlich. Sie verfeinerten ihren Ansatz und schufen eine neue Sprache, die sie SEQUEL nannten, für Structured English Query Language. Sie basierte auf einfachen, deklarativen Befehlen wie SELECT, FROM und WHERE. Ein Nutzer konnte die gewünschten Spalten, die Tabellen, in denen die Daten lagen, und die Filterbedingungen in einer einzigen, kohärenten Anweisung spezifizieren.

SEQUEL, später wegen eines Markenrechtsstreits mit einem britischen Ingenieurunternehmen zu SQL gekürzt, war das fehlende Puzzleteil. Es war der praktische, benutzerfreundliche Schlüssel, um die theoretische Macht von Codds relationalem Modell freizusetzen. Die Kombination war potent: eine einfache, flexible Art, Daten zu speichern, und eine einfache, mächtige Sprache, sie abzufragen. Das System-R-Projekt demonstrierte erfolgreich, dass eine relationale Datenbank mit SQL gebaut werden konnte und gut performte, wobei der erste Kunde, Pratt & Whitney, 1977 an Bord kam.

Während IBM vorsichtig Prototypen baute und das Konzept intern bewies, entwickelte die Idee, die Codd entfesselt hatte, in der akademischen Welt ein Eigenleben. An der University of California, Berkeley, hatte ein weiteres Forscherteam unter der Leitung von Michael Stonebraker und Eugene Wong ebenfalls Codds Papier von 1970 gelesen und war inspiriert, eine eigene relationale Datenbank zu bauen. Ihr Projekt, das 1973 begann, hieß Ingres (Interactive Graphics and Retrieval System). Wie das System-R-Team bei IBM entwickelten auch sie ihre eigene Abfragesprache namens QUEL, die von vielen Akademikern zu dieser Zeit als eleganter als SQL angesehen wurde.

So war Mitte der 1970er Jahre die Bühne bereitet. Das theoretische Fundament war von Ted Codd gelegt worden. Zwei große Forschungsprojekte, eines beim größten Computerunternehmen der Welt und eines an einer führenden Universität, bewiesen, dass das Konzept lebensfähig war. Eine neue, mächtige und relativ einfache Sprache, SQL, war erfunden worden, um mit diesem neuen Datenbanktyp zu interagieren. Doch die kommerzielle Welt hatte noch nicht reagiert. IBM, beschützend gegenüber seinen bestehenden Produkten, vermarktete seine Schöpfung noch nicht aggressiv. Ingres war ein akademisches Projekt, für andere Forscher verfügbar, aber noch kein kommerzielles Unternehmen.

Es bestand ein intellektuelles Vakuum zwischen der akademischen Theorie und einem riesigen, unerschlossenen kommerziellen Markt. Codds Papier und die Arbeiten an System R waren nicht geheim; sie waren veröffentlicht und auf Konferenzen vorgestellt worden. Die Details des relationalen Modells und die Struktur der SQL-Sprache lagen offen. Alles, was es brauchte, war jemand mit der richtigen Kombination aus technischem Sachverstand, unternehmerischem Ehrgeiz und der Bereitschaft, auf die Idee eines anderen zu setzen, um die Gelegenheit zu erkennen. Die Genesis war vollendet. Die Idee wartete auf einen Evangelisten, einen Erbauer und einen Verkäufer. Sie wartete auf Larry Ellison.