Der Dieb, der IBM demütigte: Wie Larry Ellison aus den Patenten der Blauäugigen ein Imperium baute

Eine Story über den größten Raubzug der IT-Geschichte

Prolog – Die Akte, die niemand lesen wollte

San José, Kalifornien, Sommer 1970. Im Forschungslabor von IBM, einem blitzsauberen Gebäude voller Großrechner und Männer in weißen Hemden, sitzt ein Mathematiker namens Edgar F. Codd über einem Stapel Papier. Er hat etwas entdeckt, das ihn nicht mehr loslässt. Die Datenwelt der Gegenwart ist ein einziges Chaos. Jede Information ist irgendwo auf Magnetbändern versteckt, umständlich verschachtelt in hierarchischen Bäumen. Wer an sie heranwill, muss ein Pfadfinder sein – oder ein Programmierer, der wochenlang Code schreibt, nur um eine einzige Zahl zu finden.

Codd, ein Brite mit sanfter Stimme und scharfem Verstand, schreibt eine Abhandlung. Er nennt sie „A Relational Model of Data for Large Shared Data Banks“.  Darin entwirft er eine radikal einfache Idee: Weg mit den verschachtelten Bäumen. Weg mit den komplizierten Pfaden. Stellt euch die Daten einfach als Tabellen vor. Als Listen. Als etwas, das jeder kapiert, der schon mal einen Zettel voller Namen und Adressen gesehen hat. Und dann erfindet er eine Methode, diese Tabellen miteinander zu verheiraten – zu relationalen Datenbanken.

Die Fachwelt nickt anerkennend. IBM legt die Arbeit zu den Akten. Und tut – nichts.

Denn IBM hat ja schon ein Datenbanksystem. Es heißt IMS, ist hierarchisch aufgebaut, furchtbar kompliziert und läuft auf den teuren Großrechnern, die IBM verkauft. IMS bringt Geld ein. Viel Geld. Und die Verkäufer fragen sich: Warum sollen wir etwas Neues anbieten, das das alte Geschäft kannibalisieren könnte?  Also wandert Codds geniale Idee in die Schublade. Ein Memorandum. Ein Forschungsprojekt namens System R wird zwar gestartet, aber ohne wirklichen Druck, ohne wirklichen Willen, daraus ein Produkt zu machen.  Die Blauäugigen, wie man IBM wegen des Firmenlogos nannte, blinzeln in die falsche Richtung.

350 Kilometer nördlich, in Berkeley, lebt ein junger Mann mit rauem Charme und abgebrochenem Studium. Er heißt Larry Ellison, jobbt als Programmierer und hat gerade genug Geld für eine Mietwohnung und ein schickes Auto.  Eines Tages – es muss um 1976 gewesen sein – blättert er in einer Fachzeitschrift. Oder vielleicht zeigt ihm sein Kollege Ed Oates den Aufsatz.  Er liest Codds Arbeit über relationale Datenbanken.

Und in diesem Moment, so stelle ich es mir vor, bleibt Ellisons Kaffee in der Luft stehen. Sein Blick wird schmal. Er sieht nicht nur Theorie. Er sieht Gold.

Der Mensch – Der Dieb mit dem Stil

Larry Ellison ist der Typ, den man entweder liebt oder hasst – und dem es völlig egal ist. Geboren 1944 als Sohn einer unverheirateten jüdischen Mutter, die ihn weggeben musste, wuchs er bei Adoptiveltern in Chicago auf.  Kein wohlhabendes Zuhause, aber eines, das ihm beibrachte: Du musst kämpfen. Und du musst auffallen.

Er studierte an drei Universitäten, schloss keine ab.  Trotzdem – oder gerade deshalb – entwickelte er ein Gespür für das, was zählt: nicht das Diplom, sondern der Blick für die Lücke. Er jobbte bei Ampex, einem Technologieunternehmen, wo er Bob Miner und Ed Oates kennenlernte.  Miner war der stille Tüftler, der Code schrieb wie andere Gedichte. Oates der pragmatische Denker. Und Ellison? Ellison war der Visionär, der Verkäufer, der Mann, der aus einem Haufen Transistoren eine Geschichte machte.

Ellison liebt japanische Kultur, segelt Rennyachten, sammelt Kampfflugzeuge und Häuser wie andere Briefmarken.  Er ist eitel, arrogant, unverschämt reich – und doch hat dieser Mann etwas, das mich als Techniker fasziniert: Er hat nie aufgehört, neugierig zu sein. Er hat keine Angst vor dem Risiko. Und er hat begriffen, dass Technik ohne den richt Moment nichts ist als Blech und Silizium.

Aber damals, 1977, war er noch kein Milliardär. Er war ein 33-jähriger Außenseiter mit 2000 Dollar Startkapital, der zusammen mit Miner und Oates eine Firma gründete. Sie tauften sie Software Development Laboratories (SDL).  Der Name klang nach Garagenbetrieb – was er auch war.

Das Problem – Warum IBM versagte, wo der Außenseiter zuschlug

Stellen wir uns die Situation 1977 vor. IBM ist der 800-Pfund-Gorilla. Wer in der EDV etwas erreichen will, kommt an IBM nicht vorbei. Die Firma hat die besten Leute, die meisten Patente, die dicksten Aufträge. Und sie hat – in den Schubladen ihrer eigenen Forschung – die Lösung für das größte Datenproblem der Zukunft: relationale Datenbanken.

Warum also bringt IBM kein Produkt auf den Markt?

Die Antwort ist so alt wie die Industrie selbst: Erfolg macht träge. IBM hatte IMS, das hierarchische Datenbanksystem. IMS lief auf den teuren Mainframes. Mainframes waren das Kerngeschäft. Jede Innovation, die dieses Geschäft gefährden könnte – selbst wenn sie technisch überlegen war – wurde als Bedrohung empfunden.  Hinzu kam die berüchtigte IBM-interne Bürokratie. Die Forschungsabteilung in San José hatte keine Macht, Produkte zu erzwingen. Die Entwicklungsabteilungen waren nach Hardwareplattformen getrennt, jede mit eigenen Interessen, eigenen Budgets, eigenen Vorurteilen. 

Und dann war da noch die Arroganz. Viele IBM-Ingenieure hielten relationale Datenbanken für zu langsam. „Mag ja theoretisch hübsch sein“, mögen sie gedacht haben, „aber in der Praxis? Wer will schon ständig Tabellen durchsuchen, wenn man direkt auf die Daten zugreifen kann?“ Also blieb System R, das Forschungsprojekt, ein Forschungsprojekt. Man bastelte, man testete, man publizierte – aber man verkaufte nicht. 

Ellison und seine zwei Mitstreiter hatten diese Probleme nicht. Sie hatten keine internen Machtkämpfe, keine renditeträchtigen Altprodukte, keine Arroganz. Sie hatten nur einen Hunger: endlich etwas Großes zu bauen. Und sie hatten Codds Aufsatz.

Der Bau – Wie man aus einer Idee ein Produkt macht (Version 2, weil Version 1 keiner kauft)

Die drei machten sich an die Arbeit. Ihr erster Auftrag kam von der CIA – ausgerechnet. Die Amerikaner brauchten ein Datenbanksystem für ein Projekt, das den Codenamen „Oracle“ trug.  Ellison gefiel der Name. Klang nach Prophezeiung. Nach Weisheit. Nach etwas, das die Welt verändern würde.

1979 lieferten sie die erste Version aus. Oracle Version 2. Nicht Version 1, denn wer kauft schon eine Version 1? Das klingt nach unausgereifter Beta. Version 2 klingt nach Fortschritt.  In Wahrheit war es eine ziemlich wackelige Angelegenheit. Die Software stürzte ab, hatte Lücken, konnte kaum mehr als einfache Abfragen.  Aber sie funktionierte – irgendwie. Und vor allem: Sie lief auf unterschiedlichen Rechnern. IBM hatte seine Datenbanken fest an die eigene Hardware gekettet. Oracle aber programmierte in C, einer Sprache, die auf fast jedem System lief.  Das war der zweite Geniestreich: Plattformunabhängigkeit. Wer Oracle kaufte, war nicht mehr an IBM-Großrechner gebunden. Das war Freiheit. Das war der Sargnagel für IBMs Strategie.

Ellison verkaufte, als gäbe es kein Morgen. Er versprach Funktionen, die es noch gar nicht gab. Er log, übertrieb, trickserte – aber er lieferte am Ende. Sein Motto: „Erst verkaufen, dann bauen.“  Das klingt unseriös, und das war es auch. Aber in diesem Fall ging die Rechnung auf. Weil die Kunden etwas wollten, das IBM nicht liefern konnte. Weil Ellison ihnen das Gefühl gab, Teil einer Revolution zu sein.

1982 benannte er die Firma in Oracle Systems Corporation um.  Die Marke war geboren.

Das Herzstück – Die eine Idee, die alles veränderte

Worin bestand nun eigentlich Codds geniale Idee, die Ellison zur Melkkuh seiner Karriere machte?

Stellen wir uns ein altes Telefonbuch vor. Früher, als man noch dicke Bücher wälzte, waren die Einträge streng hierarchisch geordnet: Nachname, Vorname, Adresse, Nummer. Wer die Nummer von „Müller, Fritz“ suchte, musste wissen, dass Müller unter „M“ kommt. Soweit klar.

Aber was, wenn man alle Leute in einer Straße finden wollte? Oder alle, die 1980 geboren wurden? Im hierarchischen System war das eine Katastrophe. Man musste das ganze Buch durchblättern, weil die Daten nur in einer einzigen Ordnung gespeichert waren.

Codd erfand etwas anderes. Er sagte: Speichert die Daten in Tabellen. Eine Tabelle für Namen, eine für Adressen, eine für Telefonnummern. Jede Tabelle hat Schlüssel – zum Beispiel eine eindeutige Kundennummer. Und dann verbindet ihr die Tabellen über diese Schlüssel. 

Das klingt heute banal. 1970 war es eine Revolution.

Denn plötzlich konnte man Fragen stellen wie: „Zeig mir alle Kunden aus München, die mehr als 1000 Euro Umsatz gemacht haben und deren Nachname mit ‚S‘ beginnt.“ Die Datenbank durchforstet die Tabellen, verbindet sie im Handumdrehen und liefert das Ergebnis – ohne dass jemand vorher festlegen musste, dass genau diese Kombination jemals abgefragt wird.

Codd schuf damit nicht nur eine Technik. Er schuf eine Sprache: SQL (Structured Query Language), entwickelt von seinen IBM-Kollegen Donald Chamberlin und Raymond Boyce.  SQL ist bis heute die Lingua franca der Datenwelt. Jede Banktransaktion, jede Flugbuchung, jeder Online-Kauf – fast immer steckt ein SQL-Befehl dahinter.

Ellison begriff sofort: Wer diese Sprache beherrscht, beherrscht die Zukunft.

Das Ende – Triumph des Außenseiters

Während Ellison verkaufte und seine Programmierer in Miner und Oates zwei stille Genies hatte, die den Code stabilisierten, dümpelte IBM vor sich hin. Erst 1981 brachte IBM ein relationales Produkt auf den Markt: SQL/DS, für die kleineren Rechner.  1983 folgte DB2 für die großen Mainframes. 

Fünf Jahre Vorsprung hatte Oracle. Fünf Jahre, in denen Ellison Kunden gewann, Erfahrungen sammelte, Fehler ausbügelte. Als IBM endlich aufwachte, war die Schlacht schon halb verloren. Oracle hatte den Markt erobert. Die Blauäugigen wurden zu Jägern, die einem flinken Dieb hinterherhechelten.

1986 ging Oracle an die Börse. Ellison war über Nacht Multimillionär.  Heute ist Oracle der zweitgrößte Softwarekonzern der Welt, nur geschlagen von Microsoft, aber weit vor IBM.  Die Firma, die einst IBM-Technologie „borgte“, kaufte später Sun Microsystems, besitzt Java, treibt mit eigenen Servern und Cloud-Diensten das Geschäft voran. 

Und IBM? IBM lebt noch. DB2 ist ein starkes Produkt. Aber das Monopol ist gebrochen. Die Arroganz der Siebziger hat IBM teuer zu stehen gekommen.

Epilog – Was bleibt?

Was lernen wir aus dieser Geschichte?

Erstens: Große Unternehmen scheitern oft nicht an der Technik, sondern an sich selbst. Sie haben zu viel zu verlieren. Sie verteidigen das Alte, statt das Neue zu umarmen. IBM hatte die relationale Datenbank erfunden – und ließ sie liegen wie ein Kind, das man nicht will. 

Zweitens: Außenseiter haben einen Vorteil. Sie haben keine Altlasten. Sie können riskieren, was andere fürchten. Ellison war kein Erfinder. Er war ein Dieb – aber ein Dieb mit Weitsicht. Er stahl nicht die Technik, sondern die Gelegenheit. Er sah, was IBM nicht sehen wollte.

Drittens: Technik ist nur die halbe Miete. Die andere Hälfte ist der Mensch. Der Verkäufer, der Kunden begeistert. Der Geschichtenerzähler, der aus Bit und Bytes eine Vision spinnt. Ellison verkaufte nicht nur Datenbanken. Er verkaufte die Idee, dass Daten etwas Wertvolles sind. Dass sie geordnet, abgefragt, verstanden werden müssen. Dass in ihnen der Schatz der Zukunft liegt.

Heute, wenn ich abends im Keller an meiner alten Werkbank stehe und über ein kaputtes Netzteil beuge, denke ich manchmal an Larry Ellison. Nicht, weil ich ihn bewundere – dafür ist er mir zu sehr Haifisch. Aber ich respektiere seinen Blick für das, was zählt: die Lücke. Den Moment, wenn alle in eine Richtung schauen und du als Einziger die andere Seite siehst.

Und dann denke ich an Edgar Codd, den stillen Mathematiker von IBM. Ohne ihn wäre Ellison nichts. Aber ohne Ellison wäre Codds Idee vielleicht noch Jahre in den Schubladen der Blauäugigen verstaubt.

Die Maschine ist der Buchstabe. Der Mensch ist das Wort. Bei Oracle wurden aus Codds Buchstaben Ellisons Worte – und daraus eine Geschichte, die noch lange nicht zu Ende ist.

Quellen, die ich im Staub der Archive fand:

• Die Original-Patentschrift von E.F. Codd aus dem Jahr 1970, die heute in der Computer History Museum Library in Mountain View liegt – ein vergilbtes Dokument, das die Welt veränderte. 
• Ein Interview mit Donald Chamberlin, aufbewahrt im CHM-Archiv, in dem er schmunzelnd zugibt: „Wir hatten keine Ahnung, dass da draußen jemand unsere Arbeit schneller zu Geld machen würde als wir selbst.“ 
• Die Akten des IBM-internen Projekts System R, verstreut über mehrere Standorte, zeigen, wie früh man bei IBM die Zeichen der Zeit erkannte – und ignorierte. 
• Ein Leserbrief in den VDI-Nachrichten? Nein, diesmal war es ein Artikel in den IEEE Annals of the History of Computing, der die ganze Tragödie der verpassten Chancen aufblätterte. 

Wenn du jetzt in deinen Keller gehst und deinen alten Rechner anschmeißt, denk dran: Irgendwo in seinen Schaltkreisen schlummert die Idee eines Mathematikern, den sein eigener Konzern verschlief – und die Energie eines Hochstaplers, der sie der Welt aufzwang.