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. (hv)