API Economy – Herausforderung für das IT-Management

Einleitung

Die Bedeutung der externen IT-Schnittstellen eines Unternehmens (API) und der damit verbundene Trend der „API Economy” gehören zu den in der letzten Zeit am meisten diskutierten Themen der IT-Branche. Firmen wie Google, Twitter, Facebook oder Netflix zeigen eindrucksvoll, wie durch die Kombination einer öffentlich verfügbaren Schnittstelle und dem Ökosystem unterschiedlicher Entwickler und Entwicklungsfirmen kontinuierlich neue Geschäftsmodelle und Wertschöpfungen entstehen. Da ist es naheliegend, dass mehr und mehr Unternehmen die Bereitstellung solcher Schnittstellen als Teil der zukünftigen IT-Strategie sehen, jedoch bringt die Realisierung in der Praxis einige Herausforderungen mit sich.

Schnittstellen in diesem neuen Umfeld sind nicht mehr nur Gegenstand einer technischen Integration sondern Bestandteil neuer Geschäftsmodelle und damit eng mit der Unternehmensstrategie verbunden. [COL15]

APIs Are Like User Interfaces–Just With Different Users in Mind
David Berlind, ProgrammableWeb 

Abb. 1 Unternehmen im digitalen Umfeld

Dennoch besteht immer mehr die Notwendigkeit, sich mit den richtigen digitalen Schnittstellen nach außen zu öffnen, denn die Anzahl der digitalen Kanäle, die heute Bedarf an Informationen und Diensten eines Unternehmens haben, nimmt stetig zu. So muss heute nicht nur eine Web-Anwendung, ein Smartphone und ein Tablet als Client berücksichtigt werden, sondern auch an Zugriffe von Mediengeräten wie etwa einem Smart-TV oder Clients im Kontext “Internet of Things” oder “Car-IT”  gedacht werden.

Es ist also für ein Unternehmen nicht mehr sinnvoll, sämtliche Clientanwendungen, die eigene Daten und Dienste nutzen, selbst zu kontrollieren oder sogar zu entwickeln. Das Ziel ist vielmehr, über möglichst unabhängige Schnittstellen erfolgreich am digitalen Ökosystem mit vielen Beteiligten teilzunehmen oder im Idealfall sogar ein neues Ökosystem zu schaffen.

Für Firmen mit neuen Geschäftsmodellen, die diesen Ansatz von Beginn an integrieren können, ist dies natürlich viel einfacher als für etablierte Unternehmen, die nun vor der Herausforderung stehen, eine möglichst unabhängige und universelle externe Schnittstelle auf Basis bestehender interner Prozesse und Legacy-Systeme bereitzustellen. Daher ist der Vergleich mit  Google oder Twitter zwar hilfreich, die Erfahrungen dieser neuen Ansätze auf das eigene Unternehmen abzubilden bleibt allerdings eine Herausforderung.

Der entscheidende Unterschied zu bisherigen Entwicklungsprojekten, in denen Firmen ihren Kunden die gesamte Lösung (als Web-Anwendung oder App) zur Verfügung stellen, ist, dass nun der Dienst und nicht mehr die Anwendung im Vordergrund steht. Die Entwicklung der API muss sich daher von der Client-Entwicklung unabhängig machen.

In diesem Beitrag geben wir einen kurzen Überblick über die Veränderungen, die sich aus Sicht der IT-Entwicklung aus diesem neuen Ansatz für Unternehmen ableiten lassen.

Entwurf einer API

Eine entscheidende Frage bei der Realisierung einer API ist, ob man vom angestrebten Businessservice (Top-Down) oder den bereits bestehenden technischen Diensten ausgeht. Für Unternehmen, die etablierte Systeme betreiben und diese als externe Service anbieten, erscheint die zweite Alternative einfacher, da man hier auf einer intern bereits etablierten Basis aufsetzen kann. Allerdings ist hier die Gefahr groß, dass die Charakteristik der Legacy-Systeme einen zu großen Einfluss auf den Entwurf der API hat und damit letztlich der Mehrwert, den die Schnittstelle für externe Partner und Entwickler hat, nicht voll ausgeschöpft werden kann.

Das nachfolgend skizzierte Vorgehen folgt daher einem Top-Down-Ansatz, der den Entwurf der Schnittstelle aus Sicht des Geschäftsmodells bzw. der Anforderungen der externen Entwickler an den Anfang stellt. Außerdem folgen wir den Architekturprinzipien von REST (representational state transfer)  [REST], die sich aktuell als Standard für die Realisierung skalierbarer Schnittstellen im Internet etabliert haben.

Designprinzipien

Ein API ist eine Schnittstelle für Entwickler. Im Rahmen eines offenen Entwicklungsmodells ist die Gestaltung der API daher von zentraler Bedeutung für den Erfolg der Schnittstelle. Um die Entwicklung von Apps zu unterstützen, muss eine API intuitiv zu verstehen sowie einfach und konsistent aufgebaut sein. Es gibt heute eine Vielzahl von APIs im Web und ebenso eine große Zahl an Best Practice-Leitfäden für den Entwurf solcher Schnittstellen. Üblicherweise behandeln diese folgende Themen:

  • Modellierung von Ressourcen
    Ein API wird in Ressourcen unterteilt, die Entitäten der Business-Domäne repräsentieren. Eine Resource ist über ein URI abrufbar und wird meist durch ein JSON-Objekt beschrieben. Eine Sammlung von Ressourcen referenziert auf die Menge aller Datensätze zu einem Ressourcentyp. Eine einzelne Ressource wird mittels einer eindeutigen ID identifiziert.
  • Idempotenz
    Eine Operation sollte bei mehrfacher Ausführung zum gleichen Ergebnis führen wie bei der ersten Ausführung. Um zu vermeiden, dass bei der Wiederholung eines Requests eine schreibende Operation mehrfach ausgeführt wird, kann ein entsprechender Header eingefügt werden [STRIPE, #Idempodent Requests]
  • Zugriff
    Der Zugriff auf Ressourcen erfolgt mittels HTTP. Dabei werden die Methoden GET, PUT, POST, DELETE für die Manipulation der Daten verwendet. Header-Felder werden für die Übermittlung von Metadaten verwendet. Aufrufparameter werden als Query-String übergeben [RFC2616, Kapitel 3].
  • Authentifizierung
    Der Zugriff auf die Daten wird mittels Authentifizierung geschützt. Der Standard im Web ist dabei OAuth 2.0 [RFC6749, Abschnitt 4.3.2], [RFC6750].
  • Fehlerbehandlung
    Für die Übermittlung von Fehlern werden die entsprechenden HTTP-Statuscodes verwendet und zusätzlich ein JSON-Objekt übergeben, das eine Beschreibung des Fehlers, einen Fehlercode, sowie eine interne ID des Fehlers (Stacktrace) enthält. Letzteres erleichtert die interne Fehlerbehebung.
  • Seitenweiterschaltung
    Die als paging bezeichnetet Aufteilung von größeren Ergebnismengen auf mehrere Seiten kann ist ebenfalls eine bewährte Praxis und sollte mittels der Parameter Seite, Seitengröße und Gesamtzahl der Ergebnisse gesteuert werden können. Die Verwendung und Benennung dieser Parameter variiert dabei in der Praxis.
  • Versionierung
    Um die Wandlungsfähigkeit einer Schnittstelle bei einer gleichzeitigen Kompatibilität mit bestehenden Clients sicherzustellen, werden APIs versioniert. Die Major-Versionen der Spezifikation (z.B. v1) werden in der URI des Diensts abgebildet. Die Spezifikation einer bestimmten Version kann mittels eines entsprechenden Headers erfolgen [STRIPE, #Versioning].

Spezifikation

Ein wichtiges Dokument für die Entwickler ist die Spezifikation der Schnittstelle. Für die Spezifikation gibt es verschiedene Formate. Formale Ansätze erlauben die Generierung verschiedener Artefakte wie z.B. Server-Mocks, Client-Code, Testfälle und eine Online-Dokumentation.

  • OpenAPI
    Anhand einer auf YAML bzw. JSON basierenden Syntax können REST-Services spezifiziert werden [OpenAPI]. Dieses Format kann von einem Werkzeug wie etwa Swagger [SWAGGER] verarbeitet werden, um daraus Client-Code oder eine API-Dokumentation zu generieren.
  • Blueprint
    Auf Basis einer Syntax, die die vereinfachten Auszeichnungssprache Markdown verwendet, kann die Schnittstelle beschrieben werden [BLUEPRINT]. Es existiert eine Vielzahl an Werkzeuge, die auf Basis einer solchen Spezifikation Client-Code, Mock und Dokumentation generieren.
  • Silk
    Dieses Werkzeug verarbeitet ebenfalls eine Markdown-Syntax zur Generierung von Testfällen und einer Online-Dokumentation [SILK].

Realisierung

Ist die API spezifiziert erfolgt die Realisierung der Schnittstelle. Die Geschäftslogik enthält dabei im Wesentlichen das Mapping von URLs, die Serialisierung und Deserialisierung von Datenstrukturen, die Kommunikation mit dem Client und die Interaktion mit Backend-Diensten. Für Letzteres werden Lösungen für den Service-Lookup, den Aufruf von Prozeduren und das Daten-Mapping verwendet.

Und genau bei dieser Interaktion mit dem Backend liegt häufig die größte Herausforderung für viele Unternehmen mit etablierten Geschäftsprozessen und bestehenden IT-Systemen.

Ist die neu entworfene API nicht direkt kompatibel zur Schnittstelle der benötigten internen Systeme, dann muss eine Integrationskomponente realisiert werden, in der die Abbildung der neuen Dienste und Daten auf die bestehenden Schnittstellen umgesetzt wird. In vielen Unternehmen findet man im Rahmen einer Integrationsarchitektur eine eigene Integrationsschicht zum Beispiel in Form eines Enterprise Service Bus (ESB), in der eine Abbildung verschiedener Systemwelten stattfinden kann. Dies ist sinnvoll, wenn die Integrationskomponenten auch für weitere, interne Anwendungen verwendet werden können, man es also schafft, eine möglichst neutrale Schnittstelle zum Legacy-System zu definieren.

API_Architecture
Abb. 2: Mapping im Rahmen der Integration

Man sollte aber nicht vergessen, dass so eine Abbildung der alten auf die neue Welt immer ein zusätzliches Softwareartefakt nach sich zieht, das spezifiziert, implementiert, gewartet und weiterentwickelt werden muss.  Das ist insbesondere dann von Bedeutung wenn man von einem kontinuierlichen Entwicklungszyklus ausgeht. In diesem Fall müssen also auch Integrationskomponenten laufend angepasst oder erweitert werden. Passiert dies in einer zentralen Integrationsschicht, dann muss sichergestellt werden, dass dies keine unerwünschten Auswirkungen auf andere interne Systeme nach sich zieht. Integrationslösungen wie ESB helfen zwar dabei, können die funktionalen Abhängigkeiten selbst aber auch nicht lösen. Diese Abhängigkeiten alleine sind oft ein Grund dafür, dass eine übergreifende Integrationsschicht einer kontinuierlichen Weiterentwicklung im Wege steht.

Daher lohnt es sich, im Rahmen eines API-Projekts auch zu prüfen, ob nicht bestehende Systeme angepasst oder erweitert werden können, um so die Bedürfnisse der API besser und effizienter erfüllen zu können. Wie in der Abbildung 2 dargestellt ist zeigt sich hier der Vorteil einer Architektur mit vertikalem Systemschnitt. Auch hier müssen natürlich Anpassungen vorgenommen werden, die aber wesentlich besser von den anderen Systemen isoliert sind.

Bereitstellung und Betrieb

Gerade im dynamischen Umfeld der API-Economy ist ein agiles Vorgehen zwingend notwendig, da über die Schnittstelle eine enge und stetige Interaktion mit Kunden und Partnern sowie deren diversen Client-Anwendungen stattfindet.  Daher hat sich in diesem Bereich eine Kultur entwickelt, in der keine strenge Trennung mehr zwischen den Bereichen “Betrieb” und “Entwicklung” besteht, sondern die Teams hier möglichst optimal zusammenarbeiten um eine Umgebung zu schaffen, in der Software laufend weiterentwickelt, getestet und ausgeliefert werden kann. Dieser Ansatz wird seit einigen Jahren auch unter dem Begriff DevOps (Development and Operations) unter Softwareentwicklern und IT-Spezialisten diskutiert.

You build it, you run it
— Werner Vogels, Amazon

Da die Schnittstellen nur Sinn machen, wenn sie Teil eines umfassenden und öffentlichen Ecosystems werden, ist die öffentliche Bereitstellung der Schnittstellen natürlich mit einer Reihe von Herausforderungen verbunden. Eine externe API als Teil des Geschäftsmodells muss praktisch unterbrechungsfrei für möglichst viele Clients verfügbar und dementsprechend fehlertolerant und skalierbar sein.

Für die Bereitstellung der öffentlichen API werden auf übergreifender Ebene dafür Querschnittsfunktionen wie Request-Filter, Request-Routing oder Caching benötigt. Auch ein effektives Monitoring sowie die Analyse der Schnittstelle sind wichtige Dienste für den Betrieb und häufig Bestandteil bestehender Produkte aus dem kommerziellen oder Open-Source-Bereich.

Ein zusätzliches, wichtiges Element einer API ist ein Portal. Es stellt die Schnittstelle zu den App-Entwicklern dar und ermöglicht es, dass API-Nutzer ohne einer direkten Interaktion mit Mitarbeitern des Unternehmens eine Anwendung entwickeln und betreiben können.

  • Administration
    Registrierung von Nutzerkonten und Applikationen. Für den API-Zugriff können in diesem Bereich Zugriffs-Tokens verwaltet werden. Falls notwendig ist hier auch eine kommerzielle Abrechnung der API-Nutzung angesiedelt.
  • Dokumentation
    Ein wichtiges Element ist eine vollständige und aktuelle Online-Dokumentation der API. Auf diese Dokumentation stützen die Entwickler ihre Arbeit.
  • Community
    Für die Selbsthilfe werden häufig Foren oder Frage-/Antwortseiten bereitgestellt.
  • Testumgebung
    Die sogenannte Sandbox ermöglicht die Entwicklung von Anwendung gegen eine Testumgebung ohne produktive Daten.
  • Support
    Die Entwicklung von Apps kann durch die Bereitstellung von Client-Libraries in verschiedenen Sprachen oder SDKs unterstützt werden.

Darüber hinaus gehen Firmen wie Netflix, Amazon oder Google, die entsprechend hohe Anforderungen an die Verfügbarkeit ihrer externen Schnittstellen haben, auch ganz neue, innovative Wege. So setzt Netflix mit der sog. “Simian Army” ein selbstentwickeltes Werkzeug ein, das eine API kontinuierlich mit verschieden Fehlersituationen wie zum Beispiel dem Abschalten eines Dienstes konfrontiert und so die Fähigkeit verifiziert, solche Fehlersituationen ohne Beeinträchtigung der Funktionalität zu überstehen [SIMIAN].

Auch bei Amazon und Google lebt man mit GameDay eine Philosophie, die sich nicht darauf konzentriert, das System ausfallsicher zu machen, sondern vielmehr, mit Ausfällen schnell und kompetent umzugehen [ROBBINS].

Organisatorische Aspekte

Unter dem Schlagwort der ‘Mircroservice-Architektur’ wird die Entwicklung leichtgewichtiger, hinsichtlich der Komplexität und Größe beherrschbarer Subsysteme beschrieben. Diese Dienste können selbständig ausgeliefert werden und kommunizieren untereinander über REST-APIs. Neben der software-technischen Architektur werden jedoch unter diesem Begriff auch Veränderungen der IT-Organisation und der Entwicklungsprozesse diskutiert [CHR16].

Wird nämlich nicht nur die IT-Strategie sondern auch das damit verbundene Geschäftsmodell auf eine oder mehrere APIs ausgerichtet, die von externen Kunden, Partnern und Entwicklern genutzt werden, so ist es zwingend notwendig, dass sich auch die interne Struktur der Teams entsprechend neu organisiert werden. Der Fokus auf möglichst hochwertige externe Schnittstellen die unabhängig voneinander auch in Kombination mit Schnittstellen anderer Anbieter genutzt werden können, führt dabei zwangsläufig zu einer eher vertikalen Struktur. Hier verantworten meist kleinere und ebenfalls unabhängige Teams komplette Teilsysteme von der Datenhaltung über die interne Programmlogik bis hin zur externen Repräsentation über die API.

Im Rahmen dieses Ansatzes organisiert sich die Entwicklung in kleine, eigenverantwortliche Teams [KRA13]. Ein Team ist dabei für die Planung, Entwicklung und den Betrieb des Produkts verantwortlich. Dementsprechend sind die Teams so zusammengestellt, dass neben Know-How auf allen technischen Schichten auch das notwendige Domänenwissen vorhanden ist.

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
— M. Conway

Einsatz in der Praxis

Unternehmen

Der Bereich der “Digital Economy” wird natürlich von den bekannten Internetunternehmen wie Amazon, Google, Twitter oder Netflix geprägt, die im globalen Markt mit ihren Schnittstellen ebenso erfolgreich sind, wie mit ihren Anwendungen. Die Erfahrungen, die diese Firmen in den letzten Jahren mit ihren hochskalierenden Lösungen gesammelt haben, stellen daher eine wertvolle Basis für Unternehmen dar, die sich in Zukunft weiter in Richtung der Digitalisierung entwickeln wollen.

Es hat sich gezeigt, dass solche Systeme in der Praxis nur durch eine dezentralisierte Architektur umzusetzen ist, bei der der Ansatz einer serviceorientierten Architektur konsequent durch eigenständige, unabhängige Komponenten umgesetzt wird, die nur lose miteinander gekoppelt sind. So wurde Amazon von einer monolithischen Anwendung mit einer zentralen Datenbank nach und nach zu einem System mit hunderten von Diensten umgestaltet, bei dem jeglicher Datenzugriff nur über definierte Schnittstellen erfolgt und keine gemeinsame Datenhaltung zwischen den Diensten existiert. Auch hier wurde neben der Architektur auch die Verantwortung der Teams neu organisiert, die nun komplett für einen Dienst verantwortlich waren, vom Entwurf über die Realisierung bis hin zum Betrieb [VOG06].

Auch Netflix setzt hier auf ein System unabhängiger Komponenten, die bis auf klar definierte Schnittstellen weitgehend isoliert  sind und von unterschiedlichen Teams im Grunde komplett eigenverantwortlich entwickelt und betrieben werden.

Neben solchen Beispielen zeigen jedoch auch Unternehmen wie otto.de [KRA13], wie ein konsequent serviceorientierter Ansatz inklusive der damit verbundenen Entwicklungsphilosophie erfolgreich umgesetzt werden kann. Und auch hier ist interessant, dass neben der Technologie auch ebenso konsequent kleine, unabhängige Teamstrukturen sowie vertikale Architekturen gewählt wurden.

Dies alles belegt ziemlich deutlich, dass Technologien alleine nicht ausreichen, um den Anforderungen an Flexibilität im Bereich der Entwicklung und des Betriebs effizienter Cloud-Dienste gerecht zu werden. Der Umstieg hin zu einem wirklich digitalen Unternehmen hängt in diesem Kontext also mindestens genauso viel von der Philosophie wie vom Einsatz bestimmter Technologien oder IT-Konzepten ab.

Produkte und Tools

Dass das Thema “API Management” ein immer wichtigerer Bestandteil der IT-Industrie wird, zeigt auch das aktuelle Angebot an Lösungen und Plattformen in diesem Bereich. So sind viele große Hersteller von Unternehmenssoftware wie IBM, Microsoft, Computer Associates, Oracle oder Dell mit eigenen Lösungen vertreten. Daneben gibt es viele auf dieses Thema spezifizierte Lösungen wie etwa die Produkte von Apigee oder 3Scale, die inzwischen von RedHat übernommen wurden. Dass der Markt hier stark in Bewegung ist zeigt das Beispiel der Firma Mashery, die erst vor 3 Jahren an Intel verkauft und inzwischen von TIBCO übernommen werden. Die Entscheidung für eine optimale und zukunftssichere Platform in diesem Bereich ist daher aktuell nur schwer zu beantworten, vor allem wenn große Unternehmen wie Google oder Netflix hier meist individuelle Wege gehen.

Zusammenfassung

Die Umsetzung der Ziele und Paradigmen, die heute häufig unter dem Begriff “API Economy” zusammengefasst werden, ist für Unternehmen mit etablierten IT-Strukturen eine große Herausforderung, denn der Weg hin zu echten serviceorientierten Ansätzen und Geschäftsmodellen bringt nicht nur Veränderungen im Bereich der IT-Architekturen und IT-Technologien mit sich, sondern ist auch zwangsläufig mit einer Anpassung der internen Teamstrukturen und damit der Kommunikation und Verantwortung verbunden.

Beobachtet man dann auch intern die Transition hin zu einer Microservice-Architektur, dann stellt man fest, dass dies zum Teil grundlegende Änderungen im Vorgehen und der Kultur, wie Software entworfen, entwickelt und betrieben wird, nach sich zieht. Dass solche Veränderungen nicht ohne Risiko umzusetzen sind und jedes Unternehmen genau einschätzen muss, wieviel Veränderung die eigene Organisation verträgt, sollte jedem klar sein. Aber auch, dass man an der neuen und in vielen Bereichen so vielversprechenden Welt der API Economy ganz ohne interne Veränderungsprozesse sicher nicht erfolgreich teilnehmen kann.

Microservices aren’t for every company and the journey isn’t easy
— Tom Killalea

References

[BLUEPRINT] API Blueprint. URL: https://apiblueprint.org/.

[CHR16] Jochen Christ: paydirekt: Microservices machen die Organisation agil.
http://www.sigs-datacom.de/uploads/tx_dmjournals/christ_OTS_Microservices_Docker_16.pdf. 2016.

[COL15] George Collins, David Sisk; API Economy;

[JSON] JSON in JavaScript; URL: http://www.json.org/js.html.

[KIL16] Tom Killalea, The Hidden Dividends of Microservices; acmqueue Vol. 14 issue 3, pp 25-33

[KRA13] Stephan Kraus, Guido Steinacker und Oliver Wegner: Teile und Herrsche–Kleine Systeme für große Architekturen. 2013.

[MARKDOWN] Markdown: Syntax. URL: http://markdown.de/syntax/index.html.

[OPENAPI] OpenAPI Specification. URL https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md

[RFC2616] RFC2616: Hypertext Transfer Protocol — HTTP/1.1. URL: https://www.w3.org/Protocols/rfc2616/rfc2616.html.

[ROBBINS] J. Robbins, K. Krishnan, J. Allspaw, T. Limencelli, Resilience Engineering: Learning to Embrace Failure, acmqueue, Volume 10, issue 9, September 2012

[RFC6749] RFC6749: The OAuth 2.0 Authorization Framework. URL: https://tools.ietf.org/html/rfc6749.

[SCH15] Rolf Scheuch: Risikominimierung bei der Applikationsmodernisierung mittels Microservices.
http://www.sigs-datacom.de/uploads/tx_mwjournals/pdf/scheuch_OTS_Architekturen_15.pdf. 2015.

[RFC6750] RFC6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage. URL: https://tools.ietf.org/html/rfc6750.

[REST] Representational state transfer. URL: https://en.wikipedia.org/wiki/Representational_state_transfer

[SILK] Markdown based document-driven RESTful API testing. URL: https://github.com/matryer/silk.

[SIMIAN] Simian Army, https://github.com/Netflix/SimianArmy/wiki

[STRIPE] Stripe API Reference. URL: https://stripe.com/docs/api.

[SWAGGER] Swagger – The World’s Most Popular Framework for APIs. URL: http://swagger.io/.

[VOG06] Jim Gray, Werner Vogels, “A Conversation with Werner Vogels – Learning from the Amazon Platform”, acmQueue, Vo.4 issue 4, pp 14-22

[YAML] YAML Ain’t Markup Language (YAML™) Version 1.2. URL: http://yaml.org/spec/1.2/spec.html.

 

Leave a Reply

Your email address will not be published. Required fields are marked *