"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."
- Kathrin Feibel, IBM
Eine zentrale Frage bei der Einführung von DevOps ist die nach der richtigen Kommunikation. Es ist wichtig, die Zusammenarbeit zwischen verschiedenen Organisationsbereichen zu verstärken und das Entstehen neuer Silos zu vermeiden. Das verlangt auch nach einem neuen Verständnis von Führung. Das Management wird im Daily Business immer weniger mitentscheiden und stattdessen eine Enabler-Rolle einnehmen. - Alexander Bauer, NTT Ltd.
Obwohl DevOps seinen Ursprung in der Softwareentwicklung hat und dort eine klare Daseinsberechtigung besitzt, sind die größten Vorteile, die Bewältigung und Optimierung komplexer Prozesse. Zur Bewältigung komplexer Softwareprojekte mag es nicht der optimale Ansatz sein, aber besonders in kritischen Anwendungen oder Vorfällen führt fehlende Kommunikation mit operativen Eben schnell zu Problemen. Eine engere Verzahnung von Entwicklung und ausführenden Ebenen ist daher eine logische Konsequenz und hilft, Änderungen schneller umzusetzen. - Dr. Bastian Braun, MGM
Wir beobachten häufig ein inkonsistentes Vorgehen bei den Unternehmen: „Agil“ wird dann mit der Möglichkeit verwechselt, sich alle zwei Wochen etwas Neues wünschen zu können. Doch so einfach ist es natürlich nicht. Prozesse müssen fundamental umgebaut und die Grenzen zwischen Fachbereichen abgebaut werden. Wer mit Mitarbeitern aus Unternehmen spricht, die per Dekret „agil“ wurden, merkt, dass das oft Schmerzen verursacht, die im Management so vorher nicht bedacht wurden. - Dr. Christoph Ehlers, Consol
Der Trend zu agilen Methoden ist aktuell vor allem aus der Softwareentwicklung heraus getrieben. Doch die Erfolge, die damit erzielt werden – zum Beispiel eine kürzere Time-to-Market – sorgen auch für einen positiven Druck auf Operations-Seite. DevOps ist letzten Endes genau das: die Erweiterung von Agilität in Richtung Betrieb. Die kommunikative Mauer zwischen Development und Operations muss eingerissen werden. Der Weg dahin ist die Einführung von echten cross-funktionalen Teams unter Einbindung von Development und Operations. - Stephan Lange, Accenture
DevOps ist 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. Konzepte wie der Betrieb in Produktteams oder Googles SRE-Ansatz können Antworten geben – müssen aber an die jeweilige Unternehmenssituation angepasst werden. - Brian Rosenberger, Micro Focus
Beim Thema DevOps tritt der Grundkonflikt zwischen „lokaler“ und „globaler“ Optimierung besonders offen zutage: 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. Unternehmen, denen das wirklich gelingt, sind am Markt noch eher dünn gesät. In vielen Branchen stellt außerdem die Sicherheit ein Hemmnis dar, das in der Praxis nicht einfach ignoriert werden kann. Diese kann nicht einfach im Nachhinein an eine bestehende Lösung „angeflanscht“ werden, sondern muss in jeder Phase in den Entwicklungsprozess integriert sein. - Marc Rosenberg, Neos IT
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."