Teil 1: Wie Unternehmen am besten unausgesprochene Blockaden beseitigen

DevOoops – zu welchen Fehlern DevOps-Initiativen führen können

Brian Dawson

© Shutterstock / studiostoks

„DevOoops“ ist die ironische Bezeichnung von Fehlern, die bei der Umsetzung von DevOps-Initiativen entstehen können. Dabei ist das oberste Ziel solcher Initiativen die Effizienzsteigerung im Softwarebereitstellungsprozess. Doch nicht immer führen diese zur angestrebten reibungslosen Verknüpfung agiler Software-Entwicklung (Development) mit einem steten, stabilen und sicheren IT-Betrieb (Operations). Die dreiteilige Fachartikelserie DevOoops beleuchtet die Hintergründe je eines „DevOoops“ anhand konkreter Szenarien und gibt dazu passend konkrete Handlungs- und Lösungsempfehlungen. Der erste Beitrag bezieht sich auf nicht-angesprochene Organisationshürden.

Das primäre Ziel von DevOps ist es, die Effizienz im Software-Delivery-Prozess zu steigern. Doch das ist nicht immer umsetzbar, sondern führt manchmal zu Fehlern – beispielsweise im Fall von Abteilungen, die in Silos arbeiten: „Wir sind dafür nicht zuständig“ ist eine klassische Reaktion von Abteilungen, die nicht mit anderen vernetzt sind. Ihnen fehlt der Kontext, um das System als Ganzes zu betrachten und Verbesserungsmöglichkeiten zu erkennen. Dieses kulturelle Problem versucht DevOps zu lösen, indem es diese Silos aufbricht. Viele Unternehmen geben jedoch nur vor, „silofrei“ zu sein – tatsächlich aber schaffen sie bereits das nächste Silo, indem sie eine eigene „DevOps-Abteilung“ ins Leben rufen. Gelebte DevOps steht oft im Widerspruch zur DevOps-Grundidee.

Vor mehr als einem halben Jahrhundert, während der Arbeit an Compilern, traf Melvin Conway den Kern der heutigen Problematik, die mittels moderner Softwareentwicklung und DevOps-Praktiken gelöst werden soll: „Unternehmen, die Systeme entwerfen“, sagte er, „sind oft darauf beschränkt, Entwürfe zu liefern, die lediglich Kopien der Kommunikationsstrukturen dieser Unternehmen sind.“ Dieses Konzept, bekannt als Conway’s Law, schlägt vor, wie das Versäumnis, Silos aufzubrechen und funktionsübergreifende, kollaborative Teams zu organisieren, heute als einer der am häufigsten übersehenen Schritte zur Implementierung von DevOps gilt. Dies resultiert – trotz aller besten Absichten – in dysfunktionaler Software.

Woher aber stammt dieses Problem? Die meisten Unternehmen sind nach Funktionen organisiert – beispielsweise nach Tagesgeschäft, Projektmanagement, Projekt-Ownern, Entwicklern, Qualitätssicherung, App Deployment, Infrastruktur und Sicherheit – die sich alle auf ihre eigenen Fachgebiete konzentrieren. DevOps-Initiativen versuchen, diese Silos aufzubrechen, was einfacher gesagt ist, als getan. Die meisten Unternehmen, die sich auf DevOps einlassen, sehen sich mit einer Mentalität konfrontiert, die am besten mit „wir gegen die“ beschrieben ist.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

Organisatorische Probleme erzeugen jedoch Spannungen, die zu schwierigen, mit Reibungsverlusten verbundenen, Übergaben zwischen den Teams führen. Diese Probleme treten oft im Software-Bereitstellungsprozess sowie in der Software selbst, in Form von Qualitätsunterschieden einzelner Funktionen, inkonsistenter Benutzererfahrung und anderen Problemen auf. Man stelle sich vor, der Input für eine Anwendung stammt aus mehreren, nicht abgestimmten Quellen und die User müssen jeweils unterschiedlich abgestimmte Benutzererfahrung mitbringen. Das bedeutet, wenn nun ein Business Analyst und ein Entwickler eine Kundenanforderung für den Kunden unterschiedlich interpretieren, wird das Endprodukt die Erwartungen nicht erfüllen können.

Ist nun ein Team für Anmeldung und Authentifizierung verantwortlich und ein anderes für die primäre Landing-Page, sieht die Login-Seite unter Umständen komplett anders aus als die eigentliche Startseite der Applikation. Unternehmen müssen sich daher klarmachen, dass ihre Kultur einen direkten Einfluss auf den Erfolg von DevOps hat, weshalb sie gut beraten sind, sich dazu zu verpflichten, diese Herausforderungen offensiv anzugehen. Klar, das wird nicht einfach und braucht seine Zeit – mit Engagement lässt sich diese Herausforderung jedoch gut meistern.

Strategien zur Vermeidung von DevOoops

Hier folgen drei Strategien zur Beseitigung von Organisations-Blockaden und damit zur Vermeidung dieser speziellen „DevOoops“:

Die Ausrichtung

In puncto Ausrichtung geht es um die Organisation realer oder virtueller Teams rund um Produkte, Produktfunktionalität oder einzelne Funktionen und deren optimale Abstimmung. Bestimmte Fähigkeiten und Funktionsgruppen sind hierbei weniger als Kriterien der Team-Organisation geeignet. Ein geeignetes Beispiel aus der Praxis ist ein kleines, agiles Team, das sich um die Middleware kümmert und mit Vertretern aus den Bereichen Business, Entwicklung, Qualitätsmanagement und Betriebsabläufen bestückt ist.

Die Kommunikation

Es ist unerlässlich, Kommunikation, Vertrauen und Transparenz kontinuierlich zu fördern. Dies kann einerseits durch den Einsatz von Echtzeit-Kommunikations-Tools wie „Slack“ erfolgen. Andererseits unterstützt auch die Zentralisierung und gemeinsame Nutzung von Daten (etwa mit Tools wie Jira) den Austausch. Die Teams müssen lernen, das gegenseitige Misstrauen abzubauen. Unternehmen sollten zudem entsprechende Berichtsmechanismen einrichten, die Erfolge und Misserfolge beinhalten – mit dem Ziel, die Qualität des Endprodukts zu verbessern.

Die Inklusion

Ein weiterer Punkt ist die frühzeitige und nachhaltige Integration der wichtigen Interessengruppen. Sobald diese Teams stehen, können die DevOps-Projekte starten. Dabei sollte jeder, der an diesem Software-Projekt beteiligt ist, eine Stimme erhalten. Die Unternehmen müssen ein gemeinsames Verständnis dafür entwickeln, was die individuellen Bedürfnisse der Teams sind, und diese Bedürfnisse aufeinander abstimmen. Dies schafft die Voraussetzung für eine kontinuierliche Zusammenarbeit und effiziente Kommunikation.

Fazit

Zusammengefasst gilt es, die Teams rund um die Themen Produkt und Funktionalität zu organisieren, alle Beteiligten in den Softwareentwicklungsprozess dieser Teams einzubeziehen sowie die schwierigste Aufgabe in diesem Prozess beherzt anzugehen: die Schaffung einer Kultur für DevOps. Diese ist mindestens ebenso wichtig wie die Prozesse, Vorgehensweisen, Tools und Technologien.

Geschrieben von
Brian Dawson
Brian Dawson
Brian Dawson ist DevOps-Evangelist bei CloudBees.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: