Kolumne: Stropek as a Service

Erfolgsfaktor API: Warum APIs Bestandteil jedes SaaS-Produkts sein sollten
Kommentare

SaaS hat die Sichtweise vieler Kunden in Hinblick auf ein integriertes Gesamtsystem versus Best-of-Breed verändert. Der Einsatz verschiedener SaaS-Lösungen ist selbst in kleinen und mittelständischen Unternehmen gang und gäbe.

Office 365 für Email, Slack für interne Kommunikation, Salesforce für CRM, Dynamics NAV als ERP, Dropbox Business für Dateiablage, Trello zum Aufgabenmanagement, time cockpit für Projektzeiterfassung – solche SaaS-Landschaften begegnen uns in der Praxis nicht selten.

Damit das funktioniert, braucht es in allen beteiligten SaaS-Lösungen Schnittstellen, die sich einfach verwenden lassen. Meiner Erfahrung nach haben viele Kunden das mittlerweile verstanden. Die Möglichkeit zur Integration einer SaaS-Lösung in eine größere Systemlandschaft ist für sie zu einem wichtigen Auswahlkriterium geworden.

API als vollwertige Produktfunktion

Wer als SaaS-Anbieter also erfolgreich sein will, muss ein modernes Web-API als integralen Bestandteil seiner Lösung anbieten. Damit meine ich, dass das Web-API nicht nur ein unwichtiges Detail am Rande ist, über das man nur mit wenigen Implementierungspartnern spricht. Das Web-API wird zur wichtigen Produktfunktion, der im Hinblick auf Gestaltung, Tests, Dokumentation, Support und Produktpräsentation genauso viel Aufmerksamkeit wie anderen Programmteilen gewidmet wird. Ein geheim gehaltenes API ohne Doku, vielleicht sogar ausgeschlossen vom offiziellen Support, ist von vorgestern und zeugt nicht davon, dass ein SaaS-Anbieter mit der Zeit geht.

Ein positives Beispiel gefällig? Die SaaS-Collaboration-Software Slack ist noch keine drei Jahre am Markt, hat in dieser Zeit aber mehr als zwei Millionen Benutzer (ca. 675.000 davon sind zahlende Benutzer) gewonnen. Damit ist Slack eine der großen SaaS-Erfolgsgeschichten der letzten Jahre. Slacks hervorragendes Web-API ist meiner Meinung nach ein wichtiger Puzzlestein für den Erfolg. Werfen Sie einen Blick auf https://api.slack.com/. Es ist beeindruckend, wie liebevoll und detailliert das Slack-Team das Web-API gestaltet und dokumentiert.

RESTful Web APIs sind der Standard

Das Programmierparadigma REST (Representational State Transfer) hat sich im SaaS-Bereich gegenüber Alternativen wie SOAP eindeutig durchgesetzt. Wer darauf setzt und die dafür üblichen Best Practices einhält, kann davon ausgehen, dass Anwender sich zu Hause fühlen, wenn sie das RESTful Web API verwenden möchten. Außerdem kann man auf eine Vielzahl an Tools (z. B. Entwicklungstools, Frameworks), Integrationsplattformen (z. B. IFTTT, Zapier, Microsoft Azure Logic Apps) und Datenanalyseplattformen (z. B. Microsoft PowerBI, XOData) zurückgreifen und so Zeit und Geld in der Entwicklung sparen.

Metadaten

Als SaaS-Anbieter kann man seinen Kunden das Konsumieren das Web-API wesentlich erleichtern, indem man Metadaten zur Verfügung stellt. Tools können diese Metadaten lesen und dadurch eine grafische Oberfläche zum Zusammenklicken der gewünschten API-Operationen anbieten, sie zum automatischen Generieren von Code verwenden, daraus eine hübsche Dokumentation erzeugen und vieles mehr.

Zwei der meiner Meinung nach wichtigsten Metadatenformate für Web-APIs sind Swagger und OData. Für beide gibt es für alle gängigen Entwicklungsplattformen fertige Tools und Bibliotheken. OData hat Stärken, wenn es um Datenbank-bezogene Web-APIs geht, da der Standard eine für Web-APIs optimierte, SQL-ähnliche Abfragesprache enthält. OData spielt außerdem eine große Rolle, wenn man im Microsoft- oder SAP-Umfeld entwickelt, da beide Firmen OData in vielen Produkten und Services verwenden.

Swagger auf der anderen Seite ist allgemeiner einsetzbar und sehr weit verbreitet. Integrationsplattformen wie Microsoft Azure Logic Apps können von Haus aus Swagger-Metadaten verarbeiten. Darüber hinaus steht eine große Anzahl an Tools (z. B. Codegeneratoren, Metadateneditoren) für die Entwicklungsphase zur Verfügung.

Push, nicht Pull

Wenn Kunden SaaS-Produkte integrieren möchten, ist ein Pull-Mechanismus (z. B. „hole dir alle fünf Minuten die Daten aus X und kopiere sie in Y“) selten zufriedenstellend. Der Kunde ist wegen der Zeitverzögerung nicht glücklich und als SaaS-Anbieter kann man solche Schnittstellen wegen der regelmäßig auftretenden, relativ hohen Systemlast im Quellsystem auch nicht leiden. Man kann zwar den Schmerz reduzieren, indem man im Web-API eine einfache Filtermöglichkeit bietet, um geänderte, neue und gelöschte Datensätze seit einem gewissen Zeitstempel herauszufinden. Das sind aber alles nur provisorische Lösungen für das grundlegende Problem: SaaS-Lösungen müssen Ereignisse (z. B. das Anlegen eines neuen Datensatzes) pushen und dadurch Prozesse in nachgelagerten SaaS-Systemen auslösen.

Webhooks sind eine Lösung für diese Herausforderung, die rasch an Popularität gewonnen hat und mittlerweile von fast allen großen Anbietern unterstützt wird (z. B. Visual Studio Team Services, Microsoft Office 365, GitHub, Docker Hub, Jira, Slack, Zendesk, Dropbox, etc.). Technisch sind Webhooks HTTP-Callbacks, die von einem System aufgerufen werden, wenn gewisse Ereignisse auftreten (z. B. neue E-Mail in der Office 365 Outlook-Mailbox). Manche SaaS-Lösungen wie z. B. Visual Studio Team Services unterstützen auch weitere Kanäle wie zum Beispiel Azure Service Bus zum Benachrichtigen (die entsprechende Funktion wird dort als Service Hooks bezeichnet).

Durch die Kombination von Webhooks im Quellsystem, Integrationslösungen wie Zapier und RESTful Web APIs im Zielsystem können Kunden mit wenig Aufwand ihre gewünschten SaaS-Lösungen zu einer, aus Benutzersicht integrierten Plattform verbinden. Wenn man als SaaS-Anbieter langfristig Erfolg haben will, muss man hier mitspielen können. Microsoft macht es in ASP.NET immer leichter, in Webhooks einzusteigen. Erst kürzlich ist RC1 der ASP.NET WebHooks-Bibliothek erschienen.

Die große Herausforderung: Autorisierung

Das alles klingt zu schön um wahr zu sein, oder? Natürlich gibt es eine Menge Herausforderungen zu meistern. Die größte ist, aus meiner Sicht, die der Autorisierung. Jeder der großen Cloudanbieter versucht uns davon zu überzeugen, dass das jeweilige Identity-System (z. B. Microsoft Account FKA Windows Live ID, Azure Active Directory, Google Sign-In) das einzig Wahre ist. Zugegeben, hätten wir ein einzelnes System zur Authentifizierung und Autorisierung, wäre Softwareentwicklung einfacher. Ganzheitlich schadet ein wenig Konkurrenz und Wahlfreiheit aber keineswegs.

Was soll man als SaaS-Anbieter also machen? Mein erster Tipp wäre, so wenig wie möglich neu zu erfinden. Mit OpenID Connect und OAuth2 sind zwei Standards vorhanden, die allen modernen Identity-Systemen zugrunde liegen. Wenn man auf sie setzt, liegt man schon einmal nicht ganz falsch. Wenn man Identity Management nicht zu seinem Hauptgeschäft macht, sollte man außerdem keine Zeit darauf verwenden, die genannten Standards selbst zu implementieren. Ich empfehle, entweder auf existierende Identity-Systeme von Microsoft, Google & Co. zu setzen oder fertige Frameworks dafür zu verwenden. Diese gibt als Open Source (z. B. IdentityServer) oder in Form kommerzieller Angebote (z. B. Auth0).

Meiner Ansicht nach ist die Integration bestehender, weit verbreiteter Identity-Systeme von Vorteil. Man erleichtert es dadurch Kunden enorm, Integrationen zwischen SaaS-Lösungen zu bauen, da nicht für jedes beteiligte SaaS-Produkt getrennte Konten zu verwalten und zu verwenden sind.

Wir brauchen technische Product Owner

Neben den technischen Herausforderungen kämpfen viele Firmen, die ich auf dem Weg Richtung SaaS begleiten darf, mit organisatorischen Fragen. Product Owner sind häufig fachlich orientiert, und es fehlt ihnen an technischem Hintergrund. Die Gestaltung von Bildschirmmasken, Dashboard oder Reports ist ihnen viel wichtiger als ein sauberes Design des Web-APIs. Support-Teams sind oft nicht darauf ausgerichtet, statt fachlicher Fragen von Endbenutzern plötzlich technische Anfragen durch externe Entwickler beantworten zu müssen.

Ich bin jedoch davon überzeugt, dass es sich auszahlt, an der Lösung solcher Probleme zu arbeiten und Web-APIs als Teil des angebotenen SaaS-Produktportfolios zu betrachten. Kunden wissen es zu schätzen. Darüber hinaus werden sich neue Geschäftspotentiale entwickeln, indem Integrationspartner sich Ihre SaaS-Angebote zunutze machen, um sie in Verbindung mit anderen SaaS-Produkten als integrierte Lösungen anzubieten.
 

Lesen Sie hier alle Ausgaben der Kolumne „Stropek as a Service„!
In der Kolumne greift Rainer Stropek spannende Aspekte wie die Finanzierung, den Customer Lifetime Value, aber auch wichtige Themen wie Billing, Kundenbindung durch Qualität oder APIs auf – alles aus der Sicht eines Unternehmers, der seit 20 Jahren in der IT-Branche tätig ist und seit fünf Jahren intensive Erfahrungen mit SaaS gesammelt hat.

 

Schnell und überall: Datenzugriff mit Entity Framework Core 2.0

Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

C# 7.0 – Neues im Detail

Christian Nagel (CN innovation)

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -