Wie Agilität die Enterprise-IT-Organisation verändert

Gut zwölf Jahre ist es her, als eine Reihe namhafter Softwareentwickler das Agile Manifest veröffentlicht hat. Sätze wie "Anforderungsänderungen sind selbst spät in der Entwicklung willkommen" waren Anfang des Jahrtausends eine Revolution für die IT-Welt. Über ein Jahrzehnt später ist es der agilen Idee wie vielen revolutionären Ideen ergangen: Sie ist in der Mitte der Gesellschaft, in diesem Fall in den Unternehmen, angekommen. Scrum und Sprints sind in vielen Projekten eine Selbstverständlichkeit geworden. Je nach Unternehmen, Projektgröße und Komplexität werden die agilen Konzepte mal konsequent und mal abgeschwächt angewendet. In der Regel läuft es auf eine Mischung aus agilen und plangetriebenen Verfahren hinaus. "Gezähmte Agilität" ist das dazu passende Stichwort.

Die zwei Seiten der Agilität

Agilität wirkt dabei in zwei Richtungen: Einmal nach "vorne" in Richtung Anwender, Kunden und Auftraggeber. Um diese Seite der Agilität zu managen, existieren unterschiedliche Methoden und Werkzeuge. So bietet der Interaction Room die passende methodische Unterstützung. Mit seiner Hilfe lassen sich die Hindernisse für agiles Arbeiten aus dem Weg räumen. Fach- und IT-Abteilungen können sich auf ihre Projektziele konzentrieren.

Aber das agile Konzept in der Anwendungsentwicklung wirkt sich auch in Richtung des Betriebs aus: Wenn in kurzen Abständen neue Releases auf produktionsnahen oder sogar produktiven Systemen veröffentlicht werden sollen, ist der IT-Betrieb gefordert. Während früher zwei große Updates jährlich betrieben wurden, gibt heute die agile Entwicklung die Schlagzahl vor. Im Wochenrhythmus oder sogar täglich steht eine neue Version zur Verfügung.

Der IT-Betrieb muss sich dieser Taktung anpassen. Hier kommt es zu einem Zielkonflikt zwischen Development und Operations: Beide Bereiche müssen die Anforderungen des Business schnell und sicher umsetzen. Für die einen bedeutet das, kreativ neue Lösungen zu entwickeln und zu veröffentlichen. Für die anderen, auf Basis fester Strukturen eine stabile Verfügbarkeit zu garantieren. So gesellt sich das Biz zu Dev und Ops.

Um die Situation zwischen Betrieb und Entwicklung zu entspannen, sollten die Verantwortlichen den Hebel an zwei Stellen ansetzen: Auf technischer Ebene geht es um die Automatisierung der Prozesse zur Inbetriebnahme. Auf organisatorischer Ebene um die Bildung von sogenannten DevOps-Teams, also gemeinschaftlich verantwortlichen Arbeitsgruppen, die sich aus Entwicklern und Betriebspersonal zusammensetzen.

Es kann "automatisch" besser werden

Ziel ist es, sowohl die bereitgestellte Software als auch die Entwicklungs-, Test- und Produktivumgebungen automatisiert - sozusagen auf Knopfdruck - zu produzieren und bereitzustellen. Bisher war dieser hohe Automatisierungsgrad in den meisten Organisationen nicht notwendig. Bei wenigen neuen Releases pro Jahr rechnet sich der damit verbundene Aufwand nicht. Gleichzeitig ändert sich mit großer Wahrscheinlichkeit die Struktur der Zielumgebung, wenn zwischen zwei Software-Updates mehrere Monate vergehen. Ein einmal automatisierter Prozess müsste also erneut überarbeitet und an die neuen Strukturen angepasst werden.

Deswegen wird bei solchen eher statischen Rahmenbedingungen in der IT auf "Handarbeit" gesetzt. Dabei ist jeder einzelne Mitarbeiter für den Erfolg des stark taylorisierten Prozesses von Bedeutung. Unvorhergesehene Abwesenheiten, der Verlust von Kompetenzträgern oder unterschiedlich qualifizierte Fachleute sorgen für Probleme im gesamten Prozess. Oder sogar für seinen Stillstand.

Wenn Updates aber nicht im Abstand von Monaten, sondern mehrmals pro Woche, täglich oder bei jedem Freischalten neuen Quellcodes durch den Entwickler veröffentlicht werden sollen, müssen die IT-Betriebsprozesse grundlegend überdacht werden. Jetzt sind Installationsroutinen gefragt, die permanent prüfen, ob veränderte Software in Betrieb genommen werden kann. Die Schlagworte "Continuous Integration" und "Continuous Delivery" beschreiben die Idee dahinter sehr plastisch.

Im Gegensatz zu ersten Ansätzen der Automatisierung bietet die aktuelle Continuous-Delivery-Werkzeugpalette heute vielfältige Möglichkeiten: Das reicht vom Adressieren heterogener Infrastrukturen bis zum automatisierten Bereitstellen von Umgebungen und deren Integration in die vorhandene IT-Infrastruktur (beispielsweise mit Softwarelösungen wie "Puppet" oder "Chef"). Zum Content Delivery gehören auch Tools für die Umsetzung von Monitoring- und Logging-Mechanismen für das automatisierte Testen, das Verwalten von Softwarekomponenten (zum Beispiel "Nexus") und das Orchestrieren des gesamten Prozesses (zum Beispiel "Jenkins"): von der Verfügbarkeit neuen Quellcodes bis hin zu der Inbetriebnahme des entsprechenden Softwareupdates in der Produktivumgebung.

Wie stark Prozesse von einem höheren Automatisierungsgrad profitieren können, zeigt ein Beispiel aus der Versicherungswirtschaft: Bei einem größeren Konzern mussten bislang für die Inbetriebnahme eines Partnersystems zirka zwei Tage veranschlagt werden. Ein relativ langer Zeitraum für ein Softwaresystem, das in der Aufruf-Hierachie eher auf einem unteren Rang liegt. Hinzu kam die Fehleranfälligkeit des Prozesses, ausgelöst durch den hohen Anteil manueller Arbeitsschritte bei der Implementierung. Der Einsatz einer Automatisierungslösung reduzierte den Zeitaufwand um fast 98 Prozent: In weniger als einer Stunde steht das neue System jetzt - bei einer deutlich geringen Fehlerquote des Prozesses - bereit. Die Abbildung "Inbetriebnahme des Partnersystems" zeigt wie diese automatisiert wurde.

Automatisierung wirkt sich an mehreren Stellen positiv auf den Gesamt-Prozess aus. So werden Fehler vermieden, die durch die unterschiedliche Konfiguration von Entwicklungs-, Test- und Produktivumgebungen entstehen. Da diese Fehlerquelle entfällt, wird die Fehlersuche insgesamt erleichtert.

Die Automatisierung des Inbetriebnahmeprozesses verändert die Rolle des IT-Betriebs und die Anforderungen an diesen. Der IT-Betrieb wird zunehmend zu einem Entwicklungsprozess - nämlich des Prozesses zur Entwicklung von Infrastruktur inklusive der darin befindlichen Umgebungen. Das verbirgt sich hinter dem Schlagwort "Infrastructure as Code". Automatisierung bedarf einer formalen Beschreibung der Umgebungen, typischerweise ausgedrückt in sogenannten DSLs (Domain Specific Languages = domänenspezifische Sprachen, beispielsweise angepassten Programmiersprachen) der Automatisierungswerkzeuge.

Die Bereitstellung von Infrastruktur wird zu einem Prozess, der mit den gleichen Methoden und zum Teil sogar den gleichen Werkzeugen unterstützt werden kann wie die Softwareentwicklung. Beispiele dafür sind die Versionierung von Code für die Infrastruktur oder das Entwickeln von Design Patterns für bestimmte Infrastrukturaufgaben wie das Aufsetzen eines Webservers.

Um neue Software schneller, sicherer und fehlerfreier zu veröffentlichen, ist Automatisierung nur ein Ansatz. Auch der passende organisatorische Rahmen, innerhalb dessen Entwicklung und Betrieb zusammenarbeiten, hilft dabei, die gestiegenen Anforderungen an die Geschwindigkeit zu realisieren.

DevOps - das Ende der CIO-Organisation

Bisher war die Aufteilung innerhalb einer IT-Organisation eindeutig: Auf der einen Seite ein Verantwortlicher für die komplette Anwendungsentwicklung. Auf der anderen Seite sein Pendant für den IT-Betrieb. Die Berichtswege beider Manager treffen sich bei einem IT-Verantwortlichen. Fertig ist die klassische deutsche CIO-Organisation. Diese Aufteilung hat sich nicht ohne Grund über Jahre und Jahrzehnte bewährt, sie bringt einige Vorteile mit sich: So müssen Querschnittskompetenzen in Entwicklung und Betrieb nur einmal vorgehalten werden. In Zeiten hochspezialisierter Betriebsprozesse und teurer Hardware wird eine optimale Ressourcenauslastung gewährleistet.

Aber diese Aufstellung der IT bringt auch Nachteile mit sich. Ein Nachteil, der angesichts immer kürzerer Releasezyklen zunehmend ins Gewicht fällt: Die Organisation ist nicht flexibel. Probleme führen dazu, dass erst über mehrere Hierarchiestufen hinweg geklärt werden muss, ob die Software oder der Betrieb der Software fehlerhaft ist. Bei solchen Prüfprozessen geht Wissen über technische und inhaltliche Details verloren. Dieser Know-how-Verlust erschwert die Fehleranalyse. Die Folge sind Systeme, die bei Problemen unnötig lange nicht richtig funktionieren. Aber im Jahr 2013 muss beispielsweise ein Kundenportal permanent erreichbar sein. Eine mobile Anwendung muss ad hoc einen sprunghaften Anstieg der Zugriffszahlen verkraften können.

Die aufbauorganisatorische Lösung dieses Problems ist einfach und heißt DevOps. Dahinter steckt die Idee, dass für bestimmte Anwendungen gemischte Teams aus Development und Operations verantwortlich sind. Kommt es zu Problemen, kümmert sich das ganze Team darum, diese möglichst schnell zu lösen. Denn das Team wird auch an der Verfügbarkeit der Lösung oder des Service gemessen. In DevOps-Organisationen gibt es keine "andere Abteilung" mehr, der im Zweifel der Schwarze Peter zugeschoben werden kann.

In der Praxis gibt es einige Beispiele für die erfolgreiche Umsetzung dieser DevOps-Idee. Das des weltweit größten Online-Buchhändlers kennt wahrscheinlich jeder: den virtuellen Einkaufswagen, in dem die Einkäufe vor dem Bezahlen gesammelt werden. Für die komplette Entwicklung und Bereitstellung dieses Service ist ein Team innerhalb der IT-Abteilung des Internethändlers verantwortlich. Diese Konstellation sorgt dafür, dass es im Problemfall nicht mehr entscheidend ist, ob die Ursache dafür ein Entwicklungs- oder ein Betriebsfehler ist.

DevOps hat seinen Preis und seine Grenzen: Einerseits müssen einige Kompetenzen, ebenso wie einige Querschnittservices, doppelt vorgehalten werden. Das hat Auswirkungen auf die IT-Kostenstruktur. Andererseits agiert auch das DevOps-Team nicht völlig unabhängig: Teilweise werden Commodity-Services wie Datenbanken, Standardhardware und andere Infrastruktursysteme zentral zur Verfügung gestellt. Und spätestens bei den Themen Strom und Klima zeigt sich die Abhängigkeit von anderen Abteilungen.

Je jünger, desto DevOps

Um zu entscheiden, ob und wie DevOps in der Praxis sinnvoll umgesetzt werden soll, müssen die Vor- und Nachteile dieser Organisationsform im Einzelfall genau betrachtet werden. Anhand einiger allgemeiner Indikatoren können jedoch Tendenzen abgeleitet werden, die eher für DevOps oder für die klassische CIO-Organisation sprechen:

• Systeme, die sich nur langsam verändern und kaum strukturellen Anpassungen ausgesetzt sind, sind kein Auslöser für die Einführung von DevOps-Strukturen.

• Ebenso wenig sind Anwendungen DevOps-relevant, die Teil einer hochintegrierten IT-Landschaft sind. Für diese Anwendungen ist es in aller Regel schwierig, Änderungsreichweiten vorherzusagen. Denn bei Anpassungen müssen häufig ganze Landschaften oder zumindest erhebliche Teile im Ganzen eingeführt werden. Die daraus resultierende Komplexität kann für die Gesamtverantwortung eines einzigen Teams zu groß werden.

• DevOps eignet sich für Strukturen mit klaren Trennlinien in der Form nur lose gekoppelter, asynchroner integrierter Dienste. Diese Voraussetzungen sind vor allem in jüngeren Systemen gegeben. Daher sind es insbesondere die oberflächenintensiven und kundensichtbaren Systeme am Anfang ihres Lebenszyklus, die für DevOps geeignet sind.

• Mobile Anwendungen sind fast schon von ihrer Natur aus geeignete Kandidaten für eine DevOps-Organisationsform.

Die Vorteile von DevOps zu nutzen ohne dabei auf die Vorteile der klassischen CIO-Organisation zu verzichten, kann mit organisatorischen Mischformen erreicht werden, die beide Welten kombinieren. Die etablierte CIO-Organisation wird im ersten Schritt nicht komplett umgewandelt, sobald ein Projekt auf der Agenda erscheint, das mehr Flexibilität und Schnelligkeit erfordert. In dieser Situation ist es sinnvoll, ein DevOps-Team aufzubauen und neben die CIO-Organisation zu stellen. Um dies umzusetzen, müssen im Vorfeld einige organisatorische Fragen geklärt werden, beispielsweise: Welche Services werden von dem zentralen Betrieb in Anspruch genommen? Wie weit handelt das DevOps-Team autonom?

Wenn die ersten Erfahrungen mit DevOps positiv waren, führt dies regelmäßig dazu, dass weitere Bereiche innerhalb der IT umstrukturiert werden. Am Ende steht aber nur selten eine reine DevOps-Organisation. Denn in gewachsenen Anwendungslandschaften arbeiten Systeme in unterschiedlichen Phasen ihres Lebenszyklus parallel, hier gibt es sowohl stabile als auch flexible Strukturen. Aus diesem Grund ist es sinnvoll, Mischformen von DevOps- und CIO-Organisation in Kauf zu nehmen. Dies sorgt einerseits für die Einheitlichkeit von Prozessen, garantiert andererseits aber auch die notwendige Flexibilität.

DevOps ist nicht das Ende der Fahnenstange

Mit der gemeinsamen Verantwortung von Entwicklung und Betrieb innerhalb der IT-Abteilung ist das Thema aber noch nicht zu Ende gedacht. Das zunehmende Business Alignment der IT, die wachsende IT-Kompetenz in den Fachabteilungen und die Kommoditisierung des Betriebs sorgen dafür, dass Umstrukturierungen nicht an den Grenzen der IT-Abteilung aufhören.

BizDevOps-Konzepte - Business, Development und Operations wirken bei Softwareentwicklung und -betrieb zusammen - sind heute bereits in Startups verbreitet, die auf die Lean-Startup-Methode setzen. In Zukunft wird BizDevOps auch über diesen Kreis hinaus eine größere Rolle spielen. Der eingangs erwähnte Interaction Room schlägt in Projekten die Brücke zwischen IT-Entwicklung und Business und ist ein Schritt in diese Richtung.

Selbst wenn BizDevOps-Konzepte im Detail zu Lasten von Redundanz, Ressourcennutzung und klar strukturierten Prozessen gehen: Die Gesamtorganisation wird von der schnelleren Entwicklung schlanker Softwaresysteme, die die Anforderungen der Anwender erfüllen, profitieren.