API as a Product: Wertschöpfungskette und Strategieroadmap

Wie wir in Teil 1 der Miniserie über API as a Product gesehen haben, werden APIs für die interne IT-Restrukturierung, Verbesserung der Zusammenarbeit mit Partnern oder als öffentliche API eingesetzt. Im zweiten Teil werfen wir einen genaueren Blick auf die API-Wertschöpfungskette und leiten davon eine Roadmap für die Durchführung von API as a Product-Strategien ab.

Die API Wertschöpfungskette

Wertschöpfung mit APIs beginnt bei einer Organisation, die Daten oder Funktionalität als Anwendungsschnittstelle zur Verfügung stellt (API-Anbieterin). Konsument_innen der API sind typischerweise interne oder externe Entwickler_innen, die unter Nutzung der API Anwendungen für eine bestimmte Gruppe von Nutzer_innen erstellen.

Wie in Teil 1 für öffentliche APIs angesprochen, gibt es eine typische Arbeitsteilung zwischen API-Anbieterin und API-Konsumentin: Die API-Anbieterin stellt ihre Daten oder Funktionalität direkt nur den API-Konsument_innen zur Verfügung und mittelbar über deren Apps den App-Nutzer_innen. Entwicklung und Betrieb der API liegen wie bei Software as a Service (SaaS) bei der Anbieterin. API-Konsument_innen können sich dadurch voll und ganz auf die Erzeugung innovativer Lösungen durch Erweiterung oder Integration der über die Schnittstelle der API-Anbieterin verfügbaren Ressourcen konzentrieren. APIs beschleunigen dadurch nicht nur die Time-To-Market von Applikationen, sondern ermöglichen unter Umständen sogar Lösungen, die vorher wegen des Aufwands eigenständiger Entwicklung nicht möglich gewesen wären.

Ein prominentes Beispiel hierfür ist die Integration der Google Maps API in der Uber App. Ohne die Kartenfunktionalität wäre Uber als Dienstleistung undenkbar. Man kann sich leicht vorstellen, dass die Entwicklung einer eigenen API anstelle der Nutzung der Google Maps API einen starken Bremseffekt auf die Veröffentlichung ausgelöst und erhebliche Kosten verursacht hätte.

Wichtig zu beachten ist, dass die Zielgruppe im Markt für APIs sowie Begleitprodukte und -dienstleitungen (API-Economy) die Applikationsentwicklerinnen sind. Daraus ergeben sich bestimmte Ansprüche an die Nutzbarkeit der API. So sind Korrektheit, Zuverlässigkeit und Geschwindigkeit der API, klare und aktuelle Dokumentation, Codebeispiele oder das kostenfreie Testen der API, kurz gesagt: generell niedrige Nutzungsbarrieren von hoher Bedeutung. Diese besondere Form des Marketings wird häufig prägnant Business-to-Developer(B2D)-Marketing genannt.

Roadmap für API as a Product

Produktvision, Ziele und Meilensteine formulieren

Beim Formulieren einer API as a Product(AaaP)-Strategie ist es grundsätzlich sinnvoll, die drei wesentlichen Ausbauschritte der API von interner API über die Ausweitung auf Partner und anschließende Veröffentlichung als Public API als zentrale Meilensteine aufzufassen. Wichtig zu beachten ist dabei, dass jede Ausweitung des Zugriffs auf eine größere Gruppe von API-Konsument_innen ein eigenes Kosten-/Nutzenprofil hat. Eine Re-Evaluierung des Zielerreichungsgrads nach dem Erreichen jedes Meilensteins ist daher ratsam. Interne und Partner-APIs können auch alleine schon beträchtliche wirtschaftliche Effekte erzielen und viele strategische Ziele erfüllen.

Um den Erfolg einer AaaP-Strategie messen zu können, sollten zunächst klare und messbare Ziele formuliert sein und in einer Produktvision zusammengefasst werden. Bei der Formulierung von konkreten Schritten ist es sinnvoll, zunächst die Akteure in der API Wertschöpfungskette zu definieren. Typische Fragen sind also:

• Wer ist die API-Anbieterin, und welche Daten und Funktionalitäten sind wertvoll und sollen über die API verfügbar gemacht werden? Auf welchem Weg soll die API verfügbar sein?
• Wer sind die API-Konsument_innen und welchen Nutzen können die per API bereitgestellten Daten und Funktionalitäten für sie haben? Wie kann die API-Anbieterin von der Nutzung durch die API-Konsument_innen profitieren?
• Wer sind die App-Nutzer_innen und welchen Nutzen können die unter Einbezug der API entwickelten Apps für sie stiften? Wie können sowohl API-Anbieterin als auch API-Konsument_in daraus Nutzen ziehen?

Am Beispiel

Nehmen wir zum Beispiel an, Firma Musterfrau hat ein intern genutztes Altsystem und organisiert dessen Betrieb im Moment selbst. Das System enthält kritische Informationen für das operative Geschäft, ist aber hinsichtlich der Bedienbarkeit und Performance in die Jahre gekommen. Insbesondere ist der Zugriff umständlich und die laufenden Kosten für den Betrieb und Maintenance des Systems sollen reduziert werden. Eine AaaP-Vision wäre hier also, durch Modernisierung des Altsystems kompetitiver zu werden. Daraus lassen sich zwei konkrete strategische Ziele ableiten:

1. Beschleunigung und Effizienzsteigerung von Prozessen durch Verbesserung des Zugriffs auf das Altsystem, und
2. Reduzierung der Total Cost of Ownership im Betrieb.

Im ersten Schritt sollte eine interne Restruktierung angestrebt werden. Sinnvoll wäre also, den Zugriff auf das Altsystem mittels einer internen API zu verbessern und dann eine Cloudmigration durchzuführen, um die Kosten zu senken.

Bei der weiteren Ausgestaltung sollte dann die AaaP-Wertschöpfungskette herangezogen werden, um die Bedürfnisse von API-Anbieterin, API-Nutzer_in und App-Nutzer_in zu reflektieren. Für Firma Musterfrau als API-Anbieterin ist zum Beispiel äußerst wichtig, dass die API einen positiven Effekt auf die KPI des Unternehmens hat; und natürlich auch, dass die Cloudmigration nicht dazu führt, dass sensible Daten öffentlich exponiert werden. Die API-Nutzer_innen sind in diesem Beispiel Mitarbeiter_innen des Unternehmens, die Tools auf der Basis des Altsystems zur Verfügung stellen. Für sie ist wichtig, dass keine Einschränkung der Funktionen durch die API entstehen und dass Unterstützung bei der Migration verfügbar ist (z.B. durch Migrationsanleitungen oder direkten Support). Benutzer_innen der Tools legen darauf Wert, dass ihr bisheriges Nutzungsspektrum erhalten bleibt oder erweitert wird und dass sich ggf. nicht-funktionale Aspekte wie Performance verbessern.

Nach Erreichen des Meilensteins für die interne API und einer Evaluierung des Zielerreichungsgrads sollte Firma Musterfrau danach überlegen, ob beispielsweise eine Partner-API als nächster Schritt sinnvoll sein kann.

Auf die Developer Experience (DX) achten

Für den Erfolg jeder API ist der wichtigste Aspekt, dass sie durch API-Konsument_innen angenommen wird und nützliche Lösungen für die App-Nutzer_innen entwickelt werden. Wie bei User Interfaces (UI) spielen bei APIs dafür Usability-Kriterien eine große Rolle. In Analogie zur User Experience (UX) bei UIs werden diese Aspekte im API-Kontext häufig unter dem Begriff Developer Experience (DX) zusammengefasst.

Gute DX sorgt dafür, dass Zugangsbarrieren für die API-Konsument_in gesenkt werden. Insbesondere ist wichtig, dass typische Frustrationsquellen vermieden werden, etwa fehlende Ressourcen für das Onboarding, beispielsweise Möglichkeiten zum Ausprobieren (Sandboxes) oder vorgefertigter Code (wie SDKs oder Libraries), ebenso kein oder wenig Support, und unzureichende oder nicht aktuelle Dokumentation. Der zentrale Faktor für die Adoption durch API-Konsument_innen ist aber natürlich, dass die API das Problem der Konsument_in schnell und zuverlässig löst. Kurz gesagt: Die von der API bereitgestellten Ressourcen müssen hohen Wert für die API-Konsument_innen haben, und die Präsentation der API muss die Werthaftigkeit auch deutlich machen. Dass DX-Maßnahmen effektiv umgesetzt wurden, kann man an der Zufriedenheit der API-Konsument_innen ablesen, die insbesondere sich durch intensive Nutzung und positives Feedback zeigt.

Die hier angedeuteten DX-Aspekte

• Wert der Ressourcen,
• Onboarding,
• Support und
• Dokumentation

werden konzeptionell im 4-Felder Modell der DX zusammengefasst. Beim Umsetzen von konkreten DX-Maßnahmen sollte man darauf achten, jedem der vier Aspekte Bedeutung zu schenken, da einseitige Umsetzung schnell zum Ausschlusskriterium werden kann. Beispielsweise kann unzureichende Dokumentation einem längerfristigen Einsatz einer API im Weg stehen, auch wenn die angebotenen Ressourcen generell wertvoll sind, das Onboarding für schnelle erste Erfolge sorgt und es Support bei Problemen gibt.

Ein nicht zu vernachlässigender Aspekt für kommerzielle APIs (also Partner-APIs und öffentliche APIs) ist außerdem ein klares und einfaches Preismodell. Oft ist es darüber hinaus auch sinnvoll, proaktiv auf weitere Verwendungsmöglichkeiten hinzuweisen, die von der API-Konsument_in bislang nicht berücksichtigt worden sind.

API-Management-Lösungen nutzen

Wie in anderen Entwicklungsprojekten ist es auch bei API-Projekten aus Kosten- und Qualitätsgründen wichtig, das sprichwörtliche Rad nicht ständig neu zu erfinden. Ähnlich wie in der Programmentwicklung gibt es für die API-Entwicklung vorgefertigte Lösungen, die bei der technischen Umsetzung von APIs eingesetzt werden können und typische Probleme bereits vorab beheben. Azure API Management von Microsoft, Google Apigee und IBM API Management sowie Mulesoft Anypoint Platform und Red Hat 3scale sind Beispiele für solche API-Management-Lösungen.

Einige der oben genannten DX-Aspekte, die beim Marketing an API-Konsument_innen berücksichtigt werden sollten, werden bei API-Management-Lösungen in einem API-Portal gebündelt. Unter anderem sorgt das API-Portal für Sichtbarkeit und ist häufig der Ort des ersten Kontakts der API-Konsument_in mit der API (zum Beispiel wenn die API-Konsument_in nach einer entsprechenden API im Web gesucht hat). Darüber hinaus sollte der Wert der Ressourcen für die API-Konsument_in unmittelbar im API-Portal klar gemacht werden. Auch weiterführende Links zu Onboarding, Dokumentation und Support sollten verfügbar sein.

Auf der technischen Ebene helfen API-Management-Lösungen bei der Steuerung des Zugriffs auf die API bzw. die dahinter liegenden Ressourcen. Wenn App-Nutzer mittels einer App auf die API zugreifen, sorgt ein API-Gateway für das Routing der Anfragen an die Systeme des API-Anbieters. Das Gateway bietet sich daher auch als Ort für die Implementierung von Qualitäts- und Sicherheitsaspekten wie Authentifizierung/Authorisierung und Caching an.

Mit API-Management-Lösungen können zudem Aspekte der Monetarisierung schnell und effektiv adressiert werden, indem Bezahlmodelle dokumentiert und ggf. die Rechnungserstellung und Abrechnung über Zahlungsdienstleister integriert werden. Auf welche Weise eine API monetarisiert wird, hängt stark davon ab, ob die API intern, für Partner zugänglich oder komplett öffentlich ist. Generell klassifizieren wir in

1. kostenlose APIs (z.B. Facebook Login);
2. APIs, bei denen der Entwickler / die Entwicklerin bezahlt (z.B. Dropbox);
3. APIs, bei denen der Entwickler / die Entwicklerin bezahlt wird (z.B. Google Adsense); und
4. APIs mit indirekter Monetarisierung (z.B. YouTube).

Im Sinne der DX bietet sich für Partner-APIs oder öffentliche APIs häufig ein Freemiummodell an, mit einer kostenlosen, beschränkten API-Stufe und bezahltem, unbeschränktem Zugang. Das Freemium-Modell erlaubt API-Konsument_innen, mit minimaler, eigener Vorleistung zu testen, ob die API den eignen Anforderungen entspricht. Das senkt wiederum Nutzungsbarrieren.

APIs sind (leider) kein Allheilmittel

Trotz der verblüffenden Effekte von API-Strategien, gibt es natürlich auch einige Probleme und typische Kritikpunkte.

Naheliegend ist, dass Fragen im Zusammenhang mit der möglichen Exponierung wichtiger Daten und Funktionalitäten sowie der Notwendigkeit zur Sicherstellung des legitimen Gebrauchs entstehen. Viele dieser Themen können allerdings entweder technisch durch API-Gateways oder durch die geeignete Vertragsgestaltung abgesichtert werden.

Zudem müssen Entscheidungsträger natürlich das Spektrum möglicher positiver Effekte von APIs vor Durchführung einer AaaP-Strategie kennen. Kurz gesagt muss Bewusstsein dafür geschaffen werden, dass APIs Kern eines modernen Businessmodells bzw. Teil einer modernen Geschäftsstrategie sein können. Das AWS-Beispiel aus Teil 1 zeigt deutlich, welcher Erfolg am Ende der Adoption des API-Businessmodels stehen kann. Generell können bei der schrittweisen Durchführung der Entwicklung wie in der Roadmap von interner API zur Partner API bis hin zur öffentlichen API verschiedene positive Effekte beobachtet werden. Beispiele sind interne Effizienzsteigerungen, bessere Partnerkommunikation durch Partner-APIs und Einnahmensteigerungen sowie Verbesserung des Markenimages durch öffentliche APIs.

Dass APIs nicht nur Thema für die Googles und Amazons dieser Welt sind, sondern auch für kleinere oder nicht primär in der IT aktive Unternehmen sinnvoll sein können, zeigen Beispiele wie Dun & Bradstreet oder Marvel Entertainment.

Was meint ihr? Können APIs ein wirkungsvolles Instrument sein, um schlummerndes Potenzial in Unternehmen zu wecken? Lasst uns wissen, was ihr denkt! friedrich (punkt) kurz (@) maibornwolff (punkt) de

 

---

Quellen

• API Monetization – Understanding your Business Model Options
• Dan Woods, Daniel Jacobson & Greg Brail – Apis: A Strategy Guide: Creating Channels with Application Programming Interfaces
• Luis Weir – Enterprise API Management
• The API Economy
• Jarkko Moilanen, Marjukka Niinioja &Marko Seppänen – API Economy 101: Changes Your Business
• Jordan Novet – Uber paid Google $58 million over three years for map services
• Christy Pettey – 10 Steps to the API Economy
• Sean Michael Kerner – Top 10 API Management Tools
• Mike Budzynski – How to monetize APIs with Azure API Management

---

Über den Autor