Kolumne: Stropek as a Service

Weder Fisch noch Fleisch – Wie SaaS-Anbieter durch Nichtfestlegen ein Risiko eingehen
Kommentare

Dass Cloud und SaaS zwei Entwicklungen sind, denen sich nur ganz wenige dauerhaft verschließen können, hat sich mittlerweile herumgesprochen. Trotz des großen Interesses folgt dem „Ja“ zur Cloud oftmals noch ein „Aber“. Diese Zurückhaltung kann aber statt Risikovermeidung ein höheres Risiko verursachen.

In der Softwareentwicklung mag man keine Abhängigkeiten. Schon in der Ausbildung lernt man, dass Abhängigkeiten durch Abstraktionsschichten zu vermeiden sind. Ein paar Interfaces hier, etwas Inversion of Control da, plattformunabhängige Kommunikationsstandards statt proprietärer Protokolle – auf solche Dinge sind wir trainiert.

Manager sehen mehr das geschäftliche Risiko und weisen auf die Gefahr des Lock-in-Effekts hin. Wenn wir uns ganz auf eine Komponente verlassen, dann sind wir doch dem Anbieter auf Gedeih und Verderb ausgeliefert. Diesen Zustand will man vermeiden. Wenn es um SaaS und Cloud geht, übersehen viele jedoch die Nachteile, die mangels klarer Festlegungen unbewusst in Kauf genommen werden.

„Cloud ja, aber …“

Dass Cloud und SaaS zwei Entwicklungen sind, denen sich nur ganz wenige dauerhaft verschließen können, hat sich mittlerweile herumgesprochen. Die Zahlen, die die großen Cloud-Anbieter veröffentlichen, zeigen das in beeindruckender Weise. Auch persönlich nehme ich in meiner Arbeit mit Kunden stark steigendes Interesse an Cloud und SaaS wahr. Wenn ich von Kunden zu entsprechenden Architekturworkshops eingeladen werde, folgen dem „Ja zu Cloud“ in den meisten Fällen einige „Aber“. Hier ein paar Beispiele:

  • Cloud ja, aber wenn ein Kunde will, müssen wir unsere Software auch in seinem Rechenzentrum installieren können.
  • SaaS ja, aber wenn ein Kunde unbedingt kaufen statt mieten will, brauchen wir dafür eine Antwort.
  • Microsoft Azure ja, aber nur Dienste, die auch außerhalb von Azure existieren, damit wir in keine Lock-in-Falle tappen.
  • Cloud ja, aber ohne große Änderungen an unserer Software. Größere Umbauten machen wir aber erst, wenn wir sehen, dass die Nachfrage der Kunden nach Cloud vorhanden ist.

Höheres Risiko durch scheinbare Risikovermeidung

Argumentationen wie die obigen erscheinen auf den ersten Blick rational und sinnvoll. Schließlich will man für alle Fälle gerüstet zu sein. Leider hat die Sache einige ganz gewaltige Haken. Je mehr Optionen man sich offen hält, desto mehr sitzt man zwischen den Stühlen. Man kann weder die Vorteile von SaaS und Cloud Computing so richtig ausnutzen noch die Konzentration voll und ganz auf eine On-Premise-Strategie lenken. Das Angebot wird weder von Cloud-Enthusiasten noch von Cloud-Verweigerern als vollwertig angesehen. Man ist weder Fisch noch Fleisch.

Vergebene Einsparungspotenziale

Wer sich in der Cloud nur auf Dienste und Funktionen beschränkt, die genauso auch für die Installation im eigenen Rechenzentrum zur Verfügung stehen, lässt ein hohes Einsparungspotenzial links liegen. Ein Beispiel: Angenommen, Sie brauchen für Ihre Software Volltextsuche. Microsoft bietet mit Azure Search einen fertigen Dienst, der in wenigen Minuten aktiviert und einsatzbereit ist. Kein Herumschlagen mit Servern, VMs, Containern oder Ähnlichem. Kein Schreiben komplizierter Scripts zum Skalieren je nach Abfragelast. Keine Administratoren zum Konfigurieren des Hochverfügbarkeitsclusters und Einrichten von Back-ups. Stattdessen ein paar Klicks und los gehts.

„Ja, aber dann sind wir doch in Azure eingesperrt“. Stimmt, na und? Wenn ein fertiger PaaS-Dienst genau das tut, was man braucht und man dadurch massive Vorteile in puncto Kosten und Time to Market bekommt, warum nicht zugreifen? Ja, man wird Kunden mit gehöriger Cloud-Skepsis verlieren, man wird aber auch Kunden durch niedrigere Preise und bessere Funktionen gewinnen. Nur das Lock-in-Risiko zu sehen und vor den Vorteilen die Augen zu verschließen, ist keine gute Strategie. Die Cloud kann bisher Unerreichbares durch Kosteneinsparungen, Skaleneffekte, Hochverfügbarkeit, Hochskalierbarkeit etc. möglich machen.

Verschlafene Umbaumaßnahmen

In die Jahre gekommene Software ist naturgemäß nicht für den Betrieb in der Cloud gebaut. Die meisten Softwarearchitekturen, mit denen ich in der Praxis konfrontiert werde, sehen Cluster als etwas Besonderes, gehen von einer stabilen Serverumgebung aus, setzen spezifische Konfigurationen auf Betriebssystemebene voraus, speichern Daten lokal auf Anwendungsservern etc. Durch Infrastructure as a Service (IaaS) und Containertechnologie kann man heute auch solche Anwendungen mit geringfügigen Änderungen in die Cloud bringen.

Genau hier lauert die Gefahr: Es ist verlockend, den Weg des geringsten Widerstands zu gehen, größere Umbaumaßnahmen zu vermeiden und den Schritt in die Cloud mit IaaS zu gehen. Der Haken dabei ist, dass man dadurch – wenn überhaupt – nur einen Bruchteil des Potenzials der Cloud nutzt. Die Kosten sinken nicht spürbar, funktional ändert sich nichts Wesentliches, Kunden und Entscheidungsträger sind enttäuscht, und schon wird das Experiment „Cloud“ als gescheitert eingestuft.

Die Power der Cloud kommt oft erst zum Tragen, wenn die Software bereit dafür ist. Den notwendigen Investitionen für SaaS und Cloud muss man die neuen Möglichkeiten gegenüberstellen. Zwei konkrete Beispiele:

  • Der Umstieg von Single-Tenancy auf Multi-Tenancy ist nicht einfach. Ist er gemacht, kann man als SaaS-Anbieter Skaleneffekte nutzen. Die Grenzkosten des Betriebs eines Tenants sind wesentlich niedriger als die Kosten, die ein Kunde bei Betrieb im eigenen Rechenzentrum kalkulieren müsste.
  • PaaS-Umgebungen wie Azure App Service oder Azure SQL Database haben gegenüber ihren lokal installierbaren Verwandten IIS und SQL Server gewisse Einschränkungen. Die Software muss eventuell darauf vorbereitet werden. Danach fallen die Administrationskosten jedoch auf nahezu null.

Komplexe Preismodelle

Auf der geschäftlichen Seite ist es oft das SaaS-Preismodell, bei dem man vor der notwendigen Konsequenz zurückschreckt. Man hat Angst, Bestandskunden durch Preismodelländerungen zu verärgern. Man möchte sowohl Käufer als auch Mieter möglichst gut bedienen. Man will es jedem recht machen, erntet aber Durcheinander und Verwirrung. Dazu kommt, dass viele Hersteller Angst vor der Flexibilität und Transparenz haben, die SaaS dem Endkunden gibt. Schließlich kann das SaaS-Abonnement jederzeit gekündigt werden, wenn die Software nicht mehr benötigt wird oder nicht das hält, was sich der Kunde versprochen hat.

Ich möchte auch hier wieder dafür plädieren, offen für Neues zu sein. Ein einfaches Preismodell ohne Aufzwingen von Mindestfristen oder Mindestmengen macht es dem Kunden leichter, einzusteigen und zu probieren. Natürlich wird man Kunden durch die einfache Kündigungsmöglichkeit im Lauf der Zeit verlieren. Man gewinnt aber auch solche, die die Software bei einem klassischen Lizenzmodell nicht einmal in Betracht gezogen hätten. Es wird auch passieren, dass Kunden die Abonnementgröße an die tatsächliche Nutzung anpassen statt Unmengen an Lizenzen zu kaufen, die keiner verwendet. Dagegen steht ein einfacherer und kürzerer Vertriebsprozess, da die Einstiegshürde für den Endkunden durch ein nutzungsabhängiges SaaS-Preismodell sinkt.

Risiko Opportunitätskosten

Risikomanagement ist berechtigt, keine Frage. Wer sich dabei jedoch rein darauf konzentriert, sich alle Möglichkeiten offen zu halten, übersieht, dass gerade dadurch ein neues Risiko entsteht: Opportunitätskosten dürfen nicht außer Acht gelassen werden, wenn man die Möglichkeiten von SaaS und Cloud Computing nicht voll ausschöpft. Diese Opportunitätskosten sind sehr real. Sie machen sich durch höhere Entwicklungskosten, Personalkosten für Systemadministration, längere Projektlaufzeiten etc. bemerkbar. Im Gegensatz dazu sind die Risiken durch den Lock-in-Effekt schwer in Zahlen zu fassen. Man fürchtet sich vor der Einstellung von Services oder Preiserhöhungen, weiß aber nicht, ob und in welchem Ausmaß diese Dinge jemals eintreten werden.

Eine Möglichkeit zur Risikoreduzierung ist in manchen Fällen der Einsatz plattformunabhängiger Protokolle und Bibliotheken, die sowohl von PaaS-Services in der Cloud als auch von lokal verfügbaren Produkten unterstützt werden. Hier einige Beispiele:

AMQP für Messaging (wird auch vom Azure Service Bus unterstützt)
• MongoDB-Protokoll für NoSQL (wird auch vom Azure-Dienst DocumentDB unterstützt)
iisnode (unterstützt Node.js in IIS und Azure)
• T-SQL (große Schnittmenge zwischen SQL Server und Azure SQL Database)

Wer jedoch meint, mit diesem Ansatz alle Problem gelöst zu haben, irrt. Meist handelt es sich um eine Teilmenge der vom Cloud-Dienst gebotenen Funktionen. Wer wirklich in den Genuss der vollen Leistungsfähigkeit kommen wird, muss zumindest in Teilbereichen die nativen Protokolle und Bibliotheken nutzen. Den Umstellungsaufwand für den Fall der Fälle reduzieren kann man dadurch aber allemal.

Bewusste unternehmerische Entscheidungen

Meiner Meinung nach kann man die Risiken und Chancen von reinrassigem SaaS in der Cloud nicht auf Punkt und Komma berechnen. Es gilt, strategische, unternehmerische Entscheidungen zu treffen, für die man fundierte Kenntnisse des Markts auf Kunden- und Lieferantenseite braucht. Man kann versuchen, diese Entscheidungen bis zu einem gewissen Grad abzusichern, indem man zum Beispiel

  • durch Prototypen die Vorteile von PaaS in der Cloud besser abschätzen lernt,
  • auf Grundlage eines Testbetriebs mit einer eingegrenzten Kundengruppe die zukünftigen Cloud-Kosten einschätzt,
  • die Kundenreaktion durch regional oder inhaltlich abgegrenzte SaaS-Angebote testet,
  • die Vertrauenswürdigkeit von Cloud-Anbietern bewertet, indem man sich ihr Verhalten in der Vergangenheit und ihre Marktstellung genau ansieht etc.

Zögert man aber zu lange oder macht man den Schritt nur halbherzig, läuft man Gefahr, dass einem „junge Wilde“, die alles auf die SaaS- und Cloud-Karte setzen, ordentlich zusetzen.

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

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -