Good Practices für den Weg in die Private Cloud

von Michael Kircher, Stefanie Gooren-Sieber und Robertino Solanas
 

Die DATEV eG ist seit 50 Jahren die IT-Genossenschaft der deutschen Steuerberater, Rechtsanwälte und Wirtschaftsprüfer. Ihre zentralen Anwendungen, mit denen Daten von rund 2,5 Millionen meist mittelständischen Unternehmen, Organisationen und Behörden verarbeitet werden, hat sie im Rechenzentrum aufgesetzt. Für die bisher zum Großteil Mainframe- und JEE-basierten Webanwendungen konnte DATEV in der Vergangenheit auf eine hohe Kontinuität bei den Technologielieferanten setzen, beispielsweise bei IBM oder Microsoft. Doch der technologische Fortschritt, die weltweite Open-Source-Gemeinde und die größten IT-Player wie Amazon, Google, Alibaba oder Netflix verändern sowohl die grundlegenden Spielregeln als auch das Tempo der Entwicklung fundamental. Der eine richtige Weg existiert nicht mehr: Das Ausprobieren in kleinen Schritten mit kurzen Feedbackzyklen und sofortiger Reaktion auf Veränderungen ersetzt den langfristigen Plan.

Im Rahmen der eigenen Zukunftsstrategie hat DATEV daher beschlossen, die Anwendungslandschaft sukzessive auf eine Private-Cloud-Infrastruktur zu migrieren. Die Grundlage bildet dabei eine Platform-as-a-Service-Infrastruktur (PaaS) auf Basis von Cloud Foundry. So werden einzelne Anwendungen über Virtualisierung und Containerisierung voneinander isoliert. Dies ermöglicht eine horizontale Skalierbarkeit der Anwendungen und gibt den Entwicklerteams mehr Flexibilität und Autonomie. Wie in vielen anderen IT-Unternehmen waren auch bei DATEV die dafür notwendigen Veränderungen in den Bereichen Infrastruktur, Organisation und Kultur groß.

DATEV hat vor drei Jahren begonnen, im eigenen Rechenzentrum eine Private-Cloud-Infrastruktur aufzubauen und die eigenen Anwendungen sukzessive in die neue Umgebung zu migrieren. Im Vordergrund stehen dabei zunächst die Kernanwendungen im Rechenzentrum, doch auch für Desktop-Anwendungen werden entsprechende Vorbereitungen getroffen. Konkret fiel die Entscheidung für den Aufbau einer Private Cloud auf Basis von Pivotal Cloud Foundry. Mit dieser neuen Plattformarchitektur für Cloud-Anwendungen will man die Vorteile von Cloud-Architekturen nutzen und gleichzeitig für das Unternehmen wesentliche Anforderungen an Datenschutz sowie IT- und Betriebssicherheit sicherstellen. Andererseits wird den Entwicklungsteams ein vorbereiteter, konsistenter Weg in die Cloud-Welt bereitgestellt.

Die neue technische Architektur stellt viele Infrastrukturdienste und Bereitstellungsaufgaben als PaaS zur Verfügung und automatisiert die dahinterliegenden Prozesse. Ein Self-Service-Portal ermöglicht eine automatisierte Infrastruktur-Bereitstellung, beispielsweise zur selbstbestimmten Produktivsetzung von Anwendungen. Der PaaS-Ansatz schafft eine Autonomie, die dem für die jeweilige Anwendung verantwortlichen Team die Fokussierung auf das Endprodukt ermöglicht. Die Self-Services sind darauf ausgelegt, gleichzeitig Nachvollziehbarkeit und Revisionssicherheit zu gewährleisten. Dies erlaubt eine höhere Drehzahl, schnellere und regelmäßigere Lieferungen, aber auch schnellere Fehlerkorrekturen. Alle Maßnahmen zur Qualitätssicherung sind in einem automatisierten Prozess in der Delivery- und Deployment-Pipeline integriert. Dies trägt dazu bei, qualitativ hochwertige Software zum Kunden zu bringen.

Bei der Einführung der Entwicklung von Cloud-native Anwendungen mit Self-Services hat DATEV stark von der engen Zusammenarbeit zwischen Entwicklung und Rechenzentrumsbetrieb profitiert. Einerseits zeigt die Entwicklung frühzeitig auf, was und in welcher Betriebsqualität und -größe sie vom Rechenzentrumsbetrieb erwartet (z.B. Service Level Agreements). Andererseits gibt der Rechenzentrumsbetrieb frühzeitig Hinweise darauf, welche Aspekte (z.B. Monitoring) die Software im Hinblick auf den Betrieb umsetzen muss, damit die Betriebsqualität gewährleistet und verbessert werden kann. Beides erfolgt idealerweise in sehr kurzen Feedbackzyklen.

Die Aufteilung der Betriebsverantwortung für Infrastruktur und Anwendungen impliziert auch eine organisatorische Neuausrichtung. Früher getrennte Bereiche – oft sogar bewusst im Sinne von „Funktionstrennung“ (nach BSI) eingezogen – wurden neu sortiert. Zunächst wurde dazu die Betriebsverantwortung für Infrastruktur (Infrastruktur-Ops) und Anwendungen (Anwendungs-Ops) aufgeteilt: Die Organisation im Rechenzentrum betreibt und entwickelt die Infrastruktur und stellt diese als PaaS für den Anwendungsbetrieb bereit (siehe Grafik 1).

Die Verantwortung für Entwicklung und Betrieb der Anwendungen (DevOps) wird in die Hände der Product Teams gelegt. Nur bei Bedarf werden sie aus dem Rechenzentrum heraus im Anwendungsbetrieb unterstützt. So können Product Teams mit entsprechendem Ops-Skills autonomer agieren und schnellere Reaktionszeiten erzielen. Statt die wichtige Funktionstrennung zwischen Dev und Ops über verschiedene Bereiche zu verteilen, leben die Product Teams diese nun über Rollen und Verantwortlichkeiten. Dies ermöglicht kurze Wege und schnelle Reaktionszeiten. Die Product Teams sind über Rahmenbedingungen und Vereinbarungen (sogenannte Platform Contracts) mit den Plattform-Teams aus dem Rechenzentrum „verbunden“.

In den Product Teams werden somit die bisher in isolierten Teams verteilten Zuständigkeiten und Verantwortlichkeiten für ein Produkt unter Berücksichtigung der vorhandenen Rahmenbedingungen zusammengefasst. Das Team begleitet ein Produkt über den gesamten Lebenszyklus. Das Spannende an der Zusammenarbeit ist die Kombination von Denkweisen, Praktiken und Tools, um als Unternehmen schneller und einfacher Produkte und Services bereitzustellen. Somit ist es sinnvoll, ein Product Team crossfunktional, passend für das jeweilige Produkt, aufzubauen. Sie benötigt also Kompetenzen aus verschiedenen Disziplinen wie Entwicklung, UX-Design, Betrieb, Security und Produktmanagement. Crossfunktionale, multidisziplinäre Teams bilden also die kleinste Einheit der Entwicklung bei DATEV. Das Team muss nicht alles selbst machen. Aber es sollte in der Lage sein, flexibel zu entscheiden, was es selbst leistet und wofür es interne oder externe Dienstleister einsetzt.

Dabei werden in einer Wertschöpfungskette über alle Bereiche die gleichen Werkzeuge für den gleichen Zweck verwendet. Zum Beispiel findet in einer Wertschöpfungskette die komplette Projektplanung und Kollaboration mittels weniger standardisierter und automatisierbarer Werkzeuge statt (siehe Grafik 2). Teams müssen z.B. bei der Anwendungsübergabe, bei notwendigen Datenmigrationen und Nutzung von Subsystemen nicht mehr auf andere warten: keine Formulare, kein Handover, keine engen Change-Fenster, keine Nebeneffekte. Allerdings bedeutet dies zugleich auch mehr Verantwortung für die eigene Anwendung. Die gesamte Wertschöpfung ist als Release- bzw. Deployment-Pipeline realisiert. Diese reicht bis zum Kunden und umfasst an unterschiedlichen Stellen automatisierte Qualitätssicherungsmaßnahmen. Die Pipeline ist das Rückgrat für Continuous Integration, Continuous Delivery und Continuous Deployment.

Die Product Teams arbeiten konsequent nach DevOps-Prinzipien, um zwei vermeintlich konkurrierende Ziele zu erreichen und auszugleichen. Die Entwicklung (Dev) wünscht sich einen hohen Durchsatz an geplanter Arbeit, der Betrieb (Ops) eine stabile, sichere und wirtschaftliche Produktionsumgebung. Hinter beiden Zielen steht der Kundennutzen: Hoher Durchsatz an geplanter Arbeit führt dazu, dass schneller Produkte bzw. Features geliefert werden können, die den Kunden Wert liefern. Eine stabile, sichere und wirtschaftliche Betriebsumgebung ist Voraussetzung dafür, dass die Kunden den gewünschten Wert zu jedem gewünschten Zeitpunkt in der gewünschten Qualität geliefert bekommen. Um hohen Durchsatz an geplanter Arbeit zu erreichen, richtet die Entwicklung ihr Vorgehen konsequent an agilen Methoden aus. Regelmäßig werden neue Produktinkremente erzeugt, die potenziell Wert liefern können.

Durch die schnelle Lieferung von wertschöpfenden Funktionen zum Kunden wird auch schnelles Feedback durch den Kunden ermöglicht. Solange dies nur unzureichend geschieht, werden Fehler oder falsche Einschätzungen erst relativ spät erkannt. Ein kontinuierliches Feedback existiert nicht. Lange Wartezeiten bis zum Release verhindern außerdem kurzfristige, motivationsfördernde Erfolgserlebnisse für die Product Teams. Ist dies nicht gegeben, so sinkt die Bindung und Identifikation der Teams mit dem Produkt. Dies wirkt sich langfristig auf dessen Qualität aus.

Der kontinuierliche Verbesserungsprozess lebt vom Messen und Monitoring der produktiven Systeme, der empirisch erhobenen Kundenzufriedenheit aber auch dem Wirkungsgrad der internen Prozesse der Wertschöpfungskette, der Entwicklungs- und Betriebseffizienz. Die Messungen zeigen auf, ob mit bestimmten Maßnahmen die gewünschten Verbesserungen erzielt werden konnten. Dabei steht nicht im Vordergrund, möglichst viel zu messen, sondern die richtigen und wichtigen Dinge, welche für den Erfolg des Produktes ausschlaggebend sind. Dabei geht es beispielsweise um das Nutzungsverhalten oder Nutzerzahlen und Umsatz eines Produkts. Aber auch die Art und Häufigkeit von Fehlern, die Verfügbarkeit der Anwendungen oder die Performance des Gesamtsystems können hier relevante Themen sein.

Die Architektur-Migration ist nicht nur ein technisches und organisatorisches Projekt, sondern auch eines, dass die Menschen betrifft. Die Einführung von DevOps bedeutet neben der organisatorischen Veränderung auch einen Wandel in der täglichen Arbeit – auch aber nicht nur in der Zusammenarbeit zwischen Softwareentwicklung und Betrieb. Die Grundlagen für diese Veränderungen sind agile Prinzipien und Werte wie z.B. gegenseitiges Vertrauen, stetiger Informationsfluss, eine anhaltende Bereitschaft zum Lernen und die Gründung von interaktiven Kompetenzplattformen (Communities of Practice und Competence Center). Im Kern geht es um den Wandel von funktionsbasierten Teams (Silos) zu produktorientierten Teams mit interdisziplinär aufgestellten Kompetenzen.
    
Ohne spezifisch zugeschnittenes Trainingsprogramm ist der für die Product Teams essenzielle Know-how-Aufbau in einem Unternehmen in der Größe von DATEV schwierig. Für eine Maximierung der Wirkung war es wichtig, skalierende Qualifikationsmaßnahmen zu finden, statt lokale Wissensdefizite zu kompensieren (siehe Grafik 3).

Als ein Baustein zur Begleitung des kulturellen Wandels wurden gezielt Weiterbildungsmaßnahmen entwickelt, die über alle Hierarchieebenen hinweg darauf abzielen, sowohl die notwendigen technologischen Kompetenzen, als auch die kulturellen Prinzipien von DevOps zu vermitteln. Entwickler lernen in zwei Wochen Vollzeittraining den gesamten Technologiestack und die Development-Pipeline von der Planung bis zum Monitoring kennen. Dabei werden sie durch Schlüsselpersonen aus den Unterstützungsrollen (z.B. IT-Security, Architekten etc.), durch praktische Übungen und interaktive Vorträge begleitet. Von den potenziell mehreren hundert Entwicklern, die bei DATEV auf unterschiedlichen Technologiestacks unterwegs sind, haben mittlerweile etwa die Hälfte dieses von DATEV entwickelte gesamtheitliche Trainingsprogramm durchlaufen.

Ergänzend dazu gibt es ein siebenmonatiges Curriculum speziell für Architekten. Darin werden Fähigkeiten und Kompetenzen in den Bereichen betriebswirtschaftliches Knowhow, Anforderungsmanagement, Testsystematik, Architekturplanung und -umsetzung sowie Kommunikation und Führung anhand eines als Architekt zu begleitenden konkreten Projektes trainiert. Weiterhin werden gezielt Themenblöcke zu verschiedenen Soft Skills angeboten, darunter insbesondere Stakeholderanalysen, Führen ohne Macht, Architektur im agilen Prozess sowie Konfliktmanagement.

Die erfolgreiche Transition in die Cloud erfordert nicht nur die nötigen Kompetenzen und die Akzeptanz der Entwickler, sondern auch das Verständnis und die Unterstützung des Managements. Daher gibt es auch für Nicht-Entwickler-Rollen eine zweitägige Schulung zu den Herausforderungen der Transition in die Cloud-Welt. Hierbei werden vor allem prozessuale, organisatorische und kulturelle Themen aufgegriffen und vermittelt.

Freilich ist es mit einer Schulung allein trotz des geschilderten Umfangs nicht getan. Das eigentliche und kontinuierliche Lernen erfolgt „on the job“ – jeder darf und muss „Fehler machen“ dürfen, um effektiv zu lernen. Es ist also sehr sinnvoll, zu teilen was jeder gelernt hat und sich gegenseitig zu helfen. Als weiterer Baustein wurde bei DATEV daher ein interner Wissens-Self-Service analog zu stackoverflow.com ins Leben gerufen, um das klassische Prinzip von Hotlines und Support-Verteilern mindestens zu entlasten, bestenfalls auch abzulösen.

Parallel dazu haben sich bei DATEV vor mehr als 5 Jahren die ersten internen Communities of Practice gegründet. Darin vernetzen sich Kollegen, die ein Thema verbindet, auf unbürokratische Weise. In den Communities finden sowohl gegenseitige Beratung im Sinne von Peer-Sparring, Weiterbildung, der „Blick über den Tellerrand“ als auch einfach Geselligkeit statt. Eine dieser Communities ist die Software Craftsmanship, die das Verständnis von Softwareentwicklung als „Handwerk“ mit entsprechendem Qualitätsanspruch forciert.