Identifikation von Nutzenpotentialen im Bereich des Cloud Computings auf Basis eines Balanced Scorecard Modells

Transkript

1 Identifikation von Nutzenpotentialen im Bereich des Cloud Computings auf Basis eines Balanced Scorecard Modells Bachelorthesis vorgelegt am an der Hochschule für Wirtschaft und Recht Berlin Fachbereich Berufsakademie Von Etienne Bottke Bereich Wirtschaft Fachrichtung Wirtschaftsinformatik Studienjahrgang 2006 Studienhalbjahr 6 Ausbildungsbetrieb IBM Deutschland MBS GmbH Erstgutachter Prof. Dr. Andreas Schmietendorf Zweitgutachter Prof. Dr. Rainer Rumpel

2 II Inhaltsverzeichnis Inhaltsverzeichnis...II Abkürzungsverzeichnis... IV Abbildungsverzeichnis... VI Tabellenverzeichnis...VII 1. Einleitung Grundlagen Cloud Computing Historie Definition verschiedener Cloud Computing Typen Infrastructure-as-a-Service Platform-as-a-Service Software-as-a-Service Abgrenzung von Virtualisierung und Cloud Computing Synthese einer Cloud Computing-Definition Abgrenzung von private und public Clouds Zielstellung von Cloud Computing Voraussetzungen für die Einführung von Cloud Computing Servicebezogene Anforderungen Service-Strategie Service-Katalog-Management / Service-Katalog Service-Level-Management Sourcing-Strategie Organisatorische Anforderungen Aufbauorganisatorische Veränderungen Ablauforganisatorische Veränderungen Technische Anforderungen Virtualisierung Hypervisoren Automatische Provisionierung Metering Monitoring Image Repository Self Service-Portale

3 III 4. Vorhandene Cloud Computing-Lösungen Vergleichsmethodologie Vergleich von public IaaS-Angeboten im Serverbereich Vergleich von public IaaS-Angeboten im Speicherbereich Analyse der Produktreife Analyse von Risiken und Gaps bei den vorhandenen Lösungen Bewertungsmodelle für Cloud Computing Methodik zur Kennzahlenentwicklung Zieldefinition Ziele der Finanzperspektive Ziele der Prozessperspektive Ziele der Kundenperspektive Ziele der Lern- und Entwicklungsperspektive Ableitung von Fragen Fragen der Finanzperspektive Fragen der Prozessperspektive Fragen der Kundenperspektive Fragen der Lern- und Entwicklungsperspektive Ableitung von Metriken Metriken der Finanzperspektive Metriken der Prozessperspektive Metriken der Kundenperspektive Metriken der Lern- und Entwicklungsperspektive Entwicklung einer Balanced Scorecard Fazit Ausblick Literaturverzeichnis Internetverzeichnis Anhang

4 IV Abkürzungsverzeichnis AMI Amazon Machine Image API Application Programming Interface ASP.NET Active Server Pages.NET ATM Asynchronous Transfer Mode AWS Amazon Web Services BSC Balanced Scorecard BSS Business Support System CORBA Common Object Request Broker Architecture CPU Central Processing Unit DDoS Distributed Denial of Service DoS Denial of Service EC2 Elastic Compute Cloud ESX Ein Typ 1 Hypervisor von VMware 1 FTP File Transfer Protocol GQM Goal Question Metric Html Hypertext Markup Language IaaS Infrastructure-as-a-Service ITIL Information Technology Infrastructure Library L2 (Cache) Level 2 (Cache) LAMP Linux, Apache, MySQL, PHP oder Python oder Perl OMG Object Management Group OS Operating System OSS Operational Support System PaaS Platform-as-a-Service QoS Quality of Service RPC Remote Procedure Call S3 Simple Storage Service SaaS Software-as-a-Service SLA Service Level Agreement SLM Service Level Management 1 Weitere Informationen unter

5 V SOA Serviceorientierte Architektur SPOC Single Point of Contact SSL Secure Socket Layer TCO Total Cost of Ownership TCP / IP Transaction Control Protocol / Internet Protocol VM Virtuelle Maschine VMM Virtual Machine Manager XEN Ein Typ 1 Hypervisor von Citrix 2 XML extensible Markup Language 2 Weitere Informationen unter

6 VI Abbildungsverzeichnis Abbildung 1: Die Schichten und Aspekte von Cloud Computing (IT-as-a-Service) Abbildung 2: IT-Service-Lebenszyklus nach ITIL V Abbildung 3: Zusammenhang von Service-Strategie, Service-Katalog und den IT- Service-Lebenszyklus-Phasen Abbildung 4: Beispielhafte Architekturbausteine einer private Cloud-Lösung Abbildung 5: Anbietervergleich im public IaaS-Serverbereich Abbildung 6: Anbietervergleich im public IaaS-Storagebereich Abbildung 7: Schematischer Aufbau eines Bewertungsmodells nach dem GQM- Ansatz Abbildung 8: Ursache-Wirkung Diagramm der Ziele der BSC Abbildung 9: Entwicklung der Suchhäufigkeit und der Anzahl der Erwähnungen des Begriffs Cloud Computing auf Nachrichtenseiten von Januar 2007 bis Mai Abbildung 10: Entwicklung der Suchhäufigkeit und der Anzahl der Erwähnungen der Begriffe Cloud Computing, SOA und CORBA von Januar 2004 bis Mai Abbildung 11: Hype Cycle für neue Technologien Abbildung 12: Abdeckung der Cloud-Architekturbausteine durch IBM Produkte Abbildung 13: Anbieter im Hosting, Infrastructure Utility und Cloud Computing- Umfeld

7 VII Tabellenverzeichnis Tabelle 1: Eigenschaften von SaaS Tabelle 2: Eigenschaften verschiedener public IaaS-Anbieter im Serverbereich Tabelle 3: Eigenschaften verschiedener public IaaS-Anbieter im Speicherbereich Tabelle 4: GQM Template Tabelle 5: GQM Template für das Metaziel Optimierung der Kostenstruktur Tabelle 6: Abstraction Sheet für das Metaziel Optimierung der Kostenstruktur Tabelle 7: GQM Template für das Metaziel Reduktion der Prozesskosten Tabelle 8: Abstraction Sheet für das Metaziel Reduktion der Prozesskosten Tabelle 9: GQM Template für das Metaziel Reduktion der Prozessanzahl Tabelle 10: Abstraction Sheet für das Metaziel Reduktion der Prozessanzahl Tabelle 11: GQM Template für das Metaziel Erhöhung der Kundenzufriedenheit Tabelle 12: Abstraction Sheet für das Metaziel Erhöhung der Kundenzufriedenheit Tabelle 13: GQM Template für das Metaziel Optimierung der Rollenstruktur Tabelle 14: Abstraction Sheet für das Metaziel Optimierung der Rollenstruktur Tabelle 15: Vergleich typischer Eigenschaften Application Hosting und SaaS Tabelle 16: Verschiedene Definitionen für Cloud Computing, chronologisch geordnet Tabelle 17: Definierte Usertypen für public IaaS-Serverangebote Tabelle 18: Definierte Usertypen für public IaaS-Speicherangebote Tabelle 19: Struktur eines GQM Abstraction Sheet Tabelle 20: Definition der Kennzahl Höhe der IT-Ausgaben Tabelle 21: Definition der Kennzahl Höhe der IT-Kostenquote Tabelle 22: Definition der Kennzahl Anteil variabler Kosten an den IT-Ausgaben Tabelle 23: Definition der Kennzahl Anteil fixer Kosten an den IT-Ausgaben Tabelle 24: Definition der Kennzahl Anteil auf Verbrauchsbasis berechneter Services Tabelle 25: Definition der Kennzahl Anteil fix abgegoltener Services Tabelle 26: Definition der Kennzahl Umsatz mit fix abgegoltenen Services Tabelle 27: Definition der Kennzahl Umsatz mit variabel berechneten Services Tabelle 28: Definition der Kennzahl Veränderung des Umsatzes fix abgegoltener Services Tabelle 29: Definition der Kennzahl Veränderung des Umsatzes pay-per-use berechneter Services Tabelle 30: Definition der Kennzahl Ø Kosten je Bereitstellungsprozess

8 VIII Tabelle 31: Definition der Kennzahl Abweichung der Aktuellen Ø Kosten je Bereitstellungsprozess von den geplanten Ø Kosten je Bereitstellungsprozess Tabelle 32: Definition der Kennzahl Ø Anzahl definierter Prozessschritte in Bereitstellungsprozessen Tabelle 33: Definition der Kennzahl Ø Anzahl manueller Prozessschritte in Bereitstellungsprozessen Tabelle 34: Definition der Kennzahl Veränderung der Ø Bereitstellungsprozesskosten Tabelle 35: Definition der Kennzahl Anzahl definierter Bereitstellungsprozesse Tabelle 36: Definition der Kennzahl Anzahl definierter Prozessschritte Tabelle 37: Definition der Kennzahl Subjektive Bewertung der Prozesstreue durch den IT-Verantwortlichen Tabelle 38: Definition der Kennzahl Anteil in Reviews identifizierter Abweichungen vom Standardprozess Tabelle 39: Definition der Kennzahl Anzahl bereitgestellter Services Tabelle 40: Definition der Kennzahl Subjektive Bewertung der Komplexität der Bereitgestellten Services durch den IT-Verantwortlichen Tabelle 41: Definition der Kennzahl Veränderung der Bereitstellungsprozessanzahl Tabelle 42: Definition der Kennzahl Anzahl Servicerequests für Services mit niedriger/mittlerer/hoher Komplexität Tabelle 43: Definition der Kennzahl Ø Bereitstellungszeit Tabelle 44: Definition der Kennzahl Standardabweichung der Bereitstellungszeit Tabelle 45: Definition der Kennzahl Anteil der Bereitstellungen die länger als die Maximalzeit dauern Tabelle 46: Definition der Kennzahl Veränderung der Bereitstellungszeit Tabelle 47: Definition der Kennzahl Veränderung der Kundenzufriedenheit Tabelle 48: Definition der Kennzahl Anzahl Mitarbeiter Tabelle 49: Definition der Kennzahl Mitarbeiterfluktuation Tabelle 50: Definition der Kennzahl Anteil der Mitarbeiter mit neuen Rollen Tabelle 51: Definition der Kennzahl Administrator-Server-Verhältnis

9 Einleitung Insbesondere in wirtschaftlich angespannten Zeiten sehen sich IT-Abteilungen und Organisationen mit einem immer größeren Kostendruck und sinkenden Budgets konfrontiert. Daher suchen viele Unternehmen nach Möglichkeiten, ihre IT flexibler und kosteneffizienter zu gestalten, um Einsparpotentiale zu realisieren. 3 Dem gegenüber steht ein stark wachsender Bedarf nach IT-Ressourcen wie Rechenzeit, Speicherkapazität und der Verfügbarkeit von Software. Zur Lösung dieser Problematik existieren verschiedene Ansätze. Ein Begriff, der in diesem Zusammenhang in den letzten Jahren immer häufiger in der Fachpresse erwähnt wurde, ist Cloud Computing. Seit Amazon, Google und Microsoft Produkte angekündigt haben, die mit Cloud Computing überschrieben sind, ist dieses auch in einer breiteren Öffentlichkeit ein Thema (Siehe Abbildung 9 im Anhang). 4 Diese Popularität führt zu einer sehr großen Zahl an Publikationen und Meinungsäußerungen und einer entsprechenden Unklarheit darüber, was Cloud Computing eigentlich ist. 5 Das Fehlen einer einheitlichen Definition und das frühe Stadium des Hypes um Cloud Computing 6 haben diese Problematik weiter verstärkt. Da die Datenbasis der bereits umgesetzten Cloud-Lösungen bisher nur klein ist, steht die wissenschaftliche Untersuchung der Auswirkungen und des Nutzens dieser Lösungen noch aus. Dennoch plant mehr als ein Drittel aller Unternehmen, in den nächsten zwei Jahren unternehmenskritische Anwendungen in die Wolke zu verlagern. 7 Ziel dieser Arbeit wird es daher sein, den Entwurf eines Bewertungsmodells zu entwickeln. Hierfür wird zunächst eine Definition für Cloud Computing synthetisiert. Anschließend sollen die Anforderungen an ein Unternehmen, welches plant Cloud Computing einzuführen, erarbeitet werden. Der Hauptteil der Arbeit wird sich mit der Erarbeitung eines strategischen Steuerungswerkzeugs und eines Bewertungsmodells beschäftigen und zeigen, wie Cloud Computing-Lösungen anhand von wichtigen Kennzahlen und Messgrößen bewertet werden können. Bei all diesen Betrachtungen werden private Cloud-Lösungen im Vordergrund stehen. Lediglich für den Vergleich verschiedener Cloud-Angebote werden public Cloud- Lösungen herangezogen. 3 Vgl. [68] Happich, Gudrun (2009). 4 Vgl. [69] Herrmann, Wolfgang (2009). 5 Vgl. [83] Schaffry, Andreas (2009). 6 Vgl. [3] Ball, Graham et al. (2008), S. 13f, siehe auch Abbildung 11 im Anhang. 7 Vgl. [28] Guptill, Bruce (2008), S. 1ff.

10 Grundlagen Cloud Computing Als Grundlage für die Erarbeitung eines Bewertungsmodells für Cloud Computing soll in diesem Kapitel zunächst beleuchtet werden, aus welchen Paradigmen sich Cloud Computing entwickelt hat. Anschließend werden verschiedene Definitionsansätze näher betrachtet, um ein einheitliches Verständnis möglichst vieler Aspekte des Cloud Computings zu schaffen. Darauf aufbauend soll eine Abgrenzung zum Themengebiet Virtualisierung geschaffen und die Unterschiede von private und public Clouds herausgearbeitet werden. 2.1 Historie Die Ursprünge des Cloud Computings in seiner heutigen Form liegen in verschiedenen Paradigmen zur effizienteren Nutzung begrenzter oder verteilter IT-Ressourcen. Aus Infrastruktur-Sicht geht das Cloud Computing auf Service-Büros und Timesharing- Systeme zurück, die bereits Anfang der 1960er Jahre zur besseren Auslastung der ersten Großrechner existierten. Diese ermöglichten es Endnutzern, per Telefon die Rechenleistung des unter Umständen weit entfernten Großrechners zu nutzen. 8 Dieses Paradigma wurde durch das Aufkommen von PCs Anfang der 1980er Jahre abgelöst. Diese versprachen, die Abhängigkeit von einem zentralen Rechenzentrum aufzubrechen und zu einer größeren Autonomie über Daten und Programme zu führen. 9 Da ein Großteil, der nun auf den PCs vorhandenen Rechenkapazität brach lag, wurde zu Beginn der 1990er Jahre Grid Computing entwickelt. Durch dieses Paradigma des verteilten Rechnens war es möglich, komplexe, rechenintensive Aufgaben in kleine Teilprobleme zu zerteilen und auf mehreren Rechnern lösen zu lassen. 10 Diese Entwicklung setzte sich im Paradigma des bereits 1960 beschriebenen Utility Computing fort. 11 Dahinter verbirgt sich die Idee, IT-Ressourcen ähnlich wie Strom, Gas, Wasser und Telefonie als Service über ein Versorgungsnetz zu beziehen und je nach Nutzung zu bezahlen. 12 Dieses Paradigma geht nun fließend ins Cloud Computing über. Neben dieser Entwicklung auf Infrastrukturebene gab es auch auf der Anwendungsebene Ansätze, die dem Cloud Computing ähnlich sind und zu diesem geführt haben. Bereits Anfang der 1990er Jahre konnten Programme durch Remote Procedure Calls (RPCs) transparent auf 8 Vgl. [29] Hayes, Brian (2008), S Vgl. ebenda, S Vgl. [26] Foster, Ian (2002), S. 1ff. 11 Vgl. [87] Thompson, Matt (2009). 12 Vgl. [45] Rappa, Michael (2004), S. 33f.

11 - 3 - verteilten Rechnern ausgeführt werden. Mit dem Aufkommen der objektorientierten Programmierung entstand der Bedarf, eine ähnliche Verteilung für Objekte zu erzielen. Das Ergebnis der Entwicklungen in diesem Bereich war der von der OMG veröffentlichte CORBA- Standard. Damit war es möglich, Objekte unabhängig von der Sprache in der sie implementiert waren und dem Rechner auf dem sie residierten, zu nutzen. Daraus entwickelte sich die Vorstellung eines Object Webs, in welchem Objekte residieren, die für einzelne Anwendungen verwendet werden können, ohne zu wissen, wo sie sich befinden. 13 Mit Aufkommen des Servicegedankens wurde dieses Paradigma abgewandelt und zu SOA weiterentwickelt. Hierbei werden nicht ganze Objekte, sondern Services mit definiertem In- und Output konsumiert. Der SOA eigene Servicegedanke wird im Cloud Computing auf die gesamte IT übertragen und einen Schritt weiter entwickelt, so dass die Paradigmen heute langsam ineinander übergehen. 14 Begrifflich wurde die Cloud erstmals 1993 in einem kommerziellen Zusammenhang erwähnt. 15 Damals allerdings im Kontext mit großen ATM-Netzwerken wurde Cloud Computing zum ersten Mal im heutigen Begriffskontext verwendet, damals jedoch beschränkt auf den Software-as-a-Service-Aspekt. 16 Dieser und weitere Aspekte sollen zur Erarbeitung einer Definition im Folgenden vorgestellt werden. 2.2 Definition verschiedener Cloud Computing Typen Obwohl der Begriff Cloud Computing bereits seit 2001 in der Fachpresse immer wieder erwähnt wird, existiert bis heute keine allgemein akzeptierte Definition des Begriffs. 17 Alle bisher vorgeschlagenen Definitionen beschränken sich auf wenige Aspekte des Cloud Compu ting oder sind durch ein bestimmtes Produktportfolio geprägt. So verstehen Anbieter von Virtualisierungslösungen Cloud Computing als Weiterentwicklung der Server- und Desktopvirtualisierung der letzten Jahre. 20 Softwarehersteller wiederum verstehen Cloud Computing häufig als Vertriebs- und Verbreitungsmodell für ihre Software im 13 Vgl. [21] Chun, Andy Hon Wai; Wong, Gary Yat Chung (1999), S. 447ff. 14 Vgl. [75] Manhart, Klaus (2009). 15 Vgl. [73] Laubach, Mark (1993). 16 Vgl. [76] New York Times (2001). 17 Vgl. [7] Books24x7 (2009), S Siehe hierzu Tabelle 16 im Anhang. 19 Vgl. [69] Herrmann, Wolfgang (2009). 20 Vgl. [49] VMware (2009), S. 3f.

12 - 4 - Sinne von Software-as-a-Service (SaaS) oder Platform-as-a-Service (PaaS). 21 Hardwareanbieter und Unternehmen, die über große Rechen- und Speicherkapazitäten verfügen, verstehen Cloud Computing häufig als bloße Bereitstellung dieser Kapazitäten im Sinne von Infrastructure-as-a-Service (IaaS). 22 Die folgende Abbildung zeigt, wie Cloud Computing im Rahmen dieser Arbeit weiter gefasst als IT-as-a-Service verstanden wird. Abbildung 1: Die Schichten und Aspekte von Cloud Computing (IT-as-a-Service) (Quelle: [57] Barnitzke, Armin (2009)) Demnach beinhaltet eine Cloud-Lösung die Aspekte IaaS, PaaS und SaaS, die teilweise durch Virtualisierung zur Verfügung gestellt werden. Da auch bei den Definitionen und Erklärungen einiger Aspekte in der Literatur Uneinigkeit herrscht, sollen die Schichten im Folgenden näher beschrieben werden Infrastructure-as-a-Service Infrastructure-as-a-Service (IaaS) ist die unterste Stufe einer Cloud-Architektur. 23 Es beschreibt die Bereitstellung grundlegender IT-Ressourcen als Service über das Netzwerk. 21 Vgl. [39] Kurz, Johann (2008), S. 34ff. 22 Vgl. [52] Amazon Web Services (2009a). 23 Vgl. [48] Sun Microsystems (2009), S. 14.

13 - 5 - Dabei verfügt ein Serviceprovider über entsprechend große Speicher-, Rechen- und Netzwerkkapazitäten, die durch Technologien wie Virtualisierung zu Pools zusammengefasst werden. Aus diesen Pools können die Ressourcen dynamisch aufgeteilt, zugewiesen und elastisch skaliert werden. Hierdurch können bestimmte Workloads verarbeitet und Belastungsspitzen ausgeglichen werden. Vielfach findet sich in diesem Zusammenhang noch die Unterscheidung bzw. Abgrenzung von Storage-as-a-Service zu IaaS. 26 Dies bezieht sich meist speziell auf die Verwendung des Speichers als Backup-System, im Gegensatz zur Nutzung für Bewegungsdaten während der Verarbeitung. Im Rahmen dieser Arbeit wird Storage-as-a-Service als Bestandteil von IaaS angesehen Platform-as-a-Service Platform-as-a-Service (PaaS) oder auch Application Platform-as-a-Service (APaaS) stellt ein weiteres Abstraktionslevel zur Verfügung. Primär wird hier eine Plattform zur Verfügung gestellt, auf der Anwendungssoftware laufen kann. Die Bereitstellung der notwendigen Hardware-Ressourcen erfolgt dabei transparent. 27 Die Services, die in diesem Bereich angeboten werden, unterscheiden sich teilweise sehr stark in Art und Umfang. Sie reichen von der bloßen Bereitstellung einer Laufzeitumgebung für Programme in bestimmten Sprachen (z.b. Python und Java bei Google Apps Engine 28 ). Beinhalten aber auch ganze Programmierumgebungen, Betriebssysteme (z.b. Microsoft Azure) oder eine Laufzeitumgebung für eine Vielzahl an Applikationen (z.b. Salesforce Force.com). 29 Die Grenze zu Software-as-a-Service verläuft hier fließend Software-as-a-Service Software-as-a-Service (SaaS) bildet die oberste Schicht der Cloud-Architektur. 30 Sie ist dabei die Ebene, die am meisten in der Literatur wahrgenommen und mit dem Begriff Cloud Computing in Zusammenhang gebracht wird. 31 Gleichzeitig ist SaaS aber auch ein Begriff, der 24 Vgl. [48] Sun Microsystems (2009), S Vgl. [15] Caceres, Juan et al. (2008), S Vgl. [22] CXO Media (2008), S Vgl. [15] Caceres, Juan et al. (2008), S Vgl. [67] Google (2009). 29 Vgl. [57] Barnitzke, Armin (2009). 30 Vgl. ebenda. 31 Vgl. [37] Kontzer, Tony (2008), S. 32.

14 - 6 - sehr stark für Marketingzwecke verwendet wird, ohne dass das darunter liegende Produkt tatsächlich dem Software-as-a-Service Modell entspricht. 32 Im Allgemeinen versteht man unter SaaS ein Software-Distributionsmodell, bei dem Anwendungen über das Netzwerk als Service bezogen werden. 33 Die Applikation selbst verbleibt im Eigentum des Serviceproviders und wird von diesem auch betreut und gewartet. 34 Neben diesen wesentlichen Eigenschaften zeigt Tabelle 1 weitere Eigenschaften von SaaS, die in der Literatur erwähnt und als essentiell angesehen werden. Tabelle 1: Eigenschaften von SaaS Eigenschaften von SaaS Das Bezahlungsmodell basiert auf dem Umfang der Nutzung (payper-use, im Gegensatz zu einmaligen Lizenzgebühren) Alle Nutzer haben (typischerweise) Zugriff auf eine oder sehr wenige Instanzen der angebotenen Software (single instance multi-tenancy) Der Zugriff auf die Software erfolgt mittels Webtechnologien (TCP/IP, Html, XML, Web Browser, etc.) Die Software verbleibt im Eigentum des Serviceproviders und wird von diesem betreut und gewartet (Patches, Updates, etc.) Die angebotene Software beruht auf einem einheitlichen Kern und wird nicht für jeden Kunden individuell aufgesetzt/angepasst. SaaS ist insbesondere auf ein one-to-many-geschäftsmodell ausgerichtet Die eingesetzte Software ist hochgradig konfigurierbar, da Codeanpassungen nicht möglich/vorgesehen sind Quelle/n (Auswahl) [1] Alvarez, Gene et al. (2008), S. 4. [42] Plex Systems (2009), S. 2. [51] West, Mike (2008), S. 1. [9] Bradshaw, David (2009), S. 6. [42] Plex Systems (2009), S. 3. [48] Sun Microsystems (2009), S. 13f. [1] Alvarez, Gene et al. (2008), S. 4. [9] Bradshaw, David (2009), S. 6. [42] Plex Systems (2009), S. 1. [1] Alvarez, Gene et al. (2008), S. 4. [9] Bradshaw, David (2009), S. 6. [42] Plex Systems (2009), S. 1. [1] Alvarez, Gene et al. (2008), S. 4. [1] Alvarez, Gene et al. (2008), S. 4. [9] Bradshaw, David (2009), S. 6. [42] Plex Systems (2009), S. 3. [9] Bradshaw, David (2009), S. 6. Die angebotene Software reicht dabei von grundlegenden Unternehmensapplikationen wie bis hin zu vollständigen CRM-Systemen. Die vielfach unklare Abgrenzung zum Application Hosting wird beim Vergleich der typischen Eigenschaften beider Lösungen deutlich. 35 So unterscheidet sich SaaS maßgeblich 32 Vgl. [42] Plex Systems (2009), S Vgl. [1] Alvarez, Gene et al. (2008), S Vgl. ebenda, S Siehe hierzu Tabelle 15 im Anhang.

15 - 7 - durch das Lizenzmodell (OS und SW) und im grundlegenden System-Design vom klassischen Application Hosting. Neben dieser Abgrenzung zum Application Hosting auf organisatorischer Ebene soll im Folgenden auch eine Abgrenzung auf der eher technischen Ebene zur Virtualisierung geschaffen werden. 2.3 Abgrenzung von Virtualisierung und Cloud Computing Insbesondere Anbieter von Virtualisierungssoftware betonen immer wieder die Bedeutung von Virtualisierung für das Cloud Computing. 36 Eine Beschreibung dieses Zusammenhangs oder eine klare Abgrenzung ist dabei meist nicht vorhanden. Auf der untersten Ebene einer Cloud-Architektur ist der Zusammenhang von Virtualisierung und Cloud Computing noch relativ offensichtlich. Für jedes IaaS-Angebot werden virtualisierte Ressourcen verwendet. 37 Anders ist eine Umsetzung der Elastizitätsanforderungen an eine Cloud kaum möglich. Auf der PaaS- und SaaS-Ebene kommen Virtualisierungstechniken schon bei der Entwicklung neuer Software für das Cloud Computing zum Tragen. So müssen Plattform- und Softwarelösungen nicht mehr zwingend eine große Zahl an verschiedenen Betriebssystemen und Konfigurationen unterstützen, sondern können auf einer Umgebung entwickelt, getestet und auf diese zugeschnitten werden. 38 Die Auslieferung erfolgt dann als komplettes Package einer laufenden VM. 39 Ein Archiv dieser virtuellen Maschinen kann die Grundlage bilden, um in Echtzeit elastisch zu skalieren. Trotz dieses starken Zusammenhangs von Virtualisierung und Cloud Computing erfordert eine Cloud-Lösung noch weitere Aspekte, die über klassische Virtualisierung hinausgehen. Zum Beispiel verfügen Hypervisoren meist nicht über die Funktionalität, den Ressourcenkonsum einer virtuellen Maschine einem Nutzer zuzuordnen. 40 Eine Cloud-Lösung erfordert allerdings, dass der Ressourcenverbrauch jedes Kunden genau erfasst wird, um die Nutzungskosten berechnen zu können. Darüber hinaus werden Virtualisierungstechniken vorwiegend genutzt, um vorhandene Workloads besser zu verteilen und die Utilization einzelner Maschi- 36 Vgl. [49] VMware (2009). S. 3ff. 37 Vgl. [15] Caceres, Juan et al. (2008), S. 51f. 38 Vgl. [29] Hayes, Brian (2008), S Vgl. [38] Kroeker, Kirk (2009), S Vgl. [59] Eucalyptus Systems (2009).

16 - 8 - nen zu steigern. Die Einführung einer Cloud geht darüber hinaus und zielt darauf ab, den Servicegedanken in der IT konsequent umzusetzen. Eine Cloud Computing-Lösung erfordert demnach neben der Technologie Virtualisierung noch weitere Änderungen im Serviceverständnis und der Organisation der IT in einem Unternehmen. Virtualisierung ist also eine wesentliche Voraussetzung für die Funktionalität einer Cloud Computing-Lösung, aber ein virtualisiertes Rechenzentrum allein ist keine Cloud. Diese teilweise unklare Abgrenzung, die Vielzahl an veröffentlichten Definitionen und der intensive Gebrauch des Wortes Cloud Computing im Marketingumfeld haben ein einheitliches Begriffsverständnis bisher nicht ermöglicht. Daher soll im Folgenden eine Definition im Rahmen dieser Arbeit hergeleitet werden. 2.4 Synthese einer Cloud Computing-Definition Die Bisher veröffentlichten Definitionen unterscheiden sich teilweise sehr deutlich voneinander. So grenzt beispielsweise Forrester Research SaaS klar vom Cloud Computing ab 43, während es in anderen Quellen und im Rahmen dieser Arbeit als eine Ebene der Cloud- Architektur angesehen wird. 44 Viele Unternehmen orientieren sich bei ihrem Begriffsverständnis stark an ihrem Produktportfolio, während die großen Beratungshäuser und Analysten eher den Ansatz von Befragungen zur Synthese einer Definition verfolgen. Die hieraus entstehenden Definitionen zielen jedoch darauf ab, entscheiden zu können, ob eine gegebene Lösung Cloud Computing ist oder nicht. Da Cloud Computing allerdings kein einzelnes Produkt, sondern ein System aus verschiedenen Technologien, Architekturen und Services ist, 45 sollte weniger nach einer singulären Definition, als vielmehr nach einem Modell gesucht werden, das Cloud Computing beschreibt. Hierbei sollen die Eigenschaften berücksichtigt werden, die in einem Großteil der Definitionen zum Ausdruck kommen. Dies sind vor allem die elastische Skalierbarkeit, die Bezahlung je nach Nutzungsumfang und die Nutzung von Internettechnologien. 46 Darüber hinaus spielt eine hochgradige Automatisierung der Abläufe innerhalb der IT eine wesentliche Rolle Vgl. [11] Brodkin, Jon (2008), S Vgl. [59] Eucalyptus Systems (2009). 43 Vgl. [69] Herrmann, Wolfgang (2009). 44 Siehe 2.2 Definition verschiedener Cloud Computing Typen. 45 Vgl. [39] Kurz, Johann (2008), S Siehe Tabelle 16 im Anhang. 47 Vgl. Listing 1: Interview mit Michael Behrendt, Fragen 5 und 6.

17 - 9 - In Anlehnung an die Definition von [5] Bittman, Thomas et al. (2009) wir das Cloud Computing-Modell im Rahmen dieser Arbeit wie folgt verstanden: Cloud Computing ist ein Modell zur Erstellung und automatisierten Lieferung von standardisierten IT-Ressourcen als Service (IT-as-a-Service) an interne und/oder externe Kunden, über das Netzwerk. Diese Ressourcen können elastisch skaliert werden, während sich die Kosten ausschließlich nach dem Verbrauch richten. Hierbei umfassen IT-Ressourcen alle Aspekte von IaaS, PaaS und SaaS. Im Rahmen dieses Modells werden nicht nur Lösungen als Cloud Computing verstanden, die alle drei Aspekte beinhalten. Aber je mehr Aspekte inbegriffen sind, desto größer ist der Bezug zum Modell und um so eher können die mit Cloud Computing assoziierten Optimierungspotentiale realisiert werden Abgrenzung von private und public Clouds Cloud-Lösungen lassen sich neben der Unterscheidung nach der Stärke des Bezugs zum Cloud-Modell, noch in private und public Clouds differenzieren. Die Grenze zwischen beiden Ansätzen ist dabei Teil der Diskussion um eine einheitliche Definition. So werden private Clouds teilweise als Einstiegspunkt großer Unternehmen ins Cloud Computing gesehen, 49 teilweise werden sie als bloße Marketingkonstrukte interpretiert, 50 oder ihre Existenz gänzlich negiert. 51 Dem gegenüber steht ein großes Wachstumspotential des Marktes um private Clouds und die Absicht vieler Unternehmen, diese zu implementieren. 52 Die Unterscheidung zwischen private und public Clouds wird dabei typischerweise an den räumlichen Gegebenheiten (on-premise/off-premise), der Beziehung der Nutzer untereinander oder den Besitzverhältnissen der zugrunde liegenden Infrastruktur getroffen. On-premise meint hierbei, dass der physikalische Aufenthaltsort der Cloud-Ressourcen auf dem Firmengelände liegt, während off-premise eine physikalische Position außerhalb des Firmengeländes meint. Im Rahmen dieser Arbeit gilt eine Cloud Computing-Lösung als private Cloud, wenn der Servicekonsument gleichzeitig Eigentümer der darunter liegenden Infrastruktur ist. Er 48 Vgl. [5] Bittman, Thomas et al. (2009), S Vgl. [48] Sun Microsystems (2009), S Vgl. [72] Kuppinger, Martin (2009). 51 Vgl. [58] Conry-Murray, Andrew (2009). 52 Vgl. [51] West, Mike (2008), S. 6.

18 muss dabei nicht zwingend Betreiber dieser sein, das heißt es existiert auch die Möglichkeit einer hosted private Cloud. 53 Darüber hinaus spielt die Art und Größe des Nutzerpools eine Rolle, das heißt, dass eine private Cloud typischerweise dediziert nur einem Unternehmen oder Unternehmensverbund zugänglich ist. Bei public Clouds ist der Servicekonsument demnach nicht Eigentümer der Infrastruktur, diese ist Eigentum des Serviceproviders und der Nutzerkreis ist relativ groß und offen. Infrastruktur bezieht sich hierbei sowohl auf Hardware als auch auf Software. Beide Cloud Computing-Formen können dabei nicht isoliert voneinander betrachtet werden, da es Mischformen und Überschneidungen geben kann. Eine Cloud wie Amazons EC2 ist aus Sicht eines externen Kunden eine public Cloud. Aus Sicht einer Abteilung von Amazon, die EC2 für ihre Zwecke nutzt, ist sie eine private Cloud. Hieraus folgt, dass eine Überschneidung beider Formen existiert, wenn ein Serviceprovider auch gleichzeitig ein Konsument seiner Services ist. Eine Mischform zwischen beiden entsteht beispielsweise, wenn ein private Cloud Service auf einem public Cloud Service aufgesetzt wird, ein denkbares Szenario ist hier eine private SaaS-Lösung unter Verwendung eines public IaaS-Angebots. 54 Ähnlich verhält es sich, wenn die Kapazitäten einer private Cloud um Ressourcen einer public Cloud ergänzt werden, um Spitzenbelastungen abzufedern. 55 Diese werden als hybrid Cloud-Lösungen bezeichnet. Auch Cloud-Lösungen, die im Kontext eines Extranets nach dem e-business Modell existieren, verwischen diese Grenze. 56 Das größte Nutzenpotential wird hierbei eben diesen Mischformen zugeschrieben. 57 Die initiale Entscheidung vieler Unternehmen für eine reine private Cloud ist daher vorwiegend von Sicherheits- und Verfügbarkeitsaspekten gesteuert, da public Clouds hier noch nicht die entsprechenden SLA, QoS und Sicherheitsansprüche erfüllen kön nen. Unabhängig davon ob eine Cloud-Lösung private oder public ist, werden mit dem Cloud Computing-Modell bestimmte Zielstellungen verfolgt. Welche dies sind, wird im nächsten Abschnitt dargestellt. 53 Vgl. Listing 1: Interview mit Michael Behrendt, Frage Vgl. [5] Bittman, Thomas et al. (2009), S Vgl. [11] Brodkin, Jon (2008), S Vgl. ebenda, S Vgl. [49] VMware (2009), S Vgl. [48] Sun Microsystems (2009), S Vgl. [44] Preimesberger, Chris (2008), S. 18.

19 Zielstellung von Cloud Computing Änderungen der IT-Architektur und der Art und Weise, wie IT betrieben wird, wurden immer durch äußere Umstände beeinflusst. Im Umfeld zunehmend gesättigter Märkte, sinkender IT- Budgets und höheren Flexibilitätsanforderungen wird der Ergebnisdruck direkt auf die IT übertragen. 60 Im Kontext der Finanz- und Wirtschaftskrise wird elastisches Skalieren und die Möglichkeit, kurzfristig IT-Aufwendungen reduzieren zu können, immer bedeutsamer. Insbesondere mit Hinblick auf die Tatsache, dass Unternehmensserver üblicherweise nur zu 15% ausgelastet sind und der Betrieb eines Assets jährlich das zwei- bis dreifach des Anschaffungspreises ausmacht, wodurch bis zu 70% der IT-Budgets für den Unterhalt aufgewendet werden müssen. 61 Cloud Computing adressiert all diese Problemfelder. Die Zielstellungen sind dabei, unabhängig von der Diskussion um eine Definition, auf einem hohen Abstraktionslevel breiter Konsens. Hier werden Cloud Computing-Lösungen mit der Reduktion von Kosten, einer Flexibilisierung der IT und der besseren Unterstützung des Kerngeschäfts durch die IT assoziiert. 62 Die hiermit verbundenen Feinziele hängen jedoch stark vom Bezug einer konkreten Cloud- Lösung zum Cloud Computing-Modell ab. Darüber hinaus spielt die Entscheidung für eine private oder public Cloud-Lösung eine wesentliche Rolle. Bei public Cloud-Services liegt der Schwerpunkt der Kunden klar auf der Kostenreduktion und der gesteigerten Flexibilität durch die elastische Skalierbarkeit. Neben der reinen Reduktion der Ausgaben findet auch eine Umwandlung von fixen Kosten (z.b. IT-Budget) in variable Kosten statt (pay-per-use), die wiederum die Beweglichkeit und Flexibilität des Unternehmens als Ganzes stärkt. 63 Hierdurch werden auch die TCO für IT-Lösungen verringert, da diese nun maßgeblich vom Umfang der Nutzung abhängen und nicht mehr vom Umfang der benötigten Infrastruktur. 64 Die Flexibilität wird gesteigert, da abhängig von der Art der Schnittstelle und Komplexität des Service ein schneller Providerwechsel möglich ist. Darüber hinaus bieten public Cloud-Lösungen die Möglichkeit, das Wachstum des Ressourcenbedarfs und Lastspitzen kostengünstig auszugleichen, ohne neue Hardware anschaffen zu müssen Vgl. [68] Happich, Gudrun (2009). 61 Vgl. [33] IBM Corporation (2009b), S Vgl. [51] West, Mike (2008), S. 2f. 63 Vgl. [50] Vizard, Michael (2009), S Vgl. [51] West, Mike (2008), S Vgl. [48] Sun Microsystems (2009), S. 5.

20 Kunden, die sich für private Cloud Computing-Lösungen entscheiden, haben meist einen Fokus auf alle drei Grobziele. Welches dabei besonders stark im Vordergrund steht, hängt von der konkreten Lösung ab. Kosteneinsparungen werden hier durch Serverkonsolidierung und die damit verbundenen Personal- und Energieeinsparungen erzielt. 66 Dieser Effekt wird durch das wesentlich günstigere Administrator-Server-Verhältnis in Cloud-Umgebungen noch verstärkt. 67 Die höhere Flexibilität wird unter anderem durch starke Automatisierung und die damit verbundenen geringeren Antwortzeiten auf neue Anforderungen erzielt, wodurch ebenfalls die Unterstützung des Kerngeschäfts durch die IT verbessert wird. Insbesondere für die Einführung einer private Cloud-Lösung existieren jedoch Voraussetzungen, die ein Unternehmen erfüllen muss, um alle Ziele des Cloud Computings zu erreichen. Welche dies sind, soll im folgenden Abschnitt erläutert werden. 3. Voraussetzungen für die Einführung von Cloud Computing Da Cloud Computing eine umfassende Änderung in der Art und Weise bedeutet, wie ein Unternehmen seine IT betreibt, stellt die erfolgreiche Einführung einer solchen Lösung weitreichende Anforderungen an eine Organisation. Da die IT heute in nahezu jedem Unternehmen eine Kernaufgabe übernimmt, ohne die das Tagesgeschäft nicht möglich wäre, beziehen sich diese Anforderungen zwar primär auf die IT-Organisation, erfordern aber auch Veränderungen im übrigen Unternehmen. Denn wie bei jedem Paradigmenwechsel erfordert Cloud Computing nicht nur den Einsatz neuer Technologien, sondern auch ein Umdenken innerhalb der Organisation und einen stärkeren Servicebezug. Da die Anforderungen natürlich auch von der Art der Cloud-Lösung abhängen, soll in den folgenden Abschnitten von der Einführung einer umfassenden private Cloud-Lösung ausgegangen werden. 3.1 Servicebezogene Anforderungen Eine Veränderung innerhalb eines Unternehmens in der Größenordnung wie Cloud Computing sie darstellt, erfordert immer auch die Unterstützung des Managements und eine Anpassung der Unternehmensstrategie. Der Cloud Computing eigene Servicegedanke muss im Un- 66 Vgl. [31] IBM Corporation (2008b), S Vgl. Listing 1: Interview mit Michael Behrendt, Frage 4.

21 ternehmen abgebildet und sichtbar gemacht werden. Um dies zu realisieren, müssen verschiedene Managementinstrumente geschaffen, beziehungsweise angepasst werden. Dies betrifft den gesamten IT-Service-Lebenszyklus, wobei die einzelnen Phasen unterschiedlich stark beeinflusst werden. Da sich ITIL in der Industrie als Quasistandard etabliert hat, wird im Folgenden Bezug zu den Begriffen des ITIL V3 Frameworks hergestellt. Abbildung 2: IT-Service-Lebenszyklus nach ITIL V3 (Quelle: [77] Pevzner, Boris (2007)) Service-Strategie Die Service-Strategie bildet den Rahmen für alle Aktivitäten zum Entwurf, zur Umsetzung und zum Betrieb von IT-Services. 68 Sie steuert die Ausgestaltung aller Phasen des IT-Service- Lebenszyklus und kommt einer Handlungsanleitung für die Unternehmensführung gleich. 69 Die Service-Strategie hat Einfluss auf den Service-Katalog, das Service-Katalog- Management, das Service-Level-Management und die Sourcing-Strategie. Diese sind wesentliche Inputgeber während des Designs und des Betriebs der Cloud Computing-Lösung. Darüber hinaus ist es Teil der Service-Strategie, den Rahmen für wesentliche Kennzahlen vorzugeben und zu steuern, wo und wie diese Kennzahlen bestimmt werden. Daher ist eine angepasste Service-Strategie ebenfalls als Voraussetzung für die erfolgreiche Einführung einer Cloud Computing-Lösung zu sehen. 68 Vgl. [34] Iqbal, Majid; Nieves, Michael (2007), S. 8f. 69 Vgl. [24] Ebel, Nadin (2009), S. 91.

22 Abbildung 3: Zusammenhang von Service-Strategie, Service-Katalog und den IT- Service-Lebenszyklus-Phasen (Quelle: [41] Lloyd, Vernon; Rudd, Colin (2007), S. 59.) Service-Katalog-Management / Service-Katalog Ein weiteres Kernelement der servicebezogenen Anforderungen ist das Vorhandensein eines Service-Katalogs und die Etablierung der erforderlichen Service-Katalog-Management- Prozesse. Das Service-Katalog-Management dient dazu, eine Quelle konsistenter Informationen über die angebotenen Services (den Service-Katalog) zur Verfügung zu stellen und die Prozesse zu etablieren, den Katalog zu verwalten. 70 Ohne diese Informationen ist das Design einer Cloud Computing-Lösung, welche die Zielstellungen des Cloud Computing-Modells erfüllen soll, nicht möglich. Daher ist ein differenzierter Service-Katalog eine notwendige Voraussetzung für die Einführung einer Cloud Computing-Lösung. Darüber hinaus müssen die Prozesse des Service-Katalog-Managements angepasst werden. Insbesondere innerhalb der Aktivität der Servicedefinition muss die Zusammenarbeit zwi- 70 Vgl. [41] Lloyd, Vernon; Rudd, Colin (2007), S. 60.

23 schen Fachabteilung (Servicerequester) und IT-Abteilung (Serviceprovider) intensiviert und im Ablauf wesentlich beschleunigt werden. Dies ist von Bedeutung, um die Erfüllung der Flexibilitätsanforderung an die Cloud Computing-Lösung nicht durch Verzögerungen innerhalb dieser Aktivität zu gefährden Service-Level-Management Das Service-Level-Management (SLM) dient dem Austausch und der Vereinbarung von IT- Service-Zielen zwischen dem Servicerequester und dem Serviceprovider. 71 Die vereinbarten SLAs sind ein wesentlicher Einflussfaktor für die Umsetzung eines Services. Die Bedeutung eines Service-Katalogs wird hier noch einmal hervorgehoben, da dieser den Scope des Service-Level-Managements festlegt. 72 Im Rahmen einer Cloud Computing-Lösung kommt dem SLM eine besondere Bedeutung zu, da es die Grundlage für die Beziehung zwischen Servicekonsument und Serviceprovider darstellt. Das in vielen Unternehmen bereits vorhandene SLM ist meist auf die Durchsetzung von SLAs nach außen fokussiert, während SLAs innerhalb des Unternehmens nur selten etabliert sind oder effizient genutzt werden. 73 Dies ist aber insbesondere bei private und hybrid Cloud- Lösungen von großer Bedeutung und ist deshalb als wesentliche servicebezogene Anforderung anzusehen Sourcing-Strategie Neben der Anpassung der vorgenannten Phasen und Aktivitäten innerhalb des IT-Service- Lebenszyklus ist auch eine Sourcing-Strategie beim Entwurf einer Cloud Computing-Lösung zu berücksichtigen. Sie ist Teil der Service-Strategie und insbesondere im Kontext einer hybrid Cloud-Lösung von Bedeutung. Die Sourcing-Strategie muss hierbei insbesondere die Möglichkeiten berücksichtigen, die intern vorhandenen Ressourcen kurzfristig um externe (public Cloud) Ressourcen zu erweitern. Da dies aber vor allem mit Sicherheits-, Vertraulichkeits- und Datenschutzaspekten kollidieren kann, ist hier eine klare Richtlinie in Form einer Sourcing-Strategie notwendig. Darüber hinaus muss in der Sourcing-Strategie festgelegt werden, welche Services innerhalb der Cloud-Lösung erbracht werden sollen und welche weiterhin von Legacy-Systemen oder Ex- 71 Vgl. [41] Lloyd, Vernon; Rudd, Colin (2007), S Vgl. ebenda, S Vgl. [60] Fahlbusch, Klaus-Dieter (2008).

24 ternen bezogen werden. Sie ist damit wesentlich für die Definition des Scopes der zu implementieren Cloud-Lösung. 3.2 Organisatorische Anforderungen Veränderungen der Strategie eines Unternehmens führen immer auch zu Veränderungen in der Abteilungs- und Prozessstruktur. Die vorgenannten servicebezogenen Anforderungen müssen daher in der Organisation des Unternehmens reflektiert werden. Dies bezieht sich sowohl auf die Aufbau- als auch auf die Ablauforganisation Aufbauorganisatorische Veränderungen Die erforderlichen aufbauorganisatorischen Veränderungen betreffen primär die IT- Organisation innerhalb des Unternehmens, während die Fachabteilungen weitgehend unverändert bestehen bleiben können. Durch Cloud Computing wird eine zusätzliche Abstraktionsebene in die IT-Architektur des Unternehmens eingezogen, die innerhalb der IT-Organisation reflektiert sein muss. Hierfür müssen wesentlich grobgranularere Rollen definiert werden, als es typischerweise bisher der Fall ist. In heutigen Rechenzentren existieren meist feingranulare Rollen mit einem sehr eingeschränkten Aufgabenbereich, wie beispielsweise Datenbankadministration oder Server Storage. 74 Ein Großteil der von diesen Rollen ausgeführten Arbeitsschritte ist zwar toolunterstützt, aber hochgradig manuell. Ein wesentliches Kernelement einer private Cloud- Lösung ist jedoch starke Automatisierung und die Verringerung manueller Arbeitsschritte zur Erhöhung der Flexibilität. 75 Daher müssen insbesondere im Rechenzentrum grobgranularere Rollen definiert werden, die auf einem höheren Abstraktionslevel agieren. 76 Hierbei sollten Rollen geschaffen werden, die sich an den Ebenen einer Cloud Computing-Architektur (SaaS, PaaS, IaaS) orientieren. Hier wäre beispielsweise eine Ablösung von klassischen Rollen wie Serveradministrator durch grobgranularere Rollen wie IaaS-Administrator möglich. Diese könnten eine Ebene der Cloud-Architektur vollständig abdecken, wodurch Brüche in den Prozessabläufen vermieden werden können und eine schnellere Reaktion auf Kundenanfragen möglich wird. Durch die Spezialisierung auf diese Schichten ist demnach die Umsetzung der Flexibilitätsanforderung möglich. 74 Vgl. [25] Feil, Thomas; Tiemeyer, Ernst (2007), S. 357ff. 75 Siehe 2.6 Zielstellung von Cloud Computing. 76 Vgl. Listing 1: Interview mit Michael Behrendt, Frage 5.

25 Ebenfalls mit Hinblick auf die Flexibilität sollte die Schnittstelle zwischen Servicekonsument und Serviceprovider aufbauorganisatorisch neu abgebildet werden. Hier ist die Einführung eines Service Desk im Sinne eines Single Point of Contact notwendig. Betrachtet man die Arbeit mit dem Service-Konsumenten als Wertschöpfung, so steht der Service Desk am Anfang dieser Wertschöpfungskette. 77 Er ist damit eine notwendige Voraussetzung, um den Servicegedanken, der Cloud Computing zugrunde liegt, umzusetzen Ablauforganisatorische Veränderungen Diese aufbauorganisatorischen Veränderungen sind dabei stets mit der Etablierung neuer oder der Anpassung alter Prozesse verbunden. Die servicebezogenen Anforderungen wirken ebenfalls maßgeblich auf die neuen Prozesse ein. Auch hier sind die Veränderungen primär auf die IT-Organisation innerhalb des Unternehmens bezogen, gehen aber auch darüber hinaus. So werden auch in den Fachabteilungen neue, beziehungsweise veränderte Prozesse an der Schnittstelle zur IT benötigt. Insbesondere die Veränderungen im Rahmen der Service-Strategie haben großen Einfluss auf die Abläufe innerhalb der IT. So müssen sämtliche Prozesse im IT-Service-Lebenszyklus auf Cloud Computing-Services zugeschnitten werden. Die Anpassungen fokussieren hierbei darauf, die implementierte Cloud-Lösung konsistent und flexibel zu halten. Eine besondere Rolle kommt dabei dem Servicerequestprozess zu, der sowohl die IT als auch die Fachabteilungen mit einbezieht. Die Konsistenz der Cloud-Lösung wird mit diesem Prozess sichergestellt, da neue Services über eine wohl definierte Schnittstelle angefragt werden. Weitere wesentliche Prozessanpassungen betreffen die Bereitstellungsprozesse innerhalb der IT. Hier sind insbesondere das Provisioning und das Monitoring mit ihren jeweiligen Regelprozessen zu nennen. In klassischen IT-Umgebungen sind die Zeiträume, die für die Bereitstellung neuer Ressourcen und Services benötigt werden, in Dimensionen von Tagen bis hin zu Wochen angegeben. 78 Auch das Monitoring ist vorwiegend langfristig orientiert und nicht auf die unmittelbare Intervention im Bedarfsfall ausgelegt. Damit bieten beide Prozesse in ihrer klassischen Ausprägung nicht die erforderlichen Durchlauf- und Reaktionszeiten, die eine Cloud Computing-Lösung erfordert. Diese sollten sich in Dimensionen von Minuten bis Stunden befinden und damit nahe an der Echtzeitumsetzung. 77 Vgl. [25] Feil, Thomas; Tiemeyer, Ernst (2007), S Vgl. Listing 1: Interview mit Michael Behrendt, Frage 8.

26 Generell müssen alle ablauforganisatorischen Veränderungen auf die Durchsetzung von kurzen Prozessdurchlaufzeiten ausgerichtet sein, um die Flexibilität der Cloud Computing- Lösung optimal zu unterstützen. Die konkrete Ausgestaltung der einzelnen Prozesse kann dabei unterschiedlich sein, sollte sich jedoch an Best Practice-Ansätzen wie ITIL orientieren und im Einklang mit der Prozessstruktur des Gesamtunternehmens stehen. 3.3 Technische Anforderungen Eine weitere wesentliche Voraussetzung für die Einführung einer Cloud Computing-Lösung ist der Einsatz verschiedener Technologien. Diese beziehen sich ausschließlich auf die IT- Organisation und dienen zur Umsetzung der Automatisierung und zur Prozessbeschleunigung. Dabei werden einzelne dieser Technologien in den meisten Rechenzentren bereits genutzt. Die im Folgenden beschriebenen technischen Anforderungen beziehen sich deshalb nicht nur auf die Einführung dieser Technologien, sondern auch auf die Anpassung der bereits erfolgten Nutzung. Die benannten Technologien sind dabei nicht isoliert voneinander zu betrachten, sondern sollten als untereinander verbundenes System wahrgenommen und verstanden werden. 79 Dieses System aus Architekturbausteinen ist dabei mit den genannten Technologien noch nicht zwingend vollständig. Abhängig vom Konzept und Design der einzuführenden Cloud Computing- Lösung können weitere Bausteine hinzukommen. Hier sind insbesondere Tools zur weiteren Unterstützung der servicebezogenen Anforderungen und der notwendigen Prozessanpassungen denkbar. Abbildung 4 auf der folgenden Seite zeigt ein exemplarisches Architekturbausteinsystem für Cloud Computing. Dabei bildet es sowohl den Prozess des automatischen Skalierens, induziert vom Monitoring, als auch den Prozess der initialen Bereitstellung von Services durch ein Self Service-Portal ab. 79 Siehe Abbildung 4 auf der folgenden Seite.

27 Abbildung 4: Beispielhafte Architekturbausteine einer private Cloud-Lösung Virtualisierung Virtualisierung ist eine Kerntechnologie zur Einführung einer private Cloud. Ohne Virtualisierung sind die Flexibilität und Reaktionsgeschwindigkeit, die von einer solchen Lösung erwartet werden, nicht zu erreichen. 80 Dabei ist Virtualisierung selbst weniger ein Baustein als vielmehr eine Technologie, die Cloud-Lösungen erst ermöglicht. Virtualisierung ist heute bereits in vielen Unternehmen ein Standardverfahren mit der Zielstellung, die IT-Kosten zu reduzieren. 81 Hierbei unterscheiden sich die Virtualisierungsansätze vor allem durch die Nutzungsmodelle. Diese sind heute vorwiegend Serverkonsolidierung, flexible Provisionierung, Test- und Entwicklungsunterstützung, dynamisches Load Balancing 80 Siehe hierzu 2.3 Abgrenzung von Virtualisierung und Cloud Computing. 81 Vgl. [71] Koller, Peter (2008).

28 und Disaster Recovery. 82 Cloud Computing unterstützt ebenfalls all diese Modelle, legt aber einen Fokus auf das flexible Provisionieren und dynamisches Load Balancing, da beide wesentliche Eckpfeiler sind, um elastisches Skalieren zu ermöglichen. Um eine Cloud Computing-Lösung darüber hinaus möglichst kosteneffizient zu gestalten, sollten im Vorfeld der Einführung die Möglichkeiten der Serverkonsolidierung ausgeschöpft werden. Da die Virtualisierung ein wesentlicher Baustein einer Cloud Computing-Lösung ist, sollte bei der Konsolidierung von Servern auf optimale Virtualisierungsleistung Wert gelegt werden, um eine maximale Performance zu erreichen. Neben der reinen Servervirtualisierung ist im Rahmen einer Cloud Computing-Lösung auch Desktop- oder Client-Virtualisierung denkbar. Diese ist allerdings keine Voraussetzung für Cloud Computing, sondern vielmehr ein mögliches Angebot der PaaS- oder SaaS-Schicht Hypervisoren Zur Überwachung und Steuerung der virtualisierten Server werden Virtual Machine Manager (VMM) oder auch Hypervisoren eingesetzt. Man unterscheidet hierbei zwischen Typ-1- und Typ-2-Hypervisoren. 83 Typ-1-Hypervisoren enthalten selbst einen kleinen Kernel, der direkt auf der physischen Hardware aufsetzt. Dieser Kern verbraucht nur minimale Ressourcen und ist ausschließlich auf Funktionen fokussiert, die direkt für die Virtualisierung benötigt werden. 84 VMM dieses Typs bieten volle Hardware-Virtualisierung und stellen jeder VM die entsprechenden Ressourcen zur Verfügung. Je nach Hersteller werden dabei einheitliche Hardwarekomponenten emuliert (zum Beispiel bei ESX von VMware) 85 oder der VM wird Zugriff auf die tatsächliche Hardware gewährt (zum Beispiel bei XEN von Citrix) 86. Da sie direkt auf der Hardware aufsetzen, müssen VMM des Typs 1 Treiber für die jeweiligen Komponenten selbst mitliefern. Typ-2-Hypervisoren benötigen für ihre Funktionen selbst ein bereits installiertes Host- Betriebssystem. 87 Hierdurch werden Hardwarezugriffe über die Treiber des Host OS möglich, 82 Vgl. [16] Casazza, Jeffrey et al. (2006), S Vgl. [85] Sommergut, Wolfgang (2009). 84 Vgl. [10] Brett, Paul et al. (2006), S Vgl. [85] Sommergut, Wolfgang (2009). 86 Vgl. ebenda. 87 Vgl. [10] Brett, Paul et al. (2006), S. 237.

29 wodurch der Hypervisor von der Bereitstellung dieser entlastet wird. 88 Allerdings wirkt sich der Ressourcenverbrauch des Host OS negativ auf die Gesamtperformance aus. Aufgrund der Performancevorteile von Typ-1-Hypervisoren und der geringeren Hardwarevielfalt im Serverumfeld sind VMM des Typs 1 in Rechenzentren wesentlich häufiger anzutreffen als solche des Typs Typ-1-Hypervisoren eignen sich auch für die Nutzung in einem Cloud Computing-Umfeld wesentlich besser, da hohe Leistung eine der Kernanforderung an eine solche Lösung ist. Darüber hinaus sollte bei der Auswahl des konkreten VMM eine optimale Unterstützung für die nachfolgenden Technologien und Tools gewährleistet werden Automatische Provisionierung Die Toolunterstützung zur Bereitstellung von neuen virtuellen Maschinen ist auch in heutigen virtualisierten Rechenzentren bereits üblich. Das vollautomatische Provisioning ist dagegen noch relativ neu und wird nur in den wenigsten Unternehmen verwendet. 90 Ziel dabei ist, die Art und Anzahl der VMs dynamisch dem jeweiligen Bedarf anzupassen. Hierdurch kann auch auf unvorhergesehene Lastschwankungen schnell reagiert werden. Im Rahmen dieser Arbeit wird das automatische Provisionieren als die Bereitstellung und die Deinstallation von Services weitestgehend ohne manuelle Arbeitsschritte verstanden. Im Kontext einer Cloud Computing-Lösung ist sie damit ein wesentlicher Erfolgsfaktor, da sie den IT-Kernprozess der Beantwortung von Servicerequests automatisiert. Die Bereitstellung kann dabei sowohl vom Monitoring, beispielsweise bei Überschreiten einer definierten Maximalauslastung einzelner VMs, als durch Userrequest getriggert werden. 91 Darüber hinaus ist eine zeitgesteuerte Bereitstellung von VMs beispielsweise für Batch Services denkbar. Der Deinstallation aktuell nicht mehr benötigter VMs kommt dabei eine ebenso große Rolle zu, da hierdurch Ressourcen für andere Zwecke frei werden. Insbesondere bei stark schwankender Auslastung muss die Balance zwischen dem Vorhalten aktuell nicht benötigter VMs (und damit dem Blockieren von Ressourcen) und dem Ressourcenverbrauch bei der Bereitstellung einer VM abgewogen werden. Die optimale Vorhaltezeit ist dabei maßgeblich von der Beweglichkeit des Umfelds abhängig und sollte individuell festgelegt werden. 88 Vgl. [10] Brett, Paul et al. (2006), S Vgl. [85] Sommergut, Wolfgang (2009). 90 Vgl. [61] Fontecchio, Mark (2009). 91 Siehe Abbildung 4.

30 Metering Ein wesentliches Merkmal einer Cloud-Lösung ist das pay-per-use-zahlungsmodell. 92 Um die tatsächlichen Kosten für jeden Kunden ermitteln zu können, ist ein effizientes und genaues Metering erforderlich. Metering wird in diesem Zusammenhang nicht nur als bloßes Messen des Ressourcenverbrauchs verstanden, sondern vielmehr auch als Zuordnung von Ressourcenkonsum zu Nutzern bzw. Kunden des Cloud-Systems und die Weitergabe dieser Informationen an das Billing und SLA-System. Damit befindet sich das Metering an der Schnittstelle vom OSS zum BSS. Das im Rahmen einer Cloud Computing-Lösung zu implementierende Metering-System muss in der Lage sein, die verschiedensten Verbrauchsmetriken zu erfassen. Diese können sehr Hardware bezogen sein (wie etwa CPU-Zeit, Speicherbelegung, Verursachter Traffic, etc.) oder einen stärkeren Softwarebezug haben (wie beispielsweise durchgeführte Transaktionen, genutzte Operationen, etc.). Darüber hinaus muss ein solches System Zuordnungen zu verschiedenen SLAs vornehmen können. Dies ist von Bedeutung, da beispielsweise der gleiche Service mit verschiedenen Verfügbarkeitsraten zu unterschiedlichen Preisen angeboten werden kann. Weiterhin muss vereinbart werden, ob die beim Provisionieren verbrauchten Ressourcen ebenfalls direkt vom Servicekonsumenten zu tragen sind. Das Metering hat daher Schnittstellen zum Hypervisor und zum automatischen Provisioning. 93 Eine weitere wesentliche Anforderung an das Metering-System ist seine Leichtgewichtigkeit. Diese ist von Bedeutung, da das Metering ständig im Hintergrund läuft und damit Ressourcen verbraucht, die nur indirekt auf die Kunden umgelegt werden können. Darüber hinaus kann ein zu schwergewichtiges Metering negativen Einfluss auf die Gesamtperformance der Cloud- Lösung haben Monitoring Dem Monitoring kommen innerhalb einer Cloud-Lösung zwei wichtige Aufgaben zu. Zum einen ist es für die Überwachung der Auslastung erforderlich und unterstützt damit die elastische Skalierbarkeit der Cloud-Lösung. Zum anderen ist es für die Überwachung der Gesundheit der Cloud notwendig, um sicherzustellen, dass SLAs eingehalten werden und die Lösung 92 Siehe 2.4 Synthese einer Cloud Computing-Definition. 93 Siehe Abbildung 4.

31 möglichst hohe Verfügbarkeitsraten aufweist. 94 Diese sind insbesondere für unternehmenskritische Anwendungen absolut erforderlich. Die Anforderungen an das Monitoring-System sind dabei denen des Meterings sehr ähnlich. Es muss genauso leichtgewichtig sein, um die Gesamtperformance nicht zu beeinträchtigen. Darüber hinaus muss es eine Vielzahl von Kennzahlen erfassen können, dabei aber anpassbar sein. Empfehlenswert erscheinen hier Tools mit einem schlanken Kern und der Möglichkeit, einzelne Kennzahlen über Plug-Ins zu implementieren. Hierdurch kann das Monitoring den Gegebenheiten und Erfordernissen der konkreten Cloud-Lösung optimal angepasst werden, ohne unnötig Ressourcen für nicht benötigte Kennzahlen zu verbrauchen Image Repository Image Repositories sind ein wesentliches Element des Image Lifecycle-Managements. Diesem kommt im Rahmen der angepassten Service-Strategie eine besondere Bedeutung zu. Im Kontext einer Cloud Computing-Lösung sollte ein Image Repository angelegt werden, das die Images zur Bereitstellung der im Service-Katalog spezifizierten Services enthält. Diese Images beinhalten jeweils den vorkonfigurierten, kompletten Anwendungsstack, der zur Bereitstellung eines Service notwendig ist. Das Provisioning-System bezieht die angeforderten Images aus dem Repository und führt die Bereitstellung aus. 95 Das Image Repository ist damit ein eine wesentliche Voraussetzung, um flexibles Skalieren in Echtzeit zu ermöglichen. Die konkrete Ausprägung des Repositories (relationale Datenbank, FTP, File-Server, etc.) ist dabei zweitrangig. Sie sollte sich aber an der Anforderung möglichst hoher Performance orientieren Self Service-Portale Ein Self Service-Portal ist keine zwingende Voraussetzung für den Betrieb einer effizienten private Cloud-Lösung. Es stellt allerdings im Umgang mit eher technisch orientierten Kunden (beispielsweise der Entwicklungsabteilung) eine wesentliche Serviceverbesserung dar. Ein typisches Self Service-Portal macht den Service-Katalog oder Teile davon zugänglich und erlaubt das manuelle Provisionieren von VMs. Insbesondere im Testumfeld können hierdurch die Abläufe beschleunigt werden, da die benötigten Testumgebungen flexibel bereitgestellt werden können. Ein solches Portal kann ebenfalls dazu genutzt werden, Basisadministrations- 94 Vgl. [32] IBM Corporation (2009a), S Siehe Abbildung 4.

32 aufgaben wie Starten, Stoppen und Neustarten von VMs zu ermöglichen. 96 Darüber hinaus kann eine Anpassung der VM zur Laufzeit ermöglicht werden, dies umfasst Anpassungen des verfügbaren Arbeitsspeichers bis hin zum Tausch der emulierten Hardwarekomponenten (abhängig vom Hypervisor) Vorhandene Cloud Computing-Lösungen Die Vielzahl an Definitionen und die Vielschichtigkeit von Cloud Computing spiegeln sich in einer ebenso großen Fülle an vorhandenen Angeboten wider. Dabei haben sich die meisten Anbieter auf eine Ebene einer Cloud Computing-Architektur konzentriert. Ein Überblick oder Vergleich der Angebote stellt sich allerdings als schwierig dar, da es bisher neben dem Marketingmaterial der Anbieter und zahlreichen Blog-Einträgen nur wenige objektive Erfahrungsberichte gibt. Dies trifft insbesondere auf den private Cloud-Bereich zu. Die einzelnen Anbieter decken die verschiedenen Schichten und Bausteine einer Cloud-Architektur mit den unterschiedlichsten Produkten und Lösungen ab. Ein Vergleich von Features oder Produkteigenschaften ist dabei sehr schwierig und für eine objektive Bewertung der Lösung nicht zielführend. Abbildung 12 im Anhang zeigt jedoch exemplarisch, wie die Bausteine von den Produkten eines Herstellers abgedeckt werden. Abbildung 13, ebenfalls im Anhang, zeigt verschiedene Anbieter im public Cloud-Umfeld und wie sie sich mit ihren Produkten im Markt platzieren. Im Folgenden sollen ausschließlich public Cloud-Angebote für den Vergleich herangezogen werden. 4.1 Vergleichsmethodologie Um eine Vergleichbarkeit der Lösungen sicherzustellen, werden im Bereich der public Cloud- Lösungen ausschließlich Infrastructure-as-a-Service-Angebote betrachtet. Auf einen Vergleich von PaaS- und SaaS-Anbietern wird verzichtet, da bei PaaS bisher nur wenige, sehr unterschiedliche und damit schwer vergleichbare Anbieter existieren. Beim Vergleich von SaaS-Anbietern ist nur ein Vergleich für eine konkrete Software sinnvoll. Daher wäre ein umfassender Anbietervergleich sehr fein granular und damit zu umfangreich. Für den Vergleich der public IaaS-Anbieter werden drei Provider herangezogen, diese werden separat sowohl in ihrem Server- als auch in ihrem Speicherangebot verglichen. Zur Herstel- 96 Vgl. [32] IBM Corporation (2009a), S Vgl. ebenda, S. 13.

33 lung der Vergleichbarkeit der Preise werden für jeden Bereich drei User mit spezifischen Anforderungen definiert und der Preis für diese ermittelt (eine Aufstellung der Anforderungen siehe Tabelle 17 und Tabelle 18 im Anhang), dabei wird ein kostenloses Betriebssystem und die USA als Standort angenommen. Bei der Ermittlung von Grundpreisen werden die jeweiligen Webseiten der Anbieter herangezogen. Zeitlich begrenzte Sonderangebote oder Volumen- beziehungsweise Pre-Paid-Angebote werden dabei außer Acht gelassen. Im Serverbereich werden für jeden Anbieter folgende Eigenschaften betrachtet: Anzahl verfügbarer Serverkofigurationen* Anzahl verfügbarer Betriebssysteme* Minimaler RAM Maximaler RAM Minimaler Diskspace Maximaler Diskspace Preis für Traffic in* Preis für Traffic out* Berechnungsgrundgröße Preis pro Berechnungsgrundgröße Preis für User 1* Preis für User 2* Preis für User 3* Verfügbarkeit Art der verfügbaren VMs APIs User Interface Zum Vergleich des Speicherangebots werden folgende Eigenschaften betrachtet: Preis pro GB Berechnungsgrundgröße Preis für Traffic in Preis für Traffic out Preis für PUT, POST, LIST, COPY Anfragen Preis für HEAD, GET Anfragen Preis für User 1* Preis für User 2* Preis für User 3* Verfügbarkeit Die mit einem Stern gekennzeichneten Eigenschaften werden auf einer Skala von null bis zehn normiert, sodass der schlechteste Wert null Punkte und der beste Wert zehn Punkte erhält. Für die Verfügbarkeit wird 99,9% mit einer Bewertung von null Punkten definiert, während 100% zehn Punkten entsprechen. Alle bewerteten Eigenschaften werden gleich stark mit dem Faktor eins gewichtet. 4.2 Vergleich von public IaaS-Angeboten im Serverbereich Für den Vergleich von public IaaS-Angeboten im Serverbereich wurden Rackspace, AWS und GoGrid als Anbieter ausgewählt. GoGrid ist die Cloud Computing-Tochter des großen Hostingunternehmens ServePath, während Rackspace Cloud Computing-Tochter früher als

34 Mosso firmierte AWS als der Pionier im public Cloud Computing ist eine Tochter von Amazon. 100 Die Anbieter unterscheiden sich in vor allem in der Anzahl der verfügbaren Serverkonfigurationen und Betriebssysteme und der Art und Weise. wie diese zur Verfügung gestellt werden. Während Rackspace ausschließlich VM Images anbietet, die nur ein Betriebssystem enthalten, bieten GoGrid und AWS eine Vielzahl an Betriebssystemen mit Web Stack. Insbesondere GoGrid hat hier einen starken Fokus auf Microsoft-Produkte und bietet neben kostenfreien Umgebungen vor allem dessen proprietäre Serverbetriebssysteme, Datenbanken und die ASP.NET Umgebung an. AWS hat einen stärkeren Fokus auf kostenfreie Umgebungen wie den LAMP Web Stack und bietet darüber hinaus ein mehrere hundert Images umfassende VM-Bibliothek mit den unterschiedlichsten vorkonfigurierten Applikationsstacks. Ein weiterer Unterschied zwischen den Providern besteht bei der Berechnungsgrundlage für die Serverkosten. AWS definiert fünf verschiedene Serverinstanztypen mit Kosten zwischen 0,10 $ und 0,80 $ pro Laufzeitstunde. Rackspace und GoGrid definieren auch jeweils Serverinstanztypen, deren Kosten pro Laufzeitstunde richten sich jedoch ausschließlich nach dem zugewiesenen Arbeitsspeicher. Die Verfügbarkeit garantieren Rackspace und GoGrid mit jeweils 100%, während AWS 99,95% zusichert. Im Falle der Nichterfüllung bieten alle Anbieter Rabatte auf die Rechnung des betroffenen Monats. Abbildung 5 zeigt das Ergebnis des Vergleichs, Tabelle 2 enthält die zugehörigen Detailinformationen. Rackspace erreichte eine Gesamtpunktzahl von 62,3 Punkten und liegt damit knapp zehn Punkte vor AWS mit 52,9 Punkten, mit relativ großem Abstand auf dem dritten Platz liegt GoGrid mit 10,0 Punkten. Insgesamt waren maximal 80 Punkte zu erreichen. 98 Vgl. [62] GoGrid (2009a). 99 Vgl. [78] Rackspace (2009a). 100 Vgl. [52] Amazon Web Services (2009a).

35 Preis Usertyp 3 Verfügbarkeit Anzahl Verfügbarer Serverkofigurationen 10,0 9,0 8,0 7,0 6,0 5,0 4,0 3,0 2,0 1,0 0,0 Anzahl Verfügbarer Betriebssysteme Preis für Traffic in ($/GB) Preis Usertyp 2 Preis für Traffic out ($/GB) Preis Usertyp 1 Rackspace AWS GoGrid Abbildung 5: Anbietervergleich im public IaaS-Serverbereich Rackspace bietet vor allem im mittleren Leistungsbereich (Usertyp 2) die günstigste Lösung. AWS wiederum verlangt für eingehenden Traffic nur geringfügig mehr, ist allerdings im outbound Traffic der günstigste Anbieter. Darüber hinaus skalieren die von AWS angebotenen Instanztypen besonders im CPU-Bereich höher als diejenigen von Rackspace und GoGrid und eignen sich daher besser für rechenintensive Aufgaben. AWS bietet mit der AMI-Bibliothek außerdem das größte Angebot vorkonfigurierter VMs. GoGrid wiederum eignet sich aufgrund des kostenlosen inbound Traffic für Aufgaben, die sehr viel Inputdaten benötigen, daraus aber nur wenig Output generieren. Gleichzeitig erhebt GoGrid aber auch den höchsten Preis für outbound Traffic. Aufgrund dieser sehr differenzierten Preisgestaltung sollte eine konkrete Entscheidung für einen public Cloud Provider immer unter Berücksichtigung der Eckdaten einer gegebenen Situation getroffen werden. Darüber hinaus sollten die betrachteten Eigenschaften nach den jeweiligen Anforderungen gewichtet werden. Es ist außerdem zu prüfen, ob weitere Faktoren, wie beispielsweise die Supportqualität, zu berücksichtigen sind. Daher ist der getroffene Vergleich lediglich als Anregung zu verstehen.

36 Tabelle 2: Eigenschaften verschiedener public IaaS-Anbieter im Serverbereich Rackspace 101 AWS 102 GoGrid 103 Wert Punkte Wert Punkte Wert Punkte Anzahl Verfügbarer Serverkofigurationen 7 10,0 5 0,0 5 0,0 Anzahl Verfügbarer Betriebssysteme 8 8,0 9 10,0 4 0,0 Minimaler RAM (GB) 0,25 GB - 1,7 GB - 0,5 GB - Maximaler RAM (GB) 15,5 GB - 15 GB - 8 GB - Minimaler Diskspace (GB) 10 GB GB - 30 GB - Maximaler Diskspace (GB) 620 GB GB GB - Preis für Traffic in ($/GB) 0,08 $/GB 2,0 0,10 $/GB 0,0 0,00 $/GB 0,0 Preis für Traffic out ($/GB) 0,22 $/GB 8,5 0,17 $/GB 10,0 0,50 $/GB 0,0 Berechnungsgrundgröße GB Instanz RAM / h h / Instanzlaufzeit GB Instanz RAM / h Preis pro Berechnungsgrundgröße 0,10 $ ($) 0,06 $ - - 0,80 $ - 0,19 $ - Preis Usertyp 1 2,70 $ 9,1 2,35 $ 10,0 6,30 $ 0,0 Preis Usertyp 2 9,30 $ 10,0 12,05 $ 7,9 22,70 $ 0,0 Preis Usertyp 3 94,80 $ 4,7 48,20 $ 10,0 135,60 $ 0,0 Verfügbarkeit 100,00% 10,0 99,95% 5,0 100,00% 10,0 Art der verfügbare VMs nur OS Verschiedenste Images im Pool (nur OS, LAMP und weitere) nur OS, LAMP, proprietärer Web Stack (Microsoft) APIs angekündigte Web Service API mit Beispielen für PHP, Python, Java, und.net Web basiertes Admin Interface Web Service API, Management Tools REST-API, Beispiele für Java, PHP, Python, Perl, C# und Ruby vorhanden Web basiertes Admin Interface User Interface Kommandozeilenzugriff Gesamtpunktzahl (von 80) 62,3 52,9 10,0 4.3 Vergleich von public IaaS-Angeboten im Speicherbereich Für den Vergleich von public IaaS-Angeboten im Storagebereich wurden ebenfalls Rackspace, AWS und GoGrid als Anbieter herangezogen. In diesem Bereich unterscheiden sich die Anbieter maßgeblich darin, welche Leistungen dem Servicekonsumenten in Rechnung gestellt werden. Alle drei Anbieter stellen ihren Kunden den genutzten Speicher sowie das Volumen des ein- und ausgehenden Traffic in Rechnung. Rackspace erhebt darüber hinaus noch Kosten für PUT, POST und LIST Kommandos auf Dateien, die kleiner als 250 kb sind, während AWS Kosten für sämtliche PUT-, COPY-, POST-, LIST- und GET-Kommandos in Rechnung stellt. 101 Alle Daten stammen aus [79] Rackspace (2009b), [80] Rackspace (2009c) und [81] Rackspace (2009d). 102 Alle Daten stammen aus [53] Amazon Web Services (2009b) und [54] Amazon Web Services (2009c). 103 Alle Daten stammen aus [63] GoGrid (2009b), [64] GoGrid (2009c), [65] GoGrid (2009d) und [66] GoGrid (2009e).

37 Verfügbarkeit Preis für Traffic in ($/GB) 10,0 9,0 8,0 7,0 6,0 5,0 4,0 3,0 2,0 1,0 0,0 Preis für Traffic out ($/GB) Preis Usertyp 3 Preis Usertyp 1 Preis Usertyp 2 Rackspace AWS GoGrid Abbildung 6: Anbietervergleich im public IaaS-Storagebereich Abbildung 6 zeigt das Ergebnis des Vergleichs, Tabelle 3 enthält die zugehörigen Detailinformationen. AWS erreichte eine Gesamtpunktzahl von 41,3 Punkten und liegt damit gut zehn Punkte vor GoGrid mit 30,0 Punkten, dicht dahinter liegt Rackspace mit 26,5 Punkten. Insgesamt waren maximal 60 Punkte zu erreichen. Der Preis pro GB ist bei allen Anbietern mit 0,15 $ identisch. Lediglich bei größerem Bedarf über 50 TB bietet AWS einen günstigeren Preis. GoGrid gewährt seinen Servicekonsumenten 10 GB kostenlosen Speicherplatz, wodurch es bei geringem Speicherbedarf (Usertyp 1) den günstigsten Preis anbieten kann. Auf Grund des relativ hohen Preises für outbound Traffic von 0,50 $ je GB verliert GoGrid seine Preisführerrolle jedoch bei erhöhtem Traffic. GoGrid ist dabei der einzige Anbieter im Storagebereich, der 100% Verfügbarkeit zusichert. AWS garantiert 99,95%, während Rackspace lediglich 99,9% Verfügbarkeit zusichert. Ähnlich wie im Serverbereich werden im Fall der Nichterfüllung Rabatte auf die Rechnung des jeweiligen Monats gewährt. Aufgrund der differenzierten Preisgestaltung sollten auch im Storagebereich eine konkrete Entscheidung für einen public Cloud Provider immer unter Berücksichtigung der Eckdaten

38 einer gegebenen Situation getroffen werden. Darüber hinaus sollten die betrachteten Eigenschaften nach den jeweiligen Anforderungen gewichtet werden. Es ist außerdem zu prüfen, ob weitere Faktoren, wie beispielsweise die Supportqualität zu berücksichtigen sind. Daher ist der getroffene Vergleich lediglich als Anregung zu verstehen. Tabelle 3: Eigenschaften verschiedener public IaaS-Anbieter im Speicherbereich Rackspace 104 AWS 105 GoGrid 106 Wert Punkte Wert Punkte Wert Punkte Preis pro GB pro Monat ($/GB) 0,00 $ 0,15 $ - 0,12-0,15 $ - - 0,15 $ - Berechnungsgrundgröße Genutzter Speicher, Transfer in und out, Anzahl PUT, POST und LIST Genutzter Speicher, Transfer in und out, Anzahl PUT, COPY, Genutzter Speicher >10GB, Transfer in und out Kommandos (auf Files <250kB) POST, LIST und GET Kommandos Preis für Traffic in ($/GB) 0,08 $ 2,0 0,10 $ 0,0 0,00 $ 10,0 Preis für Traffic out ($/GB) 0,22 $ 8,5 0,10-0,17 $ 10,0 0,50 $ 0,0 Preis für PUT, POST, LIST, COPY Anfragen ($/10000 Requests) 0,00 $ - 0,20 $ - 0,10 $ - 0,00 $ - Preis für HEAD, GET Anfragen ($/10000 Requests) 0,00 $ - 0,01 $ - 0,00 $ - Preis Usertyp 1 3,10 $ 0,0 2,96 $ 2,3 2,50 $ 10,0 Preis Usertyp 2 12,20 $ 7,5 11,77 $ 10,0 13,50 $ 0,0 Preis Usertyp 3 41,50 $ 8,5 39,80 $ 10,0 51,00 $ 0,0 Verfügbarkeit 99,90% 0,0 99,99% 9,0 100,00% 10,0 Gesamtpunktzahl (von 60) 26,5 41,3 30,0 4.4 Analyse der Produktreife Eine Bewertung der Produktreife verschiedener public Cloud-Angebote ist immer abhängig von der gewählten Perspektive. Je nach dem, ob eher finanzielle, qualitative oder servicebezogene Aspekte in den Vordergrund gestellt werden, sind die vorhandenen Lösungen als unterschiedlich reif zu beurteilen. Von einem rein finanziellen Standpunkt aus betrachtet, sind die vorgestellten public Cloud- Lösungen als reif zu betrachten, wenn ihre Kosten unter denen eines klassischen, selbstbetriebenen oder gehosteten Rechenzentrums liegen. Ein public Cloud-Angebot kann hier Kostenvorteile erreichen, selbst wenn die stündlichen Kosten für einen Server bei einem solchen Anbieter höher sind als die Kosten für den Besitz und Betrieb eines eigenen Servers. 107 Dies 104 Alle Daten stammen aus [81] Rackspace (2009d) und [82] Rackspace (2009e). 105 Alle Daten stammen aus [55] Amazon Web Services (2009d). 106 Alle Daten stammen aus [63] GoGrid (2009b) und [66] GoGrid (2009e). 107 Vgl. [2] Armbrust, Michael et al. (2009), S. 2.

39 trifft insbesondere zu, wenn der Bedarf an Ressourcen schwankt oder nur schlecht geplant werden kann. In einem klassischen Rechenzentrum müssen sich die vorhandenen Ressourcen an Spitzenlasten orientieren, wodurch in den übrigen Zeiten Leerlauf hervorgerufen wird. In einer public Cloud-Umgebung kann der Servicekonsument seinen Ressourcenverbrauch dynamisch verändern und zahlt nur für die genutzten Ressourcen. 108 Aus diesem Grund sind die betrachteten public Cloud-Angebote aus finanzieller Sicht als reif zu betrachten. Von einem qualitativen Standpunkt betrachtet, sind public Cloud-Angebote als reif zu bezeichnen, wenn sie IT-Services mit der gleichen oder einer besseren Qualität bereitstellen als ein klassisches Rechenzentrum. Qualität ist in diesem Sinne vor allem die Verfügbarkeit der Services und ihre Erbringung gemäß den vereinbarten SLAs. Die garantierte Verfügbarkeit liegt bei den betrachteten Anbietern zwischen 99,9% und 100% und damit relativ nahe bei der eines klassischen Rechenzentrums mit Hochverfügbarkeitsanforderung. 109 Allerdings muss hierbei berücksichtigt werden, dass durch die zugesicherten SLAs bei allen Anbietern bestimmte Fehlerursachen (beispielsweise DoS oder DDoS Attacken 110 ) nicht abgedeckt sind. Darüber hinaus kommt mit der Nutzung des Internets eine weitere Fehlerquelle hinzu, die in keinem SLA umfassend abgedeckt wird. Diese Problematik sollte Bestandteil zukünftiger Entwicklungen sein. Daher sind die betrachteten public Cloud-Angebote von einem qualitativen Standpunkt aus als noch nicht gänzlich ausgereift zu betrachten. Aus servicebezogener Sicht sind public Cloud Computing-Angebote als reif zu bezeichnen, wenn sie IT-Services mit dem gleichen oder einem besseren Level an Servicequalität bereitstellen wie ein klassisches Rechenzentrum. Unter Servicequalität wird im Rahmen dieser Bewertung vor allem die Bereitstellungsgeschwindigkeit und die Möglichkeit der Servicestrategieumsetzung mittels SLAs verstanden. Die Erhöhung der Bereitstellungsgeschwindigkeit und damit der Flexibilität ist eines der Kernziele jeder Cloud Computing-Lösung. Public Cloud Provider bieten hier die Möglichkeit innerhalb von wenigen Minuten neue Server- und Storagekapazitäten zu nutzen. In klassischen Rechenzentren sind hierzu oft mehrere Tage oder Wochen erforderlich. 111 Bei der Vereinbarung von SLAs bieten die Provider jedoch ausschließlich vorgefertigte Verträge an, eine individuelle Vereinbarung von Service-Levels ist nicht möglich. Hier wäre eine kundenindividuelle Modifikation der SLAs (und damit auch der 108 Vgl. [2] Armbrust, Michael et al. (2009), S Vgl. [74] Lenz, Ulrich (2007). 110 Vgl. [66] GoGrid (2009e). 111 Vgl. Listing 1: Interview mit Michael Behrendt, Frage 8.

40 Servicekosten) für die zukünftige Entwicklung ein wesentlicher Schritt zur Reifung solcher Angebote. Aus den vorgenannten Gründen sind die betrachteten public Cloud-Angebote von einem servicebezogenen Standpunkt aus als noch nicht gänzlich ausgereift zu betrachten. Zusammenfassend bietet die Analyse der Produktreife von Cloud Computing-Lösungen ein sehr differenziertes Bild. Je nach gewählter Perspektive und gesetztem Fokus sind die Produkte teilweise als reif, teilweise als noch unreif zu bewerten. Dies ist angesichts des noch geringen Alters dieser Lösungen wenig überraschend, deutet aber darauf hin, dass Cloud Computing als Ganzes noch nicht vollends ausgereift ist. Es besteht weiterhin ein großer Entwicklungsbedarf, um die noch vorhandenen Lücken zu schließen. Welche dies im Einzelnen sind, soll im folgenden Abschnitt näher beleuchtet werden. 4.5 Analyse von Risiken und Gaps bei den vorhandenen Lösungen Wie die meisten neuen Technologien und Lösungen ist auch Cloud Computing noch nicht vollends ausgereift. Es existieren Lücken und Risiken, welche eine Anwendung des Cloud- Modells behindern oder seiner Umsetzung Grenzen setzen. Diese Gaps lassen sich grob drei verschiedenen Bereichen zuordnen. Es existieren zum einen Probleme, welche die Einführung von Cloud Computing-Lösungen behindern, beziehungsweise verzögern. Zum anderen gibt es Gaps, die eher technischer Natur sind und die optimale Nutzung des Cloud-Modells beeinträchtigen. Darüber hinaus existieren auch Lücken in den bisher vorhandenen Geschäftmodellen und Managementpraktiken. Die Bereiche sind hierbei nicht isoliert voneinander zu betrachten, sondern überschneiden sich inhaltlich. Die vorhandenen Gaps beziehen sich dabei sowohl auf private als auch public Cloud-Angebote. Der wesentliche Inhibitor für die Einführung von Cloud Computing ist der Komplex der Sicherheitsproblematik Im public Cloud-Bereich meint dies vor allem das Risiko des Zugriffs Dritter auf sensible Daten. Die Gefahr hierfür wird als erhöht eingeschätzt, da die Daten außerhalb der eigenen Firewall übertragen und persistiert werden. 114 Für die Lösung dieser Problematik existieren bereits Ansätze wie SSL und fortschrittliche Verschlüsselungstechniken, deren Einsatz allerdings für die Verwendung im Cloud Computing-Umfeld bisher 112 Vgl. [46] Robertson, Bruce (2009), S Vgl. [51] West, Mike (2008), S. 7f. 114 Vgl. [46] Robertson, Bruce (2009), S. 3.

41 noch nicht optimiert wurde. Hier muss vor allem die Performance verbessert werden, damit der Security Layer nicht zu einem zusätzlichen Flaschenhals wird. Eine weitere Lücke in den bestehenden Angeboten zeigt sich im so genannten Data Location Risk. Darunter versteht man die Gefahr, Gesetze und Datenschutzregularien mit dem Transfer von Daten in die Cloud zu verletzen, da nicht mehr gewährleistet ist, dass die Daten im Ursprungsland verbleiben. Dies betrifft insbesondere public Cloud-Angebote bei denen der physikalische Speicher- und Verarbeitungsort transparent ist, kann sich aber genauso auf große, multinationale private Cloud-Lösungen beziehen. Eine Möglichkeit zur Vermeidung dieses Risikos besteht im Abschluss von SLAs, welche den physikalischen Aufenthaltsort der zu nutzenden Cloud-Ressourcen festlegen. 115 Hier bietet beispielsweise AWS als public Cloud Provider eine Lösung an, da die verfügbaren Ressourcen verschiedenen Zonen und Regionen zugeordnet wurden, um dieses Risiko zu vermeiden. 116 Ein wesentliches Risiko aus dem technischen Bereich, das einen starken Bezug zu den vorgenannten Sicherheitsaspekten hat, ist das Datenverlustrisiko. Dies bezieht sich im public Cloud-Umfeld vorwiegend auf persistente Daten, da ein Großteil aller public IaaS Provider im Storagebereich nicht über eine integrierte Backupstrategie verfügen. Eine Strategie zur Vermeidung dieses Risikos besteht in der selbstständigen Umsetzung einer Backupstrategie, entweder in-house oder mit einem anderen public Cloud Provider. 117 Hierdurch könnten allerdings Kostenvorteile einer Public Cloud-Lösung nivelliert werden. Das Datenverlustrisiko kann sich darüber hinaus auch auf transiente Daten, die während der Verarbeitung erzeugt werden, beziehen. Ein Verlust kann hier durch Absturz der VM oder des Hypervisors entstehen. Dies betrifft sowohl public als auch private Cloud-Lösungen. Ein weiteres technisches Problem stellt der zunehmende Datentransfer über Leitungen mit begrenzter Bandbreite dar. 118 Durch die Nutzung von IaaS Storage- und SaaS-Angeboten wird der Netzwerktraffic weiter erhöht. Die vorhandenen, beschränkten Bandbreiten können hier zu Performanceverlusten führen. Damit stellt der Datentransfer im Bereich des Cloud Computing insbesondere für das zukünftige Wachstum dieser Lösungen ein mögliches Hindernis dar. 119 Obwohl die Bandbreiten in internen Netzwerken für gewöhnlich größer sind als im 115 Vgl. [14] Buyya, Rajkumar et al. (2008), S Vgl. [56] Amazon Web Services (2009e). 117 Vgl. [46] Robertson, Bruce (2009), S Vgl. [2] Armbrust, Michael et al. (2009), S Vgl. ebenda, S. 2f.

42 Internetverkehr, bezieht sich diese Problematik sowohl auf private als auch auf public Cloud- Angebote. Eine Lösung dieses Problems kann dabei über zwei Wege erreicht werden. Zum einen können Kompressionsverfahren das Trafficvolumen reduzieren, wobei hier die Gefahr der bloßen Verschiebung des Flaschenhalses besteht. Zum anderen können die Bandbreiten weiter erhöht werden, was allerdings mit zusätzlichen Kosten verbunden ist. Ein weiteres Problemfeld ist die fehlende Standardisierung und mangelnde Portabilität von Cloud Computing-Lösungen. Dies bezieht sich insbesondere auf public SaaS-Angebote, aber auch auf grundlegende public Infrastruktur-Services. 120 Die fehlende Standardisierung und Portabilität äußert sich sowohl bei den Anwendungsdaten als auch beim Code zur Realisierung eines gegebenen Prozesses in der Cloud. 121 Durch die unterschiedlichen APIs der Anbieter kann einer der wesentlichen Vorteile des Cloud Computing, der unkomplizierte Providerwechsel, ausgeschaltet werden. Eine Strategie zur Vermeidung dieses Lock-In-Risikos besteht in der gleichzeitigen Unterstützung von APIs mehrerer Anbieter und der simultanen Nutzung verschiedener public Cloud Provider. 122 Eine weitere Lücke im technischen Bereich zeigt sich bei der genutzten Software. Im Bereich der verwendeten Applikationssoftware kommt neben der klassischen Anforderung des schnellen aufwärts Skalierens der Forderung nach schnellem abwärts Skalieren große Bedeutung zu. Diese ist essentiell wichtig zur Realisierung der Forderung der elastischen Skalierbarkeit an SaaS-Angebote. Applikationen im Bereich der Infrastruktursoftware müssen stärker auf den Betrieb in virtuellen Umgebungen ausgelegt werden und darüber hinaus Billing- und Metering-Funktionalitäten nativ integrieren. 123 Hierdurch können die Performanceanforderungen an Cloud-Lösungen besser umgesetzt werden. Ein weiteres Risiko aus dem technischen Bereich besteht in der Unvorhersagbarkeit der Performance von virtualisierten Maschinen. 124 Diese resultiert daraus, dass mehrere VMs, die auf einer physikalischen Maschine residieren, zwar in vielerlei Hinsicht voneinander isoliert werden können, jedoch in Performance-Fragen nicht völlig unabhängig voneinander sind. 125 Mögliche Ursachen für Performance-Wechselwirkungen zwischen VMs sind die Auslastung 120 Vgl. [46] Robertson, Bruce (2009), S Vgl. ebenda, S Vgl. ebenda, S Vgl. [2] Armbrust, Michael et al. (2009), S. 2f. 124 Vgl. ebenda, S Vgl. [10] Brett, Paul et al. (2006), S. 228.

43 des L2 Caches und Faktoren wie die Lesekopfposition, Cache-Status und ähnliches. 126 Durch diese Wechselwirkung kann die Gesamtperformance eines public oder private Cloud-Systems beeinträchtigt werden. Zur Lösung dieser Problematik sind die weiteren Entwicklungen im Virtualisierungsumfeld abzuwarten. Das letzte Problemfeld betrifft die vorhandenen Geschäftsmodelle und Managementpraktiken der Anbieter, die bisher noch nicht optimal an Cloud-Umgebungen angepasst wurden. Dies bezieht sich zum einen auf Softwarehersteller, deren Lizenzmodelle bisher noch stark auf die klassischen Einzelplatz- oder Volumenlizenzen ausgerichtet sind. Hier ist die Anpassung des Geschäfts- und Lizenzmodells hin zu pay-per-use-lizenzen und ähnlichen Modellen notwendig, um die Bedürfnisse des Cloud-Modells optimal abzudecken. 127 Ein weiteres Risiko in diesem Bereich ist die Zuverlässigkeit von Cloud Providern. Dies bezieht sich vorwiegend auf public Cloud-Anbieter und meint die Gefahr, dass ein bestimmter Anbieter das Geschäft aufgibt oder einzelne Services einstellt. 128 Dieses Risiko ist insbesondere im Zusammenhang mit einem möglichen Lock-In und in wirtschaftlich angespannten Zeiten nicht zu vernachlässigen, um Erfahrungen, wie sie Unternehmen nach dem Platzen der Internetblase mit externen Serviceprovidern gemacht haben, zu vermeiden. 129 Möglichkeiten zur Minimierung des Risikos bestehen in einer klar auf Dauerhaftigkeit ausgelegten Lieferantenwahl und der gegenseitigen Zusicherung des Servicebetriebs mittels SLAs. Die aufgezeigten Gaps und Risiken unterstreichen die Notwendigkeit einer genauen Prüfung eines Cloud-Angebots, sowohl im public als auch im private Cloud-Umfeld. Darüber hinaus wird die Wichtigkeit eines Bewertungsmodells für Cloud Computing-Lösungen deutlich. Der Entwurf eines solchen Modells für private Cloud-Lösungen soll im nächsten Abschnitt entwickelt werden. 5. Bewertungsmodelle für Cloud Computing Zur objektiven Bewertung des Erfolgs oder Misserfolgs einer Investition benötigt man stets ein Bewertungsmodell. Auch zur Überprüfung des Projektfortschritts und zur Einleitung von korrektiven Maßnahmen ist solch ein Modell notwendig. Da Cloud Computing eine hohe In- 126 Vgl. [10] Brett, Paul et al. (2006), S Vgl. [2] Armbrust, Michael et al. (2009), S Vgl. [46] Robertson, Bruce (2009), S. 3f. 129 Vgl. ebenda, S. 3f.

44 vestition in die IT eines Unternehmens bedeutet und seine Einführung ein großes IT-Projekt darstellt, ist ein Bewertungsmodell mit abgestimmten Kennzahlen hierfür von besonders großer Bedeutung. Welche Kennzahlen dabei betrachtet werden, hängt von der Zielstellung der getätigten Investition und der Unternehmensstrategie ab. Bei einer Preisführerstrategie werden eher finanzielle Kennzahlen im Fokus des verwendeten Bewertungsinstrumentes stehen. Unternehmen mit einer Qualitätsführerschaftsstrategie werden in ihren Instrumenten einen Schwerpunkt auf kundenorientierte Qualitätskennzahlen legen. Unternehmen, welche eine Diversifizierungsstrategie verfolgen, werden zur Erfolgsbewertung eine Mischung beider Kennzahlenarten verwenden. Die Bewertungsinstrumente sind dabei typischerweise Balanced Scorecards mit den vier Basisdimensionen Finanzperspektive, interne Prozessperspektive, Kundenperspektive sowie der Lern- und Entwicklungsperspektive. 130 Da die Balanced Scorecard unternehmensspezifisch ist, können einzelne Perspektiven entfernt, ausgetauscht oder durch weitere ergänzt werden. 131 Jede Perspektive enthält Kennzahlen, welche als Maß der Zielerreichung in der jeweiligen Dimension dienen können. Darüber hinaus werden Abhängigkeiten, Einflüsse und Ursache- Wirkungszusammenhänge zwischen den Kennzahlen identifiziert. 132 Zur Entwicklung der jeweiligen Kennzahlen existieren die unterschiedlichsten Ansätze. Diese reichen von empirischen Methoden wie einer Expertenbefragung zum Beispiel gemäß dem Delphi-Verfahren, bis hin zu vordefinierten Kennzahlensystemen für einzelne Dimensionen wie der DuPont-Kennzahlenpyramide für Finanzkennzahlen. Im Bereich des Cloud Computings existieren bisher noch keine Standardbewertungsmodelle. Daher soll im Folgenden der Entwurf eines solchen Modells erarbeitet werden. Hierzu wird zunächst auf die Methodik der Kennzahlenentwicklung eingegangen. Bei der Durchführung der Kennzahlenentwicklung wird ein Unternehmen angenommen, welches eine Preisführerschaftsstrategie verfolgt und plant, eine private Cloud Computing-Lösung zu implementieren. 5.1 Methodik zur Kennzahlenentwicklung Im Rahmen dieser Arbeit werden die Kennzahlen für die BSC mithilfe des Goal Question Metric (GQM) Ansatzes entwickelt. Dieser Ansatz wurde ursprünglich im Goddard Space Center der NASA entwickelt und wird seitdem von den Universitäten Maryland und Kaisers- 130 Vgl. [36] Kaplan, Robert; Norton, David (1996), S. 44ff. 131 Vgl. ebenda, S. 34f. 132 Vgl. ebenda S. 35.

45 lautern sowie dem Fraunhofer-Institut für experimentelles Software Engineering weiterentwickelt Obwohl der GQM-Ansatz aktuell für die Entwicklung von Software Engineering Metriken spezifiziert wurde, eignet sich sein methodisches Vorgehen auch zur Entwicklung von Kennzahlen für andere Vorhaben. Ausgangspunkt des GQM-Ansatzes sind immer eine oder mehrere Zielstellungen, die für ein konkretes Objekt (Produkt, Prozess, Projekt, etc.) definiert wurden. Daraus werden Fragen abgeleitet, welche die Zielstellung in ihre Hauptbestandteile zergliedern und beschreiben, wie das Ziel erreicht werden soll. Danach werden Kennzahlen definiert, welche die jeweiligen Fragen quantitativ beantworten können, dabei kann eine Metrik auch zur Beantwortung mehrerer Fragen herangezogen werden. 135 Es entsteht also ein dreistufiges hierarchisches Modell, das Top-Down aus einem Ziel Kennzahlen ableitet. Abbildung 7 zeigt den schematischen Aufbau des Modells. Abbildung 7: Schematischer Aufbau eines Bewertungsmodells nach dem GQM-Ansatz (Quelle: [4] Basili, Victor et al. (1994), S. 3) Neben den oben beschriebenen Prozessschritten zur Entwicklung der Metriken enthält der GQM-Prozess noch weitere Schritte. In diesen werden die Datensammlungsmechanismen definiert und die Datensammlung und Analyse durchgeführt. 136 Auf die Durchführung dieser Prozessschritte wird im Rahmen dieser Arbeit jedoch verzichtet. Bei der Ausführung der oben beschriebenen Schritte wird ausgehend von der angenommenen Unternehmensstrategie für jede Basis- beziehungsweise Standarddimension der Balanced Scorecard jeweils mindestens ein Ziel definiert. Da die Zieldefinition ein kritischer Punkt des GQM-Ansatzes ist, soll im Folgenden noch einmal näher auf die Methodik eingegangen werden. 133 Vgl. [4] Basili, Victor et al. (1994), S Vgl. [23] Differding, Christiane et al. (1996), S Vgl. [4] Basili, Victor et al. (1994), S. 3f. 136 Vgl. ebenda, S. 5.

46 Für die Zieldefinition beschreibt der GQM-Ansatz die fünf Hauptaspekte eines Zieles. Dies sind das Objekt, der Zweck, der Qualitätsfokus, der Blickwinkel und der Kontext. 137 Das Objekt spezifiziert den primären Gegenstand, der untersucht werden soll, beispielsweise ein Prozess, Produkt oder Projekt. Der Zweck beschreibt, wozu das Objekt untersucht wird, typische Beispiele für den Zweck sind Optimierung, zur Schaffung eines besseren Verständnisses und ähnliches. Der Qualitätsfokus beschreibt, welche konkrete Eigenschaft des Objektes untersucht werden soll. Typische Bespiele hierfür sind Kosten, Durchlaufzeiten und Zuverlässigkeit. Der vierte Aspekt, der Blickwinkel, beschreibt zum einen, wer die Daten erhebt und zum anderen, wer sie interpretiert. Der Kontext beschreibt welche Gegebenheiten hierbei eine Rolle spielen und dient dazu, Einflussfaktoren explizit zu erfassen. 138 Zur Visualisierung und zur Unterstützung der Zielformulierung wird das GQM Template verwendet. Dieses Template hat meist die Form der folgenden Tabelle. Tabelle 4: GQM Template Analysiere [Objekt] z.b. Prozess, Produkt, Modell, etc. zum Zweck [Zweck] z.b. Charakterisierung, Verbesserung, Überwachung, Auswertung, Vorhersage oder Optimierung, etc. in Bezug auf [Qualitätsfokus] z.b. Kosten, Korrektheit, Mängelbeseitigung, Änderungen, Zuverlässigkeit, Benutzerfreundlichkeit, Wartbarkeit, etc. vom Blickwinkel [Blickwinkel] z.b. Kunde, Entwickler, Abteilung, etc. im Kontext [Kontext] z.b. Ressourcen, Projekte, Prozesse, etc. (Quelle: Eigene Darstellung in Anlehnung an [23] Differding, Christiane et al. (1996), S. 9 und [86] The Data & Analysis Center for Software (2009)) Die auf diese Weise definierten Ziele werden typischerweise mit Hilfe von GQM Abstraction Sheets in Interviews weiter spezifiziert. Ein kommentiertes Beispiel eines solchen Abstraction Sheets zeigt Tabelle 19 im Anhang. Im Rahmen dieser Arbeit wird für jedes Ziel ein GQM Template und ein Abstraction Sheet erstellt. Auf die Erstellung eines darüber hinaus gehenden GQM-Plans wird verzichtet Vgl. [23] Differding, Christiane et al. (1996), S. 8f. 138 Vgl. ebenda, S Informationen zum GQM Plan siehe [23] Differding, Christiane et al. (1996), S. 13ff.

47 Zieldefinition Von der Preisführerschaftsstrategie des angenommenen Unternehmens ausgehend, müssen alle definierten Ziele vom Metaziel der Kostenreduktion abgeleitet sein. Qualitätsaspekte spielen nur dahingehend eine Rolle, dass die Servicequalität durch die Einführung der zu bewertenden private Cloud nicht sinkt. Neben der Unternehmensstrategie spielen auch die Erwartungen an die private Cloud-Lösung für die Zieldefinition eine Rolle. Diese werden im Rahmen dieser Arbeit mit den allgemeinen Zielstellungen des Cloud Computings angenommen Ziele der Finanzperspektive Für die Finanzperspektive wird aus der Cloud Computing-Zielstellung der Umwandlung von fixen in variable Kosten das Metaziel der Optimierung der Kostenstruktur des IT-Budgets abgeleitet. Tabelle 5 und Tabelle 6 zeigen das daraus entwickelte GQM Template und Abstraction Sheet. Tabelle 5: GQM Template für das Metaziel Optimierung der Kostenstruktur Analysiere Das IT-Budget zum Zweck der Optimierung in Bezug auf die Kostenstruktur vom Blickwinkel des CFO im Kontext der einzuführenden private Cloud Tabelle 6: Abstraction Sheet für das Metaziel Optimierung der Kostenstruktur Objekt IT-Budget Qualitätsfokus: Zweck Optimierung Qualitätsfokus Blickwinkel Kostenstruktur CFO Einflussfaktoren: Kontext private Cloud Kostenstruktur bedeutet zum einen das Verhältnis von Fixkosten zu variablen Kosten. Zum anderen aber auch die absolute Höhe des IT-Budgets. Baseline Hypothese: Anteil der IT-Services, die pro Nutzung bezahlt werden: niedrig, mittel, hoch Einfluss auf die Baseline Hypothese: Das existierende IT-Budget setzt sich zu 80% aus Fixkosten zusammen, während nur 20% variabel sind (Annahme). Feedback: % Je höher der Anteil der IT-Services, die pro Nutzung bezahlt werden, desto geringer ist der Fixkostenanteil am IT-Budget 140 Siehe hierzu 2.6 Zielstellung von Cloud Computing.

48 Ziele der Prozessperspektive Da Cloud Computing-Lösungen unter anderem darauf abzielen, manuelle Arbeitsschritte in den IT-Bereitstellungsprozessen zu reduzieren und hierdurch die Prozesskosten zu senken, werden diese Ziele für die Prozessperspektive der Balanced Scorecard übernommen. 141 Tabelle 7: GQM Template für das Metaziel Reduktion der Prozesskosten Analysiere Die IT-Bereitstellungsprozesse zum Zweck der Reduktion in Bezug auf die Prozesskosten vom Blickwinkel der IT-Organisation im Kontext der einzuführenden private Cloud Tabelle 8: Abstraction Sheet für das Metaziel Reduktion der Prozesskosten Objekt IT-Bereitstellungsprozesse Qualitätsfokus: Zweck Reduktion Qualitätsfokus Prozesskosten Einflussfaktoren: Blickwinkel IT-Organisation Kontext private Cloud Prozesskosten sind alle Aufwände, die beim Durchlauf der IT-Bereitstellungsprozesse entstehen. Baseline Hypothese: Anzahl an Prozessschritten in den IT- Bereitstellungsprozessen: niedrig, mittel, hoch Anteil manueller Prozessschritte in den IT- Bereitstellungsprozessen: niedrig, mittel, hoch Einfluss auf die Baseline Hypothese: Die existierenden IT-Bereitstellungsprozesse verursachen im Durchschnitt Aufwände in Höhe von 150 pro Durchlauf, zuzüglich Material. (Annahme) Feedback: % Je geringer die Anzahl an IT-Bereitstellungsprozessen und je geringer der Anteil manueller Prozessschritte, desto geringer sind die durchschnittlichen Kosten. Darüber hinaus spielt die Standardisierung der angebotenen Services und Prozesse eine wesentliche Rolle. 142 Da für die Bereitstellung standardisierter und damit weniger IT-Services ebenfalls weniger Prozesse benötigt werden, wird hieraus für die Prozessperspektive der BSC das Metaziel der Reduktion der Anzahl von IT-Bereitstellungsprozessen abgeleitet. Tabelle 9: GQM Template für das Metaziel Reduktion der Prozessanzahl Analysiere zum Zweck in Bezug auf vom Blickwinkel im Kontext Die IT-Prozesslandschaft der Reduktion die Prozessanzahl der IT-Organisation der einzuführenden private Cloud 141 Siehe hierzu Kapitel 2.6 Zielstellung von Cloud Computing. 142 Siehe hierzu Kapitel 2.4 Synthese einer Cloud Computing-Definition

49 Tabelle 10: Abstraction Sheet für das Metaziel Reduktion der Prozessanzahl Objekt IT-Prozesslandschaft Qualitätsfokus: Zweck Reduktion Qualitätsfokus Prozessanzahl Einflussfaktoren: Blickwinkel IT-Organisation Kontext private Cloud Prozessanzahl bedeutet die Menge an offiziell und informell definierten Abläufen. Baseline Hypothese: Im Moment existieren 30 verschiedene Prozesse zur Bereitstellung der verschiedensten IT-Services (Annahme) Anzahl an IT-Services: niedrig, mittel, hoch Einfluss auf die Baseline Hypothese: Je geringer die Anzahl an IT-Services, desto geringer ist die Anzahl benötigter IT-Bereitstellungsprozesse Feedback: % Ziele der Kundenperspektive Da eine private Cloud-Lösung angenommen wird, beziehen sich die Ziele und zu entwickelnden Kennzahlen der Kundenperspektive primär auf interne Kunden der IT-Organisation. Für diese Kunden spielt vor allem die Geschwindigkeit, mit der Servicerequests bearbeitet werden, eine Rolle. Nur hierdurch kann eine Fachabteilung entsprechend schnell auf die Bedürfnisse externer Kunden reagieren. Da all dies Einfluss auf die Kundenzufriedenheit hat, wird für die Kundenperspektive der BSC das Metaziel der Erhöhung der Kundenzufriedenheit angenommen. Tabelle 11: GQM Template für das Metaziel Erhöhung der Kundenzufriedenheit Analysiere zum Zweck in Bezug auf vom Blickwinkel im Kontext Die IT-Services der Erhöhung die Kundenzufriedenheit der internen Kunden der einzuführenden private Cloud Tabelle 12: Abstraction Sheet für das Metaziel Erhöhung der Kundenzufriedenheit Objekt IT-Services Qualitätsfokus: Zweck Erhöhung Qualitätsfokus Kundenzufriedenheit Einflussfaktoren: Blickwinkel interner Kunde Kontext private Cloud Kundenzufriedenheit drückt das Ausmaß der Befriedigung der Kundenwünsche aus. Baseline Hypothese: Bereitstellungszeit eines Service: niedrig, mittel, hoch Häufigkeit, mit der ein Service bereitgestellt wird: selten, gelegentlich, oft Einfluss auf die Baseline Hypothese: In internen Erhebungen sind nur ca. 40% der internen Kunden mit den Leistungen der IT-Organisation zufrieden (Annahme) Feedback: % Je geringer die Bereitstellungszeit, insbesondere bei häufig angeforderten Services, desto zufriedener sind die internen Kunden.

50 Ziele der Lern- und Entwicklungsperspektive Aus der Notwendigkeit, innerhalb der IT grobgranularere Rollen zu definieren, 143 wird für die Lern- und Entwicklungsperspektive der Balanced Scorecard das Metaziel der Optimierung der Rollenstruktur in der IT-Organisation abgeleitet. Tabelle 13: GQM Template für das Metaziel Optimierung der Rollenstruktur Analysiere zum Zweck in Bezug auf vom Blickwinkel im Kontext Die IT-Organisation der Optimierung die Rollenstruktur des CTO der einzuführenden private Cloud Tabelle 14: Abstraction Sheet für das Metaziel Optimierung der Rollenstruktur Objekt IT-Organisation Qualitätsfokus: Zweck Optimierung Rollenstruktur meint die Anzahl der definierten Rollen und den Umfang der jeweils zugehörigen Aufgabengebiete Baseline Hypothese: Aktuell existieren innerhalb der IT-Organisation 30 Jobrollen, die zur Servicebereitstellung und zum Servicebetrieb benötigt werden (Annahme) Feedback: % Qualitätsfokus Rollenstruktur Einflussfaktoren: Blickwinkel CTO Aus diesen GQM-Zielen sollen im Folgenden Fragen abgeleitet werden. Kontext private Cloud Breite der IT-Kenntnisse der Mitarbeiter: gering, mittel, hoch Abstraktionslevel der IT-Ressourcen: gering, mittel, hoch Einfluss auf die Baseline Hypothese: Je breiter der Kenntnisstand und je abstrakter die IT- Ressourcen, desto weniger Jobrollen werden zur Servicebereitstellung und zum Servicebetrieb benötigt. 5.3 Ableitung von Fragen Bei der Ableitung von Fragen aus den entwickelten GQM-Zielen werden drei Arten von Fragen gestellt. Zum einen sind dies Fragen, die das Analyseobjekt in Hinblick auf das GQM- Ziel charakterisieren. Zum anderen werden Fragen gestellt, die das Objekt in Bezug auf den jeweiligen Zweck charakterisieren. Der dritte Fragentyp sind Fragen, welche beschreiben, wie das Objekt in Bezug zum Qualitätsfokus bewertet wird. 144 Innerhalb dieses Kapitels werden zur besseren Übersichtlichkeit an den Enden der jeweiligen Abschnitte das Ziel und die daraus formulierten Fragen in Listenform wiederholt. 143 Siehe hierzu Aufbauorganisatorische Veränderungen. 144 Vgl. [4] Basili, Victor et al. (1994), S. 6f.

51 Fragen der Finanzperspektive Für das Ziel der Finanzperspektive Analysiere das IT-Budget zum Zweck der Optimierung in Bezug auf die Kostenstruktur vom Blickwinkel des CFO im Kontext der einzuführenden private Cloud bedeutet dies, zunächst das IT-Budget näher zu charakterisieren. Anschließend werden mittels Fragen die Eigenschaften des IT-Budget spezifiziert, welche für die Optimierung von Bedeutung sind. Der letzte Fragentyp spezifiziert, wie das IT-Budget in Bezug zur Kostenstruktur bewertet wird. Für das Ziel der Finanzperspektive wird als Grundlage die Frage nach der Höhe des IT-Budgets gestellt. Darauf aufbauend wird ermittelt, in welchem Verhältnis fixe und variable Kosten im Budget stehen. Da dieses Verhältnis das direkte Resultat der internen Verrechnungsmethoden ist, werden diese ebenfalls erfragt. Abschließend wird die Frage nach der Optimierung des Verhältnisses von variablen und fixen Kosten gestellt. Analysiere das IT-Budget zum Zweck der Optimierung in Bezug auf die Kostenstruktur vom Blickwinkel des CFO im Kontext der einzuführenden private Cloud o Wie hoch ist das IT-Budget? o In welchem Verhältnis stehen fixe und variable Kosten im IT-Budget? o Wie werden IT-Services intern verrechnet? o Verändert sich die Kostenstruktur der IT-Ausgaben? Fragen der Prozessperspektive Für die Prozessperspektive der Balanced Scorecard müssen für die definierten GQM-Ziele Fragen formuliert werden, welche die Reduktion der Prozesskosten und die Verschlankung der Prozessstruktur abbilden. Als Grundlage wird hierbei zunächst die Höhe der Kosten in den definierten Bereitstellungsprozessen erfragt. Da die Kosten nicht isoliert vom Umfang der jeweiligen Prozesse betrachtet werden können, wird auch hierzu eine Frage gestellt. Abschließend wird die Frage nach der Veränderung der Kosten gestellt. Analysiere die IT-Bereitstellungsprozesse zum Zweck der Reduktion in Bezug auf die Prozesskosten vom Blickwinkel der IT-Organisation im Kontext der einzuführenden private Cloud o Wie hoch sind die Kosten in den definierten Bereitstellungsprozessen? o Wie umfangreich sind die Bereitstellungsprozesse? o Verringern sich die Prozesskosten? Für das zweite GQM-Ziel der Prozessperspektive Analysiere die IT-Prozesslandschaft zum Zweck der Reduktion in Bezug auf die Prozessanzahl vom Blickwinkel der IT-Organisation

52 im Kontext der einzuführenden private Cloud, wird zunächst erfragt, wie viele definierte Bereitstellungsprozesse existieren. Da neben den formal definierten Prozessen oftmals informelle Abläufe existieren, wird darauf aufbauend erfragt, ob die definierten Prozesse Anwendung finden. Da die Prozessanzahl in direktem Zusammenhang mit der Anzahl bereitgestellter Services steht, wird diese ebenfalls erfragt. Abschließend wird formuliert, ob sich die Anzahl definierter Services verändert. Analysiere die IT-Prozesslandschaft zum Zweck der Reduktion in Bezug auf die Prozessanzahl vom Blickwinkel der IT-Organisation im Kontext der einzuführenden private Cloud o Wie viele definierte IT-Bereitstellungsprozesse existieren? o Werden die definierten Prozesse angewendet? o Wie viele IT-Services werden bereitgestellt? o Verändert sich die Anzahl definierter Bereitstellungsprozesse? Fragen der Kundenperspektive Im Rahmen der Kundenperspektive werden für das GQM-Ziel Analysiere die IT-Services zum Zweck der Erhöhung in Bezug auf die Kundenzufriedenheit vom Blickwinkel des internen Kunden im Kontext der einzuführenden private Cloud wird als Grundlage erfragt, wie häufig IT-Servicerequests gestellt werden. Eine weitere wesentliche Frage, die zur Erreichung des Ziels gestellt wird, betrifft die Bereitstellungszeit für IT-Services. Auch für dieses Ziel wird abschließend die Frage nach der Entwicklung der Bereitstellungszeit gestellt. Analysiere die IT-Services zum Zweck der Erhöhung in Bezug auf die Kundenzufriedenheit vom Blickwinkel des internen Kunden im Kontext der einzuführenden private Cloud o Wie häufig werden IT-Services angefordert? o Wie lange dauert die Bereitstellung von IT-Services? o Verändert sich die Kundenzufriedenheit? Fragen der Lern- und Entwicklungsperspektive Abschließend werden für die Lern- und Entwicklungsperspektive Fragen mit Bezug zur Optimierung der Rollenstruktur innerhalb der IT gestellt. In Bezug auf das Personal ist die Frage nach der Anzahl der Mitarbeiter essentielle Grundlage. Da Cloud Computing außerdem die weitere Professionalisierung der IT-Organisation bedeutet, sind die Erfahrung und der Kenntnisstand der Mitarbeiter eine wesentliche Bewertungsgrundlage, welche erfragt wird. Ab-

53 schließend wird für diese Perspektive ebenfalls erfragt, ob eine Entwicklung gemäß der Zielstellung stattfindet. Analysiere die IT-Organisation zum Zweck der Optimierung in Bezug auf die Rollenstruktur vom Blickwinkel des CTO im Kontext der einzuführenden private Cloud o Wie viele Mitarbeiter hat die IT-Organisation? o Wie viel Erfahrung haben die Mitarbeiter in der IT-Organisation? o Hat sich die Rollenstruktur verändert? Aus diesen Fragen werden im Folgenden Metriken abgeleitet, welche geeignet sind die jeweilige Frage quantitativ zu beantworten. 5.4 Ableitung von Metriken Zur Ableitung von Metriken werden die Fragen einzeln betrachtet und Kennzahlen zur quantitativen Beantwortung der einzelnen Fragestellungen erarbeitet. Dabei können einzelne Metriken auch zur Beantwortung mehrerer Fragen herangezogen werden. Am Ende jedes Abschnitts werden die Frage und die daraus hergeleiteten Metriken noch einmal in Listenform wiederholt. Die genauen Definitionen der Kennzahlen finden sich im Anhang. Darüber hinaus wird für alle Kennzahlen angenommen, dass sie jährlich rollierend erhoben werden Metriken der Finanzperspektive Innerhalb der Finanzperspektive wird für die quantitative Beantwortung der Frage Wie hoch ist das IT-Budget? zunächst die Höhe der IT-Ausgaben als Metrik definiert. Da dieser absolute Wert jedoch nicht für einen Vergleich über Unternehmensgrenzen hinweg geeignet ist und mögliche Schwankungen durch äußere Bindungen nicht widerspiegelt, wird außerdem die IT-Kostenquote als Metrik definiert. Wie hoch ist das IT-Budget? o Die Höhe der IT-Ausgaben o Die Höhe der IT-Kostenquote Zur Beantwortung der Frage In welchem Verhältnis stehen fixe und variable Kosten im IT- Budget? werden die prozentualen Anteile der fixen und variablen Kosten als Metriken definiert. In welchem Verhältnis stehen fixe und variable Kosten im IT-Budget? o Anteil variabler Kosten an den IT-Ausgaben

54 o Anteil fixer Kosten an den IT-Ausgaben Zur quantitativen Beantwortung der Frage Wie werden IT-Services intern verrechnet? werden insgesamt vier Metriken herangezogen. Dies sind zum einen die prozentualen Anteile der Services, die fix abgegolten beziehungsweise nach Verbrauch berechnet werden. Zum anderen werden die jeweils mit den beiden Servicetypen erzielten Umsätze verglichen. Dies ist notwendig, da hierüber eine Gewichtung der Anteile möglich ist. Wenn beispielsweise nur wenige Services nach Verbrauch berechnet werden, diese allerdings einen Großteil des Umsatzes ausmachen, könnten die Anteile allein dies nicht abbilden. Wie werden IT-Services intern verrechnet? o Anteil auf Verbrauchsbasis berechneter Services o Anteil fix abgegoltener Services o Umsatz mit fix abgegoltenen Services o Umsatz mit variabel berechneten Services Zur Messung der Veränderung der Kostenstruktur werden die aktuellen Umsätze mit fix abgegoltenen beziehungsweise pay-per-use berechneten Services mit den jeweiligen Baseline- Umsätzen verglichen. Verändert sich die Kostenstruktur der IT-Ausgaben? o Veränderung des Umsatzes fix abgegoltener Services o Veränderung des Umsatzes pay-per-use berechneter Services Metriken der Prozessperspektive Innerhalb der Prozessperspektive werden zur quantitativen Beantwortung der Frage Wie hoch sind die Kosten in den definierten Bereitstellungsprozessen? ausschließlich die durchschnittlichen Kosten über alle Bereitstellungsprozesse betrachtet. Eine Untergliederung der durchschnittlichen Bereitstellungsprozesskosten für verschiedene Prozessgruppen (beispielsweise nach Services, Komplexität, o.ä.) wird nicht angenommen. Wie hoch sind die Kosten in den definierten Bereitstellungsprozessen? o Ø Kosten je Bereitstellungsprozess o Abweichung der Aktuellen Ø Kosten je Bereitstellungsprozess von den geplanten Ø Kosten je Bereitstellungsprozess

55 Zur Abbildung des Umfangs der Bereitstellungsprozesse wird die durchschnittliche Anzahl an Prozessschritten untersucht. Darüber hinaus wird die durchschnittliche Anzahl manueller Arbeitsschritte erfasst. Wie umfangreich sind die Bereitstellungsprozesse? o Ø Anzahl definierter Prozessschritte in Bereitstellungsprozessen o Ø Anzahl manueller Prozessschritte in Bereitstellungsprozessen Um abzubilden, ob die durchschnittlichen Bereitstellungsprozesskosten sinken, werden die aktuellen Durchschnittskosten mit den ermittelten Baseline-Durchschnittskosten verglichen. Verringern sich die Prozesskosten? o Veränderung der Ø Bereitstellungsprozesskosten Für das zweite Ziel der Prozessperspektive wurden Metriken zur Bewertung der Prozesslandschaft entwickelt. Zur Beantwortung der Frage Wie viele definierte IT-Bereitstellungsprozesse existieren? wird zum einen die Anzahl der formal definierten Bereitstellungsprozesse erfasst. Da die bloße Prozessanzahl jedoch kein objektives Maß der Größe der Prozesslandschaft ist, wird außerdem die Anzahl an Bereitstellungsprozessschritten untersucht. Wie viele definierte IT-Bereitstellungsprozesse existieren? o Anzahl definierter Bereitstellungsprozesse o Anzahl definierter Prozessschritte Da oftmals neben den definierten Prozessen auch informelle Prozessabläufe existieren, sind die bereits entwickelten Metriken zum Umfang der Prozesslandschaft noch nicht ausreichend. Zur besseren Abbildung des tatsächlichen Umfangs der Prozesse muss auch erfasst werden, ob die definierten Prozesse tatsächlich angewendet werden. Da dies informell geschieht, kann eine Kennzahl hierzu nur schwer objektiv erhoben werden. Lediglich ein mittlerer Prozentsatz der Abweichungen wird in Reviews auffallen. Daher werden sowohl die subjektive Bewertung des IT-Verantwortlichen als auch der Anteil in Reviews identifizierter Abweichungen ermittelt. Werden die definierten Prozesse angewendet? o Subjektive Bewertung der Prozesstreue durch den IT-Verantwortlichen o Anteil in Reviews identifizierter Abweichungen vom Standardprozess

56 Ein weiterer wesentlicher Einflussfaktor auf den Umfang der Prozesslandschaft zur Bereitstellung von IT-Services ist die Anzahl der angebotenen Services. Auch hier wird neben der Anzahl der Services die Komplexität untersucht. Da es für die Messung der Komplexität eines Services verschiedenste Ansätze gibt, die für verschiedene Produkte unterschiedlich gute Ergebnisse liefern, wird hier erneut die subjektive Beurteilung des IT-Verantwortlichen herangezogen. Wie viele IT-Services werden bereitgestellt? o Anzahl bereitgestellter Services o Subjektive Bewertung der Komplexität der bereitgestellten Services durch den IT-Verantwortlichen Zur Überprüfung, ob sich die definierte Prozessanzahl verändert, wird die aktuelle Prozessanzahl ins Verhältnis zur Baseline-Prozessanzahl gesetzt. Verändert sich die Anzahl definierter Bereitstellungsprozesse? o Veränderung der Bereitstellungsprozessanzahl Metriken der Kundenperspektive Im Rahmen der Kundenperspektive der Balanced Scorecard wurde das Ziel der Erhöhung der Kundenzufriedenheit definiert. Hierzu wurde zunächst die Frage gestellt, Wie häufig werden IT-Services angefordert?. Zur quantitativen Beantwortung werden die Anzahl der Servicerequests für verschiedene Services definiert. Hier wäre eine Unterteilung der Kennzahl nach einzelnen Services oder nach Komplexität gruppierten Services denkbar. Im Rahmen dieser Arbeit wird von einer Unterteilung nach Komplexität ausgegangen. Wie häufig werden IT-Services angefordert? o Anzahl Servicerequests für Services mit niedriger Komplexität o Anzahl Servicerequests für Services mit mittlerer Komplexität o Anzahl Servicerequests für Services mit hoher Komplexität Um die Frage Wie lange dauert die Bereitstellung von IT-Services? quantitativ zu beantworten, wird die durchschnittliche Bereitstellungszeit, die Standardabweichung der Bereitstellungszeit und der Anteil der Bereitstellungen, die mehr als eine definierten Höchstzeitdauer beanspruchen, erfasst. Die Standardabweichung ist hierbei von Bedeutung, um Informationen über die Streuung der Zeiten zu erhalten. Da Standardisierung der Services eines der Ziele von Cloud Computing ist, sollte hier eine Minimierung angestrebt werden. Auf eine differen-

57 zierte Betrachtung der Services, untergliedert nach ihrer Komplexität, wird hier verzichtet. Sollte eine solche Betrachtung erwünscht sein, können die folgenden Metriken auch separat für die oben definierten Koplexitätsgruppen erfasst werden. Wie lange dauert die Bereitstellung von IT-Services? o Ø Bereitstellungszeit o Standardabweichung der Bereitstellungszeit o Anteil der Bereitstellungen die länger als die Maximalzeit dauern Um Veränderungen in diesem Bereich abschließend zu quantifizieren, wird die aktuelle durchschnittliche Bereitstellungszeit ins Verhältnis zur Baseline-Bereitstellungszeit gesetzt. Verändert sich die Kundenzufriedenheit? o Veränderung der Bereitstellungszeit o Veränderung der Kundenzufriedenheit Metriken der Lern- und Entwicklungsperspektive Im Rahmen der Lern- und Entwicklungsperspektive soll vor allem die Zielstellung, neue Rollen innerhalb der IT zu schaffen, überprüft werden. Als Grundlage ist hierzu die Anzahl der Mitarbeiter innerhalb der IT-Organisation notwendig, um alle anderen Kennzahlen ins Verhältnis setzen zu können. Wie viele Mitarbeiter hat die IT-Organisation? o Anzahl Mitarbeiter Die hierauf aufbauende Frage Wie viel Erfahrung haben die Mitarbeiter in der IT- Organisation? wird zum einen mit der durchschnittlichen Betriebszugehörigkeit der Mitarbeiter gemessen. Da dies allerdings als alleiniges Maß nur wenig Aussagekraft hat, wird die Mitarbeiterfluktuation ebenfalls untersucht. Darüber hinaus könnten noch Kennzahlen wie die Anzahl an Zertifizierungen erhoben werden. Da dies aber die Vergleichbarkeit der Zertifikate und eine einheitliche Fortbildungsstrategie voraussetzt, wird auf diese Kennzahl verzichtet. Wie viel Erfahrung haben die Mitarbeiter in der IT-Organisation? o Ø Jahre Betriebszugehörigkeit o Mitarbeiterfluktuation Um abschließend ermitteln zu können, ob sich die Rollenstruktur innerhalb der IT- Organisation verändert, wird erhoben, wie viele Mitarbeiter der IT bereits Rollen des neuen

58 Rollenkonzepts innehaben. Ein weiterer Indikator der Veränderungen durch Cloud Computing ist das Administrator-Server-Verhältnis. Daher wird dieses als Beispiel einer speziell auf IaaS ausgerichteten Kennzahl definiert. Hat sich die Rollenstruktur verändert? o Anteil der Mitarbeiter mit neuen Rollen o Administrator-Server-Verhältnis Aus diesen Kennzahlen soll im Folgenden die Balanced Scorecard zusammengesetzt werden. 5.5 Entwicklung einer Balanced Scorecard Eine Balanced Scorecard erhält ihre Mächtigkeit als Werkzeug erst dadurch, dass die definierten Kennzahlen in Zusammenhang gesetzt werden und dadurch ein differenzierteres Bild ergeben, als die einzelnen Metriken isoliert voneinander. Daher sollen in diesem Abschnitt vorwiegend die gegenseitigen Einflüsse zwischen den Kennzahlen beschrieben werden. Da die Metriken mittels des GQM-Ansatzes direkt aus den angenommenen operativen Zielen des betrachteten Unternehmens abgeleitet wurden und eine Betrachtung aller Metriken einzeln zu umfangreich wäre, wird ausschließlich untersucht, wie das Erreichen eines der abgeleiteten Ziele die Erreichung der anderen operativen Ziele unterstützt und beeinflusst. Da von einem Unternehmen mit Preisführerschaftsstrategie ausgegangen wird, steht das Ziel der Finanzperspektive Optimierung der Kostenstruktur im Zentrum der Betrachtung. Die Erreichung dieses Zieles bedeutet transparentere Kosten und insgesamt weniger monetären Aufwand für die Kunden der IT-Organisation. Daher wird davon ausgegangen, dass die Erreichung des Ziels der Finanzperspektive positiv auf die Erhöhung der Kundenzufriedenheit wirkt. Im Rahmen der Prozessperspektive liegt nahe, dass eine Reduktion der Prozesskosten unmittelbar positiv auf die Optimierung der Kostenstruktur wirkt. Durch die Reduktion der Prozessanzahl werden die einzelnen Prozesse öfter durchlaufen. Dies ermöglicht eine stärkere Konzentration bei der Optimierung der Abläufe und führt damit zu größeren Erfolgen bei der Prozessoptimierung. Darüber hinaus können Mengeneffekte wirksam werden. Hierdurch können Kostenvorteile entstehen, weshalb die Reduktion der Prozessanzahl positiv auf die Reduktion der Prozesskosten wirkt. Durch die Reduktion der Prozessanzahl sind ebenfalls grobgranularere Rollen nötig, die ein breiteres Aufgabenspektrum abdecken. Daher wirkt die Reduktion der Prozessanzahl ebenfalls positiv auf die Optimierung der Rollenstruktur.

59 Die Optimierung der Rollenstruktur wiederum wirkt sowohl direkt als auch indirekt positiv auf die Optimierung der Kostenstruktur. Die direkte Wirkung entsteht durch eine mögliche Reduktion der Mitarbeiterzahl, beziehungsweise ein günstigeres Ressourcen-Mitarbeiter Verhältnis in der IT-Organisation. Die indirekte Wirkung der Optimierung der Rollenstruktur auf das Ziel der Finanzperspektive entsteht über die Reduktion der Prozesskosten. Diese wird möglich, da durch grobgranularere Rollen weniger Bearbeiterwechsel im Prozessablauf nötig werden. Hierdurch können schnellere Abläufe erzeugt werden, was unmittelbar auf die Reduktion der Prozesskosten wirkt. Eine weitere Wirkung der Optimierung der Rollenstruktur betrifft die Erhöhung der Kundenzufriedenheit. Durch weniger, grobgranularere Rollen ist es für den internen Kunden leichter, den jeweils richtigen Ansprechpartner zu identifizieren und somit seine Bedürfnisse schneller, an der richtigen Stelle zu kommunizieren. Abbildung 8 zeigt, wie sich die Einzelziele aus Kapitel 5.2 zu einem Ursache- Wirkungsdiagramm zusammenfügen. Die Pfeilrichtung, beispielsweise zwischen Reduktion der Prozessanzahl und Reduktion der Prozesskosten zeigt, dass die Reduktion der Prozessanzahl zu einer Verringerung der Prozesskosten führt. Abbildung 8: Ursache-Wirkung Diagramm der Ziele der BSC

60 Die einzelnen Kennzahlen haben jeweils eine Wirkung auf die Zielerreichung der Perspektive, der sie zugeordnet wurden. Das heißt, dass eine positive Entwicklung beispielsweise der Höhe der IT-Ausgaben, positiv auf das Ziel Optimierung der Kostenstruktur wirkt. Die einzelnen Kennzahlen stehen also über ihre Ziele in Zusammenhang. Um zu zeigen, weshalb die Identifikation dieser Zusammenhänge so bedeutsam ist, wird folgender Fall angenommen: Szenario: Die Kundenzufriedenheit ist gesunken. Die Ursache hierfür soll analysiert werden. Analyse: Die Überprüfung der Kennzahlen Höhe der IT-Ausgaben und Höhe der IT- Kostenquote ergibt, dass beide gesunken sind, es wäre daher eine Verbesserung der Kundenzufriedenheit zu erwarten gewesen. Die Überprüfung der weiteren Kennzahlen der Finanzperspektive zeigt ebenfalls ganzheitlich eine positive Entwicklung. Der Anteil an IT-Mitarbeitern mit neuen Rollen ist ebenfalls gestiegen. Aufgrund der Umstrukturierungen ist die Mitarbeiterfluktuation unerwartet hoch gewesen, durch viele Neueinstellungen ist die durchschnittliche Betriebszugehörigkeit der IT-Mitarbeiter ebenfalls stark gesunken. Die negative Entwicklung dieser Kennzahlen der Lern- und Entwicklungsperspektive im Zusammenhang mit der gesunkenen Kundenzufriedenheit deutet darauf hin, dass die IT-Mitarbeiter nicht über das notwendige Wissen beziehungsweise Know-How verfügen, um Kundenbedürfnisse mit einer entsprechenden Qualität zu erfüllen. Ein Interview mit mehreren Fachabteilungen bestätigt diese Vermutung. Mögliche Aktivitäten: Aufgrund der Probleme mit der Servicequalität werden Schulungen zu den einzelnen Serviceprodukten durchgeführt. 6. Fazit Ziel dieser Arbeit war es, ein Bewertungsmodell für Cloud Computing-Lösungen zu entwickeln. Dem Leser wurden hierfür zunächst die einzelnen Bestandteile solcher Lösungen beschrieben, um darauf aufbauend eine Definition für das Phänomen Cloud Computing als Ganzes zu entwickeln. Ausgehend von den Zielstellungen einer Cloud-Lösung wurde im dritten Abschnitt ein System von Architekturbausteinen skizziert und erarbeitet, welche technischen, servicebezogenen und organisatorischen Anforderungen Cloud-Lösungen an ein Unterneh-

61 men stellen. Die im vierten Kapitel analysierten public Cloud-Angebote dienten als Hinführung zur Erarbeitung eines Bewertungsmodells. Im praktisch orientierten Kapitel fünf erhielt der Leser Einblick in die methodische Vorgehensweise zur Kennzahlenentwicklung. Darüber hinaus wurde ein strategisches Steuerungsinstrument für ein exemplarisches Unternehmen erstellt. Aufgrund des Umfangs, der weiteren Entwicklung und Reifung des Paradigmas Cloud Computing kann diese Arbeit nur einen Überblick über die Thematik geben. Eine ganzheitliche Darstellung ist aufgrund der Vielfältigkeit der Wolke nur schwer möglich. Auch die entwickelten Kennzahlen und der public Cloud-Anbietervergleich sind als Momentaufnahmen und Anregung zu verstehen, da für die Kennzahlenentwicklung lediglich ein fiktives Unternehmen verwendet wurde und im public Cloud Computing-Markt aktuell viel Bewegung herrscht. Eine Validierung der entwickelten Balanced Scorecard muss dabei mit realen Kunden erfolgen. Der Fokus lag hierbei klar auf der beschriebenen Methodik und ihrer konsequenten Anwendung. 7. Ausblick Paradigmenwechsel in der Art und Weise wie Unternehmen ihre IT betreiben, haben sich im Laufe der Jahre immer wieder ereignet. Diese waren zum einen durch den technischen Fortschritt und zum anderen durch das wirtschaftliche Umfeld induziert. Im Kontext der aktuellen wirtschaftlichen Entwicklung und des zunehmenden Drucks auf Unternehmen stellt Cloud Computing eine Möglichkeit dar, die eigene Wettbewerbsposition positiv zu beeinflussen. Daher verwundert es nicht, dass mehr als ein Drittel aller Unternehmen plant, Cloud- Lösungen produktiv zu nutzen. Dies deutet darauf hin, dass Cloud Computing in den kommenden Jahren eine weite Verbreitung in der Geschäftswelt finden wird. Gerade in diesem Zusammenhang sind objektive Bewertungsmodelle als Entscheidungsunterstützung von großer Bedeutung. Welche Kennzahlen dabei zukünftig im Fokus stehen, wird immer abhängig von der jeweiligen Unternehmensstrategie sein. Welche Metriken sich dennoch zu Standardgrößen bei der Bewertung von Cloud-Lösungen entwickeln, muss die Zukunft zeigen. Daneben ist die Frage nach einer Standard Cloud-Architektur gegenwärtig noch offen. Trotz der relativ großen Anzahl an Unternehmen, welche plant, Cloud-Lösungen einzusetzen lässt sich zum jetzigen Zeitpunkt nur schwer einschätzen, wie diese Lösungen beschaffen sein werden. Unabhängig davon deutet die derzeitige Entwicklung jedoch darauf hin, dass sowohl public als auch private Cloud-Lösungen die Art und Weise verändern werden, wie Unternehmen ihre IT betreiben.

62 Literaturverzeichnis [1] Alvarez, Gene et al. (2008) Hype Cycle for Software-as-a-Service, 2008, hrsg. von Gartner, Report ID: G , Juli 2008 [2] Armbrust, Michael et al. (2009) Above the Clouds: A Berkeley View of Cloud Computing, hrsg. von The University of California at Berkeley, Februar 2009 [3] Ball, Graham et al. (2008) Hype Cycle for Emerging Technologies, 2008, hrsg. von Gartner, Report ID: G , Juli 2008 [4] Basili, Victor et al. (1994) The Goal Question Metric Approach, hrsg. von University of Maryland und Universität Kaiserslautern, 1994 [5] Bittman, Thomas et al. (2009) Five Refining Attributes of Public and Private Cloud Computing, hrsg. von Gartner, Report ID: G , Mai 2009 [6] Blechar, Michael et al. (2008) Hype Cycle for Application Infrastructure, 2008, hrsg. von Gartner, Report ID: G , Juli 2008 [7] Books24x7 (2009) Analyst Perspectives - Cloud Computing Update, hrsg. von Books24x7, Februar 2009 [8] Bradley, Anthony; Schulte, Roy (2009) Roundup of Reference Architectures for SOA, Web and Cloud Computing Design, hrsg. von Gartner, Report ID: G , April 2009 [9] Bradshaw, David (2009) Western European Software-as-a-Service Forecast, , hrsg. von IDC, Report ID: #LT02R9, April 2009

63 [10] Brett, Paul et al. (2006) Virtualization in the Enterprise, in: Intel Technology Journal, Vol. 10, No. 3, S [11] Brodkin, Jon (2008) Private clouds bring IT mgmt. challenges, in: Network World, Vol. 25, No. 48, S [12] Burns, Charlie et al. (2008a) Clearing the Air on Cloud Computing: Insights from Ten CIOs, hrsg. von Saugatuck Technology, Report ID: MKT-469, Mai 2008 [13] Burns, Charlie et al. (2008b) Cloud Computing: Five Key Issues Framing the Research Agenda, hrsg. von Saugatuck Technology, Report ID: KI-499, August 2008 [14] Buyya, Rajkumar et al. (2008) Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities, hrsg. von Grid Computing and Distributed Systems Laboratory Department of Computer Science and Software Engineering The University of Melbourne, Juli 2008 [15] Caceres, Juan et al. (2008) A Break in the Clouds: Towards a Cloud-Definition, in: SIGCOMM Computer Communication Review, Vol. 39, No. 1, S [16] Casazza, Jeffrey et al. (2006) Redefining Server Performance Characterization for Virtualization Benchmarking, in: Intel Technology Journal, Vol. 10, No. 3, S [17] Cearley, David; Smith, David (2009) Key Attributes Distiguish Cloud Computing Services, hrsg. von Gartner, Report ID: G , März 2009 [18] Cearley, David et al. (2009a) Key Issues for Cloud Computing 2009, hrsg. von Gartner, Report ID: G , Februar 2009 [19] Cearley, David et al. (2009b) Comparing Cloud Computing and Infrastructure Utility, hrsg. von Gartner, Report ID: G , Mai 2009

64 [20] Chappel, Caroline (2008) Preparing for Cloud Computing: The Managed Services Revolution, hrsg. von Heavy Reading, November 2008 [21] Chun, Andy Hon Wai; Wong, Gary Yat Chung (1999) Architecture of Object Web, in: Hui, Lucas Chi-Kwong (Hrsg.); Lee, Dik Lun (Hrsg): Internet Applications: 5th International Computer Science Conference, ICSC'99, Hong Kong, China, December 1999, Proceedings, erschienen im Springer Verlag, Berlin, 1999, S [22] CXO Media (2008) Storage-as-a-Service: Best Efforts or Best Practice?, hrsg. von Iron Mountain Digital, April 2008 [23] Differding, Christiane et al. (1996) Technology Package for the Goal Question Metric Paradigm, hrsg. von Universität Kaiserslautern und Fraunhofer-Institut für Experimentelles Software Engineering, April 1996 [24] Ebel, Nadin (2009) ITIL V3 Basis-Zertifizierung, erschienen im Addison-Wesley Verlag, 1. Auflage, München, September 2009 [25] Feil, Thomas; Tiemeyer, Ernst (2007) Handbuch IT-management: Konzepte, Methoden, Lösungen und Arbeitshilfen für die Praxis, erschienen im Hanser Verlag, 2., überarbeitete Auflage, München, Oktober 2007 [26] Foster, Ian (2002) What is the Grid? A Three Point Checklist, hrsg. von Argonne National Laboratory & University of Chicago, Juli 2002 [27] Gens, Frank; Johnston Turner, Mary (2009) Cloud Computing Drives Break through Improvements in IT Service Delivery, Speed, and Costs, hrsg. von IDC, Report ID: #217961, April 2009 [28] Guptill, Bruce (2008) Cloud Computing: Current Data Gives Shape to User Intent, hrsg. von Saugatuck Technology, Report ID: MKT-522, Oktober 2008

65 [29] Hayes, Brian (2008) Cloud Computing, in: Communications of the ACM, Vol. 51, No. 7, S [30] IBM Corporation (2008a) IBM Perspective on Cloud Computing, hrsg. von IBM, Report ID: OIW03019USEN-00, Oktober 2008 [31] IBM Corporation (2008b) IBM Perspective on Cloud Computing, Armonk, Cloud Computing IBM Point of View.ppt, ohne Datum [32] IBM Corporation (2009a) Seeding the Clouds: Key Infrastructure Elements for Cloud Computing, hrsg. von IBM, Report ID: OIW03022-USEN-00, Februar 2009 [33] IBM Corporation (2009b) DYNAMISCHE INFRASTRUKTUR Zum Aufbau einer smarteren Welt, Armonk, DI_Client_Presentationl_DE.ppt, ohne Datum [34] Iqbal, Majid; Nieves, Michael (2007) Service Strategy, erschienen bei The Stationery Office Ltd, London, Mai 2007 [35] Joyce, Tom (2008) Virtualization: Clouds on the Horizon - Managing Virtualized Data Centers Now and in Future, hrsg. von akorri, August 2008 [36] Kaplan, Robert; Norton, David (1996) The balanced scorecard, erschienen im Verlag Mcgraw-Hill Professional, Cambridge, September 1996 [37] Kontzer, Tony (2008) Send in the Cloud, in: CIO Insight, No. 99, S [38] Kroeker, Kirk (2009) The Evolution of Virtualization, in: Communications of the ACM, Vol. 52, No. 3, S

66 [39] Kurz, Johann (2008) Cloud Computing IT in der «Wolke», in: Netzwoche, 2008 No. 17, S [40] Leclair, Lee (2009) Can cloud computing help your business cut back IT?, in: Inside Tucson Business, Vol. 18, No. 47, S. 14 [41] Lloyd, Vernon; Rudd, Colin (2007) Service Design, erschienen bei The Stationary Office Ltd., London, Mai 2007 [42] Plex Systems (2009) A Software-as-a-Service Primer, hrsg. von Plex Systems, Januar 2009 [43] Plummer, Daryl; Smith, David (2009) Global Class: The Inspiration for Cloud Computing, hrsg. von Gartner, Report ID: G , Januar 2009 [44] Preimesberger, Chris (2008) Creating private clouds, in: eweek, Vol. 25, No. 33, S [45] Rappa, Michael (2004) The utility business model and the future of computing services, in: IBM Systems Journal, Vol. 43, No. 1, S [46] Robertson, Bruce (2009) Top Five Cloud-Computing Adoption Inhibitors, hrsg. von Gartner, Report ID: G , Mai 2009 [47] Staten, James (2008) Is Cloud Computing Ready For The Enterprise?, hrsg. von Forrester, Report ID: 44229, März 2008 [48] Sun Microsystems (2009) Cloud Computing at a Higher Level, hrsg. von Sun Microsystems, Report ID: #GNHT , März 2009

67 [49] VMware (2009) Eight Key Ingredients for Building an Internal Cloud, hrsg. von VMware, Report ID: VMW_09Q2_WP_ Eight_Key_Ingredients_P10_R5, April 2009 [50] Vizard, Michael (2009) How to build private clouds, in: Baseline, No. 95, S. 16 [51] West, Mike (2008) Harnessing the Cloud: A Model for the Emerging Cloud Computing Ecosystem, hrsg. von Saugatuck Technology, Report ID: MKT-508, September 2008

68 Internetverzeichnis [52] Amazon Web Services (2009a) What is AWS?, Juni 2009, abgerufen am , [53] Amazon Web Services (2009b) Amazon Elastic Compute Cloud (Amazon EC2), Juni 2009, abgerufen am , [54] Amazon Web Services (2009c) Amazon EC2 SLA, Juni 2009, abgerufen am , [55] Amazon Web Services (2009d) Amazon Simple Storage Service (Amazon S3), Juni 2009, abgerufen am , [56] Amazon Web Services (2009e) Region and Availability Zone Concepts, Juni 2009, abgerufen am , [57] Barnitzke, Armin (2009) IBM: Cloud Computing ist nicht die Himmelfahrt der IT, sondern eine Bergwanderung - Microsite Cloud Computing - SaaS, April 2009, abgerufen am , &page=2&ms=/cloud-computing/index.html&pos=12&tpid=ee54f3c7-0de1-40f5-bb23-2cfdf022aee5&pid=ee54f3c7-0de1-40f5-bb23-2cfdf022aee5 [58] Conry-Murray, Andrew (2009) There's No Such Thing As A Private Cloud - Plug Into The Cloud, Januar 2009, abgerufen am , theres_no_such.html [59] Eucalyptus Systems (2009) Cloud Myths Dispelled, April 2009, abgerufen am ,

69 [60] Fahlbusch, Klaus-Dieter (2008) SLAs - die Verhandlungsphase - Outsourcing: Kleine Starthilfe für SLAs, , abgerufen am , index.html [61] Fontecchio, Mark (2009) Virtualisierung lässt automatische Provisionieren von Servern Wirklichkeit werden, , abgerufen am , virtualisierung/management/articles/166328/index.html [62] GoGrid (2009a) About the Cloud Hosting Experts, Juni 2009, abgerufen am , [63] GoGrid (2009b) GoGrid Cloud Hosting: Pricing, Juni 2009, abgerufen am , [64] GoGrid (2009c) GoGrid Cloud Hosting: Linux and Windows Cloud Server Images, , abgerufen am , [65] GoGrid (2009d) Cloud Computing API - More control for your GoGrid Cloud Hosting Infrastructure, , abgerufen am , [66] GoGrid (2009e) GoGrid Cloud Hosting: Service Level Agreement, Juni 2009, abgerufen am , [67] Google (2009) Google App Engine - Google Code, Juni 2009, abgerufen am , [68] Happich, Gudrun (2009) Höhere Anforderungen vage formuliert, Juni 2009, abgerufen am ,

70 [69] Herrmann, Wolfgang (2009) Zum Stand der Diskussion um Cloud Computing, April 2009, abgerufen am , [70] IBM Deutschland (2008) IBM - Cloud Computing - Deutschland, November 2008, abgerufen am , [71] Koller, Peter (2008) IDC: Virtualisierung ist in Europa Mainstream, , abgerufen am , &page=1&ms=/virtualisierung/index.html&pos=79&tpid=ee54f3c7-0de1-40f5-bb23-2cfdf022aee5&pid=17313f77-31da-4f bcd430e79bb [72] Kuppinger, Martin (2009) Die Idee der privaten Cloud ist ein Marketing-Hype nicht mehr, Mai 2009, abgerufen am , &pid=ee54f3c7-0de1-40f5-bb23-2cfdf022aee5&page=1&pos=1&ms=/cloudcomputing/index.html&tpid=ee54f3c7-0de1-40f5-bb23-2cfdf022aee5 [73] Laubach, Mark (1993) Minutes of the IP Over Asynchronous Transfer Mode Working Group (ATM), Juli 1993, abgerufen am , [74] Lenz, Ulrich (2007) IT-Systeme: Ausfallsicherheit im Kostenvergleich, Januar 2007, abgerufen am , rgleich/ [75] Manhart, Klaus (2009) Aus SOA Clouds machen, Mai 2009, abgerufen am , [76] New York Times (2001) Internet Critic Takes on Microsoft, August 2001, abgerufen am , efb6a8450a&ei=5070&pagewanted=all#

71 [77] Pevzner, Boris (2007) ITIL v3 Building a successful IT service delivery organization brick by brick, with the Service Portfolio as the cornerstone!, , abgerufen am , [78] Rackspace (2009a) The Story Behind Mosso, Rackspace Cloud Hosting & Our Passions, Juni 2009, abgerufen am , [79] Rackspace (2009b) Cloud Server Pricing from Rackspace Cloud Hosting, Juni 2009, abgerufen am , [80] Rackspace (2009c) Cloud Servers by Rackspace Cloud Hosting Specifications & Technology, Juni 2009, abgerufen am , specifications [81] Rackspace (2009d) Rackspace Cloud Legal, Juni 2009, abgerufen am , [82] Rackspace (2009e) Cloud Files Pricing from Rackspace Cloud Hosting, Juni 2009, abgerufen am , [83] Schaffry, Andreas (2009) Begriffswirrwarr um Cloud Computing, Mai 2009, abgerufen am , [84] Schwarze, Lars (2006) Sourcing: Die Strategie ist das A und O, , abgerufen am , [85] Sommergut, Wolfgang (2009) VDI-Lösung: Neue Hypervisor - Citrix Independence und VMware CVP, , abgerufen am , neue_hypervisor_vdi_citrix_independence_und_vmware_cvp/index6.html

72 [86] The Data & Analysis Center for Software (2009) Goal-Question-Metric (GQM) Approach, Juni 2009, abgerufen am , [87] Thompson, Matt (2009) Behind the Cloud Buzz, Februar 2009, abgerufen am , [88] Zeitler, Nicolas (2007) Kaum Transparenz bei IT-Kosten, Dezember 2007, abgerufen am ,

73 Anhang Anhang I: Entwicklung des Begriffs und der Technologie Cloud Computing Anhang II: Definitionen und Abgrenzung von Cloud Computing Anhang III: Produkte und Anbieter im Cloud Computing-Umfeld Anhang IV: Rahmenbedingungen des Anbietervergleichs Anhang V: GQM-Methodik und Kennzahlendefinition Kennzahlendefinition der Finanzperspektive Kennzahlendefinition der Prozessperspektive Kennzahlendefinition der Kundenperspektive Kennzahlendefinition der Lern- und Entwicklungsperspektive Anhang VI: Interview Cloud Computing Architektur Anhang VII: CD-ROM

74 Anhang I: Entwicklung des Begriffs und der Technologie Cloud Computing In diesem Abschnitt des Anhangs finden sich Darstellungen, welche die Entwicklung der Suchhäufigkeit von Cloud Computing über die Suchmaschine Google illustrieren. Darüber hinaus findet sich hier eine Einschätzung des Hypes um Cloud Computing von Gartner. Abbildung 9: Entwicklung der Suchhäufigkeit und der Anzahl der Erwähnungen des Begriffs Cloud Computing auf Nachrichtenseiten von Januar 2007 bis Mai 2009 (Quelle: in Anlehnung an: abgerufen am )) Abbildung 10: Entwicklung der Suchhäufigkeit und der Anzahl der Erwähnungen der Begriffe Cloud Computing, SOA und CORBA von Januar 2004 bis Mai 2005 (Quelle: in Anlehnung an: abgerufen am )

75 Abbildung 11: Hype Cycle für neue Technologien 2008 (Quelle: in Anlehnung an: [3] Ball, Graham et al. (2008), S. 6)

76 Anhang II: Definitionen und Abgrenzung von Cloud Computing In diesem Bereich des Anhangs findet sich zunächst eine Abgrenzung von SaaS zum klassischen Application Hosting. Da es hierbei vielfach Unklarheit gibt, werden typische Eigenschaften beider Ansätze miteinander verglichen. Darüber hinaus findet sich in diesem Abschnitt eine chronologische Auflistung verschiedener Cloud Computing-Definitionen. Tabelle 15: Vergleich typischer Eigenschaften Application Hosting und SaaS Application Hosting Zahlungsmodell Kaufpreis + monatliche Nutzungsgebühr (nach Nutzung) oder fixe Rate SaaS monatliche Nutzungsgebühr (nach Nutzung) System Design Hardware Betriebssystem Lizenzen Software Lizenzen IT Services: Backups, Patches, Security, Monitoring, etc. Upgrades / Versionsänderungen System Design und Entwicklung Ausschließlich für einen Kunden, gehosted im Rechenzentrum des Anbieters je nach Vertrag, teilweise wird sie vom Kunden beschafft, teilweise ist sie in den Raten bereits enthalten je nach Vertrag, teilweise werden sie vom Kunden beschafft, teilweise sind sie in den Raten bereits enthalten je nach Vertrag, teilweise werden sie vom Kunden beschafft, teilweise sind sie in den Raten bereits enthalten inklusive je nach Vertrag, teilweise werden sie vom Kunden beschafft, teilweise sind sie in den Raten bereits enthalten Wird vom Anbieter als Einzellösung für einen speziellen Kunden durchgeführt Mehrere Kunden, Mehrbenutzersystem inklusive inklusive inklusive inklusive inklusive, für den Kunden transparent einmalig für alle Kunden SW Anpassungen / Customizations Anpassungen sind Einzellösungen für einen Kunden, werden nicht in neuere Releases/Versionen übernommen (Quelle: Eigene Darstellung in Anlehnung an:[42] Plex Systems (2009), S. 4.) Schnelle, dauerhafte Umsetzung durch starke Konfigurierbarkeit der Basisapplikation

77 Tabelle 16: Verschiedene Definitionen für Cloud Computing, chronologisch geordnet Quelle mit Institution [47] Staten, James (2008) (Forrester) [39] Kurz, Johann (2008) (Netzwoche) [12] Burns, Charlie et al. (2008a) (Saugatuck Technology) [3] Ball, Graham et al. (2008) (Gartner) Definition (in Originalsprache, teilweise in Auszügen) A pool of abstracted, highly scalable, and managed compute infrastructure capable of hosting end customer applications and billed by consumption. Die zentralen Eigenschaften [von Cloud Computing] sind die IT-Fähigkeiten wie Infrastrukturservices (Datenbank, Datenspeicher, Rechenleistung) und Applikationsservices ( , Customer Relationship Management CRM), die über Standard-Internetprotokolle orts- und geräteunabhängig bezogen werden können. Cloud Computing encompasses on-demand infrastructure (compute, storage, networking), and on-demand software (operating systems, applications, middleware, management, and development tools), customized dynamically to fit current and immediate business process requirements, along with the ability to deliver and manage those business processes. A style of computing where massively scalable IT-enabled capabilities are delivered 'as a service' to external customers using Internet technologies. [14] Buyya, Rajkumar et al. (2008) (The University of Melbourne) A Cloud is a type of parallel and distributed system consisting of a collection of interconnected and virtualised computers that are dynamically provisioned and presented as one or more unified computing resources based on servicelevel agreements established through negotiation between the service provider and consumers. [15] Caceres, Juan et al. (2008) Clouds are a large pool of easily usable and accessible virtualized resources (such as hardware, development platforms and/or services). These resources can be dynamically re-configured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs. [48] Sun Microsystems (2009) (Sun) At a basic level, cloud computing is simply a means of delivering IT resources as services. Almost all IT resources can be delivered as a cloud service: applications, compute power, storage capacity, networking, programming tools, even communications services and collaboration tools. [49] VMware (2009) (VMware) Cloud computing refers to the use of networked infrastructure software and capacity to provide resources to users in an on-demand environment. [5] Bittman, Thomas et al. (2009) (Gartner) A style of computing where scalable and elastic IT-enabled capabilities are delivered as a service to external customers using Internet technologies.

78 Anhang III: Produkte und Anbieter im Cloud Computing-Umfeld In diesem Abschnitt des Anhang finden sich Grafiken die zeigen, wie die in Kapitel 3.3 Technische Anforderungen entwickelten Cloud Computing-Architekturbausteine von verschiedenen IBM Produkten abgedeckt werden. Darüber hinaus findet sich hier eine Darstellung von Gartner, die zeigt, welche verschiedene Anbieter im Hosting, Infrastructure Utility und Cloud Computing-Markt agieren. Abbildung 12: Abdeckung der Cloud-Architekturbausteine durch IBM Produkte

79 Abbildung 13: Anbieter im Hosting, Infrastructure Utility und Cloud Computing- Umfeld (Quelle: [19] Cearley, David et al. (2009b), S. 5.)