Ende des Hypes

DevOps ist schon länger ein Trendthema. Trends implizieren stets große Erwartungen. Bei DevOps bestand die Hoffnung darin, dass sich damit wie von Geisterhand die Planungs- und Abstimmungsprobleme zwischen Entwicklung und Betrieb bei der Bereitstellung von Software auflösen würden. Man müsse nur ein paar Tools einführen, etwas besser zusammenarbeiten, ein paar Abstimmungen etablieren und schon gehe es voran. Die Realität aber sieht anders aus. In einer Umfrage des Analystenhauses  Gartner gab ein Großteil der Befragten an, dass DevOps ihre Erwartungen nicht erfüllt hat. Auch Trendmesser wie der Gartner Hype Cycle sehen DevOps als Thema offenbar wieder in der Versenkung verschwinden. Ist das Ganze also erledigt und kehren wir zur Tagesordnung mit den üblichen Zuständigkeiten zwischen den besagten Abteilungen zurück? Auf keinen Fall!

Da DevOps kein Thema ist, das durch einen technischen Ansatz getragen wird, erledigt es sich auch nicht von selbst. An der Notwendigkeit der intensiven Zusammenarbeit hat sich nichts geändert. Die Anforderungen an Software, deren Entwicklung und Bereitstellung haben sich nun einmal grundlegend gewandelt, sodass man die sich daraus ergebenden Fragen nicht mit den Konzepten von gestern beantworten kann. DevOps ist lediglich ein Begriff für eine sich ändernde Arbeitsweise in der IT. Dass diese Änderungen nicht leicht und ohne Reibung erfolgen können, versteht sich von selbst. Änderungsprozesse brauchen Zeit und vor allen die Bereitschaft und Unterstützung des Managements. Gerade größeren Unternehmen mit etablierten Organisationstrukturen und Prozessen fällt ein Wandel, wie ihn die Etablierung von DevOps darstellt, schwer. Gelegentlich wird auch mit den Besonderheiten der deutschen Arbeitskultur argumentiert. Folgende Gründe erschweren aus diesem Blinkwinkel den notwendigen Kulturwandel:

Expertentum statt Generalisten: Das hohe Maß an Spezialisierung wie Programmierer, Administrator, Tester, Architekt ist nicht immer hilfreich in einem DevOps-Team. Die Teammitglieder müssen lernen, auch inhaltlich über den Tellerrand zu blicken. Die Mitarbeiter sollen Experten auf ihrem Gebiet bleiben, aber sich auch für die Belange des gesamten Prozesses öffnen und dafür verantwortlich sein.

Strenge Hierarchien: Teams haben eine kaum ausgeprägte Hierarchie. In DevOps-Teams sollen die Mitglieder vertrauensvoll zusammenarbeiten. Etablierte Hierarchien sind hinderlich. Führungskräfte müssen in der Lage sein, die Dev­Ops-Transformation voranzutreiben. Wichtig sind Experimentierfreude, visionäres Denken und Inspiration der Teammitglieder.

Bürokratie: Was nicht dokumentiert ist, existiert nicht. Unternehmen, die diesem Credo folgen, werden es schwer haben, eine schnittstellenlose Zusammenarbeit zu etablieren. Es geht nie um formale, sondern stets um inhaltliche Fragen. Bürokratische Hürden, zum Beispiel interne Dokumentationen, sollten auf ein minimales Maß reduziert werden.

Perfektionismus: Die kurzfristige und regelmäßige Auslieferung von Software hat das Ziel, den Kunden schnell an der Weiterentwicklung des Produkts teilhaben zu lassen. Der Grundgedanke lautet: Die Vorteile eines schnellen Releases sind größer als die möglichen Nachteile, dass die aktuelle Version noch nicht vollständig ausgereift ist. Kleinere Fehler im Betrieb werden wiederum durch das nächste kurzfristig folgende Update behoben.

Diese Vorgehensweise kann dem traditionellen Anspruch und der lange gepflegten Praxis widersprechen, dass man nur umfassend erprobte Produkte zum Kunden gibt. Kunden und Anbieter müssen lernen, dass die Teilhabe an frühen Innovationen im Wettbewerb oft mehr wiegt als ein ausgereiftes, aber veraltetes Produkt.

Die Punkte unterstreichen, dass DevOps eine Aufgabe des Managements ist und kein technischer Ansatz. Der Lernprozess muss auch deswegen von der Entscheiderebene aus ini­tiiert werden, sonst bleibt er stecken.