Friedrich Kurz

Lesezeit: 11 Minuten

Techblog

API as a Product: Background und Businessmodelle

Web-Anwendungsschnittstellen (Web Application Programming Interfaces, Web APIs) haben sich in den letzten 10-15 Jahren von einer Technik der Anwendungsentwicklung zu einem eigenständigen Kanal für das Angebot von Daten und Dienstleistungen und zu einem signifikanten Treiber für das Wachstum von Unternehmen entwickelt. APIs sind in vielerlei Hinsicht eine Repräsentation der Ressourcen, Produkte und Dienstleistungen von Unternehmen…

Techblog

Web-Anwendungsschnittstellen (Web Application Programming Interfaces, Web APIs) haben sich in den letzten 10-15 Jahren von einer Technik der Anwendungsentwicklung zu einem eigenständigen Kanal für das Angebot von Daten und Dienstleistungen und zu einem signifikanten Treiber für das Wachstum von Unternehmen entwickelt.

APIs sind in vielerlei Hinsicht eine Repräsentation der Ressourcen, Produkte und Dienstleistungen von Unternehmen als Software. Sie erlauben internen Entwickler_innen, Partner_innen oder der breiten Öffentlichkeit kontrollierten Zugang auf Firmendaten und -Dienstleistungen. APIs haben aber nicht nur eine technische Dimension, sondern können Kern eines agilen Businessmodells sein, das interne Prozesse optimiert und neue und innovative Wege der Zusammenarbeit mit Partnern öffnet.

In Teil 1 unserer zweiteiligen Miniserie über API as a Product gehen wir auf die gängigen Modelle ein, wie Unternehmen APIs einsetzen können und warum es wichtig ist, APIs als Produkte zu entwickeln und zu vermarkten.

APIs: Ein Wachstumsmarkt

Dass APIs zumindest bei großen Techkonzernen einen wesentlichen Anteil an der Wertschöpfung haben, ist kein großes Geheimnis. Nach Schätzungen machen beispielsweise Salesforce und eBay 50 bis 60 Prozent ihres Umsatzes alleine mit APIs.

Eine nicht unwesentliche Triebfeder für die Entwicklung von APIs ist die digitale Plattformökonomie. Die Entwicklung einer API ist häufig die zentrale Voraussetzung für ein Unternehmen, um in das Ökosystem eines Plattformanbieters integriert und die hiermit verbundenen Vorteile nutzen zu können. Umgekehrt müssen Anbieter von digitalen Plattformen Schnittstellen für die Interaktion mit Produkt- und Dienstleistungsanbietern bieten, wobei häufig APIs zum Einsatz kommen.

Unterstrichen wird die wirtschaftliche Bedeutung von APIs auch vom Entstehen milliardenschwer bewerteter API-First Companies, deren ganzes Geschäftsmodell um die Vermarktung ihres API-Angebots kreist. Zwei bekannte Beispiele sind der Kommunikationsdienstleister Twilio und der Search-as-a-Service Anbieter Algolia. Firmen mit Cloudangeboten wie Microsoft, Amazon und Google haben ausserdem ganze Komplettpakete rund um das Management von APIs in ihrem Portfolio (Azure API Management von Microsoft, AWS API Management von Amazon oder Google Apigee).

Angesichts der seit 2005 ungebremst anwachsenden Zahl von öffentlich verfügbaren Schnittstellen gibt es außerdem kaum einen Grund anzunehmen, dass der Rückenwind für APIs in der nächsten Zeit wieder abflauen wird.

APIs als Teil der Geschäftsstrategie

Im Kontext von APIs werden häufig die öffentlich verfügbaren Angebote großer Techkonzerne, wie z.B. die Google Analytics API, Google Maps API, Twitter API und PayPal API, als Beispiele genannt. Öffentliche APIs sind aber nur eins der Modelle, wie Unternehmen APIs in ihre Geschäftstrategie aufnehmen können. Bei aller Strahlkraft, die öffentliche APIs haben, wird häufig außer Acht gelassen, dass APIs auch als Kern eines agilen Businessmodels verstanden werden können, das erstaunliche Entwicklungen in Unternehmen anstoßen kann.

Der vielleicht berühmteste Pionier für diese Strategie ist Amazon. 2002 stellte der damalige Amazon-Chef Jeff Bezos seinem Entwicklungs-Team das berühmt gewordene API-Mandat vor. Die zentrale Forderung des Mandats war die vollständige Restrukturierung von Amazons interner (Daten-)Kommunikation mit APIs. Damit verbunden war die Forderung, alle APIs potenziell öffentlich verfügbar und als eigenständige Produkte vermarkten zu können.

Wieviel Einfluss das API-Mandat auf die interne Struktur von Amazon hatte und wie erfolgreich es im Hinblick auf den Unternehmenserfolg war, sieht man beispielsweise an Amazons Clouddienstleistungs-Plattform Amazon Web Services (AWS). AWS wurde der Öffentlichkeit nicht ganz zufällig 2006 — also nur vier Jahre nach dem API-Mandat — vorgestellt. AWS ist heute nicht nur einer der führenden Cloudprovider, sondern stellt Stand 2020 sogar ca. 57 Prozent des operativen Gewinns von Amazon. (Der letzte Punkt des API-Mandats — “alle, die sich nicht daran halten, werden gefeuert” — hatte vermutlich auch einen gewissen Anteil am Erfolg von AWS .)

API Modelle

Interne Restrukturierung mit APIs

Wenn man dem Amazon-Modell folgt, steht am Anfang der API-Strategie die Restrukturierung der Bereitstellung von Ressourcen innerhalb des Unternehmens mit einer oder mehreren internen APIs (Private API). Der Idee nach ist der zentrale Mechanismus, mit dem APIs intern ihre Wirkung entfalten, dass sichtbar- und zugänglichmachen von Ressourcen. Nutzer innerhalb des Unternehmens können dann unter Nutzung der API rasch potenziell neue und innovative unternehmensinterne Applikationen entwickeln (z.B. Management-Dashboards oder interne Mobile Apps). Dadurch können positive Effekte auf die Unternehmensperformance entstehen, indem bestehende interne Prozesse beschleunigt oder vollkommen neuer Kooperationen über Abteilungsgrenzen hinweg entstehen.

Interne APIs sind außerdem auch als universelles Backend für Apps auf verschiedenen Plattformen nutzbar: zum Beispiel, um mehrere Mobilplattformen gleichzeitig bedienen zu können oder Internet-of-Things-Anwendungen zu ermöglichen.

Ein positiver Nebeneffekt des Einsatzes von internen APIs kann außerdem darin bestehen, dass sie wartungsintensiven und fehleranfälligen inoffiziellen IT-Lösungen (“Schatten-IT”) entgegen wirken. Ad-hoc Lösungen und Workarounds, die wegen mangelnder Verfügbarkeit von Daten und Funktionalitäten entstanden sind, können mit APIs also potenziell durch besser wartbare und besser funktionerende Lösungen ersetzt werden. Ein häufig genanntes Beispiel für schwer zugängliche oder schwer sichtbare Ressourcen sind Daten und Funktionalitäten, die in Legacysystemen gekapselt sind. Ein Neudesign durch das Vorschalten einer API vor das Legacysystem kann so auch eine schnelle Antwort auf den Druck zur digitalen Transformation sein.

Zu den bekannteren Unternehmen, die eine interne Restrukturierung mit APIs durchgeführt haben, zählen z.B. die New York Times oder der BigData Dienstleister AccuWeather. Im Fall der New York Times war der maßgebliche Impuls für die Entwicklung einer internen API das Bedürfnis, den Zugriff auf das Content-Management-System zu verbessern. Die NYT API ist mittlerweile öffentlich verfügbar, wird aber auch innerhalb des Unternehmens weiterhin intensiv genutzt.

Der erste Schritt in die API-Economy: Partner-APIs

Interne APIs können bereits erstaunliche Effekte auf die Effizienz interner Prozesse haben. Wenn eine weitere Öffnung der API angestrebt wird, ist es außerdem sinnvoll, erste Erfahrungen im Umgang mit APIs in technologischer und wirtschaftlicher Hinsicht zunächst im sicheren Unternehmensumfeld zu sammeln. Das vermeidet imageschädigende, öffentliche Fehltritte.

Um die sprichwörtlichen “Wasser” des API-Marktplatzes zu testen, ist ein nächster sinnvoller Schritt, auch Partnern des Unternehmens Zugriff auf die API zu ermöglichen. Partner-APIs erlauben eine mögliche Verbesserung der Integration mit Geschäftskunden. Außerdem sind sie eine schlanke und flexible Lösung, wenn es nicht möglich ist, Softwarekomplettlösungen für Partner anzubieten, oder wenn Partner tatsächlich nur den Zugriff auf Daten und Funktionalitäten benötigen. Mit der API auf Self-Service-Basis können Partnerunternehmen auf Daten und Funktionalitäten zugreifen, die für eigene Anwendungen nötig sind, und selbst maßgeschneiderte Lösungen für die eigenen Anforderungen entwickeln.

Limitierter Zugriff auf die API kann außerdem als Mittel in Vertragsverhandlungen mit potenziellen Partnern benutzt werden, um eine bessere Informations- und Vertrauensbasis zu schaffen.

Dass Partner-APIs bereits einen beträchtlichen wirtschaftlichen Erfolg erzielen können — APIs also nicht unbedingt komplett öffentlich zugänglich gemacht werden müssen, um erfolgreich zu sein — zeigt das Beispiel von Netflix. Die API des Streaming-Dienstleisters wurde 2014 von einer öffentlichen API auf eine rein partnerorientierte API umgestellt; interessanterweise erlebte das Unternehmen ab diesem Zeitpunkt eine erstaunliche Wachstumsphase mit einer Umsatzsteigerung von knapp 1 Mrd. US-Dollar auf zuletzt 5 Mrd. US-Dollar.

Skaleneffekte nutzen mit öffentlichen APIs

Der letzte Schritt einer API-Strategie im Amazon-Stil ist dann die generelle Öffnung in Form einer öffentlichen API. Auf eine öffentliche API hat im Gegensatz zu privaten und Partner-APIs prinzipiell die breite Internetöffentlichkeit Zugriff. Typischerweise werden bei öffentlichen APIs einfache Funktionen kostenlos angeboten — z.B. um Neukunden anzuwerben — und mit bezahlten, komplexeren Funktionen kombiniert. Einige bekannte Beispiele für öffentliche APIs gehören gleichzeitig zu den langlebigsten: mit der eBay API kann unter anderem das Kaufen und Verkaufen über eBay automatisiert werden (seit 2000). Andere Beispiele sind die Amazon Web API und die Google Search API (beide 2002).

Vorteile einer öffentlichen API gegenüber einer privaten sind natürlich die Möglichkeit, eine breitere Zielgruppe für die eigenen Produkte und Dienstleistungen zu erreichen; damit können möglicherweise deutlich erhöhte Einnahmen verbunden sein. Der Mechanismus, der hinter dem Skalierungspotenzial mit APIs steckt, ist eine geschickte Arbeitsteilung. Kaum ein Unternehmen kann für alle möglichen Zielgruppen geeignete Lösungen anbieten. Mit Bereitstellung einer API können API-Kunden maßgeschneiderte Lösungen für eine bestimmte Zielgruppe entwickeln, die für das Unternehmen vorher nicht — oder nur unter erhöhtem Aufwand — erreichbar gewesen wären. Die API-Nutzung skaliert also mit den Nutzern aller unter Einsatz der API entwickelten Lösungen.

Ein weiterer Vorteil von öffentlichen APIs gegenüber internen oder Partner-APIs sind außerdem schnellere und tiefgreifendere Iterationen zur Produktverbesserung durch das vermehrte Feedback der breiteren Kundenbasis. Öffentliche APIs können außerdem auch als eine Form der Werbung angesehen werden. Typischerweise werden öffentliche APIs aus Sichtbarkeitsgründen mit der Bereitstellung von Nutzerportalen kombiniert. Auf Nutzerportalen können z.B. Angebotsdokumentation und Hilfeleistungen verfügbar gemacht werden (mehr dazu in Teil 2). Implizit wird ausserdem die Sichtbarkeit und Awareness für ein Unternehmen, seine Produkte und Dienstleistungen erhöht, sowie technische Versiertheit demonstriert.

Langfristigen Erfolg sichern mit API as a Product

Ob man nun APIs für die interne Restrukturierung, zur Verbesserung der Partnerkommunikation oder zur Verbreiterung der Kundenbasis für Produkte und Dienstleistungen einsetzt, sollte die Entwicklung einer API grundsätzlich als langfristige Produktentwicklung (API as a Product, AaaP) — und nicht als einmaliges Projekt — verstanden werden.

Die API ist in der Regel stark mit dem Produkt- und Dienstleistungsportfolio gekoppelt und muss sich mit deren Änderungen weiterentwickeln. Darüber hinaus ist es wie bei traditionellen Produkten nötig, die API mit den Anforderungen der Nutzer wachsen zu lassen und zu verbessern.

Bei der Entwicklung einer API ist es daher wertvoll, mit Minimum Viable Products (MVPs) rasch zu verwendbaren Ergebnissen und in eine Feedback-/Weiterentwicklungs-Schleife zu kommen. Auf organisatorischer Seite sollte ein API-Programm im Idealfall einen Produktmanager bzw. eine Produktmanagerin besitzen, der oder die eine mit der Unternehmensstrategie abgestimmte Roadmap für die API entwickelt und durch ein Team aus Entwickler_innen, Community Managern, Support, Marketing- und Rechtsexpertise, sowie Qualitätssicherung unterstützt wird.

Durch die schnellen Weiterentwicklungsschritte wird es außerdem zwingend nötig, Änderungen — insbesondere Breaking Changes — klar, schnell und umfänglich zu dokumentieren und zu kommunizieren.

In Teil 2 dieser Miniserie über API as a Product werfen wir einen Blick auf die API-Wertschöpfungskette ein und zeichnen eine Roadmap für die Umsetzung von API as a Product-Stategien vor.

 


Quellen


Über den Autor

Friedrich Kurz

Senior Software Engineer in Web Engineering

Friedrich arbeitet seit 2,5 Jahren als Vollzeit-Software-Ingenieur bei MaibornWolff. In seinem aktuellen Projekt hilft er dabei, die AWS-Cloud-Infrastruktur für die Webplattform eines Kunden aufzubauen. Friedrich sieht sich selbst eher als Technologie-Generalist mit einem breiten Interessenspektrum als ein Technologiespezialist. Er ist jedoch auch sehr an funktionaler Programmierung und allgemeinen Methoden zum Schreiben von korrektem, sauberem und wartbarem Code interessiert.