von
APIs werden vorrangig dazu verwendet, um die Geschäftsfähigkeiten einer Organisation zu bündeln und für andere (Teams oder Organisationen) verfügbar und damit nutzbar zu machen. Dabei werden häufig
- Datenschätze aus sonst schwer zugänglichen Bereichen eines Rechenzentrums gehoben (API-fizierung),
- in sinnvoller Weise gefiltert (passend zu dem Rechte- und Rollenkonzept), aufbereitet und/oder verdelt,
- und in standardisierter Form (Protokoll, Taxonomie / Datenmodell, Vereinbarungen)
- als Produkt angeboten, welches dann in den wichtigen Ökosystemen platziert wird.
Man spricht deswegen auch von einer „API-as-a-Product Strategie“.
Produkt-Gedanke hinter APIs
"Product orientation is the missing ingredient that makes the difference between ordinary enterprise integration and an agile business built on a platform of APIs.”
aus https://www.thoughtworks.com/radar/techniques/apis-as-a-product
Die Produkt-Denke zieht auch insbesondere in die Teams ein, die die APIs und die dahinter liegenden Services anbieten: das Produkt-Team ist meist cross-funktional aufgestellt und "kümmert" sich um das Produkt, d.h. der Erfolg des Produktes steht im Fokus aller Beteiligten, und dieser Erfolg wird durch Monitoring- und Analysewerkzeuge stets im Auge behalten. So kann das Produkt-Team quantitativ und qualitativ feststellen, ob z.B. die letzten Änderungen am Produkt gefruchtet haben oder nicht und ggf. nachbessern.
Einbettung in Ökosysteme
Die Art und Weise, wie eine API als Produkt behandelt wird, unterscheidet sich in der Regel je nach Art des Ökosystems allerdings sehr stark, und die Anzahl der Ökosysteme ist häufig abhängig von der Größe und den technischen Anwendungsgebieten einer Organisation.
Wir unterscheiden dabei folgende Ökosysteme:
Je nach Ökosystem gelten für gleich klingende Aufgabenstellungen jeweils andere Spielregeln.
Zum Beispiel weist ein API-Katalog im internen Ökosystem eher Charakteristiken eines „Developer Portals“ oder „Katalogs“ auf, während man im B2B-Bereich eher die Funktionalität eines „Shops“ oder "Marketplaces" benötigt und ggf. auch Vertrags- und Monetarisierungs-Prozessen einen wichtigen Stellenwert gibt.
Im Gegensatz zu internen Ökosystemen, wo man Autonomie und Selfservices benötigt, spielen hingegen im B2B-Partner Ökosystem menschliche Beratungstätigkeiten (z.B. Partner Onboarding, Enablement und Vertragsmanagement) und zentrale Governance-Aspekte eine wichtigere Rolle.
Der Kontext ist entscheidend - was gut in einem Ökosystem funktioniert, richtet in einem anderen Ökosystem unter Umständen sogar Schaden an (man denke z.B. an einen aufwändigen, manuellen Onboarding-Prozess von internen Consumern, das würde einige von der Nutzung abhalten/abschrecken, was entgegen den mit der internen API verbundenen Zielen wäre).
Wie geht es weiter? - To be continued…
Im nächsten Artikel knüpfen wir nahtlos an das Thema an, und beschäftigen uns näher mit den einzelnen Bestandteilen von API-basierten Produkten.