IT-Strategien

Service Level Agreements

Cloud Computing verändert die Konzeption von Service Level Agreements (SLA): Nicht mehr technische Komponenten werden dort beschrieben, sondern Geschäftsprozesse. Die technische Realisierung bleibt dem Dienstleister überlassen. Notwendig ist nicht nur eine sehr enge Zusammenarbeit von Auftraggeber und Provider, sondern auch ein flexiblerer Umgang mit dynamischen Anforderungen.

Service Level Agreements

© Hersteller/Archiv

Service Level Agreements

Dienstleistungen in der IT werden üblicherweise über 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 eine dynamische Dienstleistung darstellt.

In der Public Cloud sind die Leistungen standardisiert und die Anbieter wenden hier auch standardisierte 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, inwieweit die jeweilige Standardleistung ihre Bedürfnisse und die Änderungen ihres Geschäftsbetriebes 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.

Leistungen müssen messbar sein

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. In die SLA dürfen 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 bestimmte Mindestzahl von Aufrufen pro Zeiteinheit.

Ein entsprechendes Monitoring sowie ein Reporting muss daher ebenfalls Bestandteil der SLA sein.

So wichtig klare Vereinbarungen auch 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 Vereinbarungen nicht ausräumen können. Wer meint, der Provider würde ihn beim ersten Punkt, der in der SLA nicht genau so 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 die SLA

Allerdings stellt sich mit der zunehmenden Verbreitung von Cloud Computing auch heraus, dass der herkömmliche Ansatz der SLA sich nicht so ohne Weiteres auf die Eigenheiten dieses Konzeptes 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-Ausstattung 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-Verkaufsvorgang 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 Betriebes 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, inwieweit 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.

Beim 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 auf 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 sind die Basis

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-Commerce-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 eine umfangreiche Beratungsleistung durch den Provider und eine 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, sodass bei der Umsetzung häufig wesentlich mehr Kriterien berücksichtigt werden müssen als ursprünglich geplant: So ergibt sich die Verfügbarkeit eines Webshops 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.

Dynamische Dokumente

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 beispielsweise legt daher immer größten Wert auf Nähe zum Anwender und darauf, in die Erfassung der Prozesse eingebunden zu werden.

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 die Festlegungen 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 ein Unternehmen beispielsweise in seinem Webshop statt Artikelfotos künftig 3D-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.

Autor: Diethelm Siebuhr - Easynet Global Services

© Hersteller / Archiv

Der Autor: Diethelm Siebuhr - Geschäftsführer Central Europe bei Easynet Global Services in Hamburg
Zugangskontrolle

© Foto: Easynet

Betreiber von Rechenzentren müssen gewährleisten, dass nur autorisierte Personen Zugang haben.

Mehr zum Thema

Schutz aus der Cloud: Das müssen Sie wissen
Optimale Sicherheit

Noch vor wenigen Jahren war Cloud Computing kaum mehr als ein Schlagwort der IT-Industrie. Das hat sich geändert. Die Cloud ist Realität. Was es in…
Microsoft Azure ExpressRoute
Equinix und Microsoft

Equinix und Microsoft werden Zugang zu Microsoft Azure ExpressRoute in 16 Märkten weltweit anbieten.
Probleme bei Cloud-Providern?
Cloud-Dienste

Einer aktuellen Compuware-Studie zufolge hält ein Großteil befragter IT-Führungskräfte Cloud Service Level Agreements für unzureichend.
Cloud-Telefonanlage von O2 mit NFON als Basis
Digital Phone: Cloud-Telefonanlage von O2

Telefonica Deutschland bringt das Digital Phone von O2 auf den Markt. Das jüngste Cloud-Angebot der Telefongesellschaft dient als Telefonanlage für…
Mailbox.org-Logo
Business-Alternative für Office 365 & Google Apps

Mailbox.org will eine sichere Alternative für Office 365 und Google Apps sein. Hauptargument: E-Mails und ein Cloud-basiertes Office auf Servern in…