| Inhaltsverzeichnis | 5 |
| 1Einleitung | 9 |
| 1.1 Ohne Automatisierung keine Perfektion | 9 |
| 1.2 Cloud ist Zukunft | 11 |
| 1.3 Dank Hyperkonvergenz zur IT aus der Steckdose | 11 |
| 1.4 Mit geballtem Know-how Meilensteine setzen | 12 |
| Literatur | 13 |
| 2Herausforderung für IT-Betreiber | 15 |
| 2.1 Das Cloud-Paradigma | 15 |
| 2.2 Wirksamkeit und Effizienz der IT | 19 |
| 2.3 Den richtigen (IT-)Partner finden | 21 |
| 2.4 Standortbestimmung | 22 |
| 2.5 Optimierungsziele | 24 |
| 2.6 Fazit | 27 |
| 3 Standardisierung als erster Schritt in dieEinfachheit | 30 |
| 3.1 Die Situation: gewachsene IT-Strukturen | 30 |
| 3.2 Standardisieren – warum? | 31 |
| 3.3 Dynamische IT braucht ein Standardfundament | 32 |
| 3.4 Allgemeine und interne Standards | 33 |
| 3.5 Beispiel Tankstellenkette | 34 |
| 3.6 Make or Buy – IT-Strategie stellt die Weichen | 35 |
| 3.7 Unterschiedliche Ausgangssituationen: Neuaufbau oder Transformation? | 37 |
| 3.8 Standardisierung der Governance am Beispiel des Security Management | 42 |
| 3.9 Fazit | 42 |
| Literatur | 43 |
| 4 Konsolidierung: Offensive für moderne,flexible Strukturen | 45 |
| 4.1 Einführung | 45 |
| 4.2 Größe und Gemeinsamkeiten nutzen: Potenziale der Konsolidierung | 46 |
| 4.3 Ressourcen besser auslasten: Vorteile der Virtualisierung | 47 |
| 4.4 Da ist mehr drin: Auslastung optimieren | 48 |
| 4.5 Ziele festlegen: Weniger bringt mehr, lautet die Devise | 50 |
| 4.6 Scope definieren: mit Blick über den Tellerrand | 50 |
| 4.7 Echte Bedingungen schaffen: Proof of Concept/Szenarien | 51 |
| 4.8 Bestehendes bestens nutzen: Standards und technische Rahmenwerke | 52 |
| 4.9 Auf der sicheren Seite: Qualität zählt | 53 |
| 4.10 Einmal ist nicht genug: Konsolidierung als fortlaufender Prozess | 53 |
| 4.11 Systematisch, richtig, gut: Konsolidieren mit Programm | 54 |
| 4.12 Das A und O für den Erfolg: die Messmethoden | 54 |
| 4.13 Wissen, worauf es ankommt: Konzeption und Migration im Detail | 55 |
| 4.14 Mit weniger Aufwand mehr erreichen – Migration-as-aService (MaaS) | 57 |
| 4.15 Das große Ganze im Visier: effiziente Rechen-zentrumslandschaft | 58 |
| 4.16 Fazit | 59 |
| Literatur | 60 |
| 5Automatisierung als notwendiger nächster Schritt | 62 |
| 5.1 Standardisierung und Konsolidierung ebnen den Weg zur Automation | 62 |
| 5.2 Was ist Automation? | 63 |
| 5.3 Nutzen der Automatisierung | 65 |
| 5.4 Rolle der Configuration Management Data Base | 66 |
| 5.5 Stufen der Automatisierung/Reifegrad | 68 |
| 5.6 Tools für Automatisierung | 71 |
| 5.7 Automatisierung einführen | 73 |
| 5.8 Automatisierung leben | 74 |
| 6Die Hebelwirkung von Automatisierung beim Cloud Computing | 76 |
| 6.1 Einführung und Kontext | 76 |
| 6.2 Begriffsdefinitionen und -abgrenzungen | 77 |
| 6.2.1 Cloud Computing vs. Nutzung von Cloud-Technologie im eigenen RZ | 77 |
| 6.2.2 Automatisierung | 79 |
| 6.3 Domänen der Automatisierung im Rechenzentrumsbetrieb | 80 |
| 6.4 Auswirkung der Automatisierung | 82 |
| 6.4.1 Nutzen der Automatisierung im eigenen RZ | 82 |
| 6.4.2 Zusätzlicher Nutzen bei Bezug von Cloud-Services | 83 |
| 6.4.3 Self-Service unterstützt mündige Anwender | 86 |
| 6.5 Herausforderungen in der Praxis | 87 |
| 6.5.1 Auswahl geeigneter Werkzeuge | 87 |
| 6.5.2 Vermeidung providerspezifischer Werkzeuge | 88 |
| 6.5.3 Geänderte Erwartungshaltung auf Anwenderseite | 88 |
| 6.5.4 Verständnis Cloud-spezifischer Anforderungen an Anwendungen | 89 |
| 6.5.5 IT-Finanzprozesse | 90 |
| 6.6 Ausblick | 92 |
| 6.6.1 Naht das Ende des redundanten Active-Active-Datacenters? | 92 |
| 6.6.2 Container und Agnostizität | 92 |
| 6.6.3 Continuous Delivery | 92 |
| Literatur | 93 |
| 7Automation dynamischer Cloud-Portfolios mit CAMP | 96 |
| 7.1 Einleitung | 96 |
| 7.2 Dynamische Bereitstellung von IT-Infrastrukturen bei T-Systems | 97 |
| 7.2.1 Die Cloud bei T-Systems | 98 |
| 7.2.2 Automation bei T-Systems | 100 |
| 7.3 Herausforderungen bei der Automation dynamischer Cloud-Produkte | 102 |
| 7.3.1 Erfassung der Prozedere und organisationsweite Standardisierung | 103 |
| 7.3.2 Übergaben als kritische Größen für IT-Service-Prozesse | 106 |
| 7.3.3 Evaluation und Selektion adäquater Technologien | 107 |
| 7.3.4 Effektives Availability& Continuity-Management | 108 |
| 7.4 Automation bei T-Systems am Beispiel von CAMP | 108 |
| 7.4.1 Designprinzipien von CAMP | 109 |
| 7.4.2 Die zentrale Workflow Engine | 111 |
| 7.4.3 Die Datendrehscheibe eCMDB | 111 |
| 7.4.4 Das Konfigurationsportal | 113 |
| 7.4.5 Lokale Tech Bases | 114 |
| 7.5 Best Practice: Empfehlungen und Erfahrungswerte aus CAMP | 115 |
| 7.5.1 Eindeutige Zieldefinition | 115 |
| 7.5.2 Frühzeitig enge Zusammenarbeit | 115 |
| 7.5.3 CMO und FMO im Fokus behalten | 116 |
| 7.5.4 Klare Zielgruppenidentifikation | 116 |
| 7.5.5 Definierte Eckwerte und Variantensparsamkeit | 116 |
| 7.5.6 Eindeutige Projektdimensionen | 117 |
| 7.6 Fazit | 118 |
| 8Schlusswort | 120 |
| 8.1 Dreiklang aus Automatisierung, Standardisierung und Konsolidierung | 120 |
| 8.2 Der richtige Weg durch das Automatisierungsdickicht | 121 |
| Literatur | 122 |
| Herausgeber | 123 |
