eBizTalk - Berichten, Unterhalten, Weiterbilden

In diesem Artikel gehe ich auf eine häufig verwendete (ich möchte sagen „Vorurteil“) Rolle von APIs (Application Programming Interface bzw. Anwendungsschnittstelle) ein, in der sie als reine Middleware deklariert werden. Ich erkläre, dass APIs als Produkte behandelt werden sollten und was die daraus resultierenden Vorteile sind. Dieser Artikel gehört zu einer Reihe von Artikeln über API Management in Enterprise Organisationen. Ziel der Reihe, ist meine Sicht auf API Management zu geben, wie es im Enterprise-Kontext eingesetzt werden kann.

API-Lösungen und API-Produkte

Es gibt zwei Arten von APIs, API-Lösungen und API-Produkte.

Eine API-Lösung besteht aus einer oder mehreren APIs, die ein Integrationsproblem lösen. Genauer gesagt werden API-Lösungen eingesetzt, um direkte Kommunikation zwischen Computersystemen zu ermöglichen. Ein Beispiel hierfür könnte eine Situation sein, in der Kundendaten in mehreren Geschäftsbereichen, oder auch Silos, ausgetauscht werden müssen.

Ein API-Produkt besteht ebenfalls aus einer oder mehreren APIs, die jedoch eine Schnittstelle zu einem Wertversprechen bereitstellen. Mit anderen Worten, ein API-Produkt besteht aus Value Proposition-Schnittstellen. Um das obere Beispiel weiterzuführen, könnte ein API-Produkt unternehmensglobale Kundendaten zur Verfügung stellen, damit diese intern verwendet werden können.

API-Produkte sind mehr als Middleware

API-Lösungen sind also APIs die speziell für einen einzelnen Integrationsfall erstellt wurden. In diesem Fall erfüllen sie die Definition als Middleware, sie vermitteln zwischen Programmen um die Komplexität dieser zu verbergen. Viele Legacy-Architekturen auf diese Weise gewachsen. Aber APIs als reine Integrationstechnologie zu betrachten wäre ein Fehler, da der größte Teil des Mehrwertes, den APIs bieten können, ignoriert werden würde. Durch sie werden Werte im modernen Geschäft ausgetauscht. Dies macht APIs auch zur Sache der Geschäftsführung und Strategieentscheider. APIs sind allein Sache der IT-Abteilung.

Bei API-Lösungen, wie auch bei API-Produkten kann man den Konsumenten der API als intern oder extern klassifizieren. In der Welt der APIs ist ein Verbraucher einfach jeder, der einen Dienst nutzt, unabhängig davon ob er bezahlt wird oder nicht. Ein externer Verbraucher ist genau das, ein Dritter, der außerhalb der Unternehmenseinheit die API oder den Dienst, der durch eine API bereitgestellt wird, nutzt. Ein interner Verbraucher ist jedoch jemand, der innerhalb des Geschäftsbereichs existiert. Dies sind also Teams die unternehmensinternen Lösungen und Integrationen schaffen. Dies wird durch das untere Bild illustriert:

Abbildung 1: externe vs interne Verbraucher

Aus geschäftlicher Sicht steckt hinter jeder Transaktion ein Mehrwert, unabhängig von der Art der Datenverarbeitung oder ob sie den Umsatz direkt steigert. Es ist demnach nicht weithergeholt, wenn APIs als Produkt verwaltet werden, um so neue umsatzorientierte Einnahmequellen zu schaffen. Aus diesem Grund ist es wichtig, APIs als Geschäftsressource /Assets und nicht als amorphe Codebasis zu sehen. APIs sind also nicht nur Sache der IT-Abteilung.

50% of Salesforce transactions are done through their API. – source

Viele betrachten API-Produkte jedoch als Dinge, die große Internetunternehmen verwenden, um Ökosysteme rund um ihre Dienste zu erstellen. Konsistent gestaltete RESTful-APIs tragen jedoch auch intern dazu bei, direkte Kosten und auch Opportunitätskosten zu sparen, die eine mehrfach wiederholte Entwicklung von API-Lösungen mit sich bringt. In größeren Unternehmen ist es häufig der Fall, dass für Integrationsprojekte neue API-Lösungen erstellt werden. Wiederholt sich der Integrationsbedarf des gleichen Backendsystems, wird wieder eine neue Lösung geschaffen. In solchen Fällen treibt ein API-Produkt die Idee der Wiederverwendbarkeit von Schnittstellen voran, indem es zahlreiche API-Ressourcen in Pakete sammelt, die auf die Bedürfnisse verschiedener Entwicklergemeinschaften zugeschnitten sind.

Wie bereits erwähnt, sind die Benutzer eines API-Produkts interne oder externe Verbraucher, die Dienste oder Integrationen erstellen, sei es für Kunden, für Mitarbeiter oder um Automatisierung und Effizienz zu erhöhen. APIs sind also eine Möglichkeit für Unternehmen, die Entwicklung zu beschleunigen und die Effizienz in Wochen oder Monaten, nicht in Jahren zu verbessern.

Fazit

Das Label der Middleware bleibt in größeren Unternehmen jedoch meist bestehen. Es gibt viele Gründe dafür: Legacy-Architekturen, Monolithic Applications und traditionelle Integrations- und Entwicklungstechniken, die alle dazu neigen, APIs als reines Mittel zum Zweck zu sehen.

In vielen Unternehmen ist diese Verwendung tief verwurzelt und wird demnach weiterhin gelebt und umgesetzt. Was bei einer API-Produktstrategie zu bedenken ist, betrachten wir später in dieser Serie zu API Management.