Wie können wir neue Ideen schneller umsetzen? Wie reagieren wir flexibler auf Kundenwünsche und Marktveränderungen? Und wie stellen wir trotz kürzerer Innovationszyklen stabile und fehlerfreie IT-Produkte und -Services sicher? Um in dynamischen Märkten wettbewerbsfähig zu bleiben, muss moderne IT hohen Anforderungen gerecht werden. In diesem Zusammenhang ist immer häufiger von „DevOps“ die Rede – eine Philosophie, die auf ein engeres Zusammenrücken der konkurrierenden Bereiche Produktentwicklung und IT-Betrieb setzt. Aber was genau ist der Grundgedanke der Bewegung, die bei Unternehmen wie Netflix, Walmart, Amazon oder Facebook bereits erfolgreich im Einsatz ist?
Dev & Ops = DevOps: Miteinander statt Gegeneinander
Der belgische IT-Consultant Patrick Debois ahnte im Oktober 2009 nicht, dass die von ihm mitorganisierte Konferenz „DevOps Days“ einen neuen Begriff in der Software-Entwicklung prägen würde. Gemeinsam mit Gleichgesinnten intensivierte Debois die Diskussion um eine effizientere Zusammenarbeit zwischen Entwicklung und Betrieb. Der Durchbruch von DevOps erfolgte 2011, als Analysten von Gartner dem Denkansatz das Zeug zur „Mainstream-Managementtechnik“ attestierten. Nur vier Jahre später kam Gartner in der DevOps-Umfrage 2015 bereits zu dem Ergebnis, dass rund 60 Prozent der Unternehmen die DevOps-Idee einsetzen oder zumindest planen.
Obwohl DevOps in einer technologischen Umgebung geboren wurde, geht es im Kern weniger um ein Framework oder Tool, sondern um eine Unternehmenskultur, die auf Respekt und gegenseitigem Aufgabenverständnis beruht und Silodenken vermeidet.
Der Konflikt zwischen Entwicklung und Betrieb
Aber warum ist die Zusammenarbeit zwischen Entwicklung und Betrieb eigentlich so schwierig? Kurz gesagt ist es das Ziel der Produktentwicklung, die vom Auftraggeber gewünschten Features zeitnah umzusetzen – je mehr Releases, desto besser. Der Betrieb hingegen trägt die Verantwortung für eine stabiles Produkt bzw. einen funktionierenden Service – jeder Release bedeutet Veränderung und damit ein erhöhtes Risiko. Obwohl beide Abteilungen im Grunde für dasselbe Ziel arbeiten – zufriedene Anwender – ist die Kollaboration zwischen Entwicklung und Betrieb traditionell konfliktbelastet.
Der Einsatz agiler Methoden verschärft die Spaltung häufig noch weiter – nämlich dann, wenn Agilität auf das Produktentwicklungsteam beschränkt bleibt. Werden Releases zwar in kurzen Iterationen erstellt, dann aber von Wasserfall-Methoden im Betrieb ausgebremst, verpufft der Mehrwert von Scrum & Co und neues Konfliktpotenzial entsteht. Der Betrieb wird zum „Flaschenhals“, so dass sich Time-to-Market im schlimmsten Fall nicht nennenswert verringert.
Die DevOps Trinity
Bei DevOps geht es aber nicht nur darum, dem IT-Betrieb agile Methoden aufzuoktroyieren, sondern Produkteentwicklung und Betrieb müssen an einen Tisch gebracht werden.
Obwohl es keine verbindliche Definition von DevOps gibt, haben sich in den letzten Jahren drei wesentliche Säulen herauskristallisiert, deren Optimierung zu reibungsloseren Abläufen zwischen den beiden Abteilungen beiträgt:
- Zusammenarbeit („People & Culture“)
Kulturelle Basis von DevOps ist das gegenseitige Vertrauen, ein kontinuierlicher Informationsfluss zwischen Entwicklung und Betrieb, das Teilen von Wissen und Lernbereitschaft, gemeinsame Werte statt Schuldzuweisungen.
- Prozesse („Process & Practices“)
Die Einführung des DevOps erfordert darüber hinaus definierte (schlanke) Prozesse. Ziel ist es, Verschwendung zu vermeiden und Workflows transparenter zu gestalten.
- Automation („Tools & Technologies“)
Alles, was effektiv automatisiert werden kann, sollte auch automatisiert werden. So werden Mitarbeiter von sich wiederholenden Aufgaben befreit, Fehler reduziert und Prozesse optimiert.
Eine ähnliche, aber inhaltlich im wesentlichen vergleichbare DevOps-Definition nach John Willis ist C.A.L.M.S. – ein Konzept, das auf den Komponenten Culture, Automation, Lean, Measurement, Sharing beruht.
Unfriendly Takeover?
Ein häufiges Missverständnis ist die Sorge, dass der Betrieb von der Entwicklung „mit übernommen“ werden soll („NoOps“) oder dass künftig eine Elite an Alleskönnern gesucht wird („Full Stack Developer“). Ja, DevOps-Produktentwickler sollten über ein Breitenwissen verfügen, um die Bedürfnisse im Betrieb verstehen zu können – und umkehrt. Nichtsdestotrotz bleibt die Spezialisierung der Bereiche erhalten, Teams werden vielmehr crossfunktional besetzt, um alle benötigten Fähigkeiten abzudecken.
Fazit: Agilität zu Ende gedacht
Im Zentrum von DevOps stehen die Menschen und die Art und Weise, wie sie zusammenarbeiten. Agilität soll die Grenzen der Produktentwicklung sprengen und abteilungsübergreifend etabliert werden, um ihr volles Potenzial entfalten. Ohne eine entsprechende Unternehmenskultur wird die Einführung von DevOps deshalb zwangsläufig scheitern.
Beitrag teilen
