APIs als Produkte: Best Practices für API-Programme

Ob die digitale Transformation eines Unternehmens erfolgreich ist, hängt von dessen Fähigkeit ab, Daten, Dienste und Anwendungen aus ihren Silos zu befreien und sie wiederzuverwenden. Programmierschnittstellen (APIs) werden benötigt, um auf Daten oder Funktionen anderer interner oder externer Anwendungen zuzugreifen, sie zu nutzen und gegebenenfalls mit Daten von Drittanbietern zu kombinieren. Dazu bedarf es einer API-Strategie, die APIs als Produkte behandelt. Dieser Artikel beschreibt die wichtigsten Schritte und Best Practices, um mit der Produktisierung von APIs loszulegen.
Von   Alex Walling   |  Field CTO   |  Rapid
7. Februar 2023

APIs als Produkte definieren

Für viele traditionelle, nicht softwareorientierte Unternehmen sind APIs oft nur ein technisches Werkzeug. Dies ist jedoch eine verkürzte Sichtweise auf APIs und ihren Nutzen. Für eine erfolgreiche digitale Transformation sollten Unternehmen bei der Entwicklung, Bereitstellung und Unterstützung ihrer APIs auf eine produktbezogene Denkweise setzen.

Der erste Schritt zu einer solchen Denkweise ist, Entwickler sowohl als Builder (Anbieter in einer traditionellen Lieferantenbeziehung) als auch als Nutzer (Käufer) zu betrachten. Diese Unterteilung zwingt die API-Entwickler dazu, die Funktion und den Wert ihrer APIs klar zu definieren und dafür zu sorgen, dass die Endanwender leichter verstehen, wie sie von der Nutzung einer bestimmten API profitieren können. Eine klare Formulierung des Werts und der Funktion einer API ermöglicht es dem Builder, aussagekräftigere Dokumentationen zu erstellen und durch konkrete Beschreibungen dafür zu sorgen, dass die API, wenn sie in einem API-Hub veröffentlicht wird, leichter auffindbar ist.

Der nächste Schritt bei der Produktisierung von APIs ist die Erstellung eines Anforderungsdokuments. Dieses Dokument sollte die Ziele des API-Programms definieren und festhalten, was zu ihrem Erreichen notwendig ist. Etwa welche Werkzeuge, was für ein Budget und welches Personal benötigt werden. Ferner sollte die Funktion der einzelnen APIs beschrieben und ihr Wert mit den übergeordneten Unternehmenszielen abgeglichen werden. Neben bereits vorhandenen APIs sollten auch eventuell neu hinzukommende APIs (und der damit verbundenen Personal- beziehungsweise Ressourcenbedarf) aufgeführt werden.

Eine erfolgreiche API-Einführung beginnt bereits in den frühesten Phasen des Entwicklungsprozesses mit dem API-Design. Klare API-Designprinzipien sorgen für ein intuitives und konsistentes Erlebnis, das die Akzeptanz der Programmierschnittstelle fördert.

Für die Produktisierung von APIs ist es wichtig, von den Entwicklern Feedback einzuholen und darauf zu reagieren. So können Fehler und unerwartete Verhaltensweisen entdeckt werden, aber auch neue Funktionen und APIs identifiziert und zeitnah priorisiert werden. APIs als Produkte zu betrachten und entsprechend zu entwickeln, ist eine Sache. Ebenso muss darüber nachgedacht werden, wie APIs im gesamten Unternehmen effektiv zum Einsatz kommen, und welche personellen und technischen Ressourcen dafür erforderlich sind.

Die richtige Organisationsstruktur

Die Verantwortung für die Produktisierung von APIs sollte nicht allein bei den Entwicklern liegen, sondern im gesamten Unternehmen verankert sein. Besonders wichtig ist, wer für das API-Programm letztlich verantwortlich ist. Hier gibt es drei gängige Strukturen: Single Team Ownership, bei der die Verantwortlichkeit für das API-Programm bei einem Team liegt, Cross-Organisational Ownership, bei dem die Verantwortlichkeit organisationsübergreifend geteilt wird und Hybrid Ownership, eine Mischung der beiden Varianten.

Single Team Ownership bietet die größte Autonomie, schafft ein Gefühl der Eigenverantwortung und ermöglicht mehr Experimente. Der Nachteil dieser Struktur ist die Isolation, die die Beteiligung innerhalb des Unternehmens behindert.

Cross-Organisational Ownership fördert die Interoperabilität und erschließt spezialisiertes Fachwissen. Diese Struktur fördert die Investition in den Programmerfolg, ist aber weniger flexibel. Oft bleiben die einzelnen Rollen und Zuständigkeiten unklar, was sich negativ auf die Verantwortlichkeit des API-Programms auswirkt.

Hybrid Ownership bietet die beste Flexibilität und ist effizient im Hinblick auf Entscheidungsfindung und Kaufkraft. Die Kombination beider Eigentumsstrukturen ermöglicht Autonomie und Zusammenarbeit. Allerdings erfordert dieses Modell die klarsten Vorgaben in Bezug auf Entscheidungsfindung und Verantwortung, damit der Entscheidungsprozess nicht leidet.

Kriterien für die Auswahl eines API-Hubs

Ein API-Hub ist ein wichtiges Instrument, um sicherzustellen, dass die Produktisierung der APIs erreicht wird. Es ist ein zentraler Ort, an dem Entwickler Zugriff auf alle verfügbaren APIs haben, diese gemeinsam bearbeiten und nutzen können. Die meisten Unternehmen nutzen in ihrem API-Ökosystem eine Reihe von verschiedenen API-Gateways. Um effektiv zu sein, muss ein API-Hub mit dieser Multi-Gateway-Architektur arbeiten können. Mit einem API-Hub als zentrale Anlaufstelle finden Entwickler schneller die richtigen APIs, was dafür sorgt, dass diese besser angenommen und genutzt werden.

Neben der Zentralisierung und den Suchfunktionen, die die Auffindbarkeit von APIs ermöglichen, sollte ein API-Hub die gesamte Entwicklererfahrung durch integrierte Entwickler-Tools für API-Design und -Entwicklung hin zum Testen und Veröffentlichen unterstützen. Ein breites Spektrum an Funktionen, die direkt in den API-Hub integriert werden, ermöglichen den Entwicklern, nicht so viel zwischen vielen Umgebungen hin- und herzuwechseln. Der Hub sollte die Zusammenarbeit zwischen Entwicklern über den gesamten Entwicklungszyklus hinweg erleichtern und die Verwendung verschiedener API-Typen wie REST, SOAP, GraphQL und Kafka unterstützen.

Eines der wichtigsten Kriterien für die Auswahl eines API-Hubs sind Sicherheit und Governance-Funktionen. Bei Governance und Zugangskontrollen sollte auch darauf geachtet werden, dass den API-Nutzern trotz allem ein einfaches und intuitives Onboarding-Erlebnis geboten wird. Das ist wichtig, um die Akzeptanz zu verbessern. Ferner müssen Governance und Zugangskontrollen für das gesamte API-Ökosystem gewährleistet werden. Für eine effiziente Nutzung sollte es möglich sein, Sichtbarkeit und rollenbasierte Zugriffskontrollen für alle APIs einzurichten, unabhängig von den Gateways, über die sie laufen und klare Einblicke darüber zu erhalten, wer die APIs auf welcher Ebene nutzt.

In Hinblick auf Integrationsmöglichkeiten, sollte ein API-Hub Entwicklern und Architekturteams die Flexibilität bieten, die beste Technologie für ihren Bedarf oder Anwendungsfall zu wählen. Dies erfordert eine offene, entwicklerfreundliche Plattform. Der API-Hub sollte Erweiterbarkeit durch eine Plattform-API, Unterstützung für Webhooks sowie CI/CD-Integrationen bieten und, wie erwähnt, Multi-Gateway-API-Ökosysteme unterstützen.

Go-To-Market und Kommunikationsplan

Die bloße Bereitstellung von APIs ist noch keine Garantie für ihre Akzeptanz. Daher sollte nach der Auswahl des API-Hubs ein Go-To-Market (GTM) Plan ausgearbeitet werden. Eine wichtige Entscheidung hier ist, welche APIs von Anfang an über den Hub verfügbar sind und welche eventuell später noch hinzugefügt werden. Mit einem diskreten Anfangsangebot an APIs ist es einfacher, Nutzungs-Trends zu erkennen und entsprechend das Angebot anzupassen und gegebenenfalls zu erweitern.

Und schließlich ist es wichtig, die gesamte User Journey zu skizzieren. Dies gilt sowohl für API-Builder als auch für API-Nutzer. Mit einer klaren Vorstellung von diesen beiden Zielgruppen lässt sich ein effektiver Kommunikationsplan aufstellen, der die für sie jeweils wichtigsten Aspekte anspricht und klare Anleitungen für die Interaktion mit den APIs im API-Hub bietet. Es ist wichtig, dass dieser Kommunikationsplan sowohl die API-Nutzer als auch die API-Builder berücksichtigt (wobei die Kommunikationsdokumente jeweils getrennt behandelt werden sollten). Für API-Builder sollte der Plan bewährte Verfahren und Methoden für die Kommunikation der Funktionalität und der Vorteile der API enthalten. Die Schaffung dieser Struktur in der Frühphase des Kommunikationsplans stellt sicher, dass alle Beteiligten mit einer gemeinsamen Nomenklatur arbeiten, die klar und verständlich ist.

Evaluierung

Um die Leistung des API-Programms zu erfassen und zu verstehen, wie weit das Unternehmen bei der Produktisierung der APIs vorangeschritten ist, sollten quantitative Metriken festgelegt werden. Häufiger verwendete Metriken in diesem Kontext sind:

  • Total API Call Volume – Bewertung des Wachstums und der Nutzung der API im Laufe der Zeit
  • API Call Volume By Partner – Messung der Verbreitung zur Analyse der Marktdurchdringung
  • Average Daily User Count – Verständnis vom Nutzen und der Wirksamkeit der API
  • Total Number of Users – Messung der Auffindbarkeit und Akzeptanz
  • Total Number of Partners – Indikator für den Grad der Marktakzeptanz
  • Revenue – Analyse der Wirksamkeit des Monetarisierungsmodells

Eine erfolgreiche digitale Transformation hängt davon ab, dass Unternehmen ihre APIs wirksam als Produkte behandeln. Die Einführung dieses produktbezogenen Ansatzes trägt dazu bei, dass APIs angenommen und kontinuierlich genutzt werden, und fördert Ziele wie beschleunigte Innovation, kürzere Markteinführungszeiten und API-gesteuerte Einnahmen. Die im Artikel beschriebenen Best Practices sind eine gute Ausgangsbasis für die API-Produktisierung. Wird diese konsequent umgesetzt, steht einer erfolgreichen digitalen Transformation hoffentlich nichts mehr im Wege.

Alex Walling ist Field CTO beim API-Marktplatzanbieter Rapid. Er begann seine Karriere während seines Informatikstudiums als Mitbegründer von HackCU, einem Hackathon der University of Colorado. Bei Rapid hatte er verschiedene Positionen in den Bereichen Developer Relations und Sales Engineering inne.

Um einen Kommentar zu hinterlassen müssen sie Autor sein, oder mit Ihrem LinkedIn Account eingeloggt sein.

33902

share

Artikel teilen

Top Artikel

Ähnliche Artikel