Mit DevOps auf Irrwegen: Sind Unternehmen wirklich so vernetzt wie notwendig?
Autor/Redakteur: Brian Dawson, DevOps-Evangelist und Fachmann bei CloudBees/gg
DevOps kann ohne Übertreibung als eine der einflussreichsten Transformationen in der Softwareentwicklung und -bereitstellung der letzten zwei Jahrzehnten betrachtet werden. Der Ansatz fördert unter anderem eine bessere Zusammenarbeit zwischen Dev- (Development) und Ops- (Operation) Teams, Automatisierung, einen stärkeren Fokus auf die Unternehmenskultur und eine verbesserte Berücksichtigung von Feedback-Schleifen zur Präzisierung der Lieferprozesse.
In der Theorie ist DevOps ein Game Changer. In der Praxis ist sein Nutzen jedoch schwieriger zu definieren. Mit dem Eintritt von DevOps in das Teenager-Alter ist die Idee einer vollständig integrierten Softwarebereitstellungsfunktion, die auf ein gemeinsames Ziel ausgerichtet ist, nämlich Geschäftswert zu generieren, doch eher Illusion als Realität.
Daher stellt sich den DevOps-Teams zunächst die Frage, ob sie selbst so vernetzt sind, wie sie sein sollten. In der Realität neigen Entwickler und operative ITler dazu, ihre eigenen Versionen von „dev DevOps“ und „ops DevOps“ zu haben, die unglücklicherweise innerhalb vermeintlich integrierter Teams gegeneinander arbeiten. Obwohl sie vielleicht Deployment-Pipelines eingerichtet haben, tendieren die einzelnen Parteien dazu, ihre eigenen Tools zu verwenden, auf ihre eigenen Informationen zuzugreifen und ihren eigenen Arbeitsabläufen zu folgen, was zu gelegentlichen verpassten Handoffs und Verzögerungen bei der Softwareauslieferung führt.
Blickt man auf das gesamte Unternehmen, fransen die DevOps-Kulturen weiter aus. Eine perfekte DevOps-Umsetzung bedeutet, dass Teams in verschiedenen Abteilungen, Geschäftsbereichen sowie Regionen alle synchron arbeiten und in einer zuverlässigen Taktung hochwertige Software bereitstellen. In der Realität ist DevOps im Unternehmen nur schwer umzusetzen, da die meisten Unternehmen keine gemeinsame Sprache, keinen einheitlichen Prozess und keine Best Practices für alle Teams implementiert haben, die von der Geschäftsleitung mitgetragen werden.
Zusätzlich besteht die Problematik, DevOps-Abteilungen mit dem Rest der Organisation zu verknüpfen. DevOps per Definition soll an sich das Konzept der Zusammenarbeit auf andere Parteien jenseits der konventionellen technischen Aufgaben erweitern; dazu zählen unter anderem Qualitätssicherung, Tests und Security. Wie also bindet eine DevOps-Kultur die Ziele, Bedürfnisse, Ressourcen und Prozesse anderer Bereiche im Unternehmen ein, die von der Softwarebereitstellung abhängig sind – wie Produktmarketing, Vertrieb und Geschäftsführung?
Bessere Software bereitstellen
Gartner beschreibt DevOps als „schnelle IT-Service-Bereitstellung durch die Einführung agiler, schlanker Methoden im Rahmen eines systemorientierten Ansatzes.“ Mit anderen Worten: schnellere und besser organisierte Bereitstellung. Aber hat DevOps den Software-first-Organisationen geholfen, bessere Software zu entwickeln? Hat der Ansatz ihnen geholfen, die passenden Prozesse einzuführen, um die gewünschte Software in der erforderlichen Geschwindigkeit bereitzustellen und so den größtmöglichen Wert für das Unternehmen zu schaffen? Frei nach einem englischen Sprichwort „Wenn ein Baum im Wald umfällt und niemand da ist, um es zu hören, würde es wirklich ein Geräusch beim Aufschlag geben?“ lässt sich also paraphrasieren: Wenn Unternehmen Software entwickeln und es niemanden gibt, der sie nutzen könnte, wurde dann wirklich ein Mehrwert geschaffen?
