SLA im Cloud Computing - Prozess statt Technik: Cloud Computing braucht andere SLA von Diethelm Siebuhr, ist Geschäftsführer Central Europe bei Easynet Global Services in Hamburg

In der IT werden Dienstleistungen üblicherweise durch Service Level Agreements (SLA) definiert. Damit legen Auftraggeber und Dienstleister verbindlich fest, was die Leistung alles umfasst, aber auch wie zu verfahren ist, wenn es Abweichungen von der Leistung gibt. Dies gilt auch beim Cloud Computing, das ja ebenfalls eine dynamische Dienstleistung darstellt.

In der Public Cloud sind die Leistungen standardisiert und die Anbieter wenden hier auch standardisiere SLA an: Nur so lassen sich die Kosten durch den Provider niedrig kalkulieren. Die Public Cloud bietet damit nicht nur wenig Spielraum für individuelle Anforderungen, sondern auch für dynamische Änderungen. Anwender müssen hier sehr gut aufpassen, in wie weit die jeweilige Standardleistung ihre Bedürfnisse und die Änderungen ihres Geschäftsbetriebs erfüllt. Der gelegentlich geäußerte Vorschlag, die Unternehmen müssten die SLA der Provider, beispielsweise wegen Datenschutzvorgaben, individuell nachverhandeln, ist im Bereich der Public Cloud meist unrealistisch, denn das Geschäftsmodell der Provider beruht hier gerade auf der vollständigen Standardisierung.

Ganz anders sieht es bei der Private oder Enterprise Cloud aus: Hier vereinbaren Auftraggeber und Provider die Leistungen entsprechend spezifischer Bedürfnisse und halten dies in individuell verhandelten SLA fest. Hier wird dann beispielsweise definiert welche Verfügbarkeit der Provider für seine Services garantiert oder ob ein in der Cloud gehosteter Online-Shop tatsächlich an sieben Tagen in der Woche durchgängig zu 99,99 Prozent verfügbar sein muss. Verfügbarkeit ist so für beide Seiten ein Kalkulationspunkt: Höhere Verfügbarkeit bedeutet für den Provider mehr technischen Aufwand und damit höhere Kosten. Der Auftraggeber muss seinerseits überlegen, wie viel ihm die Reduzierung von Geschäftsrisiken durch die Erhöhung der Verfügbarkeit wert ist.

Im Rahmen von SLA lassen sich jedoch nur Leistungen definieren, die auch messbar sind. Es dürfen in die SLA nur Dinge aufgenommen werden, die konkret überprüfbar sind, andernfalls sind, mitunter unerfreuliche Auseinandersetzungen vorprogrammiert. Eine pauschale Forderung wie "Verfügbarkeit von 99,99 Prozent" reicht daher nicht, stattdessen muss genau definiert werden, wann, wo und mit welchen Methoden diese Verfügbarkeit festgestellt wird, etwa durch eine bestimmt Mindestzahl von Aufrufen pro Zeiteinheit. Ein entsprechendes Monitoring sowie ein Reporting muss daher ebenfalls Bestandteil der SLA sein.

So wichtig klare Vereinbarungen sind, man sollte aber nicht aus den Augen verlieren, dass die Grundlage für ein derartiges Geschäft nicht möglichst ausgefeilte SLA, sondern zunächst einmal ein Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer ist. Das kommt noch vor der Formulierung von SLA, denn wer hier bereits ein "schlechtes Gefühl" hat, der wird es auch durch noch so elaborierte SLA nicht ausräumen können. Wer meint, der Provider würde ihn beim ersten Punkt, der in der SLA nicht genauso beschrieben ist, wie er dann in der Realität eintrifft, über den Tisch ziehen, der sollte besser die Finger von dem Geschäft lassen.

Neue Anforderungen an SLA

Allerdings stellt sich mit der zunehmenden Verbreitung des Cloud Computings auch heraus, dass der herkömmliche Ansatz der SLA sich nicht so ohne weiteres auf die Eigenheiten dieses Konzepts anwenden lässt: Unternehmen, die wesentliche Geschäftsprozesse zu einem Provider auslagern, wollen meist möglichst genau festlegen, auf welche Weise dieser seine Leistungen zu erbringen hat. Sie bestimmen dabei auch Technik und Infrastruktur, was in vielen Fällen so weit geht, dass sie bestimmte Hardware in den SLA vorschreiben, manchmal die CPU-Aus­stattung der Server oder die Ping-Zeiten der Netzwerkinfrastruktur.

Natürlich will ein Auftraggeber möglichst wenig Überraschungen erleben, aber solche technisch orientieren SLA widersprechen dem grundlegenden Konzept des Cloud Computing. Denn dabei ist IT "nur" ein Service, der Geschäftsprozesse zur Verfügung stellt, beispielsweise den Betrieb einer E-Commerce-Plattform mit einem definierten Leistungsniveau; hier also einen kompletten, reibungslosen Online-Ver­kaufs­vorgang mit bestimmten Reaktionszeiten, vom Einstellen eines Artikels in den Warenkorb des Shops bis zum Auftrag.

Wie der Provider diesen Service realisiert, mit welcher Hard- und Software, mit welcher technischen Infrastruktur oder mit welchen personellen Ressourcen, das fällt beim Cloud Computing definitionsgemäß ausschließlich in den Aufgabenbereich des Providers. Der Service heißt im Cloud Computing nicht: Betrieb einer E-Commerce-Plattform mit Server XY, YZ- Festplatten oder einem bestimmten Kühlungssystem, sondern: Bereitstellung eines E-Shops für beispielsweise n- Verkaufsvorgänge. Die technischen Einzelheiten des Betriebs beim Provider gehören beim Cloud Computing nicht mehr in das SLA.

Dieses Verfahren bedeutet für viele IT-Abteilungen natürlich ein Umdenken, denn sie sind damit nicht mehr in die Bereitstellung der IT involviert, sondern übernehmen nur noch eine kontrollierende Funktion. Ihre Aufgabe ist es zu prüfen, in wie weit die Vorgaben der SLA hinsichtlich der Geschäftsprozesse vom Provider erfüllt werden, ohne sich aber darum zu kümmern, auf welche Weise dieser seinen Pflichten nachkommt..

Im Cloud Computing sollten SLA außerdem möglichst auf prozessbezogene Kennzahlen beschränkt bleiben, also auf Kennzahlen, die Geschäftsprozesse beschreiben– zum Beispiel Bewältigung einer bestimmten Anzahl von Anfragen oder Einkäufen in einem definierten Zeitraum, aber nicht mehr eine ganze technische Infrastruktur. Die Bedeutung der SLA verringert sich dadurch jedoch nicht, im Gegenteil, ihre Bedeutung nimmt zu, weil nach Wegfall der technischen Vorgaben die SLA nun die zentrale Schnittstelle zwischen den Geschäftsprozessen des Auftraggebers und der Leistung des Providers bilden.

Geschäftsprozesse als Basis von SLA

Eine Voraussetzung für diesen Ansatz ist, dass der Provider die Geschäftsprozesse seiner Auftraggeber kennt und versteht. Auch das stellt für beide Seiten eine Herausforderung dar. Denn während sich die Drehzahl einer Festplatte oder die Leistung einer CPU eindeutig messen lässt, ist Entsprechendes bei Geschäftsprozessen weitaus schwieriger. So verbindet eine E-Com­merce-Plattform eine Vielzahl miteinander verflochtener Prozesse, die die SLA alle abbilden, gewichten und für die sie die passenden Messpunkte definieren müssen. Dies ist eine komplexe Aufgabe, die umfangreiche Beratungsleistung durch den Provider und enge Zusammenarbeit zwischen ihm und dem jeweiligen Unternehmen erfordert.

In der Praxis zeigt sich immer wieder, dass Unternehmen die Komplexität ihrer eigenen Prozesse erheblich unterschätzen, so dass bei der Umsetzung häufig wesentlich mehr Kriterien berücksichtigt werden müssen als ursprünglich geplant: Die Verfügbarkeit eines Webshops ergibt sich in der Praxis ja nicht aus einer einzigen Zahl, sondern aus einer Reihe von Faktoren, etwa dem Aufruf, der Anzeige einer Artikelauswahl oder der Dauer des Einstellens von Waren in den Warenkorb.

In vielen Unternehmen sind die Geschäftsprozesse jedoch nicht vollständig transparent und als Außenstehender kann der Provider diese Prozesse nicht ohne Unterstützung des Auftraggebers beschreiben. Das Aufsetzen von SLA muss in gemeinsamer Arbeit und in enger Abstimmung erstellt werden. Easynet legt daher immer größten Wert auf Nähe zum Anwender und auf die Einbindung in die Erfassung der Prozesse.

Das verbreitete Vorgehen, bei dem SLA in einem letzten Akt der Vertragsverhandlungen festgelegt werden, passt ebenfalls nicht mehr in die Ära des Cloud Computing. Stattdessen müssen sich die Partner möglichst frühzeitig verständigen, welche SLA benötigt werden, die der Provider dann in die technische Lösung integriert. Gleichzeitig ist ein Iterationsverfahren sinnvoll, um SLA und deren Umsetzung anzupassen. Erst dann lässt sich ein SLA aufsetzen, das in der Lage ist, die Dynamik der Geschäftsprozesse zu unterstützen.

An Geschäftsprozessen orientierte SLA für Private Clouds gibt es daher nicht von der Stange, etwa als Formular, das man ausfüllt, unterschreibt und dann abheftet. Je besser die Geschäftsprozesse in den SLA abgebildet werden, desto individueller sind diese ausgestaltet. Es handelt sich um ein "dynamisches" Dokument, das individuell konzipiert ist und das sich mit den Geschäftsprozessen verändert. Will beispielsweise ein Unterneh­men in seinem Webshop statt Fotos von Artikeln künftig 3-D-Ansichten oder Videos zeigen, so hat das Auswirkungen auf die Antwortzeiten des Shops und tangiert auch das SLA. Auch Veränderungen, die sich aus dem Geschäftsumfang – etwa mehr Kunden oder mehr Artikel – ergeben, müssen in den SLA dynamisch berücksichtigt werden.

Diese Neuausrichtung bei der Erarbeitung von SLA ergibt sich zwar direkt aus der konzeptionellen Eigenart des Cloud Computing, aber man muss natürlich zugeben, dass dies bisher erst von wenigen Unternehmen so wahrgenommen wird, dazu ist die Private Cloud einfach noch nicht genügend verankert – und man muss auch sagen: noch nicht genügend verstanden. So wollen viele Unternehmen zwar die IT bereits als Service nutzen, aber sie denken trotzdem weiter in technischen Kategorien und wollen auch technische Aspekte in die SLA aufnehmen. Das große Umdenken wird mit der fortschreitenden Etablierung des Cloud Computing noch stattfinden.