Cloud Computing - was bringt's? (German)

Am 27. September 2012 durfte ich gemeinsam mit Thomas Rümmler von AIT einen Vortrag zum oben genannten Thema auf dem 2. Symposium für Software Architektur und effiziente Entwicklung variantenreicher Systeme der Technischen Akademie Esslingen (Stuttgart) halten. Die Slides für unseren Vortrag finden Sie unten. Der Text wurde im Tagungshandbuch (ISBN 978-3-943563-01-6) veröffentlicht.

Autoren

Thomas Rümmler
AIT GmbH & Co. KG, Stuttgart

Rainer Stropek
software architects gmbh, Linz, Österreich

Zusammenfassung

Ist Cloud Computing für Sie sinnvoll? Sollten Sie auf Platform-as-a-Service bei Ihrer Softwareentwicklung setzen? Entsteht durch Cloud Computing für Ihr Unternehmen ein Mehrwert?

Beim Einsatz einer Cloud-Plattform, wie z.B. Windows Azure, können sich Vorteile für Ihre Softwareentwicklung und Ihr Unternehmen ergeben. Es gibt verschiedene Einsatzszenarien, in denen Cloud Computing besonders geeignet ist. Die Wahl des Abstraktionsniveaus (SaaS, PaaS, IaaS) in Verbindung mit den richtigen Designentscheidungen sind richtungsweisend.

Die Projekte time cockpit und TFM stellen exemplarisch die Unterschiede im Softwareentwicklungs- und Betriebsprozess bei SaaS Lösungen in der Cloud im Vergleich zur klassischen Softwareentwicklung für den Vorortbetrieb dar. Die beiden Produkte waren zwei der ersten Lösungen aus dem deutschsprachigen Raum, die von Grund auf für SaaS und Cloud konzipiert wurden.

1. Grundlagen

1.1 Einführung in Cloud Computing

Die Top Ten IT-Trends für das Jahr 2012 der Analysten Gartner, Forrester, PAC, IDC und Experton Group beinhalten Cloud Computing. (vgl. Kurzlechner, 2011, S. o.A.) Armbrust et al. bewerten den Einfluss von Cloud Computing wie folgt: „Cloud Computing is likely to have the same impact on software that foundries have had on the hardware industry.“[1] (Armbrust et al., 2009, S. 2–3) Laut Benlian et al. werden die aktuellen Entwicklungen der großen Unternehmen in der IT-Branche, wie Microsoft oder SAP, als „[…] Basis für neue, ‚as-a-Service‘-basierte Software-Ecosysteme gelegt.“ (Benlian et al., 2010, S. 58)

Die Cloud scheint zu verändern. Diesen Eindruck bestätigt auch Gunter Dueck, der in seiner Kolumne DUECK-β-INSIDE, welche regelmäßig im Informatik Spektrum[2] veröffentlicht wird, einen Artikel namens Cloudwirbel verfasst hat. Direkt in der Einleitung formuliert er die Auswirkungen auf die IT wie folgt: „Die Cloud beginnt, unsere ganze IT durcheinander zu wirbeln!“ (Dueck, 2011, S. 309)

Doch was steckt dahinter? Welcher Mehrwert ergibt sich für Softwarehersteller und welche Auswirkungen hat das auf die Architektur?

In Deutschland gibt es noch keine eindeutige, standardisierte Definition von Cloud Computing. Derzeit arbeitet das Deutsche Institut für Normung e.V. (DIN)[3] im Arbeitsausschuss für Verteilte Anwendungsplattformen und Dienste des Normenausschusses für Informationstechnik und Anwendungen an der Normierung des Begriffs. (vgl. DIN, 2011, S. 1) Jedoch gibt es noch weitere, unterschiedliche Ansätze, den Begriff zu erläutern.

So veröffentlicht beispielsweise das Fraunhofer Institut auf seiner Website eine Erklärung zu Cloud Computing. Nachfolgend ein Auszug daraus: „Cloud Computing bezeichnet […] ein IT-Modell, das weit über das reine Computing - also die Nutzung von Rechenleistung - hinaus geht. Im Wesentlichen bezeichnet Cloud Computing die Auslagerung von IT-Diensten an externe Dienstleister. Diese kann neben Rechenleistung und Speicherkapazitäten (Infrastructure-as-a-Service) auch die Bereitstellung von Plattformen mit Mehrwertdiensten wie Sicherheitslösungen und Abrechnungsdiensten oder […] die Nutzung von Software-as-a-Service in vielen verschiedenen Ausprägungen umfassen.“ (Fraunhofer-Allianz Cloud Computing, 2011, S. o.A.)

Auch der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V. (BITKOM)[4] beschäftigt sich mit dem Thema. In seinem Leitfaden Cloud Computing ist folgende Erläuterung zu finden: „Cloud Computing ist eine Form der bedarfsgerechten und flexiblen Nutzung von IT-Leistungen. Diese werden in Echtzeit als Service über das Internet bereitgestellt und nach Nutzung abgerechnet. Damit ermöglicht Cloud Computing den Nutzern eine Umverteilung von Investitions- zu Betriebsaufwand.“ (BITKOM, 2009, S. 9)

Alternativ kann sich auf die formal festgeschriebene Definition des National Institute of Standards and Technology [5] (NIST) stützen, einer Behörde, die zum US-amerikanischen Handelsministerium gehört.

Die Definition von Cloud Computing des NIST[6] beginnt wie folgt: „Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.“ [7](Mell & Grance, 2011, S. 2)

Das NIST listet in seiner Definition fünf grundlegende Eigenschaften auf: On-demand self-service, Broad network access, Resource pooling, Rapid elasticity sowie Measured service. (vgl. Mell & Grance, 2011, S. 2) Gartner [8] hingegen stellt folgende fünf Kriterien von Cloud Computing besonders heraus: Service-Based, Scalable and Elastic, Shared, Metered by Use sowie Uses Internet Technologies. (vgl. Gartner, 2009, S. o.A.) Die wohl bekannteste Eigenschaft ist bei Gartner als Metered by Use gekennzeichnet. Bei der NIST Definition hingegen ist diese Eigenschaft nicht separat aufgelistet. Hier verbirgt sich das Merkmal hinter drei anderen Aspekten.

1.2 Anbieter

Aus Sicht der ISVs sind Anbieter von Platform as a Service von besonderem Interesse. Dieses Angebot zielt speziell auf Softwareentwickler und bietet ihnen eine Plattform, auf deren Basis Software hergestellt werden kann (vgl. 3.1).

Für eine Cloud-Plattform gibt es aktuell vier große Anbieter. Es handelt sich dabei um Amazon, Google, Microsoft und Salesforce. (vgl. Meir-Huber, 2010, S. 79, 118, 151, 161) Amazon tritt mit seinem Produkt Amazon Web Services[9] am Markt auf. Google nennt seine Plattform Google App Engine[10]. Microsofts Cloud-Plattform ist unter dem Namen Windows Azure Platform[11] zu finden und Salsforce hat die Plattform force.com[12] rund um sein CRM-System erstellt.

Anbieter von Cloud-Plattformen sind in Ihrer Anzahl deutlich geringer am Markt vertreten, als Anbieter von Infrastructure as a Service (vgl. 3.1). Dies liegt darin begründet, dass der Plattformenmarkt ein junger Markt ist, während Anbieter im Bereich Infrastructure as a Service auf die Erfahrungen aus Hostingangeboten zurückgreifen können. Eine Auswahl und Klassifikation der großen Managed Hosting Provider in Europa steht in der Studie Managed hosting in Europe des Marktforschungsunternehmens Quocirca [13] zur Verfügung (vgl. Tarzey & Longbottom, 2009, S. 7)

2. Hosting vs. Cloud

2.1 Abgrenzung

Hostingangebot und Cloud-Dienstleistungen lassen sich eindeutig von einander unterscheiden. Dazu dienen folgende Abgrenzungsfaktoren:

Abgrenzungsfaktor Abstraktion: Plattformorientiertes Cloud Computing arbeitet auf einem höheren Abstraktionslevel als Hosting.

Eine Parallele der Abstraktion lässt sich zwischen Hosting und Infrastructure as a Service ziehen. Eine Cloud-Plattform bietet seinen Kunden Dienste auf einer höheren logischen Ebene, als reine Verwaltungsdienste. Dem Anwendungsentwickler wird eine Entwicklungsumgebung bereitgestellt, die bereits spezielle APIs zur Abstraktion der darunterliegenden Schicht anbietet. Der Zugriff auf das darunterliegende Betriebssystem bleibt in diesem Fall verwehrt. (vgl. Meir-Huber, 2010, S. 44)

Die Abstraktion ruft Einschränkungen hervor, die zu geringerer Flexibilität führen. Beispielsweise kann die Anwendung mit niedrigeren Berechtigungen ausgeführt werden, wodurch der Schreibzugriff auf das lokale Dateisystem unterbunden werden kann. (vgl. Krishnan, 2010, S. 8)

Auf der anderen Seite bietet die Abstraktion die Möglichkeit, Dienste zu nutzen, ohne sie selbst implementieren zu müssen (vgl. Abbildung 1). „Platform providers also provide abstractions around services (such as email, distributed chaches, structured storage) […]“ [14] (Krishnan, 2010, S. 8)

Abbildung 1: Plattformkomponenten

In der Abbildung 1 ist zu erkennen, dass eine entwickelte Anwendung lediglich über ein API gekapselt auf die eigentlichen Ressourcen zugreifen kann, ebenso auf Zusatzdienste wie E-Mail. Der Vorteil liegt hierbei in der Kapselung der eigentlichen Implementierung. Der Entwickler kann diese Dienste als fertige Bausteine verwenden.

Abgrenzungsfaktor Entwicklungsplattform: Eine Cloud-Plattform dient als Betriebs- und Entwicklungsplattform.

Bei PaaS wird eine Anwendung nicht nur gehostet. Eine Anwendung wird für die Plattform entwickelt, um deren API inklusive zusätzlicher Dienste nutzen zu können. Dies soll am Beispiel eines Speichermediums verdeutlicht werden. Ein Datenspeicher kann ein Dateiserver sein, auf den über Netzwerkfreigaben zugegriffen wird. In einer PaaS-Umgebung hingegen kann es einen Speicherdienst geben, der folgende zusätzliche Eigenschaften hat:

• Sicherung der Daten durch Redundanz
• Bereitstellung einer automatischen Ausfallsicherung
• Verteilen von Daten übers Internet

Diese Merkmale werten einen Speicherdienst im Gegensatz zu einem Dateiserver auf. (vgl. Pallmann, 2011, S. 42)

Abgrenzungsfaktor Zielgruppe: Cloud-Plattformen adressieren nicht IT-Dienstleister, sondern ISVs.

Die Zielgruppe unterscheidet sich von der bei IaaS bzw. Hosting. PaaS-Leistungen nehmen bevorzugt Softwareentwickler in Anspruch, um darauf aufbauend Ihre Lösung zu erstellen. Dabei werden die Funktionen von PaaS als technisches Framework verwendet. „Es stellt als Basis die Entwicklungs- oder Applikationsplattform für darauf aufsetzende SaaS-Angebote[[15]] bereit.“ (Fröschle & Reinheimer, 2010, S. 10)

Abgrenzungsfaktor Zusatzdienste: Eine Cloud-Plattform stellt auf der einen Seite eine Infrastruktur bereit, auf der ein System betrieben wird. Auf der anderen Seite bringt sie noch weitere Dienste mit, die durch die Anwendung verwendet werden können.

Beispiele dafür sind Abrechnungsservices für den Software as a Service Betrieb, Authentifizierungsdienste, Benachrichtigungssysteme, Caching und Überwachung. Selbst beim Vertrieb der entwickelten Anwendung kann eine Cloud-Plattform in Form digitaler Marktplätze unterstützen.

2.2 Architektur

Die Betriebsart ist deshalb bei der Entwicklung einer Software basierend auf Platform as a Service nicht frei wählbar. Es kann kein Setup an den Kunden ausgeliefert werden, welches auf einem Client installiert und die Software dann betrieben wird. Da PaaS eine Entwicklungs- und Betriebsplattform zugleich ist, schreibt sie den Betrieb auf der Plattform vor, auf der eine Software entwickelt wird.

Die Entscheidung für eine bestimmte Plattform hat Einfluss auf die Laufzeitumgebung, Entwicklungswerkzeuge sowie den Entwicklungsprozess. Sie kann eine starke Abhängigkeit des Softwareentwicklers vom Plattform-Anbieter erzeigen. (vgl. Tietz et al., 2011, S. 353) Dem kann jedoch durch Einhaltung von bereits bestehenden Konzepten einer guten Software-Architektur entgegengewirkt werden.

So sollte man beispielsweise bei der Anbindung der Datenhaltungsschicht einer Anwendung nicht auf proprietäre Protokolle und Verfahren eines Anbieters aufbauen. Vielmehr ist es ratsam, auf Standards, wie z.B. ODATA, welche von verschiedenen Cloud-Plattform-Anbietern unterstützt werden, zu setzen.

Eine andere Form der Sicherstellung von Unabhängigkeit ist die konsequente Kapselung von Zugriffen. Wenn man an bestimmten Stellen auf plattformanbieterspezifische Komponenten zugreifen muss, so kann über durchgängige Kapselung der Wechsel auf eine andere Plattform mit gut kalkulierbarem Aufwand durchgeführt werden. Da in diesem Fall bestimmte Bibliotheken plattformspezifisch ausgelegt sind, müssen diese bei einem Wechsel ausgetauscht werden.

Die Bindung an einen Anbieter kann jedoch unter Ausnutzung der plattformspezifischen Vorteile auch ganz bewusst erfolgen. Eine Generalisierung durch zusätzliche Schichten bedeutet in der Regel einen höheren Aufwand. Bei Zielumgebungen, die das App-Konzept, also der Einbettung von Anwendungen in eine Basisapplikation, verfolgen, kann eine enge Bindung durchaus gewünscht sein. Auch wenn das soziale Netzwerk facebook [16] nicht zu den typischen Cloud-Plattformen zählt, so gibt es gewisse Parallelen. Es erscheint jedoch im Kosten-Nutzen-Verhältnis wenig sinnvoll, den Zugriff auf die einzelnen facebook-Funktionen durch zusätzliche Schichten zu abstrahieren, um die Anwendung auch außerhalb von facebook betreiben zu können.

3. Mehrwert der Cloud

3.1 Unterschiedliche Abstraktionsniveaus

Cloud Computing wird in drei Bereiche unterteilt. In der Definition des NIST sind dies die Servicemodelle Infrastructure as a Service, Platform as a Service sowie Software as a Service. (vgl. Mell & Grance, 2011, S. 2–3)

IaaS ist in seiner Struktur einer lokalen IT-Infrastruktur ähnlich. Vom Anbieter werden virtuelle Server (die Infrastruktur), zur Verfügung gestellt. Dadurch spart sich der Kunde die Anschaffung und den Betrieb von Hardware in eigenen Rechenzentren, da sie vom Service Provider on-demand angeboten wird.

Es wird deutlich, dass es eine Verwandtschaft von IaaS zu traditionellem Hosting gibt. Bei IaaS kann man jedoch regelmäßig auf einfache Art Instanzen hinzufügen oder entfernen. Dabei kommt dem Self-Service eine besondere Bedeutung zu. Außerdem ist man nicht langfristig durch Verträge an den Anbieter gebunden ist.

Platform as a Service stellt die nächst höhere Abstraktionsschicht dar. Die Abstraktion ruft Einschränkungen hervor, die zu geringerer Flexibilität führen. Beispielsweise kann die Anwendung mit niedrigeren Berechtigungen ausgeführt werden, wodurch der Schreibzugriff auf das lokale Dateisystem unterbunden werden kann. (vgl. Krishnan, 2010, S. 8)

Auf der anderen Seite bietet die Abstraktion die Möglichkeit, Dienste zu nutzen, ohne sie selbst implementieren zu müssen. „Platform providers also provide abstractions around services (such as email, distributed chaches, structured storage) […]“ [17] (Krishnan, 2010, S. 8)

Software as a Service ist die abstrakteste Form von Cloud Computing und repräsentiert die Möglichkeit, eine Software über das Internet bei Bedarf zur Verfügung zu stellen. (vgl. Meir-Huber, 2010, S. 46) „[O]nlinefähige Standardanwendungen [werden] dem Kunden skalierbar angeboten […]. Diese können im Unternehmenskontext betrieben werden und bedürfen lediglich grundlegender unternehmensindividueller Einstellungen.“ (Fröschle & Reinheimer, 2010, S. 11)

In der Rolle des Softwareentwicklers bzw. ISVs wird die Wahl in der Regel auf den Einsatz einer Cloud-Plattform fallen. Es gibt Fälle, z.B. bei der Verwendung von Legacy-Anwendugen, bei denen die Vorteile einer Plattform nicht genutzt werden, in denen man sich auf IaaS beschränkt. Auch hybride Ansätze bei denen beide Varianten gemischt werden, sind denkbar. SaaS ist ein mögliches Ergebnis, welches der ISV erbringen kann aber nicht muss.

Je nach Wahl des Abstraktionsniveaus kann der Cloud-Provider mehr oder weniger zur Veredelung in der Wertschöpfung des Softwareentwicklungsprozesses beitragen.

3.2 Services

Die Zusatzdienste, die eine Cloud-Platform bereithält sind sehr vielfältig. Nachfolgend werden exemplarisch zwei dieser Dienste näher beleuchtet.

Authentifizierung in der Cloud (ACS)

Eine Software, die öffentlich über das Internet zugänglich ist, benötigt in der Regel einen Mechanismus zur Authentifizierung. Eine Cloud-Plattform kann hierfür bereits einen Dienst bereitstellen der die Identitätsprüfung eines Nutzers übernimmt. Dabei kommen im Internet verfügbare Identity Provider zum Einsatz, z.B. Windows Live Id, Facebook Id, Yahoo oder Google Account. Amazon, Google und Microsoft stellen je einen Authentifizierungsdienst zur Verfügung. In Windows Azure wird dieser Service durch den AppFabric Access Control Service (ACS) angeboten. Dahinter steht die Windows Identity Foundation, ein Teilbereich des .NET Frameworks [18]. (vgl. Microsoft, S. 1)

Storage

Bei der Verwendung von Storage-Systemen wird der Mehrwert einer Cloud-Plattform besonders deutlich. Während man bei einer lokal betriebenen Anwendung in der Regel eine relationale Datenbank selbst betreibt, bieten die Cloud-Provider dafür fertige Dienste an. Auch eine Mischform ist denkbar, also dass man aus einer lokalen Anwendung heraus eine Datenbank in der Cloud verwendet. Dabei ändern sich die Anforderungen an die Anwendungsarchitektur.

Bei den meisten Anwendungen, die ohne eine Cloud-Plattform entwickelt werden, spielt es keine große Rolle, wie viele Daten exakt in einer relationalen Datenbank gespeichert werden. Insbesondere wenn diese Datenbank auf bestehender Hardware bereits vorhanden ist, steht ein gewisses Speicherkontingent zur Verfügung, welches mehr oder weniger ausgenutzt werden kann.

Dies ändert sich bei dem Einsatz von Storage-Diensten in der Cloud. Diese werden unterschiedlich abgerechnet, nach Übertragungsmenge, nach verwendetem Speicherplatz oder beidem. Relationale Datenbankdienste sind nicht für alle Daten gleich gut geeignet. Muss man sehr große Datenmengen verwalten, die lediglich abgerufen, nicht jedoch weiter verarbeitet werden müssen, können diese in statischen Speicherdiensten abgelegt werden, bei denen der Speicherplatz günstiger ist als bei relationalen Datenbankdiensten.

Der Softwarearchitekt von morgen (bzw. heute) muss also mehr denn je den Kostenaspekt im Auge behalten. Design to cost gewinnt zunehmend an Bedeutung.

4. Geschäftsmodelle im Wandel von Lizenzgeschäft hin zu SaaS

4.1 SaaS aus Kunden- und Anbietersicht

Kaufen oder mieten – Software as a Service (SaaS) auf diese Frage zu reduzieren, wäre zu kurz gegriffen. Als Kunde von SaaS geht es nicht nur um eine alternative Finanzierungsform, also um die Verschiebung von CAPEX zu OPEX. Die guten SaaS Angebote sind eine Art Sorglospaket. Der Kunde muss keine Infrastruktur aufbauen, sich nicht um die Wartung kümmern und kann sich darauf verlassen, dass die benötigte Software verfügbar ist, wann immer er sie braucht. Die Erfolge, die beispielsweise Microsoft mit ihrer SaaS-Variante von Office feiert, beweisen, dass das Konzept von Kunden auf der ganzen Welt angenommen wird.

Wie sieht es auf der Anbieterseite aus? Softwarehersteller, egal ob groß oder klein, möchten auf den SaaS-Zug aufspringen. Das Distributionsmodell erscheint ihnen aus mehreren Gründen attraktiv: Aus dem Kunden wird ein Klient, der für regelmäßigen, planbaren Umsatz sorgt. Dazu kommt, dass der Vertriebsprozess einfacher wird, da die Komplexität der IT-Infrastruktur für den Kunden großteils unsichtbar bleibt. Cloud Computing ist dabei ein wichtiger Katalysator. Durch die Cloud können auch kleine und mittlere Softwarehersteller den Schritt in Richtung SaaS wagen. Sie beziehen selbst die Plattform oder Infrastruktur als Service, vermeiden dadurch riskante Anfangsinvestitionen und können mit steigendem Erfolg bedarfsgerecht wachsen. SaaS, scheinbar eine eierlegende Wollmilchsau, die Kunden und Anbieter glücklich macht? Für Softwarehersteller, die über Jahre mit Lizenzgeschäft groß geworden sind, folgt jedoch nach wenigen Schritten in Richtung SaaS oft ein bitteres Erwachen aus diesem Traum. Ob SaaS funktioniert, bestimmen maßgeblich folgende drei Faktoren:

1. Softwarearchitektur
2. Kosten- und Preismodell
3. Geschäftsprozesse

4.2 Softwarearchitektur

Lassen Sie uns mit der Softwarearchitektur beginnen. Das Zauberwort heißt hier „Multi-Tenancy“. Damit man als SaaS-Anbieter eine große Anzahl an Kunden (=Tenants) kosteneffizient bedienen kann, muss eine gemeinsam genutzte Infrastruktur auf die Kunden aufgeteilt werden. Warum nicht analog zu früher jedem Kunden seinen eigenen Server und seine eigene Datenbank? Dieses Konzept hat bei SaaS und Cloud ausgedient. Egal welchen Cloud-Anbieter Sie wählen, die Grundkosten für einen Server liegen monatlich im mittleren bis oberen zweistelligen Eurobereich. Gleiches gilt für die Datenbank. Wollen Sie als Hersteller mit SaaS nicht gerade die große Anzahl kleiner und mittlerer Kunden anlocken? Wenn Sie nicht in der Lage sind, mehrere Tenants gleichzeitig in einer gemeinsamen Infrastruktur zu betreiben, stehen sie schnell vor Mindestkosten von einigen hundert Euro pro Tenant und Monat und ihr schöner Traum vom attraktiven SaaS-Preismodell zerplatzt wie eine Seifenblase. Hier nur exemplarisch einige der Fragestellungen, die Multi-Tenancy für Softwarearchitekturen mitbringt:

• Mehrere Tenants teilen sich eine Infrastruktur – wie schottet man die Tenants voneinander ab?
• Nicht-triviale Softwareprodukte verlangen meistens kundenspezifische Anpassungen – wie geht man damit um, wenn es für alle Kunden eine gemeinsame Umgebung gibt?
• Kann man alle Kunden zwingen, gleichzeitig Versionswechsel mitzumachen? Falls nicht, wie löst man Versionierung vor dem Hintergrund von Multi-Tenancy?
• Wie sorgt man dafür, dass die zugrunde liegende Infrastruktur je nach Anzahl der aktiven Tenants elastisch skalieren kann – und das ohne Ausfall oder Neustart?

Die Qualität der Umsetzung von Multi-Tenancy stellt bei SaaS einen wichtigen Wettbewerbsvorteil dar. In der Cloud sind die Kosten variabel. Man bezahlt das, was man nutzt und kann je nach Bedarf nach oben und unten skalieren. Im lokalen Rechenzentrum mag Sie eine Auslastung von 10% ruhig schlafen lassen, da das Spielraum für Lastspitzen bedeutet. In der Cloud ist sie ein Alarmsignal. Je besser Sie Ressourcen ausnutzen, je elastischer Sie auf Änderungen der Anzahl und Aktivität der Tenants reagieren, desto niedriger sind die Kosten.

4.3 Kosten- und Preismodell

Ein gutes Verständnis über die Kostentreiber bestimmt maßgeblich den Erfolg eines SaaS Anbieters. Steigen die Kosten mit der Anzahl an Benutzern oder gibt es andere Faktoren, welche die Kosten in die Höhe treiben (z. B. Anzahl der Transaktionen, Speicherbedarf, Fixkosten für monatliche Zahlungsabwicklung über Kreditkarten, etc.)? Eine wichtige Kennzahl, an der es ständig zu arbeiten gilt, ist „Cost per Revenue Generating Unit“ (z. B. Kosten pro Benutzer oder pro Transaktion). Ausgehend von ihr gilt es, ein attraktives Preismodell zu entwickeln. Wie geben Sie die Kosten mit entsprechendem Aufschlag an Kunden weiter? Setzen Sie ganz auf PAYG („Pay as you go“) oder bieten Sie ergänzend Paketangebote an?

Das Design einer SaaS Lösung beginnt im Excel in Form des Geschäftsmodells. Im Sinne von „Design to Cost“ beeinflusst es nicht nur Marketing und Vertrieb sondern reicht bis hinein in die Softwarearchitektur. Ikea hat den Slogan „We design the price tag first“ bekannt gemacht. Als SaaS Anbieter sollten Sie sich ein Beispiel daran nehmen. Bei jeder Entscheidung betreffend Softwaredesign müssen Sie sich die Frage stellen, welche Auswirkungen sie für die operativen Kosten und damit indirekt auch für den Preis hat.

4.4 Geschäftsprozesse

Der dritte Faktor neben Architektur und Preismodell sind die Geschäftsprozesse. Viele Unternehmen unterschätzen zunächst die Revolution, die SaaS in dieser Hinsicht bedeutet. Während typische Lizenzverkäufer es gewohnt sind, wenige große Rechnungen zu schreiben, ähnelt der Verrechnungsprozess bei größeren SaaS Systemen mehr dem von Mobilfunkanbietern. Nutzungsdaten müssen bewertet werden („Rating“). Hunderte, vielleicht sogar tausende Rechnungen sind zu generieren („Billing“) und die nachfolgenden Zahlungen abzuwickeln („Payment“). Kunden erwarten heutzutage, dass das alles praktisch in Echtzeit erfolgt, da sie jederzeit abfragen wollen, wie viel Geld sie bereits verbraucht haben. Selbst wenn dieses Service nicht geboten wird, ist laufendes Rating wahrscheinlich für die Überwachung von Fair-Use Regeln oder Pre-Paid Nutzungsgrenzen notwendig.

Der Wechsel vom großen Scheck beim Lizenzverkauf zum Einwurf kleiner Münzen bei SaaS zieht in Sachen Prozesse noch weitere Kreise. Gängige Vertriebsstrukturen müssen beispielsweise überdacht werden. Umsatzabhängige Boni müssen sich mehr am CLV („Customer Lifetime Value“) orientieren anstatt nur auf die Höhe einer Kundenbestellung abzuzielen. In dualen Lizenzsystemen, bei denen Kunden die Wahl zwischen Lizenzkauf und SaaS haben, gilt es, Strukturen zu finden, die einen Konkurrenzkampf der beiden Strategien und damit Kannibalisierungseffekte verhindern.

5. Fazit

Cloud Computing ist ein wichtiges Thema für die IT-Industrie. Durch Abgrenzungsfaktoren, wie Abstraktionsniveau, Bereitstellung einer Entwicklungsplattform sowie Zusatzdienste, unterscheidet sich plattformorientiertes Cloud Computing von Hosting.

Zusammenfassend kann man sagen, dass der Wechsel zu SaaS für etablierte Unternehmen eine Herausforderung darstellt. Junge, aufstrebende Teams, die alle Aspekte von SaaS von Anfang an verinnerlichen, haben eine echte Chance, den Markt aufzumischen. Die Cloud ebnet dabei das Spielfeld, sodass die Größe eines Anbieters keinen entscheidenden Vorteil, manchmal sogar einen Nachteil wegen mangelnder Flexibilität mit sich bringt.

6. Literaturverzeichnis

Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R. H., Konwinski, A. et al. (2009). Above the Clouds: A Berkeley View of Cloud Computing. Zugriff am 06.01.2012. Verfügbar unter http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf.

Benlian, A., Hess, T. & Buxmann, P. (Hrsg.). (2010). Software-as-a-Service: Anbieterstrategien, Kundenbedürfnisse und Wertschöpfungsstrukturen (1. Aufl.). Wiesbaden: Gabler.

BITKOM (BITKOM Bundesverband Informationswirtschaft, T. u. n. M. e., Hrsg.). (2009). Cloud Computing - Evolution in der Technik, Revolution im Business: BITKOM-Leitfaden. Zugriff am 17.12.2011. Verfügbar unter http://www.bitkom.org/files/documents/BITKOM-Leitfaden-CloudComputing_Web.pdf.

DIN. (2011). Cloud Computing ready for practice?: Wolken greifbar machen, DIN. Zugriff am 15.18.2012. Verfügbar unter http://www.nia.din.de/sixcms_upload/media/2397/Einladung%20und%20Agenda%20DIN-Workshop%20Cloud%20Computing.pdf.

Dueck, G. (2011). Cloudwirbel: DUECK-BETA-INSIDE, Informatik Spektrum (34, Heft 3, S. 309–313). Berlin [u.a.]: Springer.

Fraunhofer-Allianz Cloud Computing (Fraunhofer-Gesellschaft, Hrsg.). (2011). Was ist die Cloud? Zugriff am 15.08.2012. Verfügbar unter http://www.cloud.fraunhofer.de/de/faq/cloud.html.

Fröschle, H.-P. & Reinheimer, S. (Hrsg.). (2010). Cloud computing & SaaS. Heidelberg: dpunkt.

Gartner, I. (2009). Gartner Highlights Five Attributes of Cloud Computing: Gartner's Cloud Computing Special Report Examines the Realities and Risks of Cloud. Zugriff am 21.12.2011. Verfügbar unter http://www.gartner.com/it/page.jsp?id=1035013.

Krishnan, S. (2010). Programming Windows Azure (1st). Beijing [u.a.]: O'Reilly.

Kurzlechner, W. (CIO Magazin, Hrsg.). (2011). Die Top-10-Listen der IT-Trends 2012: Gartner, Forrester, IDC & Co., IDG Business Media GmbH. Zugriff am 04.01.2012. Verfügbar unter http://www.cio.de/strategien/2298020/.

Meir-Huber, M. (2010). Cloud Computing: Praxisratgeber und Einstiegsstrategien. Frankfurt am Main: Entwickler.press.

Mell, P. & Grance, T. (National Institute of Standards and Technology, Hrsg.). (2011). The NIST Definition of Cloud Computing: Recommendations of the National Institute of Standards and Technology. Zugriff am 19.12.2011. Verfügbar unter http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf.

Microsoft: How to Authenticate Web Users with Windows Azure Access Control Service. Online verfügbar unter http://www.windowsazure.com/en-us/develop/net/how-to-guides/access-control/, zuletzt geprüft am 15.08.2012.

Pallmann, D. (2011). The Windows Azure Handbook: Volume 1: Planning & Strategy. Charleston: CreateSpace.

Tarzey, B. & Longbottom, C. (Quocirca Ltd., Hrsg.). (2009). Managed hosting in Europe: A review of the managed hosting market and suppliers in Europe. Zugriff am 29.12.2011. Verfügbar unter http://www.quocirca.com/media/reports/062009/16/Quocirca_-_Managed_Hosting_in_Europe_-_June_2009.pdf.

Tietz, V., Blichmann, G. & Hübsch, G. (2011). Cloud-Entwicklungsmethoden: Überblick, Bewertungen und Herausforderungen, Informatik Spektrum (34, Heft 4, S. 345–354). Berlin [u.a.]: Springer.