[über]
[lösungen]
[log]
Nichts Passendes dabei? Stellen Sie ein, welche Inhalte Sie auf aleri.de sehen möchten:
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.
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..
Gemäß der 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:
- 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.
- 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.