"Global denken, lokal handeln" ist ein Mantra, das gerade in der Klimadebatte wieder gerne bemüht wird. Schließlich landet jedes Gramm CO2, das der umweltbewusste Konsument nicht verbraucht, auch nicht in der Atmosphäre. Lokaler Akt, globaler Impact - eigentlich plausibel.
Foto: Wright Studio - shutterstock.com
Dass die Welt allerdings nicht immer so einfach funktioniert, weiß jeder, der schon einmal einer Diskussion über digitale Transformationsprozesse beiwohnen durfte. Das gilt selbstverständlich und insbesondere auch für das Thema DevOps, das pars pro toto für die digitale Transformation steht beziehungsweise für all die Schwierigkeiten, die damit einhergehen, wenn man das Thema auf einen Grundkonflikt herunterbricht: den zwischen Entwicklung (Anspruch) und Betrieb (Wirklichkeit). Die Übertragung von lokalen Erfolgsprojekten auf eine globale Organisation ist hier nämlich eine Mammutaufgabe, die nur den wenigsten Unternehmen gelingt, wie die Expertenrunde aus sechs Branchenvertretern feststellt, die sich zur Round-Table-Diskussion im Verlagshaus von IDG zusammengefunden hat.
Der Wertekanon der Runde: Barrieren müssen eingerissen, Silos aufgelöst, Brücken geschlagen und Hierarchien abgebaut werden. Denn vor allem aufseiten der Entwicklung wird weitestgehend agil gearbeitet. Das Hauptproblem ist heute die Überführung dieser Agilität in den Betrieb.
Foto: Michaela Handrek-Rehle
In der Entwicklung angekommen
So ist DevOps für Stephan Lange von Accenture nämlich schon heute "in der Breite der Unternehmen angekommen. Der "Dev-Teil" ist dabei weitgehend gelöst, jetzt muss allerdings die Operations-Seite nachziehen. Unternehmen beschäftigen sich zunehmend mit der Frage, wie sie in DevOps ein effizientes Betriebsmodell aufbauen können. Immerhin sind häufig mehr als 60 Prozent der Gesamtaufwände in der IT im Betrieb angesiedelt."
Die Implementierung solcher Betriebsmodelle läuft in den meisten Unternehmen aktuell noch mit zwei Geschwindigkeiten. Vor Ort gibt es bereits viele funktionierende Strukturen, wie Brian Rosenberger von Micro Focus befindet:
"Lösungen, die schon heute in einzelnen Bereichen wunderbar funktionieren, sind im gesamten Unternehmen weitgehend isoliert und oft für eine übergreifende, steuernde Wirkung nicht geeignet. Die große Aufgabe ist es, sicherzustellen, dass die vielen einzelnen (schnell drehenden) Rädchen besser ineinandergreifen."
Rosenberger beschäftigt sich seit über 15 Jahren mit dem Lebenszyklus von Softwareentwicklung in großen und vor allem stark regulierten Unternehmen, also gerade dort, wo DevOps es in der Theorie besonders schwer hat. Ein beliebtes Beispiel ist etwa die BaFin-regulierte Banken- und Versicherungsbranche, wo schnelles Deployment und automatisierte Release-Zyklen gar nicht oder nur sehr eingeschränkt möglich sind, da Produktions- und Testumgebung strikt voneinander getrennt sein müssen.
Informationen zu den Partner-Paketen der ITSM-Studie
Insellösungen verbinden
Doch damit die erwähnte Verbindung all dieser leistungsfähigen kleinen Rädchen gelingt, müssen sie aus der Isolation befreit und prozessual auf breiter Fläche eingebunden werden. Dafür müssen nicht nur rechtliche und regulatorische Hindernisse überwunden werden, sondern vor allem auch prozessuale: Schließlich ist es unmöglich, Agilität einfach per Dekret umzusetzen. Sie muss aktiv und ernsthaft gelebt sowie nachhaltig in den Betrieb überführt werden. Dafür ist es wichtig, Lösungen in Form von ineinandergreifenden Toolchains zu finden, die sich vor Ort - zum Beispiel im Rahmen eines POC - bewährt haben, wie Marc Rosenberg von Neos IT konstatiert:
"Ich bin ein großer Fan davon, einzelne bestehende Insellösungen, von denen es vor allem im Bereich des Betriebes noch immer sehr viele gibt, durch eine übergeordnete Toolchain zu verbinden. Erst dann gelingt die prozessuale Einbettung von Innovationen auf breiter Fläche. Die wichtigste Frage, die es dabei zu klären gilt, ist die nach den richtigen Tools. Hier ist es wichtig, sich geeignete Testfälle auszudenken, um zu verifizieren, ob eine bestimmte Lösung auf kleiner Fläche funktioniert, bevor diese dann im gesamten Unternehmen ausgerollt wird."
Das ist laut Round-Table-Experten vor allem eine Frage für das Management, das "im Daily Business immer weniger mitentscheiden und stattdessen eine Enabler-Rolle einnehmen wird/muss", wie Kathrin Feibel von IBM anmerkt.
Eine Forderung, die für sehr viele Führungskräfte erst mal schwer zu akzeptieren ist. Natürlich sieht sich jeder mehr oder weniger auch heute schon als "Enabler", doch besteht ein deutlicher Unterschied zwischen der Abgabe einzelner Kompetenzen und der fundamentalen - und für viele Manager auch schmerzhaften - Veränderung, die nötig ist, wenn die Verankerung von DevOps im Unternehmen langfristig gelingen soll. Für Stephan Lange ist dies nicht zuletzt auch eine kulturelle Frage:
"In Deutschland besteht immer noch ein Führungsproblem: In Verbindung mit DevOps muss Führung deutlich inhaltlicher werden. Reine Manager sind künftig weniger gefragt. Der Markt verlangt nach mehr Product Ownern und inhaltlicher Führung. Dadurch entstehen zwei Baustellen: An der Basis brauchen wir in den Unternehmen mehr Führungskompetenz und an der Spitze mehr Vertrauen in die Gestaltungsfähigkeit der agilen Teams beziehungsweise einzelner Organisationseinheiten."
DevOps = DevSecOps
Es sind also fundamentale Veränderungen notwendig, für die es zuallererst Vertrauen braucht. Entgegen stehen hier allerdings die altbekannten Sicherheitsbedenken vonseiten der Führungsebene. Die traditionelle Antwort darauf war stets, einen "DevSecOps"-Ansatz zu forcieren, bei dem Security als dritter Faktor zu Entwicklung und Betrieb hinzugefügt wird. Dass dies bei einer konsequenten Umsetzung von DevOps allerdings gar nicht explizit nötig ist, sondern dass DevOps im Gegenteil per se schon einen Security-by-Design-Ansatz darstellt, bemerkt Bastian Braun vom Security-Spezialisten MGM:
"DevOps lässt den blinden Fleck, der früher zwischen "Dev" und "Ops" bestand, verschwinden und ebnet den Weg für Security by Design, indem es die frühzeitige und teamübergreifende Integration von Sicherheit erzwingt. Die Frage nach der Zuständigkeit für einen Sicherheitspatch beispielsweise blieb früher oft unbeantwortet. Bei DevOps geht das hingegen ganz automatisch, weil nur noch ein gesamtes Team als Ansprechpartner fungiert."
Security ist bei DevOps also kein Add-On, das zu einer bestehenden Lösung hinzugefügt wird. Bei einer konsequenten Umsetzung von DevOps ist der "Sec"-Part vielmehr von Anfang an Bestandteil des Entwicklungsprozesses - vorausgesetzt, dass die Mitarbeiter genügend Sensibilität für das Thema mitbringen.
Ohnehin steht und fällt der Erfolg von DevOps im Betrieb mit der Qualifikation der Mitarbeiter, so das Fazit von Marc Rosenberg:
"Die Geschäftsführung kann nicht erwarten, dass Mitarbeiter von heute auf morgen plötzlich DevOps können, nur weil sie eine entsprechende Weiterbildung absolviert haben. Ein Medizinstudent ist schließlich auch nicht sofort nach seinem Abschluss Herzchirurg, sondern muss sich lange in der Praxis bewähren."