Strategie

API-Governance

API-Governance

Zum vorläufigen Abschluss der API-Economy-Serie wird auf die strategische Ebene des API-Managements eingegangen: API-Governance. Auf dieser Ebene wird in erster Linie die Service-Landschaft erstellt und verwaltet. Die permanente Analyse definierter Kennzahlen erlaubt es Schwächen bzw. Stärken des eigenen Service-Portfolios zu identifizieren und daraus geeignete Angebote und Preismodelle zu gestalten.

Die Optimierung des Service-Portfolios obliegt in erster Linie der Fachseite des Unternehmens. Diese sollte die Bedürfnisse der Kunden bzw. die Anforderungen des Marktes kennen und daraus entsprechende Handlungen ableiten. Dabei sind bereits bestehende Services ebenso in die Überlegungen einzubeziehen, wie Rückmeldungen zu Kennzahlen (KPI) aus dem Bereich API-Management. Die Verantwortung der Fachseite ist also nicht auf den Bereich API-Governance begrenzt, sondern reicht darüber hinaus.

Disziplin API-Governance im Kontext

Disziplin API-Governance im Kontext

API-Governance identifiziert Datenquellen und -senken und leitet daraus sinnvolle Ergänzungen des Portfolios ab. Sie initiiert auch die Terminierung von Angeboten, wenn diese aufgrund strategischer Überlegungen oder mangelnder Performanz nicht mehr sinnvoll betrieben werden können. Die Durchführung liegt jedoch in der Verantwortung des API-Management und richtet sich nach dem vereinbarten API Lifecycle Management.

Nach der Identifikation notwendiger Daten stehen Entscheidungen an, ob diese durch Eigenentwicklung erzeugt oder durch Zukauf gewonnen werden (“Make-or-Buy”). Gleiches gilt für die Vermarktung von Diensten, die entweder in Eigeninitiative, über öffentliche Marktplätze (“API Marketplace”) oder über Zwischenhändler (nach Art eines Halberzeugnisses) erfolgen kann.

Für eine ausreichende Monetarisierung sind Kennzahlen des Einkaufs, der Entwicklungs- oder Betriebskosten sowie der API-Performanz zu ermitteln und in Dashboards aufzubereiten. Basierend auf diesen Informationen geschieht die Modellierung zu Produkten (Applications oder Bundles) und Preismodellen (Subscriptions)

Auch rechtliche Fragen fallen in den Bereich der API-Governance, besonders der Datenschutz und die daraus resultierenden Anforderungen an die Anonymisierung und Speicherung von Daten. Besonders deutlich wird dies bei der jüngst erfolgten Anwendung der Datenschutzgrundverordnung (DSGVO). Für den Umgang mit personenbezogenen Daten sind die Datenschutzgrundverordnung und die Konsequenzen des §203 StGB zu beachten.

Betrachtet man API-Governance unter dem Aspekt Projekt-Management-Methoden, sind ein Programm-Manager bzw. ein oder mehrere Product Owner mit fachlicher Pflege und Weiterentwicklung der Service-Landschaft betreut.

Portfolio-Management

Als Portfolio wird im Allgemeinen eine Sammlung artverwandter Dokumente oder im - übertragenen Sinne - Objekte bezeichnet. Auch im IT-Kontext wird Portfolio als “Sammelmappe” für ähnliche Artefakte verwendet, oftmals unterteilt in IT-Anwendungsportfolio (Systeme und Programme) und IT-Projektportfolio. Das Service-Portfolio der API-Economy ist ein Anwendungsportfolio, denn es beinhaltet nur APIs, die bereits entwickelt sind. Dazu werden über geeignete Verfahren und mit Hilfe von API-Management-Lösungen die angebotenen und genutzten Services erfasst und analysiert, unabhängig davon, ob das eigene Unternehmen sie anbietet oder sie von Dritten bereitgestellt werden.

Das Ziel ist der Aufbau eines Service-Katalogs, um Lücken bzw. Duplikate im eigenen Angebot zu erkennen und die Mehrfachnutzung ähnlicher, externer Services zu reduzieren. Lücken werden im Anschluss durch Zukauf oder eigene Umsetzungsprojekte geschlossen, Redundanzen durch Service-Konsolidierung und Service-Terminierung im Rahmen des API-Lifecycle-Managements abgebaut.

Service-Bedarf identifizieren

Die Service-Landschaft richtet sich stets nach den fachlichen Anforderungen des Marktes, wird aber in ihrer Umsetzung durch technische Anforderungen und Einschränkungen (Constraints) beeinflusst.

Zur Identifikation notwendiger Schnittstellen (APIs) gibt es mehrere, ergänzende Ansätze:

Orientierung am Bedarf

Wie jedes Wirtschaftssystem verfügt auch eine API-Economy über Märkte sowie gesellschaftliche und organisatorische Rahmenbedingungen. Die Akteure der API-Economy richten ihre Tätigkeit am Geschäftswert aus und konzentrieren sich hierfür auf die Erfüllung (oder Erschaffung) des Bedarfs.

Bedarf für eine neue API bzw. einen neuen Service kann grundsätzlich aus zwei verschiedenen Quellen stammen:

  • Die Fachseite hat Bedarf für ein neues Service-Angebot bzw. es existiert eine entsprechende Erwartung im Markt. Dies ist der (zu fördernde) Idealfall, denn so existiert ein fachlich Verantwortlicher, der neben einer konkreten Erwartung hoffentlich auch Budget beisteuert.
  • Die IT hat Bedarf für neue Services identifiziert, um fachliche Bedürfnisse besser befriedigen zu können oder mit technischen Änderungen umzugehen. Auch wenn dies kein unüblicher Fall ist, braucht er doch eine intensivere Beobachtung, damit nicht Services um der Technik willen entstehen.

In jedem Falle ist es wichtig, den Bedürftigen und seine Motivation genau zu verstehen, bevor mit der Spezifikation oder gar Umsetzung begonnen wird. Ein Service muss immer einen Zweck haben, immer einen Bedarf bedienen und damit eine Legitimation haben. Oftmals entsteht der Wunsch nach einem neuen Service aus Unkenntnis über die bestehende Service-Landschaft, was ein deutlicher Indikator für fehlende Governance ist. Wenn APIs oder deren Umfang nicht bekannt sind, besteht hier dringender Verbesserungsbedarf, z.B. durch konsequente Katalogisierung und Vermarktung existierender Services.

Orientierung an fachlichen Entitäten

Aktuelle Paradigmen der Schnittstellenentwicklung wie REST oder GraphQL gehen von einem ressourcenorientieren Ansatz aus, d.h. für die im Zugriff befindlichen Entitäten werden ein oder mehrere entsprechende Services zur Verfügung gestellt. Im Minimum bietet jede Service-API dabei Operationen zur Anlage, Abfrage, Änderung und Löschung der entsprechenden Entität (CRUD: Create, Read, Update, Delete). Dazu gesellen sich in der Regel noch entsprechende Such- und Filteroperationen.

Sofern das Unternehmen nicht einen völlig neuen Markt definiert, sollten sich die notwendigen Entitäten bereits im fachlichen Domänenmodell wiederfinden oder aus benachbarten Modellen ableiten lassen. Vielfach existieren auch bereits entsprechende Beschreibungen in Branchenverbänden wie BiPRO e.V..

Entitäten-Modell

Entitäten-Modell

Gemäß obiger Abbildung wären folgende APIs eine direkte Folge des fachlichen Entitäten-Modells:

  • Anbieter API
  • Kunden API
  • Produkt API
  • Vertrag API

Die Vertrag API stellt dabei das Bindeglied zwischen dem Anbieter und seinen Kunden dar, denn eine Geschäftsbeziehung kommt über einen (Kauf- bzw. Miet-) Vertrag zustande. Dabei werden dem Vertrag bei seiner Anlage via API Referenzen zu Anbieter, Kunde und Produkt mitgegeben.

Orientierung an Prozessen

Der geforderte ressourcenorientiere Ansatz findet sich in der Regel nicht in allen (gelebten) Prozessen wieder. Üblicherweise gibt es übergreifende Prozesse, die keinen direkten Bezug zu fachlichen Entitäten haben, aber aus Prozesssicht dennoch notwendig sind. Dazu gehören z.B.:

  • Registrierung und Anmeldung
  • Zahlungsvorgänge
  • Nachrichtentransfer
  • Dokumentenmanagement

Vereinzelt kann es notwendig sein, für die fachlich sekundären Daten in diesen Prozessen eigene APIs zur Verfügung zu stellen. Dabei ist Fingerspitzengefühl notwendig, um nicht versehentlich bereits im Unternehmen bestehende Systeme in ihrer Funktionalität zu kopieren. Ist bereits ein Dokumentenmanagementsystem (DMS) vorhanden, so muss dieses System die primäre Verwaltungsinstanz für Dokumente sein. Eine eventuelle Dokument API aggregiert in diesem Fall (nach Art einer Fassade) die vorhandenen Operationen des DMS und orchestriert sie im Hinblick auf die fachlichen Prozesse.

Orientierung an Navigationspfaden

Bei der Bestimmung der Notwendigkeit für eine API ist es hilfreich sich mit der Erreichbarkeit von Entitäten zu beschäftigten. Dabei kann man zwischen zwei Fällen unterscheiden:

  1. Direkt erreichbar: Eine Entität wird durch fachliche Prozesse direkt angesprochen. Dies ist z.B. bei der Suche, Anlage oder Änderung von Kunden der Fall.
  2. Indirekt erreichbar: Eine Entität hat eine logische Abhängigkeit zu einer anderen Entität und wird üblicherweise nicht alleinstehend betrachtet. Für solche Entitäten ist in der Regel keine eigene API notwendig, da für sie eine Anlage, Änderung oder Abfrage nur im Rahmen anderer Entitäten erfolgt. Ein gutes Beispiel hierfür ist die Adresse bzw. Anschrift eines Kunden. Solange nicht ohne Kundenbezug nach Adressen gesucht oder diese erzeugt werden sollen, bedarf es keiner eigenen API.

Service Performance überwachen

Services und deren APIs bedienen einen Bedarf und die Deckung dieses Bedarfs kann unter dem Stichwort “Performance” zusammengefasst werden. Es ist Teil der API-Governance, die Performanz zu analysieren und ggfs. korrigierende Maßnahmen einzuleiten.

Basis der Analysen sind Key-Performance-Indicator (KPI), die im Bereich API-Governance definiert und durch das (tool-basierte) API-Management erfasst werden. Sie grenzen sich von technischen KPIs (Durchsatz, Latenz, Dauer etc.) durch ihren fachlichen Charakter ab und sind durchaus schwierig zu ermitteln. Darum sind die Einträge der folgenden Liste beispielhaft und als Anregung zu verstehen.

Umsatz und Ertrag

Bei kostenpflichtigen APIs muss sich der Preis zur Nutzung an den Kosten für die Entwicklung und den Betrieb orientieren. Eine (vorübergehende) Defizit-Lösung für den Markteintritt ist eine erlaubte Abweichung.

Bleibt der Ertrag nach Bereitstellung hinter den Erwartungen zurück, so kann dies mehrere Ursachen haben:

  • Die API bedient keinen Bedarf und wird entsprechend nicht genutzt. Offenbar ist in der Anforderungsanalyse von falschen Voraussetzungen ausgegangen worden oder im Projektverlauf hat sich der Fokus der API in eine falsche Richtung verschoben. Natürlich kann sich auch das Marktumfeld geändert haben, beispielsweise wenn ein Mitbewerber den Bedarf schneller bedienen konnte.
  • Die Nutzung der API ist zu teuer. Die Marktteilnehmer sind nicht bereit, den geforderten Preis zu zahlen und verzichten auf die Nutzung. Abhilfe kann ein geändertes Preismodell sein, eine Kostensenkung oder einer Aufspaltung des Service in kleinere Einheiten, um eine dedizierte Teilnutzung zu unterstützen.
  • Die technische Performanz der Schnittstelle ist mangelhaft, daher sind die Konsumenten nicht in der Lage, die beworbene Leistung in ausreichender Menge abzurufen. In diesem Falle sollte sich die Schwachstelle durch Analyse anderer KPIs ermitteln lassen.

Anfragehäufigkeit und Antwortgröße

Kommt es zu häufiger Anfrage einer API, deren Antwort üblicherweise sehr umfangreich ist, kann dies ein Indikator für einen zu generischen Service sein. Umfangreiche Antworten sollten Anfragen nach Detailinformationen vorbehalten sein, die wiederum seltener als allg. Anfragen vorkommen sollten. Ist dem nicht so, kann dies auf folgende Missstände hinweisen:

  • Der Service ist in seinem Angebot zu weit gefasst. Er bedient eine Menge von Anfragen, weil er über Entitäten- und Domänengrenzen hinweg agiert. Als Folge wird er zentraler Einsprungspunkt für eine Vielzahl von Consumern, die nicht oder nur sekundär seinen Funktionsumfang benötigen.
  • Es existiert kein alternativer Service, der Teile der Antwort bereitstellt. Erläutert werden kann dies am Beispiel einer Altersverifikation. Existiert kein entsprechender Service, der z.B. Kundennummer und gegebenes Geburtsdatum akzeptiert, werden Consumer gezwungen, (umfangreiche) Kundendaten abzurufen und die Altersverifikation selbst zu implementieren.

Anfragedauer und Systemlast

Die Behandlung jeder Anfrage an eine Schnittstelle führt unweigerlich zu Erzeugung von Systemlast (auch wenn diese immer häufiger an den Cloud-Anbieter delegiert wird). Die Systemlast und andere Faktoren haben ihrerseits Auswirkungen auf die Anfragedauer, da belastete System länger für die Abarbeitung der Anfrage benötigen. Hinweise auf diesen Umstand sind entsprechend im System-Monitoring zu finden, insbesondere der Load-Indikator diverser Betriebssysteme ist dabei von Interesse. Einer hohen Last kann durch Skalierung begegnet werden, wobei im Kontext von Microservices die horizontale Skalierung – also zusätzliche, verteilte Instanzen - bevorzugt wird.

Doch auch bei niedriger Systemlast kann es zu einer verzögerten Auslieferung der Antwort kommen, insbesondere, wenn der Service hinter der API seinerseits andere Services nutzt (“orchestriert”) oder auf Antwort von Drittsystemen warten muss. In diesem Falle kommt es zu einer Latenz, d.h. es vergeht eine gewisse Zeit, bis die Antwort an den Empfänger abgesendet wird. Dieser ungewollten Abhängigkeit von anderen Services kann man im Rahmen einer Enterprise-Architektur oder durch Prüfpunkte in der Service-Implementierung auf die Schliche kommen. Als Gegenmaßnahmen eignen sich primär die Entkopplung von Services oder – falls dies nicht möglich ist – das Einziehen eines selektiven Zwischenspeichers (Cache).

Und nicht zuletzt müssen sowohl Anfrage als auch Antwort über ein Netzwerk transportiert werden, wobei an verschiedenen Stellen Engpässe entstehen können, die negative Auswirkung auf das Service-Verhalten haben und evtl. vereinbarte Service Level Agreements (SLA) gefährden können. In diesem Falle steht eine geringe Latenz einem insgesamt ungenügenden Antwortverhalten entgegen. Nach Ermittlung der Engstelle müssen – sofern möglich – entsprechende Gegenmaßnahmen auf Infrastrukturebene eingeleitet werden.

Geschäfts- und Abrechnungsmodelle

Die Services als Teilnehmer einer API-Economy decken einen oder mehrere Business Cases ab. John Musser, Gründer und Autor von The ProgrammableWeb, eines API-zentrischen Nachrichtenportals hat über mehrere Jahre die Geschäftsmodelle im Bereich APIs gesammelt und schematisch aufgearbeitet.

John Musser, API Business Models, 2013

John Musser, API Business Models, 2013

Seine aktuell über 20 Varianten lassen sich in 4 Gruppen zusammenfassen:

  1. Free: Sowohl der Anbieter eines Service (Provider) als auch der Entwickler des Consumers verzichten auf die Erhebung von Erwerbs- oder Nutzungsgebühren. Sowohl die Verwendung des Service als auch der zugehörigen Anwendung (“App”) ist für den Kunden damit (vordergründig) kostenfrei. Grund für diesen Business-Case kann der Eintritt in einen Markt oder die Verdrängung von Markbegleitern sein. Natürlich gibt es auch für dieses Geschäftsmodell Einnahmemöglichkeiten, entweder durch die Platzierung von Werbung oder die Gewinnung und Verkauf von Benutzerdaten.
  2. Developer Pays: Service- und Consumer-Entwicklern werden die Nutzung einer Service-Leistung in Rechnung gestellt. Die Re-Finanzierung fällt in den Verantwortungsbereich des Entwicklers. Um die Kosten im Griff zu halten, werden die abgerufenen Leistungen ressourcen-genau und ad-hoc, d.h. ohne vorherigen Abschluss eines Abonnements abgerufen. Weiterhin können Grenzwerte definiert werden, um einem ausufernden Abruf von Leistungen zu begegnen. Dieses Geschäftsmodell findet sich im as-a-Service-Umfeld, besonders in den Bereichen Infrastructure-as-a-Service und Platform-as-a-Service.
  3. Developer Gets Paid: Die Anbieter eines Service bezahlen die Entwickler von nutzenden Services oder Consumer-Anwendungen für die Bereitstellung. Sie vergüten dabei den Zugang und die Vermarktung ihres eigenen Produktes durch Dritte. Neben Pauschalbeträgen kommt dabei häufig auch eine Beteiligung an generierten Umsätzen zum Einsatz, so wie es aus zahlreichen Affiliate-Programmen bekannt ist.
  4. Indirect: Ein Anbieter stellt seine Schnittstelle(n) als Teil eines (kostenpflichtigen) Produktes quasi als Mehrwert zur Verfügung. Er verwendet die somit oft ohnehin vorhandene API als “Benefit” für ein vermarktetes Produkt. Die Nutzung der API scheint damit kostenlos, aber natürlich erfolgt eine indirekte Bezahlung durch die oftmals höheren Lizenz-Gebühren des Produkt-Upgrades.

In letzter Konsequenz basieren alle Modelle auf bekannten Abrechnungsmodellen, die auch in anderen Bereichen (z.B. Mobilfunkverträge) zum Einsatz kommen.

Pre-Paid

Wie bei Telefonverträgen können dabei Zeiten für die Nutzung (z.B. 1 Monat), Volumina (z.B. 1000 Abrufe) oder Mischformen (z.B. 1000 Abrufe pro Monat) angeboten werden. Je nach den Möglichkeiten der eingesetzten Produkte, besonders des API Gateways kann danach ein harter “Cut” oder eine Drosselung bzw. Verringerung der Service-Qualität erfolgen.

Post-Paid

Post-Paid ist das vielleicht einfachste Abrechnungsformat und aus vielen Verträgen mit Energieversorgern, Versicherungen etc. bekannt. Der Nutzer (Konsument) hinterlegt eine Zahlungsmöglichkeit, die am Ende einer Zahlungsperiode belastet wird oder erhält über die aufgelaufenen Kosten eine Rechnung mit Zahlungsaufforderung.

Um der Gefahr einer unkalkulierbaren finanziellen Belastung zu begegnen, können Schwellwerte definiert werden, die bei Überschreitung zu einer Warnung (“soft limit”) bzw. bei Erreichung zu einer Nutzungsunterbrechung führen (“hard limit”). Allerdings muss in diesem Falle auch die Möglichkeit einer (automatisierten) temporären Erhöhung der Grenzwerte möglich sein, etwa um Lastspitzen im Weihnachtsgeschäft abzufangen.

Freemium

Natürlich können Services auch kostenlos angeboten werden, um Zugang zu einem Markt zu bekommen, der aufgrund von Wettbewerbsdichte oder Historie nur schwer zu erreichen ist. Im Rahmen eines “Freemium”-Modells können Basis-Services (Free) ohne Zahlungszwang angeboten werden, wobei darauf aufbauende Mehrwert-Dienste (Premium) kostenpflichtig bleiben.

Zur Unterteilung in “Free” und “Premium” eignen sich im Wesentlichen zwei Aspekte:

  • Datenumfang: Beispielhaft sei hier eine Wettervorhersage genannt, deren kostenlose Variante grundsätzlich das Wetter für den heutigen Tag prognostiziert (Temperatur, Regenwahrscheinlichkeit). In seiner kostenpflichtigen Version wird eine Vorhersage für kommende Tage angeboten, außerdem ist die Menge gelieferter Informationen höher (z.B. Luftdruck, Windgeschwindigkeit, etc.)
  • Datenqualität: Dieses Modell ist für Anbieter mit großem Datenbestand interessant und basiert auf einer zunehmenden Konkretisierung von Informationen.

So kann ein Versicherungskonzern ausgehend von den Policen abgeschlossener Versicherungen Rückschlüsse auf das Einkommen in abgedeckten Gebieten ziehen (z.B. aus Hausrat-, Gebäude und Kfz-Versicherungen). Die Basis-Variante der angebotenen Statistik-API stellt diese Daten genereller (z.B. niedriges Einkommen, mittel, hoch) oder gröber (z.B. im Radius von 5km um gegebene Postleitzahl) zur Verfügung. Die Premium-Version des Service liefert feingranulare Informationen zu geschätztem Einkommen und Verteilung, bis zum durch den Datenschutz definierten Maximum.

Fazit

Im Rahmen der API-Governance wird die Strategie einer API-Economy festgelegt, überwacht und kontinuierlich angepasst. API-Governance beschreibt die Richtung, in die das Portfolio der eigenen API Economy optimiert wird. Außerdem definiert sie die funktionalen Rahmenbedingungen, die bei der Nutzung der APIs durch interne oder externe Consumer einzuhalten sind.

Unterstützt durch die Disziplin des operativen API-Managements werden definierte Kennzahlen (KPI) mit Werten belegt und zur Adaption der Strategie im Hinblick auf eine marktgerechte Aufstellung des eigenen Angebotes herangezogen.


Das Aufmacher-Bild zum Artikel stammt von Dylan Gillis auf Unsplash