JAXenter: Viele Unternehmen führen derzeit APIs ein, die ältere technische Lösungen wie SOA oder ESBs ersetzen. Weshalb eigentlich? Warum hat die sogenannte API Economy momentan Konjunktur?
Christoph Wiechmann: Die API Economy hat den Application-Developer/Consumer mehr im Fokus, ist offener und strebt einen höheren Grad an Self-Service für an. Auch macht die API Economy nicht an der Unternehmensgrenze halt, sondern bindet genau wie Unternehmensdienste auch Cloud-Anwendungen in die API-Management-Plattform ein, welche heute für Unternehmen enorm wichtig sind.
Das Ziel ist, dass sich Fachbereiche auf die Entwicklung innovativer digitaler Dienste konzentrieren können und im Self-Service aus einem API-Katalog mit passenden On-Premise- und Cloud-Diensten zugreifen können. Die Projekte der Fachbereiche müssen sich damit nicht um die Integration in einzelne Backend-Systeme kümmern, werden dadurch agiler und sind schneller beim Kunden.
Auf der anderen Seite muss eine API-Management-Plattform dem Betreiber, also der IT bzw. den Service-Providern, die Möglichkeiten bieten, den Self-Service effizient zu überwachen und steuernd einzugreifen.
Alle News & Updates zur API Conference
JAXenter: In den meisten Fällen haben Unternehmen noch Legacy-Systeme am Laufen, die bei der Einführung von APIs integriert werden müssen. Welche technologischen Herausforderungen gilt es dabei zu meistern?
Christoph Wiechmann: Die Herausforderung besteht darin, diese Legacy-Systeme mit den gewünschten API-Schnittstellen für den API-Management Governance-Layer auszustatten. Kunden setzen dafür auf Fassaden, welche in diese Systeme integrieren, dazu Protokolle und/oder Formate umsetzen, um am Ende eine Standard API zu erzeugen.
Hinzu kommt, dass einige Systeme nicht dafür ausgelegt werden, um im üblichen Request- und Reponse-Modus zu agieren, sondern im Batch-Verfahren angesprochen werden müssen. Auch die Performance einiger Legacy-Systeme ist ein Problem, da diese nicht für viele hundert Anfragen pro Minute entwickelt bzw. ausgelegt wurden, aber mit dieser Anzahl von Anfragen klar kommen müssen.
Welcher technologische Stack bzw. Ansatz dazu verwendet wird, hängt ganz stark vom Backend-System ab und muss von Fall zu Fall entschieden werden. Für Systeme mit unzureichender Performance oder nur Batch-Verhalten könnten Data-Lakes zum Einsatz kommen und Caching auf dem API-Management Layer. Aber es kann sogar so weit gehen, dass es keine andere Möglichkeit gibt, als eine Webbasierte-Legacy-Anwendung mit einer API auszustatten, durch den Einsatz einer Browser-simulierenden Fassade.
JAXenter: Deine Session auf der APIcon heißt „Das Zusammenspiel von Identity- und API-Management-Lösungen.“ Dabei gehst du auf die Integration der APIs mit einem Identity-Management-System ein, das externe und interne Identitäten validiert. Wie genau kann das funktionieren?
Christoph Wiechmann: Eine API-Management-Lösung soll in erster Linie API-Requests von verschiedenen konsumierenden Applikationen steuern und absichern. Das Zusammenspiel passiert auf Basis von Standard-Access-Tokens, wie JWT oder OAuth/Open-ID-Connect. Diese werden vom IDP an konsumierende Applikationen im Namen des Benutzers ausgestellt und müssen vom API-Management-System zur Runtime validiert werden. Die Validierung erfolgt entweder unter Mithilfe des IDPs oder bei Self-Contained-Token eigenständig. Soweit, so gut.
Der Punkt ist aber wieder der Self-Service auf der API-Management-Lösung. Oft sollen diese IDPs OAuth Token als JWT oder als Opak-Token ausgegeben, aber es wird nicht bedacht, dass sich dahinter Application-Credentials verbergen, welche aber im Sinne von Self-Service auf dem API-Developer-Portal erzeugt und verwaltet werden. Damit also ein IDP solche Access-Tokens überhaupt ausstellen kann, muss sich das im Self-Service betriebene API-Management-System mit dem IDP synchronisieren. Dieser Aspekt wird oft unterschätzt.
JAXenter: Bei der Einführung von APIs bleibt es nicht bei den technologischen Herausforderungen. Weshalb hat das auch Konsequenzen auf die gesamte Organisation eines Unternehmens?
Christoph Wiechmann: Nur die Einführung einer API-Management-Plattform ist noch kein Garant, dass diese zum Erfolg wird. Es muss ein Umdenken im gesamten Unternehmen geben, weg von einem Silo-Denken hin zu einer offenen API-basierten Architektur. Service-Provider sollten ihre Services als API in der Plattform zu Verfügung stellen und können im Gegenzug als Mehrwert aus dem API-Katalog für eigene Entwicklungen schöpfen. Nur so wird möglich, dass sämtliche Dienste/Services inkl. Cloud-Anwendungen zur Verfügung stehen und der Nutzen der Plattform steigt.
Das Aufschalten von Services muss für Service-Provider schnell und einfach gehen, so dass es nicht als Hürde, sondern als Gewinn für das Unternehmen verstanden wird. Selbstredend, dass API-Konsumenten auf einfache, aber kontrollierte Art und Weise auf APIs zugreifen können, um diese für eigene Zwecke einzubinden.
Um das zu erreichen, müssen Unternehmen internes und externes Marketing betreiben, Service-Provider und -Consumer müssen geschult werden, und ein API-Team unterstützt besonders aktiv in der ersten Ramp-Up-Phase nach Go-Live der Plattform.
JAXenter: Wie sollte man ein API-basiertes Projekt deiner Erfahrung nach angehen? Startet man technologisch, oder muss man zuerst das Unternehmen umstrukturieren? Braucht es zunächst ein ausgefeiltes Konzept zum API Management, oder ist der MVP-Ansatz hier besser? Vielleicht hast du einen Tipp aus der Praxis, der für dich funktioniert hat?
Christoph Wiechmann: Wie immer kommt es natürlich darauf an. Aber prinzipiell halte ich einen MVP-Ansatz für sinnvoll. Dieser sollte allerdings wirklich das Minimum definieren, was im ersten Schritt notwendig ist, und nicht schon zehn goldene Henkel, die das Projekt in Verzug bringen. Auf dieser Basis holt man sich das erste Feedback von Service-Providern & Consumern.
JAXenter: Was ist die Kernbotschaft deiner Session, die jeder mit nach Hause nehmen sollte?
Christoph Wiechmann: Die Einführung eines dezidierten Identity-Management Providers ist durchaus sinnvoll, da API-Management und Identity-Management aus der Architektur-Sicht nicht zusammen gehören. Trennt man diese Themen, ergeben sich daraus flexible Möglichkeiten, um z.B. verschiedene IDPs für z.B. Social-Login für End-Kunden oder Federated Login für Partner anzubieten, wenn man sich nicht auf einen IDP festlegt.
Aber beide Lösungen, gerade bei der Verwendung von OAuth-Access-Tokens, sind eng miteinander verbunden, wenn man eine API-Management-Plattform mit Self-Service etablieren möchte, und hier möchte ich gerne meine Erfahrung in diesem Bereich teilen.
JAXenter: Vielen Dank für dieses Interview!
