API-first Ansatz: Auf dem Weg zum Open Banking

Aufgrund regulatorischer Anforderungen sind Finanzinstitute seit 2019 verpflichtet Services über APIs für Drittanbieter bereitzustellen. Die Einführung dieser APIs stellt die Finanzinstitute bis heute vor große Herausforderungen und führt zu einem Wandel in den Geschäftsmodellen der Banken. Mit einem API-first Ansatz können die Finanzinstitute ihre IT-Landschaft an diese neuen Herausforderungen anpassen, Datensilos öffnen und ihr digitales Eco-System erweitern. So sind sie in der Lage nicht nur die regulatorischen Anforderungen zu erfüllen, sondern auch auf Basis moderner Architekturen leichter und schneller interne und externe Services bereitzustellen.

PSD2 und die Rolle von APIs im Banking der Zukunft

Bekanntlich befinden sich Banken in einer stetigen digitalen Transformation. Denn wie alle anderen Marktteilnehmer müssen sie sich am Markt behaupten – seien es neue Kundenbedürfnisse, neue Interaktionskanäle oder Convinience-Anforderungen, die dabei als Treiber fungieren. Besonders im Finanzsektor spielt bei der digitalen Transformation die Regulatorik eine große Rolle. Zuletzt kam im Jahr 2019 mit PSD2 auf die europäischen Banken ein regulatorischer Knall, der die Institute ins Grübeln gebracht und oft zum technischen Umdenken angeregt hat.

Mit PSD2 (Zweite EU-Zahlungsdiensterichtlinie) kamen vor allem zwei spannende Anforderungsblöcke auf die verantwortlichen IT-Architekten: Einführung einer Stärkeren Kundenauthentifizierung (SCA) sowie die verpflichtende Einführung von Kontoschnittstellen für Drittdienstleister. Gerade Letzteres hat Banken mit traditionellem Geschäft und lediglich internen APIs, etwa für die eigene Homepage, vor immense Herausforderungen gestellt. Plötzlich mussten die Institute verpflichtend öffentliche Schnittstellen entwickeln und im Internet für alle zertifizierten Dienstleister bereitstellen.

Damit ist die PSD2-Schnittstelle die erste Open Banking API und bringt für die Banken nicht nur Herausforderungen, sondern auch neue Geschäftsideen und Innovationen im gesamten Finanzsektor mit sich. In unserem Beitrag „PSD2 und Open Banking: Das neue Banking-​Zeitalter verstehen und nutzen“ aus der Serie „Banking der Zukunft“ wurde bereits erläutert, warum Banken jetzt, über der Bereitstellung von PSD2-Schnittstellen hinaus, aktiv werden müssen. Die Zukunft der Finanzgeschäfte gehört nämlich den Ökosystemen.

API-first – Warum?

Fangen wir mit der Gegenfrage an – warum nicht API-last? Bei API-last wird die API taktisch am Ende der Systementwicklung aufgebaut, also „on top“ zum vermeintlich fertigen Produkt. Das bringt einige Nachteile mit sich: die API selbst wird zum zweiten, nachrangigen, Produkt und wird damit wahrscheinlich als Last und Zusatzarbeit empfunden. Die Belange der API-Nutzer finden potenziell wenig Beachtung, da die API lediglich einen Wrapper um das „Hauptprodukt“ darstellt. Schlussendlich findet die API damit wenig Nutzer-Akzeptanz.

Wie ist es, wenn die API strategisch am Anfang der Entwicklungszeit aufgebaut wird? API-first bedeutet nämlich, den Fokus auf eine gute API zu legen. Die API wird also zur Voraussetzung für das Produkt, zu dessen Basis. Damit werden etwa Dokumentation und Change-Management zur Selbstverständlichkeit und die Werthaltigkeit für die Nutzer steht im Vordergrund – mit dem Ziel einer hohen Nutzerakzeptanz, dem Aufbau einer API-Community und letztendlich eines nachhaltigen Produkterfolgs.

Prinzipien von API-first

Als Grundlage für das Verständnis nachfolgend zwei Aussagen zur Definition von API-first von bekannten API-first „Evangelisten“:

„Identifying and/or defining key actors and personas, determining what they expect to be able to do with your API.“ Thomas Kaz, 2009^[1]

„Before you build your website, web, mobile or single page application, you develop an API first.“ Kin Lane, 2014

Bei API-first geht es also grundsätzlich darum, sich um die API zu kümmern, bevor es an die Entwicklung anderer Elemente geht. Die API wird als unabdingbare Basis für das Produkt angesehen. Mit dem ersten Zitat wird jedoch deutlich, dass API-first mehr als ein technischer Aspekt ist, es steht die Werthaltigkeit für die letztlichen Nutzer im Vordergrund. Grob kann man von drei Kernbestandteilen von API-first sprechen:

1. Business value: Welches Problem versuchen wir zu lösen, welchen Business-Wert wollen wir mit der API liefern? Das zu lösende Problem muss durchdrungen sein, bevor man sich mit Details etwa der technischen Implementierung auseinandersetzt. Eine ins Detail durchdachte Softwarearchitektur kann wertlos sein und zu einer schlechten API führen, wenn fachliche Sinnhaftigkeit erst später geklärt wird.
2. Target audience: Für wen soll die API entwickelt werden, welche Probleme lösen sie und wie lösen sie die Probleme sonst? Die API soll wertvoll und maßgeschneidert für das Zielpublikum sein. Eine öffentliche API im Finanzsektor unterliegt sicherlich anderen Anforderungen als interne APIs für das eigene Frontend-Team, was sich im dessen Design widerspiegeln wird.
3. Design: Es gibt viele Wege, die gleichen Daten und Funktionen zur Verfügung zu stellen, doch welcher davon ist der sinnvollste? Erst unter Einbringung der Erkenntnisse zu Business value und Target audience lassen sich richtige und nachhaltige Design-Entscheidungen treffen. Ein generisches Design beispielsweise macht die API für viele Projekte anwendbar, ist aber schwer auf jedes einzelne Projekt anzuwenden; ein spezifisches Design löst ein einzelnes Problem, aber kein anderes.

Zusammenfassend lässt sich das Kernprinzip von API-first als „digital value first“ beschreiben. Die API soll als Basis des Produktes mit seinem sinnvollen Design für die Anwender einen Mehrwert liefern.

API-first Mentalität

Wusstest Du, dass zu Anfangszeiten von Amazon Jeff Bezos ein API-Mandate verfasst hat, in dem Entwickler aufgefordert werden, für jede Funktionalität APIs zu entwickeln?

„All teams will henceforth expose their data and functionality through service interfaces. Teams must communicate with each other through these interfaces. […] Anyone who doesn’t do this will be fired.“ ^[2]

Für Amazon sind APIs bewusste Investitionen, nicht einfach technische Architekturentscheidungen. Warum ist es sinnvoll, für alle Befähigungen des Unternehmens APIs zu haben? Was sind die Gedankengänge der API-first Mentalität?

Am Anfang steht dabei der Digital focus. Wir sammeln alle Befähigungen – Services, Daten, Funktionen – des Unternehmens und stellen sie als zunächst interne APIs zur Verfügung. Jede Fähigkeit wird damit intern verfügbar und stellt jeweils für sich einen digitalen Baustein dar.

Nun können einzelne Bausteine miteinander zu einem Produkt kombiniert werden, das zusammenhängend einen fachlichen Mehrwert bringt und Probleme löst, dem Digital product. Dazu wird der Netzwerkeffekt genutzt – je mehr Bausteine zur Verfügung stehen, desto mehr potenzielle Digital products können entstehen.

Doch wie bringt man nun das Produkt zum Kunden, ab wann existiert es in der digitalen Welt? Es bedarf einer Produkt-API. Erst mit der API ist das Produkt nutzbar und nützlich. Die API ist somit das Produkt und der Kunde bekommt das Product as API zur Verfügung. Einerseits existiert das Produkt nicht oder geht unter, wenn es keine oder eine schlechte API gibt; andererseits ist nur so gut, wie gut seine API ist.

Spätestens jetzt wird deutlich: API-first ist kein rein technischer Aspekt. Jeder Produktmanager muss  sich mit der „digitalen Oberfläche“ befassen. Bestenfalls ist API-first eine Mentalität oder sogar, wie im Falle von Amazon – eine Unternehmenskultur.