API oder Kundenschnittstelle?

Lohnt sich eine API-First Strategie, oder sollte man besser zuerst die Kundenschnittstelle im Fokus haben?

Doch was ist, wenn ein API auch eine Kundenschnittstelle ist?

 

Eine Frage der Perspektive

Was genau "die Kundenschnittstelle" ist, liegt letzlich an der Prespektive. Oder anders formuliert: Es hängt davon ab, was für Kunden Sie haben und wie diese genau mit Ihnen interagieren. Im B2C-Geschäft mit natürlichen Personen als Kunden ist ein API in der Regel keine Kundenschnittstelle. Ein API muss auf der Kundenseite implementiert werden um sinnvoll genutzt werden zu können. Das bedeutet, dass Sie bspw. im Kontext von Open-Banking im Sinne eines offenen API à la PSD2 mindestens teilweise die Kundenschnittstelle verlieren. Jedenfalls potentiell für jene Aktivitäten, die Sie via API zur Verfügung stellen. Nutzt Ihr Kunde eine APP eines Drittanbieters, besetzt dieser Drittanbieter die Kundenschnittstelle. Er kann in dieser APP (je nach Funktionalität) auch einen Bankwechsel anbieten. Sie haben als Bank ein API angeboten (und eine andere auch) und nun werden Sie einfach ausgetauscht.

Im Falle von B2B kommt es auf die konkrete Dienstleistung und Ausgestaltung der Nutzung an, ob ein API als Kundenschnittstelle angesehen werden kann. Ist die Nutzung exklusiv und die Implementierung des API nicht einfach ersetzbar, d.h. nicht jeder kann/darf es nutzen und das API selber (die Spezifikation) ist proprietär, dann kann das API im Kontext durchaus als Kundenschnittstelle angesehen werden.

Vermischen Sie nicht die technische Sicht der Dinge mit dem Business

Die Frage nach API-First oder Kundenschnittstelle stellt sich in dieser Form nur aus Sicht Business. Es gibt aber auch noch eine rein technische Sicht. API-First ist nicht gleichzusetzen mit Open-API oder Open-Banking etc. Wer Funktionen zuerst als sauberes API implementiert, muss dieses weder allen zugänglich machen noch als "public" veröffentlichen. Stellen Sie also sicher, dass Sie bei der Formulierung der Strategie präzise sind und intern ein gemeinsames Verständnis haben, was aus Sicht Business gemeint und gewollt ist. Und bewahren Sie der IT die interne Freiheit, die Anforderungen architektonisch so umzusetzen, wie es aus Sicht IT am sinnvollsten und nachhaltigsten ist. Eine technische API-First Strategie kann gerade im Kontext von Microservice-Architekturen ein sinnvoller Ansatz sein. Natürlich ist es später einfacher ein Public-API anzubieten, wenn man bereits intern auf standartisierte API setzt. Dennoch gibt es durchaus Unterschiede zwischen rein internen und öffentlich angebotenen API. Das fängt bei den Use-Cases an und hört nicht bei API-Management-Anforderungen wie dem Zählen und Verrechnen der Nutzung auf. Von daher muss am Anfang der Spezifikation klar sein, wer der Nutzer des API ist. Es gibt kein API welches für alle Use-Cases gleichermassen geeignet ist.

Tanzen Sie nur auf mehreren Hochzeiten gleichzeitig, wenn Sie sich nicht umziehen müssen

Das eine tun und das andere nicht lassen, könnte man sagen. Könnte man. Sollte man aber nicht in jedem Fall. Die Umsetzung einer Strategie braucht Zeit und bindet Ressourcen. Verschiedene Strategien gleichzeitig anzugehen kann daher dazu führen, dass keine so richtig umgesetzt werden kann und in Fahrt kommt. Schlimmsten Falls kommen die unterschiedlichen Strategien einander sogar in die Quere und behindern einander gegenseitig. Ist das API keine Kundenschnittstelle, fahren Sie eine Kundenschnittstellen-Strategie nur dann parallel zur einer API-First Strategie, wenn Sie das API ziemlich 1:1 für die Kundenschnittstellen-Strategie nutzen können und beide eine vergleichbare Timeline haben. Falls etwas nicht zutreffend ist, setzen Sie die beiden Strategien lieber sequenziell um.

Was ist die Motivation einer API-First Strategie?

Ein API hat zwei grosse Vorteile:

1. Es hat eine hohe Wiederverwendbarkeit;
2. Die konkrete Nutzung durch einen Endbenutzer kann verschieden implementiert werden (via APP, Web-Applikation, oder mittels Chat-Bot etc.).

Die Erstellung erfordert einen klaren Fokus und die Definition von klaren Use Cases. Damit befasst man sich eingehend mit dem Business und dem möglichen Kundennutzen. Dadurch dass ein API unabhängig einer konkreter Client-Implementierung ist, ist ein API grundsätzlich auch langlebiger und die Investition daher nachhaltiger. Obwohl es klare Use Cases braucht (zumindest sehr zu empfehlen!), können damit später auch immer wieder Use Cases abgedeckt werden, an welche man bei der Spezifikation so noch nicht gedacht hat.

Last but not least kann mit einer API-Strategie die Entwicklung einfacher modularisiert werden. Beispielsweise kann das API intern Implementiert werden, während man gewisse darauf basierende APP-Funktionen in einem Outsourcing entwickeln lässt.

Was ist die Motivation einer GUI-basierten Kundenschnittstellen Strategie?

Eine direkte GUI-basierte Kundenschnittstelle ist sofort durch einen Endkunden nutzbar. Der Nutzen ergibt sich somit unmittelbar nach Fertigstellung. Dadurch ist ein rasches Kundenfeedback möglich und das Produkt kann rasch verbessiert und angepasst werden. So wie es von den Kunden letztlich in der Realität wirklich gebraucht wird. Greift der Business-Case nicht, waren in der Regel weniger Investitionen notwendig. In einer agiler Entwicklung können damit auch früher Feedbacks von Fachleuten (Business) abgeholt werden, da diese mit einer GUI etwas anfangen können und Teile davon frühzeitig bewerten können.

Es gibt mehr Leute (vor allem auch vom Business), welche eine GUI spezifizieren können um Funktionen zu beschreiben, als eine saubere API-Spezifikation zu verfassen.

Wie entscheidet man am besten?

Die richtige Antwort ist natürlich die am wenigsten hilfreiche: Kommt drauf an. Während noch bis vor ein paar Jahren generelle Strategien wie "Mobile-First" angesagt waren, geht die Tendenz mehr Richtung Entscheid pro Produkt/Projekt. Es gibt dann nicht mehr eine generelle "API-First Strategie" für das Unternehmen. Vielmehr entscheidet man für jedes Produkt/Projekt individuell, welche Strategie sich besser eignet. Für die Modernisierung der etablierten Trading-Plattform eignet sich vielleicht eine API-First Strategie. Für das neue APP-Produkt, wo man sich zur Hypothek noch gleich den Haus-Service und den Termin mit dem Kaminfeger für das Cheminée buchen kann, vielleicht eher eine Kundenschnittstelle-Strategie, wo direkt nur die eigentliche APP entwickelt wird, ohne öffentliche API der Funktionen.

Das Wichtigste ist, dass die Entscheidung bewusst und nach klar definierten Kriterien gefällt wird. Ein generelles Richtig oder Falsch gibt es nicht.