Seit geraumer Zeit erscheint in Blogposts und auf Konferenzen immer wieder das Thema „API as a Product“. Doch was verbirgt sich konkret dahinter?
Betrachtet man APIs, so steht oftmals die technische Umsetzung im Fokus, wohingegen der Blick auf das Business vernachlässigt wird. Zunehmend werden aber immer mehr Angebote genau in diesem Kontext geschaffen. Wir sollten also dazu übergehen APIs mehr als ein Produkt zu verstehen. Heute benutzen wir diese als Service um einem Nutzer die Möglichkeit zu geben, risiko- und kostenarm auf Core-Ressourcen eines Businesses zugreifen zu können. Diesbezüglich sollten wir eine API auch weniger als reine Codebasis, sondern viel mehr als Teil des Betriebsvermögens ansehen, da wir ja genau mit dieser API entsprechende Betriebswerte generieren.
Integriert man den betriebswirtschaftlichen Aspekt, so sollte man ein paar Terminologien aus diesem Kontext im Zusammenhang mit APIs näher betrachten.
Öffentliche APIs
Als ersten Schritt nehmen wir an, dass wir APIs grundsätzlich so entwickeln als wären diese öffentlich zugänglich, also Public APIs. Durch diese Annahme sind wir schon zu Anfang der Entwicklung gezwungen, darauf zu achten, dass die API für jeden potentiellen Konsumenten durch gute Konzeption, Implementierung und Dokumentation einfach zu verstehen und anzuwenden sind.
Die Rolle des Konsumenten im API-Umfeld
Wir haben es hier mit zwei Arten von Konsumenten zu tun, dem internen und dem externen. Der externe Konsument ist jemand außerhalb des eigentlichen Businesses. Es kann ein konkreter Nutzer oder ein Anbieter eines anderen Services sein. Der interne Konsument ist Teil des Businesses. Für beide Konsumentenarten gilt, dass es sich in der Regel um Entwickler handelt. Aus betriebswirtschaftlicher Sicht steckt hinter jeder Transaktion, ob nach innen oder außen, ein entsprechender Wert. Somit ist die API als Teil der Wertschöpfungskette anzusehen.
Entwicklung
Nachdem wir uns mit den Konsumenten beschäftigt haben, sollten wir uns der Entwicklung eines API-Produkts zuwenden. Entwicklung ist grundsätzlich ein Prozess, der Kosten verursacht und daher ein Investment darstellt. Diesem Umstand sollte man sich bei der Betrachtung von APIs im Sinne eines Produkts bewusst sein. Bevor es an die konkrete Umsetzung geht, wird ein MVP (Minimal Viable Product) für das API-Produkt definiert. Dazu gehört dann auch eine Roadmap, um zu garantieren, dass die Konsumenten genau das bekommen, was diese wirklich benötigen. Durch diese Limitierung innerhalb der Entwicklung verhindern wir die Umsetzung von nicht benötigten Features, wie z.B. ungenutzten Endpoints. Potentielle Sicherheitslücken werden so reduziert.
Unveränderlichkeit
Was man bei der Entwicklung einer API auf keinen Fall außer Acht lassen sollte, ist die Unveränderlichkeit eben dieser. Im Sinne des Produktgedanken bedeutet dies, dass entsprechende Änderungen abwärtskompatibel sein müssen, da sonst Investitionen in das Produkt nicht sinnvoll sind.
Messbarkeit
Nachdem wir nun ein API-Produkt entwickelt haben und dieses den Konsumenten zur Verfügung gestellt wurde, kommt schnell die Frage nach dem Wert des Produkts auf. Hier gilt es nun die Nutzung des Produkts entsprechend zu messen bzw. messbar zu machen. So kann auch einem nicht technischen Publikum der Geschäftswert eines API-Produkts näher gebracht werden. Für dieses Publikum ist aber die Anzahl der APIs innerhalb des Produkts nicht entscheidend.
Hier einige Fragen für die Entwicklung potentieller Messgrößen:
- Wie lange dauert es, sich für die Benutzung der API zu registrieren?
- Nach welcher Zeit erhält der User den ersten 200er Response von der API?
- Wie oft wurde die API über soziale Netzwerke hinweg geteilt?
Ein weiterer wichtiger Aspekt der Messbarkeit liegt in der kontinuierlichen Beeinflussbarkeit der Roadmap, dadurch dass wir hier nun über eine direkte Feedback-Schleife zum Konsumenten verfügen.
Verfügbarkeit und Bekanntmachung
Um ein API-Produkt den Konsumenten verfügbar und bekannt zu machen wird häufig ein Developer Portal verwendet. Über dieses Portal werden die Konsumenten in die Lage versetzt die angebotene API selbstständig kennenzulernen und zu benutzen.
Sicherheit
Für API-Produkte ist auch Sicherheit ein wichtiger Faktor. Sie sollten daher durch OAuth, API Key Verification, XML/JSON Threat Protection und allgemeine Sicherheitsmechanismen geschützt sein.
Fazit
Um eine API als Produkt innerhalb der Digitalen Transformation eines Business zu etablieren, müssen wir bei der Umsetzung die genannten Punkte im Blick haben. Das Produkt sorgt schließlich dafür, dass Applikationen und Systeme von überall und zu jeder Zeit miteinander verbunden werden können.
In einem folgendem Blogpost, der im Laufe des Novembers erscheinen wird, wollen wir einen erneuten Blick auf das API-Gateway Kong werfen, um festzustellen wie uns dieses bei der Umsetzung einer „API as a Product“-Strategie unterstützen kann.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Daniel Kocot
20.11.2024 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Daniel Kocot
Senior Solution Architect / Head of API Consulting
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.