Tag: SLA


OpenStack Best-Practices: Anforderungen an eine Umgebung auf Enterprise-Niveau

Für einen stabilen und nachhaltigen Einsatz im Unternehmensumfeld haben sich fertige OpenStack-Produkte als die richtige Wahl herauskristallisiert. Denn für einen „grüne Wiese“-Ansatz ist OpenStack zu komplex. Zahlreiche kleine und große Technologieanbieter unterstützen hierbei mit Distributionen professionellen Support, Beratungs- und Integrationsleistungen als auch erweiterten Lösungen für das tägliche Management von OpenStack-Infrastrukturen. Worauf gilt es zu achten, um eine OpenStack-Infrastruktur auf Enterprise-Niveau zu betreiben? Crisp Research hat fünf Anforderungen identifiziert, die dafür ausschlaggebend sind. Continue reading “OpenStack Best-Practices: Anforderungen an eine Umgebung auf Enterprise-Niveau” »



Enterprise Cloud Portal: T-Systems konsolidiert sein Cloud-Portfolio

Mit seinem Enterprise Cloud Portal präsentiert die Deutsche Telekom Tochter T-Systems sein erstes Cloud-Service übergreifendes Angebot für Großkunden. Auf dem Portal können sich Unternehmen über die Cloud-Lösungen von T-Systems informieren, diese testen und direkt bestellen. Zu den derzeit angebotenen Services gehören Lösungen für das Mobile Device Management, Dynamic Services for Infrastructure und der Enterprise Marketplace. Ein Blick auf das Portal zeigt, dass auf die Kompatibilität mit Tablets großer Wert gelegt wurde.

An der IT-Abteilung vorbei

T-Systems möchte mit seinem Cloud-Portal auch nicht-technischen Nutzern in Großunternehmen den Zugang zu speziellen Cloud-Lösungen ermöglichen. Der Cloud-Anbieter bezieht sich dabei auf eine Studie von Gartner, die besagt, dass bis zum Jahr 2015 in etwa 35 Prozent der IT-Ausgaben, außerhalb der IT-Abteilungen ausgewählt und verwaltet werden. Genannt seien hier zum Beispiel die Bereiche Marketing, Einkauf und das Rechnungswesen.

Mobile Device Management

Das Mobile Device Management aus der Cloud soll Unternehmen bei der Administration mobiler Endgeräte mit unterschiedlichen Betriebssystemen, z.B. iOS und Android, über eine standardisierte Web-Plattform helfen. Darüber lassen sich etwa Sicherheitseinstellungen vornehmen, Zugriffsrechte auf Funktionen sowie Applikationen regeln oder bei Verlust des Endgeräts die Daten per Fernzugriff löschen. Ein Test des Mobile Device Management ist in den ersten vier Wochen für bis zu drei mobile Endgeräte kostenlos.

Dynamic Services for Infrastructure

Für Infrastructure-as-a-Service (IaaS) stehen zwei Angebote bereit: Zum einen die "Dynamic Services for Infrastructure" (DSI) aus einer Hosted Private Cloud. Zum anderen die "DSI with vCloud Datacenter Services" als eine hybride Variante. Das Management der Ressourcen übernimmt der Kunde selbst über ein web-basiertes Portal beziehungsweise über seine eigene VMware Management Software. Übersichtliche Preismodelle sollen die Kosten für die Infrastruktur transparent machen. So kostet z.B. im Paket "Small" ein Server aus der Hosted Private Cloud ab 9 Cent pro Stunde. Bei der hybriden Lösung liegt der Paketpreis für ein Virtual Datacenter in der kleinsten Ausführung bei genau 999,84 Euro pro Monat.

Enterprise Marketplace

Der Enterprise Marketplace umfasst unter anderem weitere IaaS-Lösungen inkl. Betriebssysteme für Linux und Windows Server, Platform-as-a-Service (PaaS) Lösungen, u.a. Tomcat und Microsoft SQL Server sowie eine stetig steigende Zahl von Software-as-a-Service (SaaS) Angeboten wie Doculife, CA Nimsoft, TAXOR, TIS, WeSustain, Metasonic, ARAS, Tibco Tibbr, Sugar CRM, Microsoft Enterprise Search und Microsoft Lync. Darüber hinaus sollen Unternehmen damit die Möglichkeit erhalten, nicht nur eine Vielfalt an Anwendungen hochsicher in bedarfsgerechten Formaten zu beziehen, sondern auch eigene Anwendungen migrieren und hosten zu lassen. Die volle Verfügbarkeit des Enterprise Marketplace ist für diesen Sommer geplant. Derzeit steht auf dem Cloud Portal bereits eine Vorschau zur Verfügung.

Kommentar

Mit dem Enterprise Cloud Portal fasst T-Systems sein gesamtes Cloud-Portfolio unter einem einzigen Dach zusammen. Ich hatte in einem Artikel für die Computerwoche: "Das Cloud-Portfolio von T-Systems" im Jahr 2011 analysiert. Zu dem Zeitpunkt bestand das Angebot jedoch noch aus einzelnen unabhängigen Services. Allerdings bin ich bereits damals schon zu dem Ergebnis gekommen, dass T-Systems über ein sehr gut durchdachtes und abgerundetes Cloud-Portfolio verfügt.

Das zeigt sich nun auch im konsolidierten Enterprise Cloud Portal. Von SaaS über PaaS bis IaaS und weiteren Lösungen für mobile Endgeräte ist alles dabei. T-Systems verfügt damit als einer der wenigen Anbieter über einen vollständigen Cloud-Stack und das nun sogar noch gebündelt in einem einzigen Portal.

Insbesondere in dem Enterprise Marketplace steckt viel Potential. Auf der diesjährigen CeBIT konnte ich einen ersten Blick darauf werfen, der sich meiner Einschätzung nach zu diesem Zeitpunkt noch in einem Alpha-Status befand. Einige grundlegende und zwingend notwendige Funktionen für ein IaaS Angebot, genannt seien nur automatische Skalierbarkeit und Hochverfügbarkeit, fehlten noch. Aber das war im März und ich gehe davon aus, dass T-Systems hier schon weitere Fortschritte gemacht hat. Zudem habe ich bereits aus einer sicheren Quelle erfahren, dass T-Systems/ Telekom ihre Cloud-Infrastruktur sukzessive auf OpenStack umstellen wird, was auch dem Enterprise Marketplace einen weiteren Schub hinsichtlich Kompatibilität geben wird.

Was T-Systems als Vorteil für nicht-technische Nutzer in Unternehmen sieht, sollte bei IT-Verantwortlichen Sorgenfalten verursachen. Zwar bin ich auch auf dem Standpunkt, dass sich die IT-Abteilungen zu einem Service-Broker entwickeln werden und sogar müssen. Allerdings halte ich es für recht bedenklich, wenn jede Abteilung einfach loslaufen darf und sich nach belieben IT-Services extern einkauft. Die Schuld liegt natürlich bei den IT-Abteilungen selbst, da diese sich über die Jahre hinweg einen schlechten Ruf aufgebaut haben und als langsam und nicht innovativ gelten. Darüber habe ich hier bereits vor zwei Jahren ausführlich philosophiert (Cloud Computing und die Schatten-IT).

Eine gewisse Kontrollinstanz in der Form eines Service-Broker ist weiterhin notwendig, denn sonst kommt es zu einem unkontrollierten Wildwuchs von externen Services, über die man den Überblick verlieren wird. Das lässt sich selbstverständlich kontrollieren, wenn man die Services über einen einzigen Anbieter bezieht. Und das ist genau das Ziel von T-Systems und seinem umfangreichen Enterprise Cloud Portal. Ein Kunde soll explizit und abteilungsübergreifend die Services aus der T-Systems Cloud beziehen, um damit den Wildwuchs zu vermeiden und den Überblick behalten. Die Frage ist, ob sich das bei den Kunden intern auch so durchsetzen lässt. Denn auch andere Anbieter haben hübsche Services.

Am Ende möchte ich noch auf ein Thema eingehen, was im Endkunden-Umfeld derzeit für Aufregung sorgt, Unternehmenskunden aber einen großen Vorteil bietet. Das End-to-End Angebot von Services. T-Systems ist auf Grund seiner Situation, Tochter von der Deutschen Telekom zu sein, einer der wenigen Cloud-Anbieter, der ein Service-Level von den Services auf Applikations- oder sogar virtueller Maschinen Ebene im Rechenzentrum, inkl. der Datenleitung anbieten kann. Das ermöglicht es den Kunden einen ununterbrochenen Quality-of-Service (QoS) sowie ein umfangreiches Service Level Agreement (SLA) zu erhalten, was viele andere Cloud-Anbieter nicht leisten können.



Die sieben häufigsten Fehler im SLA-Management

Die Experten für softwaregestütztes Business-Service-Management von der fusionPOINT GmbH haben die sieben häufigsten Fehler im Management von Service-Level-Agreements (SLAs) ausfindig gemacht. Ein Hauptgrund ist das sehr geringe Bewusstsein für das Thema innerhalb des Unternehmens. Denn die Schnittstellen zwischen dem Business und den IT SLAs müssen aktiv gesteuert und kontrolliert werden.

Fehler Nr. 1

Anbieter und Kunde vereinbaren keine SLAs.
Auf beiden Seiten herrschen in diesem Fall nur vage Vorstellungen darüber, welche Leistung eingekauft und welche geliefert wird. Da der Kunde ohnehin 100 Prozent möchte und der Lieferant nur das liefern kann, was seine Infrastruktur hergibt, sind Unstimmigkeiten vorprogrammiert, sobald der Kunde mit einer Leistung unzufrieden ist.

Fehler Nr. 2

Es gibt SLAs, aber diese sind beim Kunden und beim Anbieter nicht ausreichend kommuniziert.
Trotz schriftlicher Vereinbarungen sind die Details der zu erbringenden Leistung den betroffenen Personen häufig nicht bekannt oder wurden im Vorfeld nicht mit ihnen abgestimmt. In der Konsequenz ist es dann nur Zufall, wenn das geleistet wird, was der Kunde erwartet.

Fehler Nr. 3

SLAs enthalten schwammige Begriffe wie maximale Kundenzufriedenheit oder höchste Verfügbarkeit.
Kein Unternehmen wird jedoch Positionen wie „1 mal maximale Kundenzufriedenheit“ auf einem Lieferschein aufführen. SLAs müssen für beide Seiten zweifelsfrei messbar sein. In einem Reporting lässt sich dann automatisiert dokumentieren, wie die Leistungserbringung konkret aussah. Schwachstellen in der Leistungserbringung können so schnell aufgespürt und beseitigt werden.

Fehler Nr. 4

Es gibt SLAs mit messbaren Werten – aber niemand hält sich dran.
Häufig ist sich der Kunde trotz schriftlich fixierter Werten nicht bewusst, dass er keine 100 Prozent abgeschlossen hat oder nicht bereit, eine Mehrleistung zu honorieren. Umgekehrt ist der Lieferant nicht bereit, ein Servicedesign zur Erreichung der spezifischen SLAs zu machen und hierfür zu investieren. Auch hier muss die vereinbarte Leistung in beiden Unternehmen klar und transparent kommuniziert werden.

Fehler Nr. 5

SLAs werden von der Leistungsfähigkeit der IT nach oben zusammengebaut.
Hier stimmt der Ansatz nicht. Ein Business-SLA muss immer vom Geschäftsprozess des Kunden top-down abgeleitet werden. Es wird oft nicht gefragt „Was wird gebraucht?“, sondern „Was kann geleistet werden?“ Will ein Dienstleister seine Kunden zufrieden stellen, muss er die Kundenorientierung in den Vordergrund stellen.

Fehler Nr. 6

Das SLA-Management beim Anbieter erfordert zu viele manuelle Tätigkeiten.
Was nicht automatisiert ablaufen kann, benötigt zu viel Zeit und ist fehleranfällig. Das Reporting zum Kunden ist stets nachträglich und somit nur als Vergangenheitsbewältigung möglich. Eine aktive Steuerung der SLAs ist wichtig, um die eigene Leistung auf einem hohen Niveau zu halten und Verlässlichkeit zu demonstrieren. Auch die Risikominimierung und die Vermeidung von Pönalen wird hiermit gesteuert.

Fehler Nr. 7

Leistung wird nicht kundenbezogen kontrolliert, sondern nur bezogen auf die internen Leistungseinheiten.
Mit diesem Ansatz kann einiges schieflaufen. So kann es beispielsweise vorkommen, dass die geforderte Verfügbarkeit einer Leistungseinheit von x Prozent über alle Kunden eingehalten wurde und damit im grünen Bereich ist. Sind die Ausfälle aber ungleichmäßig verteilt, schreiben manche Kunden bereits die Rechnungen über Pönalen. Wichtig ist daher, auf SLA-Ebene zu managen und für jeden Kunden die spezifizierten Leistungen sicher zu stellen.


Bildquelle: http://auditagency.com.ua



Cloud Computing und Service Level Agreements: Das sollte nicht fehlen!

Unternehmen müssen die Leistungen, die Provider beim Cloud Computing erbringen sollen, genau definieren. Der Hamburger Managed Service Provider Easynet hat dazu zehn wesentliche Punkte zusammengestellt, die in den Verträgen und SLAs von Cloud-Projekten nicht fehlen sollten.

Cloud Computing ist zur Realität geworden – viele Unternehmen denken darüber nach, wie sie die Cloud für ihre IT nutzen können oder haben bereits konkrete Schritte vorgenommen. Wer einem Cloud Provider die Verantwortung für wesentliche IT-Ressourcen überträgt, muss mit ihm klare Regelungen treffen. Die folgenden zehn Punkte beinhalten die wesentlichen Aspekte, die Anwender bei der Festlegung von SLAs (Service Level Agreements) – beziehungsweise in sonstigen Verträgen – für das Cloud Computing keinesfalls vernachlässigen sollten:

  1. Technische Parameter – Die grundlegenden technischen Parameter müssen genau definiert werden, vor allem die nutzbaren Bandbreiten, die garantierte Verfügbarkeit, eventuelle Wartungs- und Reaktionszeiten, das Datenvolumen, aber auch die Datenarten, ob beispielsweise nur strukturierte Daten oder auch Multimedia-Daten abgedeckt werden.
  2. Prozessbezogene Kennzahlen – Über die technischen Basis-Parameter hinaus können sich Anwender auf prozessbezogene Kennzahlen beschränken und zum Beispiel für einen Online-Verkaufsvorgang die Reaktionszeiten, vom Einstellen eines Artikels in den Warenkorb des Shops bis zum Auftrag vereinbaren.
  3. Messmethoden – Für die verwendeten Parameter muss auch festgelegt werden, wie sie gemessen werden. So muss etwa für ein bestimmtes Verfügbarkeitsniveau genau definiert sein, wann, wo und mit welchen Methoden die Verfügbarkeit ermittelt wird.
  4. Monitoring – Ein umfassendes und skalierbares Monitoring für die laufenden Prozesse sowie ein entsprechendes Reporting ist für die SLA unverzichtbar.
  5. Speicherort – Es muss festgelegt sein, wo die Daten vom Provider gespeichert werden – zum Beispiel in Deutschland, in der EU oder weltweit. Dies ist auf Grund unterschiedlicher rechtlicher Regelungen unerlässlich.
  6. Eigentum an den Daten – Es muss klar sein, wem die vom Provider verarbeiteten Daten gehören – dem Provider oder seinem Kunden.
  7. Gerichtsstand – Für Streitigkeiten ist der Gerichtsstand von größter Bedeutung; die besten SLA nützen nämlich nichts, wenn sie auf den Antillen eingeklagt werden müssen. Mit dem Gerichtsstand entscheidet sich auch, welches Recht im Streitfall zur Anwendung kommt.
  8. Datensicherheit – Der Provider muss klar darlegen, was er zur Herstellung einer hohen Datensicherheit unternimmt, insbesondere bei kritischen und personenbezogenen Daten.
  9. Nachprüfbarkeit – Kunden müssen überprüfen können, ob die Festlegungen des Providers hinsichtlich der Datensicherheit eingehalten werden. Auch dazu müssen bereits in den SLA Vereinbarungen getroffen werden.
  10. Verbleib der Daten – Die SLA müssen auch Angaben dazu enthalten, was mit den Daten nach Ende der Geschäftsbeziehung geschieht, ob beispielsweise der Provider bei strittigen Forderungen ein Zurückbehaltungsrecht hat: Für solche Fälle sollte man bereits in den SLA eine Schiedsstelle vereinbaren.

Standard-Cloud-Angebote arbeiten in der Regel mit fertig vorgegebenen SLAs, die durch den Kunden nicht verändert oder nachverhandelt werden können. Diese Normierung ist meist die Voraussetzung für günstig angebotene Leistungen eines Cloud-Providers. Hier müssen Unternehmen genau prüfen, wo und wie weit die Standard-SLAs von einem eigenen Soll-SLAs abweichen – sind davon substantielle Punkte betroffen, sollte das jeweilige Angebot nicht genutzt werden.


Quelle: Easynet
Bildquelle: http://www.supplierrelationships.com, http://bluebuddies.com



Die Herausforderungen des Cloud Computing: Service Level Agreements

Mit der Adaption von Cloud Computing Technologien und Services stehen Unternehmen Herausforderungen gegenüber, die es zu bewältigen gilt. Zum einen müssen organisatorische Voraussetzungen geschaffen und Aufklärungsarbeit innerhalb des Unternehmens geleistet werden, um die Akzeptanz und das Verständnis zu stärken. Zum anderen treffen aber auch viele “Widerstände” von außen auf das Unternehmen. Das sind neben Fragen bzgl. der Sicherheit und des Datenschutz ebenfalls Themen zur Verfügbarkeit und Performanz des ausgewählten Cloud Service sowie dessen Integrationsfähigkeit in die bereits bestehende IT-Infrastruktur und die nahtlose Unterstützung der vorhandenen Geschäftsprozesse. Und wie auch schon aus den klassischen Sourcingmöglichkeiten bekannt, besteht auch im Cloud Computing die Angst, in die Abhängigkeit eines einzigen Anbieters zu verfallen. So müssen auch hier die Interoperabilität und die Schnittstellen des Anbieters sowie ein Vergleich zu anderen Anbieteren vorgenommen werden.

Ist die Entscheidung für die Nutzung des Cloud Computing gefallen, ist es für Unternehmen zunächst an der Zeit, eine Ist-Analyse der bestehenden IT-Infrastruktur und Systeme vorzunehmen, um auf Basis dieser zu planen, welche Cloud Services adaptiert werden sollen. Hier kann bspw. eine Kosten-/ Nutzen-Analyse weiterhelfen, bei der auch eine Risikobewertung nicht fehlen sollte. Um erste Erfahrungen auf dem Cloud Computing Gebiet zu sammeln, sollte ein Pilotprojekt initiiert werden, welches auf Grund des Cloud Computing Konzepts schnell und kostengünstig gestartet werden kann. Dieses sollte einem Gesamtverantwortlichen “Cloud” untergeordnert sein, der als zentrale Stelle innerhalb der Organisation für die Adaption und Beratung der einzelnen Abteilungen für dieses Thema zuständig ist. Mit den gesammelten Erfahrungen können dann weitere Projekte gestartet werden und die Adaption unterschiedlicher Cloud Services sukzessive vorgenommen werden.

Service Level Agreements

In einem Service Level Agreement (SLA) werden die von einem Anbieter zu erbringenden Leistungen und Abrechnungen fest vereinbart, wodurch die Dienstgüte zwischen dem Anbieter und seinem Kunden vertraglich und rechtsbindend festgelegt wird. Dabei wird der gemeinsame Vertrag aus der Sicht des Kunden beschrieben und der Anbieter hält im Gegenzug die Eigenschaften, den Umfang und die Qualität seiner Leistungen in einem Katalog fest.

Neben den Verfügbarkeiten der Leistungen sind in einem SLA ebenfalls die Ressourcenzuteilungen, die Verfügbarkeitsquote, die Reaktions- und Wartungszeiten sowie Vereinbarungen über Sicherheiten, Priorisierungen, Garantien und Abrechnungsmodelle enthalten. Des Weiteren werden ebenfalls Regelungen bzgl. des Supports und Fehlerbehebungen über bestimmte Fehlerklassen definiert und Reaktions- und Problemlösungszeiten festgelegt. Die entsprechenden Vereinbarungen werden jeweils über einen so genannten Key Performance Indikator (KPI) festgehalten und gemessen.

Darüber hinaus werden in einem SLA Regelungen festgehalten, die bei einem Verstoß des Anbieters gegen die zugesagten Leistungen, Rechtsfolgen nach sich ziehen. Bei der Nichteinhaltung der Verfügbarkeit wird hier z.B. das Malussystem eingesetzt. Aber auch die Pauschalisierung von Schadensersatzregelungen und die Voraussetzungen für eine beiderseitige Kündigung werden hier festgehalten.

Heinz Schick hat dazu einen Katalog mit zwanzig Eckpunkten erstellt, auf die bei der Erstellung eines SLAs geachtet werden sollte.

  1. Systembeschreibung: Detaillierte Anforderungsbeschreibung eines Services durch den Nutzer.
  2. Gültigkeitszeitraum für die SLAs: Festgelegter Zeitraum, in dem die Leistungen erfüllt werden müssen.
  3. Hauptrollen in dem SLA: Zuständigkeitsverteilung, die festlegt, wer für welche Aufgabe verantwortlich ist.
  4. Nutzerzufriedenheit: Spiegelt die Erwartung des eigentlichen Anwenders wieder.
  5. Verfügbarkeit: Legt Zeiträume fest, in denen der Anwender auf den Service uneingeschränkt zugreifen kann.
  6. Geplante Ausfallzeiten: Festgelegte Zeiträume, in denen Wartungen und Notfallübungen vorgenommen werden.
  7. Serviceschnittstellen: Wechselwirkungen zwischen den unterschiedlichen IT-Diensten werden untersucht und detailliert beschrieben.
  8. Zuverlässigkeit: Misst, wie häufig ein System ausfällt und wie lange benötigt wird, bis der Dienst nach der vereinbarten Dienstgüte wiederhergestellt ist.
  9. Leistungserwartung: Beschreibt z.B. die erwarteten Antwortzeiten und Durchsatzraten.
  10. Problem-Reporting und -lösung: Der Betrieb eines Services muss festgehalten werden. Dazu muss zu jedem KPI ein Messverfahren fest definiert und der Umfang des Reporting festgelegt werden.
  11. Benachrichtigungs- und Eskalationswege: Die Eskalationswege im Fehlerfall müssen festgelegt werden. Zudem sollte ein Anbieter bereits frühzeitig auf Probleme hinweisen.
  12. Wartung: Die Systeme müssen regelmäßigen Wartungszyklen unterzogen werden.
  13. Wachstum und Veränderungen: Der Anbieter muss auf Grund seiner eigenen Planungssicherheit von dem Kunden über das erwartete zukünftige Wachstum informiert werden.
  14. Backup und Wiederherstellung: Dabei gilt es Backup- und Recovery Prozesse einzuhalten und über entsprechend ausgebildetes Ersatzpersonal zu verfügen.
  15. Archivierung und Datenspeicherung: Die gesetzlichen und betrieblichen Archivierungsregeln müssen erfüllt werden. Des Weiteren muss ein Archivierungskonzept für die Speichersysteme vorhanden sein.
  16. Business-Recovery und -Continuity: Beschreibt einen Maßnahmenkatalog und eine Notfallplanung im Fehlerfall inkl. der Auswirkung auf die Geschäftsprozesse und einer Risikobewertung.
  17. Security: Ganzheitliche Maßnahmen und Konzepte zum Thema Sicherheit für einen Service.
  18. Regelmäßige Lagebesprechung: Intensive Kommunikation zwischen dem Kunden und dem Anbieter. Dazu gehören ebenfalls die monatliche Überprüfung der KPIs und Diskussionen über weitere Anforderungen und Verbesserungsvorschläge.
  19. Unterschrift: Der Anbieter übernimmt die Verantwortung für die bei ihm gehosteten und von ihm bezogenen Services.
  20. Kontinuierliche Administration: Permanente Kontrolle durch den Kunden. Dazu gehören das Überprüfen der Berichte und Abrechnungen.

Dienstleistungen und Produkte können kostengünstig angeboten werden, wenn sie standardisiert werden. Diesem Konzept bedienen sich auch Cloud Computing Anbieter. Neben ihren Infrastrukturen, Services etc. sind sie auch dazu übergegangen Standard-SLAs anzubieten, die für jeden Kunden gleichermaßen gelten. Auf Nachfrage, je nach Unternehmensgröße und gegen Aufpreis können die SLAs jedoch nachverhandelt und den Unternehmensbedürfnissen angepasst werden.

Daher gilt es für ein Unternehmen, eine sorgfältige Leistungsbeschreibung auf Basis des genutzten Services vorzunehmen. Hier kann sich das Unternehmen zunächst an die unterschiedlichen Servicearten des Cloud Computing, Infrastrucuture-as-a-Service (IaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS) orientieren, um zu bestimmen welche Dienstgüte für welchen genutzten Service benötigt wird.

Aus diesem Grund ist und kann kein SLA gleich sein. Das betrifft auch die Standard SLAs eines jeweiligen Anbieters. Nutzt ein Unternehmen bspw. eine ERP Anwendung auf Basis von SaaS, interessiert hier u.a. die Verfügbarkeit und eine schnelle Antwortzeit der Anwendung. Die Verfügbarkeit der darunter liegenden virtualisierten Umgebung, auf der sich die Anwendung befindet, ist nicht von Interesse. Wird hingegen Infrastruktur auf Basis von IaaS genutzt, ist die Verfügbarkeit eines virtuellen Servers von besonderer Bedeutung. Ebenfalls die Verfügbarkeit aber vor allem die Zuverlässigkeit bei der Nutzung eines Cloud Storage Service muss betrachtet werden. Die Anforderungen an die jeweiligen Cloud Services unterscheiden sich also grundlegend in ihren Eigenschaften und ihrer Abstraktionsebene.

Die folgenden grundlegenden Bereiche, sollte ein Cloud Computing SLA beinhalten:

  • Überblick: Nennt und beschreibt die Parteien (Kunde, Anbieter), die Gegenstand des SLA sind und erläutert grob den Inhalt und die vereinbarten Services, die bezogen werden sollen.
  • Umfang der Arbeiten: Eine ausführlichere Übersicht über die Services, die dem Kunden bereitgestellt werden.
  • Leistungsmessungen: Definition von Metriken, die regelmäßig gemäß den Vereinbarungen überprüft werden müssen. Dazu gehören z.B. die Betriebszeiten, der Durchsatz und die Anzahl der Benutzer, die parallel versorgt werden können. An dieser Stelle gilt es für das Unternehmen sehr genau die Metriken und Messpunkte festzulegen, die den Unternehmensanforderungen im Detail gerecht werden.
  • Vorgehen im Problemfall: Vom Unternehmen muss fest vorgegeben werden, wie sich der Anbieter im Fehlerfall verhält. Also in welchem Zeitraum er den Fehler dem Unternehmen mitteilt und wie er vorgeht, um das Problem zu lösen.
  • Gebührenstruktur: Legt im Detail die Preise fest, die der Anbieter dem Unternehmen für eine entsprechende Leistung abrechnet.
  • Pflichten des Kunden: Legt fest, wie und mit welchen Umfang das Unternehmen den Anbieter mit Informationen versorgt.
  • Zusicherungen/ Garantien: Der Anbieter muss dem Unternehmen gegenüber garantieren und erklären, wie er sicherstellen wird, die Vereinbarungen einzuhalten.
  • Security: Beschreibt die Sicherheitsfunktionen der Services inkl. den Maßnahmen, die vorgenommen werden, wenn es zu einer Sicherheitsverletzung kommt.
  • Compliance: Viele Unternehmen müssen branchenspezifische und regulatorische Anforderungen erfüllen, wie Informationen ausgetauscht werden müssen und wie dieses im Detail sichergestellt wird. Der Anbieter muss dem Unternehmen gegenüber versichern, dass er sich an diese Regelungen ebenso exakt halten wird und einen Notfallplan vorlegen, was vorgenommen wird, wenn es zu einer Außnahmesituation kommt.
    Vertrauliche Informationen und geistiges Eigentum: Es muss im Detail festgehalten werden, wem welches geistige Eigentum obliegt. Ebenso ist der Umgang mit vertraulichen Informationen für beide Seiten zu klären.
  • Haftungsschutz: In einer Cloud befinden sich die Daten eines Unternehmens über viele Standorte hinweg verteilt und werden ggf. von mehreren anderen Unternehmen weiterverarbeitet. Daher muss an dieser Stelle der Haftungsschutz eindeutig festgelegt werden. Dazu gehört neben dem Spezifizieren der Standorte, an denen die Daten des Unternehmens möglicherweise verarbeitet werden könnten ebenso das Sicherstellen, dass jedes weitere Unternehmen, das an dem Verarbeitungsprozess der Daten beteiligt ist, ebenfalls compliant zu den regulatorischen Anforderungen ist.
  • Regelmäßige Überprüfung: Um sicherzustellen, dass unvorhergesehene Probleme noch während der Vertragslaufzeit aufgedeckt werden, müssen feste Termine für regelmäßige Überprüfungen festgelegt werden.
  • Kündigung: Wie es in jedem Vertrag üblich ist, muss auch in dem SLA festgehalten werden, wie der Vertrag von beiden Seiten gekündigt werden kann. Dazu gehören ebenfalls die Schritte nach der Kündigung inkl. einer Beschreibung, wie die Daten in eine neue Umgebung übertragen werden, zusammen mit einem dazugehörigen Zeitplan.
  • Umsetzung: Es muss ein Zeitplan erstellt werden, auf den sich beide Parteien geeinigt haben. Darin wird festgehalten, wann die Übertragung zu dem neuen Service beginnt, der Zeitpunkt, zu dem der neue Service starten soll sowie die wichtigsten Meilensteine und Ergebnisse für beide Seiten.

Ein SLA ist sehr speziell und sollte daher nur für eine bestimmte Art eines Cloud Computing Services gelten. So liegt bspw. bei der Nutzung einer SaaS Applikation das Bereitstellen der Internetverbindung im Verantwortungsbereich des Unternehmens. Allerdings ist speziell die Leistung wie der Durchsatz und die Antwortzeiten sowie die Verfügbarkeit bei der Nutzung einer SaaS Applikation sehr kritisch. Eine performante und verfügbare Internetverbindung des Kunden kann der Cloud Computing Anbieter jedoch nicht garantieren. Hier muss der Kunde mit seinem Netzanbieter über ein separates SLA eine entsprechende Vereinbarung festlegen und Übergabepunkte definieren.



Cloud Computing und die rechtlichen Hintergründe

Beim Einsatz von Cloud Computing gilt es rechtliche Fragen zu klären. Sind die wichtigsten allerdings bekannt und können diese beantwortet werden, steht dem rechtlich sicheren Einsatz von Cloud Computing nichts mehr im Weg.

In einer Public Cloud haben die Benutzer nicht mehr die vollständige Kontrolle und den Überblick, wo ihre Daten tatsächlich gespeichert sind. Wo allerdings keine Kontrolle herrscht, kann auch nicht gesteuert werden. Die nicht mehr vorhandene Hoheit der Daten führt in diesem Fall zu rechtlichen Problemen. Hier sollte zunächst der Ansatz verfolgt werden, keine personenbezogenen Daten in die Cloud zu verlagern, da diese nicht den deutschen Datenschutzbestimmungen unterliegen. Werden allerdings doch personenbezogene Daten in der Cloud gespeichert, muss hier in jeden Fall die Zustimmung aller betroffenen Personen vorliegen.

Des Weiteren kann der Speicherort der Daten auf eine bestimmte Region festgelegt werden. In diesem Fall werden die Daten z.B. ausschließlich in Deutschland gespeichert, wodurch automatisch die deutschen Datenschutzbestimmungen gelten. Dabei sollte vorher natürlich vertraglich festgehalten werden, dass die Daten ausschließlich in dieser bestimmten Region abgelegt werden und nicht über mehrere verteilt sind.

Eine mögliche "Lücke" erhalten Cloud Anbieter mittels des Paragraphen 11 des Bundesdatenschutzgesetzes (BDSG). Dieser regelt die sogenannte Auftragsdatenverarbeitung. Dabei erhält der Cloud Anbieter durch den Auftrag seines Kunden das Recht die personenbezogenen Daten zu verarbeiten. Das impliziert natürlich, dass eine Verarbeitung der Daten nur dann vorgenommen werden darf, wenn der Kunde explizit die Rechte für das Erheben, Nutzen und Verarbeiten hat. Das ganze funktioniert natürlich nur, wenn der Kunde auch der Herr dieser Daten ist, also volle Kontrolle darüber hat. Allerdings spricht dieses genau gegen den eigentlichen (organisatorischen) Sinn und Hintergrund des Cloud Computing, da die in diesem Modell Daten per se überall verteilt gespeichert sind. Hinzu kommt, dass die Auftragsdatenverarbeitung nur im Wirtschaftsraum der europäischen Union (EU) so umgesetzt werden kann. Außerhalb der EU gelten andere Gesetzt zur Verarbeitung personenbezogener Daten.

Weiterhin ist zu beachten, dass die Daten in der Cloud verschlüsselt gespeichert sind, aber im Falle der Verarbeitung entschlüsselt werden müssen. Hier müssen noch technische Lösungen gefunden werden. Abgesehen davon müssen Anbieter von Cloud Services, speziell für Angebote in Deutschland das BDSG und hier insbesondere den Paragraph 9 beachten. In diesem sind alle Anforderungen festgehalten, die benötigt werden, um die technischen und organisatorischen Vorschriften des BDSG einzuhalten. Dazu gehört ebenfalls, wie der physische Zutritt, der Zugriff, die Eingabe und die Weitergabe der Daten nach Datenschutz- und Compliance spezifischen Vorgaben zu erfolgen hat.

Wichtig bei der Verlagerung der Infrastruktur in die Cloud sind - nicht nur rein rechtlich - die Leistungsübergabepunkte. An diesen Punkten wird u.a. die Verfügbarkeit eines genutzten Services festgelegt und gemessen. Hier gilt es also mittels eines Service Level Agreement (SLA) vertraglich festzulegen, welche Pflichten ein Cloud Anbieter gegenüber seinen Kunden zu erfüllen hat. Dazu gehören u.a. das Vorhandensein von Notfallplänen, die Verfügbarkeit der Services, aber auch die Möglichkeit für den Kunden, die im Vertrag festgehaltenen Pflichten mittels eines Audits zu überprüfen. SLAs sollten hinsichtlich der Art des spezifischen Services definiert werden, realistisch messbar sein und vor allem die tatsächlichen Leistungsanforderungen reflektieren. Für den Fall, das ein Service Level nicht eingehalten wird, müssen entsprechende (hohe) Strafzahlungen für den Cloud Anbieter vorgesehen werden.



openQRM ab sofort mit Service Level Agreements & Professional Services

Die openQRM Enterprise aus Köln bietet ihren Kunden und Nutzern von openQRM per sofort professionelle Service Level Agreements (SLA) auf Basis der Level Basic, Standard und Premium.

Durch die Einführung dieser SLAs setzt sich die openQRM Enterprise damit selbst das Ziel, hochqualitativen Support für die Cloud Computing Plattform openQRM zu liefern, wodurch Kunden direkten Kontakt mit dem openQRM Enterprise Support-Team herstellen können und weiterhin Zugriff auf einen Bug-Tracker erhalten.

Abgerundet werden die SLAs mit Professional Services, mit denen eine direkte Unterstützung bei der Einführung und der Lösung von Problemen mit openQRM geboten wird. Dazu gehören ebenfalls die regelmäßige Unterstützung durch das openQRM Enterprise Support-Team, um den einwandfreien Betrieb und die Wartung (Updates) von openQRM zu gewährleisten und die Entwicklung spezieller und spezifischer Funktionen und Anforderungen durch den Kunden.

Service Level Agreements

  • Vollständiges Zugriff auf das openQRM Enterprise Bug-Tracking System
  • Updates durch die openQRM Enterprise
  • Zertifizierung der openQRM Umgebung durch die openQRM Enterprise
  • openQRM Enterprise Newsletter
  • Monatliche Berichte inkl. Besprechung
  • Direkter Kontakt zum openQRM Enterprise Support-Team

Professional Services

  • Unterstützung der openQRM Umgebung auf Basis der eigenen Anforderungen
  • Automatische openQRM Updates
  • Entwicklung neuer Funktionen für openQRM - auch auf Basis eigener Anforderungen
  • Zertifizierung der openQRM Umgebung durch die openQRM Enterprise
  • openQRM Enterprise Newsletter

openQRM Updates ab sofort durch die openQRM Enterprise

Weiterhin wird die openQRM Enterprise die aktive Entwicklung von openQRM übernehmen, wodurch die Qualität und Innovation von openQRM weiter verbessert werden soll und wichtige Updates zeitnah veröffentlicht werden können.

Wichtig hierbei ist, dass die openQRM Enterprise alle Änderungen und Releases weiterhin auf dem Open-Source Repository von SourceForge.net zur Verfügung stellen wird, so dass jeder openQRM weiter frei nutzen kann.

Quelle

  • openQRM
  • openQRM Enterprise