Die Plattform-Denkweise im API-Produktmanagement

Es ist kein Geheimnis, dass die Pandemie die Notwendigkeit für Unternehmen, eine Digital-First-Strategie zu verfolgen, erheblich verstärkt hat. Digitale Transformationen, die zugunsten anderer Unternehmensziele depriorisiert worden waren, rückten über Nacht mit beispielloser Dringlichkeit in den Vordergrund. Laut einer globalen McKinsey-Umfrage unter Führungskräften aus dem Jahr 2020 haben Unternehmen trotz der erheblichen Herausforderungen durch COVID-19 die Geschwindigkeit, mit der sie ihre internen Abläufe digitalisiert und ihr Portfolio digitaler Produkte erweitert haben, um mehrere Jahre beschleunigt.

Im Mittelpunkt dieser digitalen Transformationen steht die Integration, die durch Anwendungsprogrammierschnittstellen (APIs) erleichtert wird. Früher nur als „Messenger“ oder „Vermittler“ gedacht, die Daten zwischen Softwaresystemen übertragen, gelten APIs heute als „Bindegewebe“ digitaler Ökosysteme, die den Organisationen, die sie aufbauen und nutzen, unbegrenzte Integrations- und Geschäftsmöglichkeiten bieten. Aufgrund des einzigartigen Potenzials, das APIs darstellen, müssen Produktmanager, die ihre Entwicklung überwachen, einen Ansatz verfolgen, der ihren latenten Wert erschließt, einen Ansatz, der Flexibilität und Erweiterbarkeit betont, um einwandfreie Integrationserfahrungen zu gewährleisten.

Mit weniger mehr erreichen

Schon vor dem vergangenen beispiellosen Jahr war der Wert von APIs für Unternehmen gut dokumentiert, und die API-Wirtschaft florierte seit einiger Zeit. Um die heutige Integrationslandschaft zu verstehen, ist es hilfreich, die Ursprünge der Best-of-Breed-Philosophie (BoB) zu untersuchen. Vor den 1990er Jahren vermarkteten Softwareanbieter Suite-Lösungen für Enterprise Resource Planning (ERP), die versuchten, eine Vielzahl von organisatorischen Herausforderungen zu lösen. Diese Suiten wurden zunehmend als umständlich und unpraktisch angesehen, weil sie unternehmensspezifische Anwendungsfälle nicht adressierten. Infolgedessen begannen die Anbieter damit, fokussiertere Tools zu entwickeln, die Herausforderungen für einen Funktionsbereich lösten, anstatt größere Suiten zu entwickeln, die versuchten, alles für alle zu tun. Unternehmen begrüßten die Idee, aus einer Vielzahl kleinerer, spezialisierterer Tools auszuwählen, und begannen, Sammlungen individueller Lösungen zusammenzustellen, die ihren speziellen Anforderungen am besten entsprachen.

Die Punkte verbinden

Als der BoB-Ansatz an Fahrt gewann, wurden Integrationen zu einem entscheidenden Bestandteil der Produktstrategien. Ein Tool, das Probleme in einem Geschäftsbereich hervorragend lösen konnte, musste in der Lage sein, sich gut in andere BoB-Produkte zu integrieren, die wahrscheinlich daneben verwendet werden. Betrachten Sie HubSpot, die Vertriebs- und CRM-Software, die von Organisationen implementiert wird, um ihre Vertriebspipelines und Kundenbeziehungen zu verfolgen und zu optimieren. HubSpot lässt sich problemlos in andere BoB-Software wie DocuSign (digitale Signaturen), Twilio (E-Mail-/SMS-Benachrichtigungen) und Zendesk (Kundensupport) integrieren, ohne dass eine zusätzliche Entwicklung durch die Ingenieurteams des Kunden erforderlich ist.

Die Notwendigkeit komplementärer Tools, die sich nahtlos ineinander fügen lassen, ging mit einer branchenweiten Verlagerung hin zur Akzeptanz von Offenheit einher, anstatt die Interaktionen zwischen Systemen einzuschränken. Irgendwann auf dem Weg dorthin wurde die Anzahl der von einem Produkt unterstützten Integrationen zu einer Marketingkennzahl.

Das Plattformangebot

Der wahre Wert von Integrationen geht jedoch über ihre Fähigkeit hinaus, unterschiedliche Tools und Systeme zu koordinieren. Im besten Fall sind APIs der kollektive Mechanismus, um Produkte in Plattformen zu verwandeln. Produkte sind per Definition Werkzeuge, die eine bestimmte Anwendung haben; daher "Apps". Sie sind in ihrer Fähigkeit eingeschränkt, mehrere Wertversprechen und damit mehrere Einnahmequellen zu schaffen. Plattformen hingegen schaffen einen Mehrwert auf andere Weise: indem sie die Infrastrukturschicht bereitstellen, auf der zahlreiche Produkte aufbauen können.

APIs eröffnen neue Geschäftskanäle, indem sie vom Fachwissen der Drittanbieter profitieren, die sie nutzen. Konsumierende Entwickler können eine Immobilien-App entwerfen, die die Places-APIs von Google Maps verwendet, um Benutzern bei der Wohnungssuche zu helfen, oder sie können die Flug-APIs von Skyscanner und die Hotel-APIs von Expedia nutzen, um eine Ökotourismus-Website zu erstellen, die auf Reisen zu einem bestimmten Ort spezialisiert ist. Diese Entwickler und externen Partner profitieren davon, indem sie Zugang zu bestehenden Daten und Diensten erhalten, die sie für ihre Unternehmen anpassen können, und API-Eigentümer wie Expedia erweitern ihre Reichweite und monetarisieren Möglichkeiten, die nicht existieren würden, wenn sie beispielsweise weiterhin nur Hotels in ihrem Produkt auflisten würden.

Modular machen

Für Produktführer erfordert die Entwicklung einer erfolgreichen API-Strategie einen Mentalitätswandel vom Produktdenken zum Plattformdenken. Das bedeutet, Produkte auf modulare, offene Weise zu entwickeln, die es ermöglicht, ihre Funktionalität neu zu kombinieren, und die Flexibilität für verbrauchende Entwickler priorisiert. Denken Sie an IKEA Regalsysteme, die Kunden kaufen, zusammenbauen und auf unterschiedliche Weise anpassen können, um eine Vielzahl von Anforderungen zu erfüllen. Gute API-Produktmanager sehen APIs als das, was sie sind: Werkzeuge zur Skalierung des Geschäfts und zur Entwicklung wertvoller Partnerschaften. Dieses Potenzial zu erkennen bedeutet, Best Practices umzusetzen, um die Akzeptanz sicherzustellen.

Begeistert die Entwickler

Wenn es eine grundlegende Säule einer soliden API-Strategie gibt, dann ist es Developer Experience (DX). Bei API-Integrationen müssen die „Kunden“, Produktmanager, begeisterte Entwickler sein. Dies sind die Benutzer, die letztendlich eine API aufrufen/integrieren, die potenziellen Partner, die helfen können, eine Produkt-zu-Plattform-Vision zu verwirklichen. Die Bezeichnung ihrer Erfahrung als „DX“ statt „UX“ erkennt an, dass sie keine typischen Endbenutzer sind – sie sind technisch wesentlich versierter. Um sich in sie einfühlen zu können, ist es wichtig, ihre spezifischen Bedürfnisse und Erwartungen zu verstehen.

Empfohlene Vorgehensweise

Die folgenden, obwohl sie keineswegs eine vollständige Liste darstellen, sind wesentliche Praktiken zum Erstellen erstklassiger APIs, die reibungslose und konsistente, vorhersehbare Integrationserfahrungen für konsumierende Entwickler gewährleisten. Produktmanager sollten das Design von APIs auf skalierbare Weise angehen, ein Best-Practice-Framework definieren und es als Dokument veröffentlichen, auf das sich Teams beim Erstellen neuer APIs beziehen können.

Konsistente Namenskonventionen und Endpunkte

Die Festlegung konsistenter Namenskonventionen für API-Endpunkte, die Art und Zweck der API eindeutig identifizieren, beseitigt Mehrdeutigkeiten und trägt zu einem positiven und vorhersehbaren DX bei. Wählen Sie am besten eine gemeinsame Basis-URL für alle APIs und ein Framework für die abschließende URL, das Fachjargon und Abkürzungen vermeidet. Nordic APIs bietet eine hilfreiche Liste mit Tipps zur Benennung von Endpunkten.

Detaillierte Erfolgs- und Fehlerreaktionsstrukturen

Entwickler wollen und erwarten vertraute Datenobjekte und Statuscodes für Erfolgs- und Fehlerreaktionen. Das bedeutet einen 2xx-Statuscode für Erfolgsszenarien, einen 4xx-Code für clientseitige Fehler und einen 5xx-Code für serverseitige Fehler. Allerdings ist die Spezifität entscheidend. Ein Aufruf an eine „E-Mail senden“-API, die einfach eine 4xx-Antwort ohne zusätzliche Informationen zurückgibt, führt zu einer schlechten Entwicklererfahrung, da sie lediglich bestätigt, dass der Fehler in der Clientanforderung lag, ohne zusätzliche Informationen darüber zu geben, was genau schief gelaufen ist.

 { "status": 400, "message": "incorrect request" }

Im Gegensatz dazu kann eine Antwort, die spezifische Details in einem für Menschen lesbaren Format und in Form eines eindeutigen Fehlercodes enthält, Entwicklern helfen, schnell zu entscheiden, wie das Fehlerszenario behoben, Code zur Behebung des Problems geschrieben und den API-Aufruf erneut versucht werden kann.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Für eine optimale DX sollten Antwortstrukturen und die Schlüssel, die den Status kommunizieren, über APIs hinweg konsistent sein. Beispielsweise sollte das Fehlercodefeld oben in jeder API ausnahmslos als „Code“ bezeichnet werden, in einigen APIs nicht als „Code“ und in anderen als „ErrorCode“.

Konfigurierbare Ratenbegrenzungen

Ratenbegrenzungen bestimmen, wie zugänglich eine API ist, indem sie bestimmen, wie oft ein Benutzer sie in einer einzigen Zeiteinheit aufrufen kann. Zu hohe Ratenlimits können Systeme mit einer unüberschaubaren Anzahl von Anforderungen überfluten, die die Leistung beeinträchtigen, während unangemessen niedrige Ratenlimits dazu führen können, dass ausstehende Transaktionen in den Systemen der Benutzer in eine Warteschlange geraten. Beide tragen zu einem schlechten DX bei. Beim Entwerfen von APIs ist es am besten, Ratenbegrenzungen zu berücksichtigen, die basierend auf bestimmten Geschäftsfällen und Umständen angepasst werden können. Kunden mit hohem Volumen haben beispielsweise möglicherweise ein echtes Bedürfnis, APIs häufiger aufzurufen.

Um geeignete Ratenbegrenzungen am besten zu bestimmen, ist es hilfreich, APIs zunächst entsprechend der Häufigkeit und dem Volumen, mit dem sie aufgerufen werden, in aussagekräftige Kategorien zu gruppieren. Beispielsweise werden APIs, die primäre Kundendaten konfigurieren (Profil-/Kontoerstellung), seltener aufgerufen und können mit niedrigeren Ratenbegrenzungen umgehen, während Transaktions-APIs („Bestellung erstellen“, „E-Mail senden“) häufiger aufgerufen werden und höhere Ratenbegrenzungen erfordern. Die Einrichtung von Kategorien oder Ebenen für verschiedene Anwendungsfälle sorgt für zuverlässigere und skalierbarere APIs. Ein Beispiel für klar definierte Ratenbegrenzungen finden Sie in der API-Dokumentation von Slack.

Umfassende Dokumentation

Die Dokumentation dient als Benutzerhandbuch für eine API. Es macht Entwicklern deutlich, was eine API macht, wie man sie benutzt und was man von ihr erwarten kann. Eine gute Dokumentation ist in klarer, zugänglicher Sprache verfasst, detailliert und interaktiv und bietet zahlreiche Demos und Codeausschnitte, um die Integration zu vereinfachen. Auf diese Weise erleichtert es ein einfaches Onboarding und eine schnelle Time to First Hello World (TTFHW), eine wichtige Metrik, die angibt, wie schnell ein Entwickler seine erste API erfolgreich aufrufen kann.

Die Dokumentation sollte eindeutig angeben, welche Felder in der API-Anforderung obligatorisch und welche optional sind, sowie die minimale und maximale Länge und den Datentyp für diese Felder. Im Wesentlichen sollte es alles enthalten, was notwendig ist, um Erwartungen zu wecken und Hindernisse für verbrauchende Entwickler zu beseitigen. Entwickler, die beispielsweise Datenbankschemata in ihren Systemen erstellen, sollten später die Länge von Spalten in Tabellen nicht anpassen müssen, da die Dokumentation die Parameter nicht spezifiziert.

Die API-Dokumentation kann die Akzeptanz steigern, indem sie nicht nur als zuverlässige Referenz für konsumierende Entwickler dient, sondern auch als Marketinginstrument für die API selbst fungiert. Häufig ist die erste Person, die API-Dokumentation zu Gesicht bekommt, ein Stakeholder mit Geschäftskontakt, der sie in den Anfangsphasen der Produktevaluierung durchsucht. Es sollte daher nicht nur Details zu den technischen Elementen der API enthalten, sondern auch die geschäftlichen Anwendungsfälle, die die API ermöglicht, klar artikulieren.

Es gibt eine Reihe von Tools auf dem Markt, die bei der Erstellung einer umfassenden API-Dokumentation helfen können. Es ist auch hilfreich, sich Beispiele für qualitativ hochwertige Dokumentationen wie die von Stripe anzusehen.

Alles zusammenbringen

Integrationen stellen einen riesigen Bereich mit vielen Komponenten dar, aber das Verständnis der Kernprinzipien einer guten API ist grundlegend für die Entwicklung einer soliden Strategie. APIs sind viel, viel mehr als bloße Systemkonnektoren. Sie sind die Bausteine ​​ausgedehnter digitaler Netzwerke und der Schlüssel zur Erschließung neuer Einnahmequellen und zur Freisetzung ungenutzter Werte. Aus diesem Grund geht es bei einer erfolgreichen API-Strategie nicht nur darum, Produkte zu entwickeln; Es geht darum, Potenzial aufzubauen. Ein API-Produktmanager muss eine Plattform-Denkweise annehmen und die Faktoren priorisieren, die eine reibungslose Einführung für die potenziellen Partner ermöglichen, die dann ihre API übernehmen, integrieren und damit ausführen können.