Kolumne: Stropek as a Service

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

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 Konkurrenz zu wechseln. Aus Kundensicht ist das natürlich angenehm, aus Anbietersicht wird aber der Druck erhöht. Schließlich könnten unzufriedene Kunden relativ leicht wechseln. Mein Tipp: Diesen Nachteil in Kauf nehmen. Niemand sollte gezwungen werden, ein SaaS-Angebot zu nutzen, das er nicht nutzen will. Ein offensichtlicher Lock-in-Effekt zeugt von Schwäche und kann im Vertrieb nach hinten losgehen.
  • Eine technische Dokumentation der Schnittstellen muss her, die übliche Endbenutzerdokumentation reicht nicht. Ist die Dokumentation schlecht oder lückenhaft, steigt der technische Supportaufwand. Mein Tipp: Fokus auf konzeptionelle Dokumente legen und Details mithilfe von Standards wie Open API Initiative (OAI) und zugehöriger Tools und Bilbiotheken (z. B. Swashbuckle für .NET) beschreiben.
  • Die Nutzung muss gedrosselt (Throttling) werden können, um zu verhindern, dass ein übermotivierter Entwickler, zum Beispiel durch eine unabsichtliche Endlosschleife, das System lahmlegt. Mein Tipp: Fertige Cloud-Dienste wie Azure API Management nutzen. Eine solche Absicherung selbst zu entwickeln, wäre viel zu aufwendig.
  • Der eine oder andere SaaS-Anbieter finanziert günstige Basisdienste durch relativ teure Spezialerweiterungen quer. Ein API kannibalisiert dieses Geschäftsmodell. Schließlich können sich Kunden eigene Tools entwickeln. Mein Tipp: Diesen Nachteil in Kauf nehmen. Nachhaltiger Erfolg im Bereich SaaS basiert auf einem Vertrauensverhältnis zwischen Anbieter und Kunden. Wenn der Kunde das Gefühl hat, ihm wird das Geld aus der Tasche gezogen, ist das nicht gerade vertrauensfördernd.

Schritt 2: Open-Source-Software und Open Data

Viele SaaS-Anbieter verwenden gerne Open-Source-Software und Open Data für ihre Produktentwicklung. Schließlich sind diese Angebote kostenlos und häufig von hoher Qualität. Wer es mit der Offenheit ernst nimmt, sieht Open Source aber nicht als Einbahnstraße. Open Source und Open Data funktionieren nur, wenn die Community nicht nur aus Egoisten besteht, die ausschließlich nehmen und nichts geben wollen. Moderne SaaS-Anbieter tragen ihren Teil zur Community bei, indem sie beispielsweise

  • Wissen teilen (z. B. in Form von Blogartikeln, Vorträgen auf Communitykonferenzen etc.),
  • eigene Komponenten als Open-Source-Projekte veröffentlichen,
  • in bestehende Open-Source-Projekte Zeit und/oder Geld investieren oder
  • die Community anderweitig unterstützen (z. B. Sponsoring, ihre Räume für Meetups zur Verfügung stellen).

Für aktives Beitragen zur Open-Source-Community braucht es aber entsprechende Vorkehrungen und Überlegungen. Hier einige Beispiele:

  • Die organisatorischen Rahmenbedingungen müssen geschaffen werden, damit die Mitarbeiterinnen und Mitarbeiter in der Community mitwirken können. Mein Tipp: Open Source und Open Data in allen Dienstverträgen und Betriebsvereinbarungen berücksichtigen und klare, einfache Regeln fixieren (z. B. bei Arbeitszeitbestimmungen, Geheimhaltungsverpflichtungen etc.).
  • Das Management muss eingebunden werden und man braucht dessen Unterstützung. Es müssen sich alle im Unternehmen darüber im Klaren sein, dass auch die Konkurrenz von den eigenen Entwicklungen profitieren kann. Mein Tipp: Ein erfolgreiches Open-Source-Projekt, das viele nutzen (inklusive der Konkurrenz), ist eine Auszeichnung für ein Entwicklungsteam und kann beispielsweise beim Recruiting sehr positive Wirkung haben.
  • Langfristige Planung darf nicht vergessen werden. Wer ein Open-Source-Projekt startet, sollte sich auch um die Weiterentwicklung und Wartung kümmern. Mein Tipp: Roadmap offen kommunizieren und soweit möglich einhalten. Wenn man einem Projekt keine Aufmerksamkeit mehr schenkt, sollte das deutlich gemacht werden.
  • Wer Open Source ernst nimmt, legt auch die Projektplanung offen. Mein Tipp: Produktplanung, Bug-Tracking etc. für jeden Interessierten auf einer Plattform wie GitHub sichtbar machen.

Schritt 3: Blockchain

Ein nächster Schritt in Richtung eines offenen Systems ist die Verwendung von Blockchain-Technologie. Damit meine ich nicht Bitcoins und andere Cryptocurrencies, sondern Blockchain-Plattformen neuerer Generation wie Ethereum oder IOTA. Nehmen wir Ethereum als Beispiel. SaaS-Anbieter können damit auf die zentrale Speicherung und Verarbeitung von Daten in einer von ihnen kontrollierten, zentralisierten Cloud verzichten. Daten und Code werden stattdessen Teil der global verteilten Blockchain. Das bedeutet nicht zwangsläufig radikale, uneingeschränkte Offenlegung aller vorhandenen Informationen und das Ende von Privatsphäre. Durch Anonymisierung und Pseudonymisierung sowie Verschlüsselung können Daten weiterhin bis zu einem gewissen Grad geschützt werden. Eine gewisse Veröffentlichung liegt aber in der Natur der Sache.

Aus meiner Sicht ist gerade die Tatsache das Interessante an Blockchains, dass der Datenzugriff und die Interaktion mit dem damit verbundenen Code (Smart Contracts) nicht mehr nur auf einen zentralen SaaS-Anbieter beschränkt ist. Organisationsübergreifende Zusammenarbeit wird auf ein ganz neues Niveau gehoben. Fehleranfälliger und zeitraubender Datenaustausch über Schnittstellen ist nicht mehr notwendig, da die Systemteilnehmer auf derselben verteilten Datenstruktur operieren. Man könnte sagen, die Demokratie erreicht dadurch die Cloud.

Ich kenne eine Menge SaaS-Anbieter, die Blockchain auf ihrer Technologieroadmap stehen haben. Es wird dabei oft übersehen, dass dieser Schritt eine radikale Öffnung nach außen bedeutet. Ich habe so meine Zweifel, dass Firmen, die heute schon Schwierigkeiten damit haben, öffentliche APIs in nennenswertem Maß anzubieten, bereit für öffentliche Blockchains sind. Was soll eine Organisation, die keinerlei Erfahrung mit eigenen Open-Source-Projekten hat, von einem Tag auf den anderen organisatorisch und technisch in die Lage versetzen, mit den Konsequenzen von Blockchains umzugehen?

Chance für kleine SaaS-Anbieter

Für kleine SaaS-Anbieter ist die Blockchain meiner Ansicht nach eine große Chance. Die meisten werden aufgrund ihrer beschränkten Ressourcen und limitierten Möglichkeiten zur Einflussnahme auf den Markt wahrscheinlich keine weltbewegenden Smart Contracts etablieren, die außerhalb von Marktnischen eine Rolle spielen. Wenn sich aber größere Organisationen oder ganze Branchen dazu durchringen, Zentralisierung aufzugeben und Teile ihres Geschäfts über öffentliche Blockchains abzuwickeln, öffnet das einen riesigen Markt für begleitende Software. Als Kunde bin ich dann nicht mehr zwangsläufig angewiesen auf Software, die von dem SaaS-Anbieter kommt, der auch die Daten kontrolliert. Der Lock-in-Effekt wird kleiner, Konkurrenz wird das Geschäft beleben und Innovation beschleunigen. Die Open-Source-Bewegung hat das schon einmal vorgemacht, die Blockchain hebt das Prinzip auf das nächste Level.

Lesen Sie 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.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -