© best_vector/Shutterstock.com
Kolumne: Stropek as a Service

Die Wolken reißen auf: Was bedeuten Open Source, Open Data, Blockchain und Co. für SaaS?


Offene Software und Daten – in der öffentlichen Wahrnehmung sind diese Begriffe durchweg positiv besetzt. Mit Offenheit verbindet man, dass jederzeit mit jeder Technologie und von jeder Plattform aus mit Softwaresystemen interagiert und auf Daten zugegriffen werden kann. Offene Software und offene Daten sind auch deshalb beliebt, weil man dadurch erstens kostenlos zu wertvollen Komponenten kommt, auf denen man bei der eigenen Entwicklungsarbeit aufbauen kann. Zweitens wird organisationsübergreifende Zusammenarbeit gefördert. Die Annahme ist, dass bessere Ergebnisse entstehen, wenn viele Leute ihre Köpfe virtuell zusammenstecken und niemand die ganze Last alleine tragen muss. Doch welche Konsequenzen hat der Trend zu Offenheit für SaaS-Anbieter? Bringt das nur Vorteile oder gibt es Nebenwirkungen, die berücksichtigt werden müssen?

Schritt 1: Offene Schnittstellen

Beginnen wir unsere Überlegungen bei der ersten grundlegendsten „Offenlegung“, die ein SaaS-Anbieter vornehmen kann: das Anbieten plattform- und technologieunabhängiger Programmierschnittstellen. Über technische Details kann man natürlich streiten (z. B. REST, GraphQL oder vielleicht doch OData), generell kann man aber sagen, dass mittlerweile HTTP-basierende Web-APIs als Industriestandard etabliert sind. Meiner Ansicht nach haben moderne SaaS-Anbieter heute keine Option mehr, als sich nach außen über solche Schnittstellen zu öffnen. SaaS-Produkte ohne Web-API wirken altbacken und werden von Kunden mehr und mehr abgelehnt.

Die Entscheidung, ein offenes Web-API anzubieten, hat aber eine Menge Konsequenzen. Hier einige Beispiele:

  • Das API muss abgesichert sein. Traditionelle Log-in-Formulare mit Benutzer und Passwort sind keine Option. Am besten greift man auf Standards wie OpenID Connect (OIDC) zurück, die allerdings nicht ganz einfach zu erlernen und mit entsprechenden Betriebskosten verbunden sind. Mein Tipp: Fertige OIDC-Dienste wie Azure Active Directory oder Auth0 nutzen oder – wenn das nicht geht – auf vorhandene Open-Source-Bibliotheken wie IdentityServer zurückgreifen.

  • Der Support muss darauf vorbereitet sein, technische Fragen zu beantworten. Die Fragen rund um das API werden ganz andere sein als die, die normale Endbenutzer zum UI stellen. Fragen zum API können aufwendig zu beantworten sein. Mein Tipp: Klare Regeln für API-Support erstellen, kommunizieren und vielleicht sogar ein gesondertes Verrechnungsmodell überlegen.

  • APIs machen es Kunden leicht, die Daten abzusaugen, um zur Konkurren...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang