Ergebnis

Disruptive Veränderung des Geschäftsmodells

Die Abkürzung „API“ steht für Application Programming Interface. Das klingt technisch, doch die Auswirkungen auf das Business-Modell eines Unternehmens sind deutlich disruptiver als die Veränderungen in der technischen Architektur.

APIs, auf Deutsch Programmierschnittstellen, ermöglichen den Austausch von Befehlen und Daten zwischen verschiedenen Komponenten von Softwaresystemen. Diese technische Fähigkeit hat in unserer vernetzten und zunehmend digitalen Welt enorme wirtschaftliche und organisatorische Auswirkungen auf Unternehmen. So bilden APIs eine wesentliche technische Grundlage für die Bildung vernetzter, auch unternehmensübergreifender Produktionssysteme.

Die Vielzahl von APIs – und sie werden immer zahlreicher – macht das Management von IT-Systemen und Software nicht einfacher. Und da immer mehr Geschäft von diesen APIs abhängt, wird der Umgang mit ihnen selbst sowie mit den dahinterliegenden Geschäftsmodellen immer wichtiger.

Da APIs und ihr Management wesentliche Elemente einer zukunftsgerichteten Enterprise-Architektur darstellen können, hat das Cross-Business-Architecture Lab einen Workstream zu diesem Thema eingerichtet. Er erläutert den Mitgliedsunternehmen die technischen und die strategischen Aspekte des API-Managements neutral und berücksichtigt dabei praktische Erfahrungen der beteiligten Unternehmen. Außerdem untersucht der Workstream die konkreten Auswirkungen des API-Managements auf die Enterprise Architecture sowie die Geschäftsmodelle.

Vorgehensmodell

Die am Workstream beteiligten Unternehmen haben API-Management definiert und schlagen darüber hinaus ein prinzipielles Vorgehensmodell vor. 

Das Vorgehen gliedert sich in fünf
(fully customizable) Schritte. Nach dem initialen Impuls wird die Strategie festgelegt. Die Umsetzung startet mit dem technischen Durchstich, bevor das Ausrollen, das heißt die „API-fizierung“ des Unternehmens stattfindet. Diese wird von Marketing-Aktivitäten begleitet. Logischerweise folgt die Betriebsphase, die nicht nur technische Themen beinhaltet und deshalb generisch Management-Phase genannt wird.

Impulse und Gründe

Sich „ernsthaft“ mit dem Thema „API- Management“ zu beschäftigen, folgt einem Impuls. Dieser kann von innerhalb oder außerhalb des Unternehmens stammen.

Verschiedene Beispiele:

• Die Tatsache, dass gefühlt „alle anderen“ APIs bereitstellen und nutzen.
• Eine Marktanfrage: Es wird von an- deren erwartet/verlangt, dass APIs angeboten werden.
• IT erkennt die Chancen des Themas und will durch einen geeigneten Showcase die Fachseite dafür motivieren.
• Aber auch: Neue Businessmodelle/ API-Management als disruptive Möglichkeiten;
• Automatisierung/Verbesserung von bestehenden Prozessen (B2B oder intern).

Strategiefestlegung

Dem hohen disruptiven Potenzial des Themas fällt aus Gesamtsicht besonderes Gewicht im weiteren Vorgehen zu. Die für das API-Management festgelegte Strategie ist Teil der IT- oder Digitalisierungsstrategie eines Unternehmens.

Sie muss unter anderem folgende Fragen beantworten:

• Warum API-Management?
• Ist der wahrgenommene Impuls dereinzige Grund, oder gibt es innerhalb oder außerhalb des Unternehmens weitere starke Impulse, die als Anforderungen berücksichtigt werden müssen
• Welche Veränderungen werden mit den APIs angestoßen?
• Welche Maßnahmen sind notwendig?
• Welcher Scope wird für das API-Management gewählt?

Technischer Durchstich

Der technische Durchstich sollte zunächst als risikoarmes Proof of Concept erfolgen. In ihm sollten die Basisinfrastruktur für das API-Management sowie eine Referenzarchitektur bereitgestellt werden. Dabei müssen die unterschiedlichen architektonischen Ausgangssituationen der Unternehmen berücksichtigt werden, z. B. ob eine serviceorientierte Architektur implementiert ist.

API-fizierung

Nachdem das Proof of Concept erfolgreich getestet wurde, müssen IT-Landschaft und EAM auf ein API-basiertes Vorgehen der Leistungserbringung umgestellt werden. Yannis Baillet, Leiter des API-Management-Workstreams und Architekt bei der SBB AG, betont dabei besonders die Veränderung des Geschäftsmodells. „Die Unternehmen müssen eine API als vermarktbares Produkt oder einen Service sehen, nicht nur als eine Schnittstelle. Wenn die SBB zum Beispiel eine API bereitstellen würde, mit der die Daten aus den Fahrkartenautomaten für Dritte zugänglich gemacht würden, wäre das für viele Touristikanbieter ein Mehrwert, für den sie die SBB bezahlen würden.“ Baillet ist sicher, dass Business-Auswirkungen der APIs die technischen Auswirkungen deutlich überwiegen. „Architektonisch sehe ich APIs als eine evolutionäre Weiterentwicklung. Was sie wirtschaftlich ermöglichen ist allerdings disruptiv und darauf müssen sich die Unternehmen einstellen.“

Marketing

Parallel zur API-fizierung muss das interne Marketing für das neue Vorgehen stattfinden. Die Entwickler-Community muss davon überzeugt werden, die IT insgesamt und natürlich die Business-Seite sollten über die Vorteile der API-fizierung intensiv informiert werden.

Management

Wenn die API-Infrastruktur aufgebaut ist und die wesentlichen Verbindungen geschlossen sind, geht es darum, diese Infrastruktur zu betreiben und kontinuierlich zu verbessern.

Referenzarchitektur

Neben Definition und Vorgehensmodell erarbeitet der Workstream eine Referenz-Architektur. Diese stellt sich folgendermaßen dar:

Über die Management-Plattform werden APIs vom Provider für potenzielle Consumer sichtbar gemacht und verwaltet. APIs werden im API Repository gehalten. Im Developer Portal erhält wiederum der Consumer Sicht auf die publizierten APIs, kann sich für deren Nutzung selbst registrieren (erhält einen persönlichen API-Key) und kann anhand der Sandbox-Umgebung die API ausprobieren. Wenn eine API vom Provider einen Endpunkt (Zugriffspunkt) publiziert, so wird die API in das Gateway transportiert und ist dann über diesen Endpunkt zur produktiven Nutzung für autorisierte Consumer bereit.

Nach erfolgter Implementierung im Consumer System kann das Consumer System API-Aufrufe über das Gateway absetzen. Das Gateway leitet die Anfrage an das Provider System weiter. Dabei wird zunächst vom Gateway anhand der API-Key kontrolliert, ob der Consumer für die Nutzung dieser API autorisiert ist. Je nach Konfiguration der API können auch Einschränkungen bzgl. der Frequenz oder der Anzahl der Aufrufe (throttling) existieren. Aufrufe werden geloggt, was wiederum dem Provider erlaubt, eine Übersicht der Nutzung seiner API über das Dashboard des Provider-Portals zu erhalten.

Für schärfere Authentisierung und Autorisierung ist die Nutzung zusätz- licher Mechanismen (Beispiel: Oauth) unabdingbar.