GraphQL (eBook)

2Von der Idee zur Umsetzung

Ob die Veröffentlichung eigener Daten und Funktionen, die Bindung neuer Geschäftspartner, oder die Gewährleistung von Skalierbarkeit der Funktionen: Es gibt viele Gründe für ein API.

Die Herausforderung zu Beginn besteht jedoch darin, ein eindeutiges Geschäftsziel zu entwickeln. So schreiben auch schon Daniel Jacobson, Greg Brail und Dan Woods in ihrem Werk APIs – A Strategy Guide, dass sie bei ihrer Unternehmensberatung immer große Probleme sahen, wenn einer ihrer Kunden auf die Fragen »Für wen ist Ihr API?« und »Welche Funktionen bietet Ihr API« mit »Für jeden.« und »Alle Funktionen« antwortete [37].

Ein API ist keine rein technische Lösung. Bei der Entwicklung müssen auch die beteiligten Personen und Prozesse bedacht werden. Um den möglichen Erfolg der Schnittstelle zu messen, hat das 2016 von Google akquirierte Unternehmen für API-Management-Tools Apigee den Kompass in Abbildung 2–1 entwickelt. Der Kompass betrachtet die verschiedenen Geschäftsfaktoren von der Vision über die Führung und Finanzierung bis hin zum Team und dem Self-Service als Einflüsse auf die Qualität des API.

Abb. 2–1
Der Apigee-Kompass zur Bestimmung der API-Qualität [2]

Es soll eine Einschätzung liefern, welche Qualität das Entwicklungsumfeld – vor allem in der Denkweise – in einem Unternehmen für die nachhaltige Erstellung großer Schnittstellen-Ökosysteme hat. Diese Einschätzung leitet sich aus den zehn Fragen eines Fragenkatalogs ab (siehe Abbildung 2–2). Aus den Antworten ergibt sich eine Gesamtwertung auf einer Skala bis maximal 100, wobei 100 das ideale Umfeld zur Entwicklung und Bereitstellung von APIs ist. Sollte die Wertung darunter liegen, zeigen die grünen, gelben und roten Balken bei den jeweiligen Kategorien an, welche Bereiche schon gut und wo noch verbessert werden kann. Weitere Informationen zum Apigee-Kompass sowie den Fragenkatalog gibt es auf der Website von Apigee [2].

Abb. 2–2
Fragen des Apigee-Kompasses zur Bestimmung der API-Qualität [2]

Um diesen geschäftlichen Prozessen gerecht zu werden, widmet sich dieses Kapitel – bevor es an die technische Umsetzung des API geht – der zugehörigen Value Chain, erörtert, wie man in diesem Umfeld eine Produktstrategie ableitet und systematisch Anforderungen an das API bestimmt.

2.1API Value Chain

Ein API ist ein indirekter Kanal, über den Daten und Funktionen von einem Anbieter über einen Entwickler zu einem Endnutzer gesendet werden. Das bedeutet also: Die Value Chain eines API hat klare Abhängigkeiten. Daraus ergeben sich verschiedene Probleme.

Anders als bei einem direkten Kanal, wie beispielsweise einer Webseite, in der Daten des Anbieters direkt dem Endnutzer angezeigt werden, benötigt der Anbieter bei einem API einen Partner, um die Endnutzer zu erreichen; etwa einen externen Entwickler.

Vergleichbar ist diese Abhängigkeit mit dem Verkauf von Lebensmitteln. Früher haben Kunden diese direkt von dem Bauern bezogen, der sie produzierte. Mittlerweile werden sie jedoch über den indirekten Kanal des Supermarktes erworben. Der Bauer ist also der Anbieter des Business Assets »Lebensmittel«, der diese indirekt über den Supermarkt an Endkunden verkauft. Abgeleitet von diesem Prozess gibt es also auch bei einem API unterschiedliche Rollen:

• Business Assets: Daten, Services, eben die Produkte des API, wie im vereinfachten Beispiel die Lebensmittel.
• API: Der Zugang zu den Business Assets, im Beispiel des Bauern also etwa ein Großhandel für Supermärkte.
• Entwickler: Diejenigen, die die Daten und Funktionen über das API für ihre Anwendungen benutzen, zum Beispiel die Supermärkte.
• Applikationen: Die Anwendungen, die mithilfe der Daten und Funktionen des API entwickelt wurden, also Angebote und das Sortiment in den Supermärkten.
• Endnutzer: Diejenigen, die die Daten und Funktionen des API über die Anwendung verwenden, also die Käufer der Lebensmittel.

Bereits bei der Auflistung lässt sich eine klare Abhängigkeit voneinander erkennen. Diesen Abhängigkeitsgraphen haben Daniel Jacobson, Greg Brail und Dan Woods in APIs – A Strategy Guide [37] verdeutlicht (siehe Abbildung 2–3).

Abb. 2–3
Die API Value Chain nach Daniel Jacobson, Greg Brail und Dan Woods [37]

Damit all diese Akteure auch wirklich Ressourcen – ob nun Zeit oder Finanzielles – in das API investieren, muss man sich schon früh die Frage stellen: Was haben die unterschiedlichen Akteure jeweils davon, eine API anzubieten oder zu nutzen?

Eine Schnittstelle kann nur dann erfolgreich sein, wenn sie jedem innerhalb der Value-Chain – von Business-Assets-Besitzer, über API-Anbieter und Entwickler, bis hin zur Applikation und den Endnutzern – einen Nutzen bringt. Da man diesen jedoch nie für alle Entwickler und Endnutzer generieren kann, sollte man sich früh bewusst machen, wer genau die Zielgruppe ist und was deren Motivation sein wird, das API und damit die angebotenen Daten und Funktionen zu verwenden.

2.1.1Geschäftsmodelle für private und öffentliche APIs

Um jedem Akteur innerhalb der API Value Chain einen Mehrwert anzubieten, haben sich unterschiedliche Geschäftsmodelle entwickelt. John Musser, Gründer von ProgrammableWeb, hat dabei auf der API Strategy Conference 2013 eine einfache, bereits aus dem Jahr 2005 stammende Kategorisierung dieser Modelle, unter die nahezu jedes API eingeteilt werden kann, vorgestellt [40] (siehe Abbildung 2–4).

Abb. 2–4
Einfache Standardeinteilung von API-Geschäftsmodellen nach Musser [40]

Damit ordnet John Musser API-Geschäftsmodelle in folgende Kategorien:

• Freie und unbeschränkte Verwendung, wie bei Facebook
• Entwickler zahlen für die Verwendung, wie bei PayPal
• Der Entwickler wird für Transaktionen über die API bezahlt, hier zum Beispiel Amazons AdSense für Werbebanner
• Indirekter Geschäftswert, wie der Erwerb von speziellen Inhalten oder die interne Nutzung

Dieses einfache Modell aus dem Jahr 2005 wurde 2013 von ihm um weitere Details erweitert, wobei weitere Unterkategorien entstanden sind (siehe Abbildungen 2–5, 2–6 und 2–7).

Abb. 2–5
Erweiterte Einteilung des »Entwickler zahlt«-Modells nach Musser [40]

Die Kategorie »Entwickler zahlt« in Abbildung 2–5 findet sich unter anderem in folgende Punkte aufgeteilt:

• Ein dynamisches Modell, bei dem je nach Nutzleistung gezahlt wird, wie bei den Amazon Services.
• Freemium: Ein Modell, bei dem die Nutzung bis zu einer gewissen Grenze kostenlos ist und oberhalb davon Kosten aufwirft, wie etwa bei Google Maps.
• Transaktionsgebühren: Falls über das API auf irgendeine Weise Geld oder anderer Wert transportiert wird, kann hierbei ein Anteil als Bezahlung anfallen, wie bei bei PayPal.

Abb. 2–6
Erweiterte Einteilung des »Entwickler wird bezahlt«-Modells nach Musser [40]

Das »Entwickler wird bezahlt«-Modell in Abbildung 2–6 kann in folgende Punkte unterteilt werden:

• Umsatzbeteiligung: Ein Teil des Einkommens durch die Verwendung des API wird geteilt, wie bei Googles AdSense.
• Partnerprogramm: Eine Partnerschaft zwischen API-Anbieter und konsumierendem Entwickler, etwa mit wiederholten oder einmaligen Zahlungen eines bestimmten Betrags. Alternativ ist eine Kostenpro-Klicks- oder -Aktion-Abrechnung möglich. Letzteres ist üblich bei Diensten wie Amazons Produktvermittlung.

Abb. 2–7
Erweiterte Einteilung des »Indirekt«-Modells nach Musser [40]

Die größte Kategorie in Abbildung 2–7, »Indirekt«, erhält in der erweiterten Unterteilung auch die meisten Unterkategorien. Diese sind unter anderem:

• Erwerb von Inhalten: Bei eBay oder Twitter ist es üblich, dass die Inhalte der Webseite von Drittanbietern, größtenteils über die API, gestellt werden. Hierbei bieten die API-Anbieter eine Plattform und Drittanbieter den Inhalt.
• Software as a Service (SaaS): Hinter dem Begriff steht das Bereitstellen von Software als Service, etwa bei Microsofts Office 365, bei dem die Software...