Systems Engineering Trends

Jede Woche Neuigkeiten aus der Welt des Systems Engineering

Open SourceStandards & Methoden

Kann man mit einer API Geld verdienen?

Eine API (Application Programming Interface) ist eine Schnittstelle für Software. Schnittstellen sind nichts neues für Systems Engineers: Sowohl standardisierte Schnittstellen als auch für die Dekomposition entwickelte Schnittstellen gehören zum Alltag.

Zwar sind teure Rechtsstreitigkeiten um APIs nicht ungewöhnlich: Wer erinnert sich noch an den Rechststreit zwischen Microsoft und Sun Microsystems aus dem Jahr 1998? Auch ist das Lizenzieren von Hardwareschnittstellen üblich. Viele Standards, wie bspw. HDMI, benötigen eine Lizenz.

Doch gerade in den letzten Jahren sind mir immer öfter Firmen aufgefallen, die Ihr Geschäftsmodell auf einer API aufgebaut haben. Wie das funktionieren kann, beschreibe ich im Folgenden.

Streit um Java API

Der Rechtsstreit zwischen Microsoft und Sun um die Java API war nur der erste, prominente Rechtsstreit. Damals ging es darum, dass Microsoft die Java-API in einer nicht-kompatiblen Art und Weise erweitert hatte („embrace and extend“). Seitdem gab es zahllose Rechtsstreitereien. Erst letztes Jahr hat das amerikanische Verfassungsgericht eine Entscheidung zu einem Streit zwischen Google und Oracle zur Java-API gefällt.

Doch auch wenn es bei solchen Streitigkeiten um oft viel Geld geht, so wird das Geld doch woanders verdient.

Die API als Gatekeeper

Eine API ist eine sauber definierte Grenze zwischen Anbieter und Verbraucher. Eine API ist mächtig, da (theoretisch) sowohl Anbieter und Verbraucher austauschbar sind. Ob dies der Fall ist, hängt davon ab, wer die API kontrolliert. Ein paar Beispiele:

Manche APIs werden von dem Anbieter kontrolliert, wie zum Beispiel die Paypal-API. Dienste, die Zahlungen mit Paypal erlauben, müssen mit dieser kommunizieren (direkt oder über einen Drittanbieter).

ODBC ist eine erfolgreiche API, um mit Datenbanken zu kommunizieren. Durch den Einsatz von ODBC werden – zumindest theoretisch – Anwendung und Datenbank voneinander entkoppelt. Viele Anwendungen nutzen allerdings Datenbank-spezifische Features, wodurch der Vorteil der API abgeschwächt wird.

Ein moderneres Beispiel ist OAuth, für Autorisierung. Erst dadurch haben wir die bequeme Möglichkeit, uns bei Webseiten über Google, Facebook und andere OAuth-Anbieter einloggen zu können.

Je mehr Nutzer einer API es gibt, desto wertvoller ist sie. Das ist einer der Gründe, warum sich oft diejenigen, die von der API profitieren wollen, sich für deren Offenheit einsetzen. Im Fall von OAuth war das Twitter. Die Entwickler hätten gern einen offenen Authentisierungs-Dienst genutzt, es gab aber keinen Standard. Um die Offenheit sicherzustellen, wurde der Standard im Komitee entwickelt und relativ schnell an IETF übergeben.

Mit 580 Zeilen Code zu einem Milliarden-Unternehmen

Segment ist ein gutes Beispiel für eine Firma, die ein Geschäftsmodell auf einer API aufgebaut hat. Segment ermöglicht das Zusammenführen von Kundendaten aus unterschiedlichen Quellen mit einer standardisierten API. Das ist ein typisches Problem, das niemand kennt – außer den Experten, die in diesem Umfeld Geschäftsanwendungen programmieren – und das sind viele.

Segment wurde 2020 von Twilio aufgekauft, für 3,2 Milliarden Dollar

Das Spannende ist, dass Peter Reinhardt, der Mitgründer von Segment, in einer Stanford-Vorlesung die Geschichte von Segment erzählt. Insbesondere glaubte er Anfangs nicht, dass sich aus deren Open Source-API (580 Zeilen Code) ein Geschäftsmodell aufbauen lässt. Das eingebettete Video startet bei 26:00, wo er die Resonanz des Markets auf die API beschreibt:

SysML 2.0 API

Als Systems Engineer bin ich daher auch hellhörig geworden, als ich hörte, dass für die SysML 2 eine API eingeplant ist. Wir sind natürlich noch weit von einem darauf basierenden Ökosystem entfernt. Aber eine API für SysML ist definitiv eine wegweisende Entscheidung.

Photo by Douglas Lopes on Unsplash

Michael Jastram

Creator and Author of SE-Trends