IFR in the Clouds: True Heading & Cloud Computing

In einem der nächsten Blogeinträge werde ich über die rechtlichen Rahmenbedingungen und die damit unter Umständen verbundenen Rechtsfolgen schreiben.
Zum besseren Verständnis habe ich diesen Blogeintrag zum Thema ITIL verfasst.

Genauer gesagt, ITIL V3.
 ITIL ist eine Sammlung von Büchern, die Empfehlungen für die Umsetzung im IT Service Management geben. Nicht mehr, nicht weniger. Kein Gesetzt, keine Norm.

Warum hat ITIL dann eine so große  Bedeutung ?

In den vergangenen Jahren hat sich ITIL zu einem De-facto-Standard entwickelt, da der Empfehlungscharakter der Buchsammlung für viele Unternehmen einen sehr akzeptablen Kompromiss zwischen Eigenlösung und den sehr abstrakten Rechtsnormen ergeben (Beispiel hierzu: § 257 HGB "Aufbewahrung von Unterlagen Aufbewahrungsfristen".

Klar soweit ? Gut. Aber wenn es nur Empfehlungen sind, wieso ist das für eine rechtliche Betrachtung unter Umständen relevant ? Haftung ergibt sich immer dann, wenn nicht die nötige Sorgfalt an den Tag gelegt wurde. Da es aber keine direkte gesetztlichen Vorgaben z.B. für die Nutzung von Cloud Services (ah, wir kommen zurück zum Thema) gibt, wird man sich bei der Bewertung an Technischen Normen oder dem "Stand der Technik" orientieren. Einfach gesagt: Was hätte ein anderer Fachmann in dieser Situation gemacht.

OK, zurück zum Thema ITIL......zunächst ein paar nützliche Begriffe :-)

Was sind IT-Service ?

Stark vereinfacht sind (IT-) Services 

Ergebnisse und Nutzen, die ein Kunde erzielen möchte ohne Verantwortung und Risiko und direkte operative Kosten zu tragen.

In der Regel zur Abbilung von Geschäftsprozessen, also einem

Satz von in Wechselbeziehungen stehenden Mitteln und Tätigkeiten, die Eingaben in Ergebnisse umgestalten.

ITIL V3 gibt sehr detailiert Empfehlugen, wie diese Services:

• Strategisch geplant werden (im Prozess SERVICE STRATEGIE)
• Erstellt und Verwaltet werden (im Prozess SERVICE DESIGN)
• In Produktion gesetzt werden ( im Prozess SERVICE TRANSITION)
• Betrieben werden (im Prozess SERVICE OPERATION).

Services werden also unter Beachtung der Marktlage strategisch geplant, hierbei werden schon erste Sourcing Entscheidungen einfließen. Ein Startup wird schon in dieser Frühen Phase beschließen, kein eigenes Rechenzentrum zu bauen sondern auf Services eines Providers zurückzugreifen. Oder eben nicht, wenn IT Services zu seinem Kerngeschäft gehören. Nehmen wir an, der Service soll genutzt werden und die erforderlichen Details werden ausgearbeitet.

Hier gibt ITIL im SERVICE DESIGN klare Empfehlungen . Wichtig an dieser Stelle sind das Availibility Management, also die Festlegung der erforderlichen SLAs unter Beachtung der damit verbundenen Kapazitätsplanung.

Konkret:  Welche Leistung benötige ich mit welchem SLA und welcher Kapazität ?

Im nächsten Schritt wird geplant, wie ich die erforderliche Leistung  besorge/sicherstelle. ITIL unterscheidet hier zwischen internen Lieferanten, mit denen OLAs = Operational Level Agreements abgeschlossen werden. Alternativ können Leistungen bei externen Anbietern eingekauft werden, diese werden als UCs= Underpinning Contracts bezeichnet. Wichtig ist, dass die geschlossenen Vereinbarungen/Verträge zu den Anforderungen an die Verfügbarkeit (Availibility) passen. Der Service Level, erforderlich für den gesamten Service besteht üblicherweise aus einer ganzen Reihe von Einzelservices, die dann ggf. unterschiedliche OLAs/UCs beinhalten.

Beispiel: SLA auf ein SAP Portal beinhaltet

• OLA Server Uptime mit dem Rechenzentrum
  
• OLA Verfügbarkeit von Switches/Routern mit dem Rechenzentrum
  
• UC zur Internetanbindung mit dem Telco Provider
• UC zur Kapazitätsausweitung mit einem Cloud Anbieter.

So einfach ist das. Und noch besser: Es spielt im Sinne von ITIL überhaupt keine Rolle, ob wir Cloud Computing nutzen oder nicht. Cloud Computing ist lediglich eine Sourcing Strategie im Supplier Management. Die Schwierigkeit kann sich allerdings aus dem Cloud Grundsatz "One-Service-Fits-All" ergeben. Wir erinnern uns: Cloud Computing ist unter anderen Aspekten günstiger, weil auf individuelle Leistungs- und Vertragsgestaltung verzichtet wird. Daraus ergeben sich unmittelbar einige noch unangenehmere Folgen:

• Der Black Box Ansatz vieler Cloud Provider lässt sich schwer/nicht in das etablierte Incident Management einbinden
• Die angebotenen SLAs (also UCs im ITIL Sinne) sind nicht ausreichend (siehe auch folgenden Blogeintrag)
• Die Anforderungen von Auditoren im Rahmen von Jahresabschlussprüfungen können erschwert sein
  
• Es gibt u.U. gesetzliche Vorschriften, Details hierzu in meinem nächsten Post. (Bundesdatetenschutzgesetzt
  
• Der Cloud Provider ist, da weitestgehend bedienerlos, nicht erreichbar
• Programmatische Kontrolle über die Cloud Landschaft bedeutet neben einer höheren Flexibilität eine höhere Verantwortung
  

Zusammenfassung:

• Cloud Services sind aus ITIL Sicht weder besonders noch kritisch zu bewerten
• Cloud Computing und ITIL passen ausgezeichnet zueinander
• ITIL gibt ausgezeichnete Empfehlungen, wie komplexe IT-Services erstellt werden
• ITIL gibt ausgezeichnete Empfehlungen zu den erforderliche Sourcing Aktivitäten
  
• Zur Absicherung eines Service SLA sind immer alle Sourcing Quellen zu beachten
• Die Anforderungen an die Nachvollziehbarkeit von Geschäftsprozessen, von Daten etc. gelten auch für das Cloud Computing. Auch wenn die erforderliche Dokumentation schwerer zu erstellen, beschaffen und zu dokumentieren ist als bei einer inhouse Lösung.
  
• Die mangelnde Flexibilität im Cloud Computing beim Abschluss des UC wird einige Vorteile des Cloud Computing (Elastizität) aufwiegen