AWS Germany – Amazon Web Services in Deutschland
Das gesamte Unternehmen mit Hilfe eines Cloud-Center of Excellence (CCOE) transformieren
übersetzt und editiert durch Marco Strauss
Große Unternehmen, die sich auf den Transformationspfad begeben, stellen häufig fest, dass sie bereits über Transformationswissen aus Unternehmensbereichen verfügen, was jedoch unbemerkt blieb. Aber warum haben sich die guten Praktiken aus diesen abgelegenen Ecken des Unternehmens nicht verbreitet und den Rest des Unternehmens verändert? Ich denke, die Antwort lautet, dass die Transformation des gesamten Unternehmens… nun ja, eine große Transformation erfordert. Das Unternehmen muss einen Weg finden, seine tiefgreifenden Veränderungen auf breiter Ebene umzusetzen, bis sie eine kritische Masse erreichen. Innovationsabteilungen verfügen in der Regel nicht über den nötigen Einfluss, um einen globalen Wandel herbeizuführen.
In diesem Blogbeitrag spricht Milin Patel, Principal Architect und Mitbegründer von Rearc und früher Head of DevOps von Dow Jones, über die Umstellung von Dow Jones auf die Cloud und DevOps und die organisatorischen Veränderungen, die dieser Wandel ausgelöst hat. Grundlegend für ihre Transformationsstrategie war der Einsatz eines Cloud Center of Excellence (CCOE), um unternehmensweit von dieser Veränderungsinitiative profitieren zu können. Es ist verlockend, sich ein CCOE nur als ein Expertenteam vorzustellen, welches aufgrund seines Wissens über die Cloud hinzugezogen wird. Doch wie Patel betont, kann ein CCOE noch viel mehr sein: Es kann der Motor für Veränderungen im gesamten Unternehmen sein, der Mittelpunkt einer ebenso umfassenden wie tiefgreifenden Transformation — der archimedische Hebel, der die Welt bewegt, oder zumindest das Unternehmen.
Vielen Dank an Milin Patel für diese Anleitung zur Einrichtung eines CCOE, welche organisatorischen Wandel vorantreiben kann.
— Mark Schwartz, Enterprise Strategist bei Amazon Web Services
Aufbau eines Cloud Center of Excellence (CCOE) -Teams zur Transformation Ihrer Technologieorganisation
Von Milin Patel
Über die letzten fünf Jahre hatte ich das große Glück, an einigen IT-Transformationen in Unternehmen beteiligt zu sein. Alles begann bei Dow Jones unter der Leitung von Stephen Orban der damals CIO bei Dow Jones war. Ich hatte die Aufgabe, eine neue Methode zur Entwicklung und Ausführung von Software in der Cloud zu finden. Dow Jones sollte so relevant bleibt und auf die sich ständig ändernde Kundennachfrage eingehen können.
Unser Erfolg bei Dow Jones und Rearc ist größtenteils darauf zurückzuführen, dass wir Entwickler in den Mittelpunkt der Transformation gestellt und sie wie zahlende Kunden behandelt haben. Mein Ziel ist es mit diesem Blogbeitrag Führungskräfte, die ihr Unternehmen transformieren wollen, mit meinen Erfahrungen vom Aufbau und Leitung eines erfolgreichen Center of Excellence (COE) -Teams bei Dow Jones zu inspirieren. Das COE-Team von Dow Jones ermöglichte die Transformation unserer Softwareentwicklungs- und Betriebspraktiken. Diese Geschichte zielt zwar hauptsächlich auf die Einführung von Cloud und DevOps aber der sechsstufige Ansatz, den ich skizziere, kann auch zur Lösung anderer Probleme in Ihrem Unternehmen angewendet werden.
Aus meiner Sicht besteht das Ziel eines Center of Excellence-Teams darin, ein großes, weit verbreitetes, tief verwurzeltes organisatorisches Problem in einem kleineren Umfang mit einem aufgeschlossenen Ansatz zu lösen. Die kleinen Erfolge können dann genutzt werden, um unternehmensweit zu skalieren.
Dow Jones ist ein seit mehr als 125 Jahren tätiges Nachrichten- und Wirtschaftsinformationsunternehmen, das in seiner Fähigkeit, Nachrichteninformationen auf neue Weise bereitzustellen, schn immer innovativ war. Das Vorzeigeprodukt ist die Online-Ausgabe des Wall Street Journal (www.wsj.com), welche seit 1996 besteht. Im Jahr 2013 erlebte WSJ eine große Veränderung im Verbraucherverhalten beim Konsum von Nachrichten und Medieninhalten. Die Leser wollten Nachrichten auf ihren Telefonen, Tablets und anderen vernetzten Geräten Geräten immer und überall konsumieren. Sie erwarteten, dass Dow Jones ein nahtloses digitales Erlebnis auf allen Geräten und Plattformen bietet. Printunternehmen verzeichneten seit Jahren einen langsamen Rückgang, aber plötzlich wurden selbst die digitalen Unternehmen von kostenlosen Nachrichtenseiten, neuen digitalen Konkurrenten und Technologiegiganten herausgefordert. Um den Bedürfnissen ihrer Leser gerecht zu werden, musste Dow Jones neue Produkte, Funktionen und Erlebnisse in einem sehr schnellen Tempo anbieten. Sie mussten schnell experimentieren, lernen und sich anpassen, waren dabei aber einfach zu langsam.
Zu dieser Zeit verfolgte Dow Jones einen Wasserfall-Projektmanagement-Ansatz. Dieser erforderte Planung, Budgetierung und Investitionen im Voraus, bevor die Technologie getestet werden konnte. Darüber hinaus dauerte die Beschaffung und Installation der Rechenzentrumshardware zwischen einem und drei Monaten.
Das spezifische Geschäftsproblem, das wir innerhalb der Technologieabteilung identifiziert und lösen wollten, bestand darin, die Softwarebereitstellung zu beschleunigen und das Experimentieren zu fördern. Die damaligen Methoden von Dow Jones zur Entwicklung und zum Betrieb von Software entsprachen nicht den wachsenden Geschäfts- und Kundenanforderungen. Wir mussten dieses Problem lösen, indem wir unseren Ansatz zur Softwareentwicklung und -bereitstellung grundlegend änderten.
Angesichts dieses Problems und einiger erster Erfahrungen mit der Cloud war Stephen zuversichtlich, dass cloudbasierte Technologien und DevOps-Praktiken notwendige Voraussetzungen für Erfolg waren. Aber wie ändern wir bei einem großen Unternehmen, das an eine bestimmte Arbeitsweise gewöhnt ist, alles, was es über Infrastruktur, Betrieb und Softwarebereitstellung zu wissen glaubt? Zu diesem Zeitpunkt gab es nicht viel Branchenwissen, auf das wir zurückgreifen konnten. Wir dachten, wir müssten weg von Infrastrukturprojekten mit enormen Kapitalkosten und langsamen Lieferzyklen und hin zu einem agilen, auf Softwareentwicklung beruhenden, Cloud-First-Ansatz. Dieser ermöglichte uns, schnell zu iterieren , ohne Angst vor Misserfolgen und finanziellen Risiken haben zu müssen. All dies führte zur Gründung unseres Center of Excellence-Teams bei Dow Jones (intern als DevOps-Team bezeichnet).
Das Leitbild des COE bestand darin, die richtigen Tools und Praktiken zu finden, die es unseren Entwicklungsteams ermöglichen würden, unseren Kunden mit Agilität und Selbstvertrauen großartige digitale Erlebnisse zu bieten. Anstatt es zu zwingen innerhalb der vertrauten und bekannten Grenzen zu arbeiten wurde dem Team die Autonomie eingeräumt, die notwendigen Design- und Prozessentscheidungen zu treffen.
Die Einführung einer Public Cloud war der wichtigste Teil unserer Lösung, um die Agilität der Softwareentwicklung zu gewährleisten. Deshalb mussten wir experimentieren, schnell scheitern und zum nächsten Experiment übergehen, bis wir die richtige Lösung gefunden hatten. Durch die Cloud wurde die undifferenzierte, aufwendige Arbeit abstrahiert, sodass wir uns auf unsere internen Kunden konzentrieren konnten.
Der Zielzustand war klar, aber der Ansatz, wie wir ihn erreichen sollten, wurde erst im Laufe der Zeit entwickelt. Ich hoffe, dass mein sechsstufiger Ansatze einen Weg bietet, den sie auch für Ihre Organisation anwenden können.
Schritt 1: Das Team aufstellen
Das COE-Team sollte klein anfangen. Nach den Erfahrungen die ich mitDow Jones gemacht hatte, wurde mir klar, wie wichtig es ist, die richtigen Leute als Teil des Gründungsteams zu haben. Zu den wichtigsten Eigenschaften, auf die Sie bei den Mitgliedern des Gründungsteams achten sollten, gehören:
• Experimentierfreudigkeit: in der Lage sein, aus Fehlern zu lernen und schnell zu iterieren
• Mut: keine Angst davor haben, den Status Quo in Frage zu stellen
• Ergebnisorientiertheit: kann eine Idee von der Ideenfindung bis zur erfolgreichen Umsetzung begleiten
• Kundenorientiertheit: weiß zu schätzen, wie sich die Produktivität der Entwickler und die betriebliche Exzellenz auswirken auf die Kunden auswirken
• Einfluss: in der Lage sein, Fähigkeiten in der Organisation, auch durch andere, zu verbreiten
Unser COE bestand aus IT Engineers mit ausgeprägten technischen Fähigkeiten und diversen Hintergründen. Das erstklassige Ingenieurtalent dieser Personen verfügt in der Regel über ein gewisses Maß an Vertrauen innerhalb des Unternehmens, was es ihnen leicht macht, einen positiven Einfluss auf den Rest des Unternehmens auszuüben. Ich persönlich denke, dass bestehende Mitarbeiter am besten als Gründungsmitglieder Ihres COE-Teams geeignet sind. Allerdings kann sich auch eine Mischung aus internen und neuen Talenten oder strategischen Partnern kann sich für Ihre COEVorhaben als nützlich erweisen. In unserem Fall brauchten wir Engineers, die sich mit Netzwerken, Systemen und Softwareentwicklung auskennen. Während unser Gründungsteam aus internen Mitarbeitern bestand, kamen in der Folge externe Mitarbeiter sowie Hochschulabsolventen hinzu.
Schritt 2: Erzielen Sie einige schnelle Erfolge
Angesichts der umfassenderen Vision einer Transformation der gesamten Organisation ist es notwendig, den anfänglichen Fokus einzugrenzen, um ein einzelnes, relativ kleines, aber wichtiges Projekt erfolgreich umzusetzen. In unserem Fall war eines unserer ersten Projekte die Migration aus einem Rechenzentrum in Hongkong.
Innerhalb von sechs Wochen migrierten wir das Rechenzentrum von WSJ Asia mithilfe eines Lift-and-Shift-Ansatzes (direkte Verlagerung einer lokalen Anwendung in die Cloud mit minimalen Änderungen) in die AWS-Region Tokio. Das war ein perfekter Start für unser COE-Team — wir mussten das Netzwerk (VPCs, Load Balancing, WAN, Datenreplikation zwischen unseren Rechenzentren in den USA und Tokio), die Maschinenimages (AMIs) in AWS, die Anwendungsleistung, die Netzwerkverkehrsverteilung, das Änderungsmanagement usw. kennen lernen. Das war nur möglich, weil wir die Autonomie hatten, alle notwendigen Entscheidungen für eine erfolgreiche Migration zu treffen.
Der Erfolg unseres ersten Cloud Projektes ermöglichte es uns, unsere Arbeit dem Rest des Unternehmens zu präsentieren. Dies half uns anfängliche Bedenken zum Betrieb einer echten Anwendung in der Cloud zu überwinden. Es gab danach weniger Angst und Unsicherheit in Bezug auf den Betrieb in der Cloud. Es eröffnete einen Dialog darüber, was möglich ist, und nicht darüber, was unbekannt ist.
Schritt 3: Unterstützung durch Führungskräfte sichern
Es ist wichtig, dass die Führungsriege aus dem Technologiebereich dem Rest des Unternehmens eine klare Botschaft über die Herausforderungen übermittelt, mit denen das Unternehmen konfrontiert ist, und wie der Plan zur Bewältigung dieser Herausforderungen aussieht. In unserem Fall haben Stephen und sein Führungsteam keine Gelegenheit verpasst, über die Arbeit des COE zu sprechen. Eine neue Technologie muss zwar unbedingt von der Basis angenommen werden, aber ich bin der festen Überzeugung, dass auch eine klare Vision und Botschaft von der Führung gleich wichtig ist. Für uns haben interne Blogs und Townhall Meetings die Botschaft in der gesamten Organisation verstärkt.
Schritt 4: Erstellen Sie wiederverwendbare Muster und Referenzarchitekturen
Nachdem wir einige Erfahrung mit den ersten Anwendungen in der Cloud gesammelt hatten war klar, dass wir einen einigermaßen wiederholbaren Prozess benötigten, um weitere Anwendungen zu integrieren. In Gesprächen mit mehreren Anwendungsteams kristallisierten sich einige Muster heraus. Wir waren in der Lage, Referenzarchitekturen und Entwürfe zu erstellen, die zwar etwas speziell waren, aber für die Anwendungsteams größtenteils nicht zu beanstanden waren.
Unser COE-Team hat hervorragende Arbeit geleistet. Es hat nicht nur die Referenzarchitekturen erstellt, sondern auch die notwendigen Tools entwickelt, um die Bereitstellung und den Betrieb von Anwendungen, die diese Referenzarchitekturen nutzen, zu automatisieren. Es war für die Anwendungsteams ein verlockender Anreiz ihre Apps schnell zum Laufen zu bringen, während wir die Muster im gesamten Unternehmen standardisieren und den Betriebsaufwand reduzieren konnten.
Schritt 5: Werden sei aktiv und erzeugen sie Begeisterung für die neue Technologie
Nach unseren ersten Erfolgen und der Unterstützung durch die Führungsebene begann der Rest der Organisation, sich zu engagieren und Teil der Transformation zu sein. Das COE-Team nutzte dies. Wir begannen, mit dem Rest der Organisation in Kontakt zu treten, indem wir DevOps Days, Lunch-and-Learn-Workshops, Schulungen (im Rahmen des DevOps University Programs) veranstalteten und Fallstudien erfolgreicher Cloud-Projekte präsentierten. Unsere internen Kunden (Entwicklungsteams) präsentierten ihre Arbeit auf den Veranstaltungen, was eine viel stärkeres Signal war als nur externe Präsentationen. Die Teilnahme von Architekten und Developer-Evangelisten von AWS und Chef sorgte für viel Begeisterung und zeigte, wie ernst wir es mit unseren Transformationsbemühungen meinten.
Schritt 6: Skalieren und Reorganisieren
Sobald Sie einige erste Projekte mit den neueren Ansätzen und Praktiken erfolgreich abgeschlossen haben, sollte der Rest des Unternehmens motiviert sein, die Dienste, Tools und das Fachwissen des COE für ihre spezifischen Bedürfnisse und Probleme zu nutzen.
Sie müssen diesen wichtigen letzten Schritt der Skalierung der COE-Funktion im gesamten Unternehmen sorgfältig planen. In unserem Fall stellten wir etwas spät fest, dass das COE für den Rest des Unternehmens zu einem Engpass bei der Einführung von Cloud- und DevOps-Praktiken geworden war. Schließlich bauten wir übergreifende Teams und DevOps-Funktionen innerhalb der einzelnen Anwendungsteams auf, um die Funktionen des COE zu skalieren.
Fazit
Unser Ansatz, durch die Etablierung eines COE-Teams eine unternehmensweite Transformation in Gang zu bringen, ermöglichte es uns, herauszufinden, was möglich ist und neue Erlebnisse für unsere Kunden in einem Tempo zu implementieren, welches im Unternehmen noch nie zuvor gesehen wurde. Im Jahr 2013 mussten Entwickler Änderungen für WSJ.com and den Build-Tagen (Dienstag und Donnerstag) bis 10 Uhr bei der Qualitätssicherung einreichen. Zehn bis fünfzehn IT-Engineers kamen dann zu einer Telefonkonferenz zusammen, die stundenlang andauerte und oft nicht erfolgreich war. Im Jahr 2016 hatten wir im Laufe des Tages mehr als 100 Bereitstellungen für mehrere Dienste in Produktions- und Nichtproduktionsumgebungen. Niemand hat die Build-Tage vemisst, aber was vielleicht am wichtigsten ist: Die Anzahl der Produktionsvorfälle ging deutlich zurück, die Liefergeschwindigkeit verbesserte sich erheblich und das Vertrauensniveau aller Entwicklungsteams war viel höher. Wir waren in der Lage, mehrere neue Web- und Mobilprodukte für unsere Kunden auf den Markt zu bringen, das Nutzererlebnis und die Leistung unserer Produkte zu verbessern, unsere digitale Abonnementbasis zu erweitern und mit Zuversicht in neue Märkte vorzudringen.
Über die Autoren
Mark Schwartz ist Enterprise Strategist bei Amazon Web Services und der Autor von „The Art of Business Value“ und „A Seat at the Table: IT Leadership in the Age of Agility“. Bevor er zu AWS kam, war er CIO des US Citizenship and Immigration Service (Teil des Homeland Security Ministeriums), CIO von Intrax und CEO von Auctiva. Er hat einen MBA-Abschluss von der Wharton School, einen Bachelor-Abschluss in Informatik von der Yale University und einen Master-Abschluss in Philosophie, ebenfalls von der Yale University. |