Der Begriff “API-Economy” beschreibt die Entwicklung, Bereitstellung und Vermarktung von Services und Daten zur (kostenpflichtigen) Nutzung durch Dritte. Die Idee einer API-Economy ist weder neu noch innovativ, sie ist vielmehr evolutionär und wird begünstigt durch die fortschreitende technische Entwicklung sowie den Gedanken der Share Economy. In letzterer liegt der Fokus nicht mehr auf Eigentum, sondern auf der bedarfsgerechten Bereitstellung und Buchung von Ressourcen.

Für eine erfolgreichen API-Economy müssen mehrere Disziplinen bedient werden, zwischen denen eine starke Interaktion stattfindet und deren Wirkungsbereiche sich teilweise überschneiden:

• API-Governance bedient den strategischen Aspekt. Hier finden die Steuerung und Analyse der eigenen API-Economy statt, basierend auf spezifischen KPIs.
• API-Design bedient den architektonischen Aspekt. Hier werden die Grundsteine zur Realisierung der API-Economy gelegt, ausgerichtet auf die strategischen Ziele und die operativen Vorgaben.
• API-Development beschäftigt sich mit der Umsetzung. Basierend auf den Vorgaben und Anregungen des API-Designs und im Einklang mit aktuellen Trends und Best Practises findet hier die Implementierung statt.
• API-Management beschreibt den operativen Teil einer API-Economy. Er wendet Techniken und Werkzeuge zur Verwaltung des API-Lifecycles an und liefert Zahlen zu definierten KPIs an API-Governance.

Motivation

Die Motivation, sich mit dem Thema API-Economy auseinanderzusetzen, ist so vielfältig, wie ihre Anwendungszwecke selbst. Der klassische Treiber, die “Make-Or-Buy”-Entscheidung, gehört sowohl dazu als auch das Partizipieren an offenen Standards, um Mehrwert in bestehenden Ökosystemen anzubieten. Auch äußere Faktoren wie Gesetze oder Regeln des (internationalen) Handels stellen einen Motivator dar.

Im Folgenden wird exemplarisch dargelegt, welche Impulse oder Vorgaben für die API-Economy relevant sind.

Monetarisierung

Selbstverständlich ist in einer API-Economy der Profit die treibende Kraft. Wie bereits erwähnt besteht das primäre Ziel in der Monetarisierung bereits (intern) vorhandener Services und Daten. Es gilt, diese “Assets” des eigenen Unternehmens neu zu bewerten und den Markt bzw. die Adressaten für die Verwendung weiter zu definieren.

Grundsätzlich folgt jedes Unternehmen der Philosophie, in seinem Leistungsspektrum entsprechend der gesetzten Rahmenparameter - der sogenannten Domäne - ein Alleinstellungsmerkmal für den Verkauf zu haben. Doch in einer API-Economy muss dieser Unique Selling Point (USP) nicht notwendigerweise ausschließlich aus eigener Kraft erwirkt werden.

Eine Versicherung, die z.B. über Gebäudehaftpflicht-, Kfz- und Hausratversicherungen Rückschlüsse auf das Einkommensniveau bestimmter Stadtgebiete ziehen kann, mag diese Daten aktuell intern verwenden, um ihre Marketingkampagnen zu optimieren. Doch – ausreichend anonymisiert und in ihrer Genauigkeit abgeschwächt – können die gewonnenen Informationen auch für andere Unternehmen von Interesse sein und sei es nur aus statistischer Neugierde. Die Versicherung kann also als Anbieter fungieren und den Abruf von Daten monetarisieren, ohne ihren strategischen Vorteil aufzugeben.

Im Einzelfall betrachtet kann die Beschaffung von Daten über eine externe API günstiger sein als die Gewinnung und Bereitstellung eigener Daten. Der Versicherer kauft in einer API-Economy “Halberzeugnisse” ein, um damit sein (digitales) Portfolio zu erweitern und einen USP in seine Produktpalette einzubringen.

Gesetzgebung

Der Gesetzgeber (nicht nur in Deutschland) hat den Wert von Daten und die Notwendigkeit abgestimmter, technischer Schnittstellen bereits vor langer Zeit erkannt. Für eigene Zwecke fordert er daher von bestimmten Partnern und Instituten Zugriffsmöglichkeit auf die dort gespeicherten Vorgänge.

Besonders der Bereich Finanzen und Steuern räumt sich ein großzügiges Recht auf die Kontoinformationen seiner Bürger ein, natürlich nur um Steuersündern oder Terrorismus-Finanzierern auf die Schliche zu kommen. Im Gegenzug kann der Steuerpflichtige den Vorgang der Einkommensteuererklärung über “Elster” bzw. die vorausgefüllte Steuererklärung und den Belegabruf beschleunigen. Ein schönes Beispiel, wie ein “Geschäftsmodell” basierend auf den Daten Dritter entwickelt werden kann.

Zusätzlich zu der Digitalisierung der eigenen Schnittstellen fordern die Gesetzgeber national und auf internationaler Ebene öffentliche Schnittstellen in bestimmten Bereichen an. Ein sehr gutes Beispiel hierfür ist die Payment Services Directive 2 (PSD2) aus dem Jahre 2015. Auf europäischer Ebene wurden damit Banken verpflichtet, binnen 2 Jahren Schnittstellen für Finanzdienstleister bereitzustellen (Sharafshahi, 2015). Seitdem hat sich ein florierender Markt für sog. FinTechs entwickelt, die ohne eigene Banklizenz Finanzprodukte und -dienstleistungen basierend auf den Banking-APIs klassischer Banken anbieten. In einen ähnlichen Kontext, wenn auch ohne Bezug zum freien Markt ist die automatische Übertragung von Informationen durch Banken an die Finanzbehörden zu sehen.

Dieser gesetzlich geforderte bzw. geförderte Wandel stellt an dieser Stelle nicht nur ein Umdenken bei der Implementierung von Verfahren oder Anwendungen dar. Grundsätzlich ermöglicht dieses System einen modularen Baukasten an Schnittstellen und damit verbundenen Diensten, die untereinander wiederverwendet werden können.

Transparenz

IT-Organisationen sind historisch gewachsen, ebenso die IT-Architekturen und folglich die damit verbundenen Schnittstellen. Vielfach fehlt durch die Historie eine Übersicht über verfügbare Schnittstellen und Services, sodass teilweise mehrfach redundante Services und deren Schnittstellen vorhanden sind. Bei dem Versuch einer Systemablösung oder dem Wechsel auf eine andere Lösung treten häufig unbeliebte Nebeneffekte auf, wie Systemausfälle durch sogenannte Schattennutzung von Services. Wird die Betrachtung noch um Service Level Agreements (SLA) ergänzt, die häufig die Verträge zwischen Systemen und Konsumenten abbilden, wird eine mehrdimensionale Abhängigkeit bei Services schnell deutlich.

Um die damit verbundene Komplexität zu managen, ist es unabdingbar, Transparenz zu schaffen über den Service- und Schnittstellenkatalog, so dass mindestens zu jedem Service und jeder damit verbundenen Schnittelle eingehende und ausgehende Abhängigkeiten mit entsprechenden Verfügbarkeitsanforderungen dokumentiert sind. Für den Aufbau eines solchen Katalogs in einer diversifizierten IT-Landschaft gibt es verschiedene Ansätze, wobei es keinen “One-Size-Fits-All”-Weg gibt. Dennoch sei an dieser Stelle der Hinweis erlaubt, dass eine “Big-Bang”- Einführung eines entsprechenden Katalogs mit sehr vielen “Schmerzen” verbunden ist und davon dringend abgeraten wird.

Einhergehend mit dem Schaffen von Transparenz wächst die Anforderung, zu prüfen, wer die eigenen Schnittstellen nutzt (“konsumiert”), wie oft, wie lange und was der Konsument damit macht. Diese Anforderung ist nicht nur durch die DSGVO entstanden, sondern verfolgt vor allem den Zweck, seine Schnittstellenpartner und deren Absichten zu kennen.

Durch die zunehmende Verteilung und Menge von Systemen steigen damit verbundene Log-Mengen und Monitoring-Informationen. Um die Übersichtlichkeit zu erhalten bedeutet dies, ein richtiges Maß an Aggregation zu schaffen in Verknüpfung mit entsprechender Eskalationslogik und einer schnellen “Drilling Down-Möglichkeit” zwecks Analyse. Zusätzlich zu den Herausforderungen beim Bedarf der Techniker fordern Konsumenten wie Endnutzer zunehmend Zugriff auf KPIs aus dem Monitoring, sodass hier auch mehr Transparenz und mehr Sicherheitsbedarf bei dem Zugriff auf die erhobenen Daten entsteht.

Interoperabilität

Der stetige Zuwachs an Interaktionsmöglichkeiten mit IT-Systemen schafft von Geschäftsseite aus den Bedarf, zum einen schnell auf diese neuen Anforderungen zu reagieren und zum anderen, diese kostengünstig umzusetzen und in auch in der Wartung handhabbar zu gestalten. Ein Lösungsansatz diesen Anspruch zu erfüllen, ist die Schaffung von standardisierten Schnittstellen und Zugangswegen. Dieser verfolgt das Ziel, eine Entkopplung zwischen den Konsumenten und dem Service anzubieten, sodass auf Basis der Service-Schnittstelle nahezu beliebige Klienten interagieren können.

Durch die Schaffung der eigentlichen Schnittstelle als Vertrag zwischen Service und Konsument wird zwischen beiden eine Entkopplung geschaffen. Diese ermöglicht es, neue Konsumenten hinzuzufügen und auch den darunterliegenden Dienst beliebig durch eine andere Implementierung auszutauschen.

Disruptive Techniken wie Conversational Interfaces und digitale Assistenten oder die Erwartungshaltung des Markts, immer schneller auf seine Bedürfnisse einzugehen, machen es erforderlich, schnell individuelle Lösungen zu präsentieren. Dabei müssen stets die Punkte Qualität und Stabilität unter dem Aspekt der Wirtschaftlichkeit betrachtet werden. Unterstützend dabei sind besonders Schnittstellen, da diese die Grundlage für einen modularen Baukasten für Applikationen schaffen. Die übergreifende Verwendung genormter (oder marktüblicher) Schnittstellen und entsprechender Datenmodelle wie Acord ermöglicht dieses anbieter-übergreifende Baukastensystem. Beispielhaft sei hier eine Vielzahl von Anbietern, welche – obgleich unterschiedlicher Primär-Angebote wie Foto-Verwaltung, Notizzettel, etc. – auf die Schnittstellen etablierter Cloud-Storage-Anbieter wie Google oder Amazon zurückgreifen. Dabei gewährleistet ein sinnvoller Einsatz von Abstraktions-Techniken und -Schichten den weitgehend problemlosen Austausch des Storage-Anbieters, wie jüngst bei Gitlab und seinem Wechsel von Microsoft Azure zur Google Cloud Engine.

Modularität

Der Trend zu service-orientierten Landschaften, zu Microservices und der daraus resultierende Rückgang monolithischer Anwendungen hat einen gemeinsamen Ursprung: Modularität. Oftmals beinhalten Anwendungen Funktionsbausteine, die in identischer oder ähnlicher Form auch in anderen Applikationen zu finden sind. Ein populäres Beispiel hierfür ist das Identity and Access Management (IAM), also die Verwaltung von Benutzern, Rollen und Rechten.

Vielfach findet die Umsetzung eines solchen Querschnittthemas anwendungsspezifisch statt, d.h. eine bereits erkannte und ausreichend häufig gelöste Herausforderung wird durch eine Eigenentwicklung ersetzt. Im besseren Falle wird das Problem durch eine ausgelagerte Bibliothek gelöst, welche zentral entwickelt und in die jeweilige Anwendung eingebunden wird.

Auch in diesem Falle bleibt eine logistische und direkte Abhängigkeit zwischen der Bibliothek und der nutzenden Anwendung bestehen. Wird in der Bibliothek ein Fehler gefunden und eine neue Version veröffentlicht, müssen zwangsläufig alle nutzenden Programme mindestens neu paketiert werden, auch wenn eine erneute Übersetzung (Compile) üblicherweise ausbleiben kann.

Konsequent zu Ende gedacht wird Modularität aber erst mit einer Auslagerung der gewünschten Funktion in einen Service, welcher über eine stabile und definierte Schnittstelle – die API – angesprochen wird. Die tatsächliche Implementierung der API ist dabei für die Anwendung transparent. Sie kann zur Laufzeit aktualisiert oder sogar ausgetauscht werden, ohne dass eine Anpassung an den nutzenden Anwendungen notwendig ist. Über ein qualifiziertes API-Lifecycle-Management ist sogar eine funktionale Änderung ohne Auswirkung auf existierende Anwendungen möglich.

Adressaten

API-Economy fördert und erwartet interdisziplinäre Zusammenarbeit auf allen Ebenen. Eine enge Abstimmung der beteiligten “Fraktionen” von Business und IT ist notwendig, um eine florierende Service-Landschaft zu realisieren. Dabei gibt es keine abgrenzende Zuordnung einer Disziplin zu einem Personenkreis. Stattdessen gibt es an vielen Stellen gewollte Überlappungen in der Zusammenarbeit, wie Abbildung 1 demonstriert.

Dieser Tatsache geschuldet sind im Bereich API-Economy agile Methoden auf Ebene Zusammenarbeit und Technik allgegenwärtig. Wie im Artikel API-Development dargelegt, sind agiles Projektmanagement und gemeinsames “Full-Stack-Development” genauso förderlich wie ein gemeinsames Verantwortungsbewusstsein der vormals getrennten Abteilungen Entwicklung und Betrieb.

Die Rollenverteilung einer API-Economy unterscheidet sich nicht wesentlich von anderen Projekt- oder Programm-Teams im IT-Umfeld. Neben Managern gibt es Enterprise- und IT-Architekten, Entwickler, Tester und natürlich den Betrieb. Die Verzahnung der einzelnen Fraktionen ist allerdings aufgrund der notwendigen Geschwindigkeit und Flexibilität höher als bei “klassischen” Software-Entwicklungsprojekten, begünstigt durch agile Praktiken und gemeinsame Verantwortung à la DevOps (mehr dazu in einem späteren Post).

Zusätzlich übernimmt die API-Economy Rollen aus dem Themen-Umfeld (Micro-) Services. Der Anbieter eines Service bzw. einer API tritt dabei als Provider auf, die Nutzer der Dienstleistung werden als Consumer bezeichnet. In der Regel handelt es sich dabei nicht um Endkunden, sondern um vermittelnde oder verarbeitende Komponenten wie Online-Portale, mobile Applikationen oder andere Services.