Was ist eigentlich DevOps?

DevOps spiegelt in verschiedenen Ansätzen der organisatorischen und technischen Umstrukturierung die Sicht auf die Wertschöpfungskette wieder. Der allgegenwärtige Leitsatz heißt:

„You build it, you ship it, you run it.“, das Zitat von Amazons Chief Technology Officer/Vizepräsident Werner Vogels* von 2006 zielt hauptsächlich darauf ab:

• technische Aspekte hinsichtlich der verwendeten Tools, der angestrebten Automatisierung hochintegrativ in den Wertschöpfungsprozess mit einzubeziehen,
• methodisch Continous-Everything für Integration, Deployment und Delivery anzuwenden,
• die Verantwortlichkeit für die Technologien und die verwendete Methodik in die Entwicklungsteams zu verlagern, sodass diese eigenverantwortlich alle Stellschrauben der Wertschöpfungskette in der Hand haben
• im Wertschöpfungsprozess Stabilität und Transparenz hinsichtlich Störungen und Prozessverbesserungen zu etablieren, sodass agile Entwicklungsmethoden auch in den Prozessen möglich sind.

Bild: Vier Leitaufgaben für DevOps-Teams

Alles zielt darauf ab, Prozesse zu optimieren und die gesamte Verantwortung hinsichtlich Technologie, Methodik und Überwachung des Betriebs in das jeweilige DevOps-Team zu verlangern. Das ist für die Unternehmenskultur ein gravierender Umbruch und eine Herausforderung insbesondere für kleinere Teams. Grundsätzlich ist es ein hilfreicher Ansatz Software schnell und effizient zu entwickeln und dem Kunden bereitzustellen bzw. für diesen zu betreiben.

intersoft-Sicht auf die Wertschöpfungskette

Wir bei intersoft haben einen Rahmen, der den Betrieb der Software für die Produktion ausgrenzt, sodass in der Wertschöpfungskette ein klarer Schnitt erfolgt. Alles andere ist in unserer Veranwortung. Dazu kommt momentan die unterschiedliche Fachlichkeit in den Entwicklungsteams. Es besteht eine Aufteilung in den unterschiedlichen Versicherungsbereichen: Leben, Komposit sowie Provision, Finanzen und allgemein als Querschnitt die Bestandsverwaltung. Das eigentliche große Produkt, ein Monolith der Java-Entwicklung, ist ein Gesamtentwicklungswerk mehrerer Teams. Die Entwicklungsteams sind weder für das Deployment noch für die Auslieferung an den Kunden selbst verantwortlich. Kurzum, es besteht die Problematik, welches Team denn im Sinne des oben genannten Leitsatzes Träger und Verantwortlicher der Wertschöpfungskette ist. Hier gibt es ein weiteres sehr spezialisiertes Team, das die Prozesse und die Bereitstellung sowie die Deployments verantwortet, fachlich aber selbst nicht implementiert.

Ob dieser Ansatz im Sinne von DevOps überhaupt ein DevOps-Ansatz ist, ist jedem selbst in der Beurteilung überlassen. Es gibt allerdings ein paar Schwachpunkte, die aktuell nicht einfach zu lösen sind.

DevOps-Ansätze in die Teams zu verlagern ist schwierig

Problematisch sind die:

• Zuordnung der Verantwortung für Build, Deployment und Bereitstellung,
• Kompetenz des entsprechenden Teams,
• Motivation in den Teams, diese Aufgabe zusätzlich zu übernehmen

Hinsichtlich der Verantwortungsübernahme stellen sich die Fragen: Kann ein Team die Aufgabe annehmen und wie sollte ein Team entsprechend aufgestellt sein, um dies zu können?

Seitens der Kompetenz, die gesamte Infrastruktur für die Produktentwicklung zu verantworten, sowie die einzusetzenden Werkzeuge zu beurteilen, gestaltet sich dies vom Umfang her schwierig. Hoch ausgelastete Teams für fachliche Features haben wenig Zeit sich die notwendigen Kompetenzen im Tagesgeschäft zu erabeiten. Cloud-Technologien, insbesondere on-premise Lösungen wie bei uns, erfordern eine permanente Wartung, Monitoring und Securityanalysen. Der sich rasch wandelnde Markt für die einzusetzenden Werkzeuge im Cloud-native-Bereich ist dabei noch eine weitere Barriere, dies in die Teams zu verlagern.

In der jetzigen Teamkonstellation bleibt dafür in den Entwicklungsteams keine Zeit und kein Raum. Für die Motivation sich auch noch mit diesen Aspekten zu beschäftigen, ist es für manche Entwickler und deren Teams auch zuviel des Guten. Das heisst, die Vermeidung von Kopfmonopolen wird so nicht ausgeschlossen, da sich vermutlich nur wenige Teammitglieder mit dem gesamten Wertschöpfungsprozess ausreichend beschäftigen würden. Dies ist aber genau ein Problem von DevOps, dass es zu vermeiden gilt. Es bedarf eines guten Verständnisses der Prozesse und der zu verwendenden Werkzeuge für die jeweilige Infrastruktur. Ansonsten besteht sehr schnell das Risiko, irgendein Tool aus der großen Vielfalt der Build- und Deploymentwerkzeuge zu wählen, welches aber nicht optimal geeignet ist, den Wertschöpfungsprozess zu verbessern. Und genau darauf zielt DevOps nunmal ab.

DevOps-lessons learned

Insofern ist mein Resümeé für intersoft und die zurzeit bestehende monolithische Softwareentwicklung: Ein spezielles Team in der Hauptverantwortung für die Wertschöpfungskette ist optimal. Sich genau auf diesen Aspekt zu fokussieren, dadurch im engen Austausch mit den Entwicklungsteams die jeweiligen Werkzeuge zu bestimmen und in den Wertschöpfungsprozess zu integrieren, steigert die Wertschöpfung beträchtlich und entlastet gleichzeitig die Entwicklungsteams dabei, sich zusätzlich um diese Aspekte zu kümmern. Vermeidet hier halbherzige DevOps-Implementierung im Unternehmen. Natürlich ist diese Ansicht nicht in Stein gemeißelt, zumal sich das Produkt architektonisch ebenfalls weiterentwickelt. Das ist jedoch ein langer Prozess, der auch von dem Spezialisten-Team mit unterstützt wird. Hier schließt sich der Kreis. DevOps ist sowohl eine Frage der gewünschten Unternehmenskultur im Sinne des Leitsatzes „You build it, you ship it, you run it.“ als auch des zu betrachtenden Produktes. Nicht alle Produkte sind Green-Field-Produkte, da sieht die Lage anders aus.

Quelle:

*Interview von Jim Gray mit Werner Vogels (30.06.2006), URL: https://queue.acm.org/detail.cfm?id=1142065 (Stand: 22.05.23).