Kooperation nach dem Gesetz von Conway: Die ideale DevOps-Teamstruktur

12.09.2019Autor / Redakteur: Daniel Gruesso * / Stephan Augsten

Die Zusammenarbeit von Development und Operations verbessert und beschleunigt Prozesse. Doch erst eine wohlüberlegte DevOps-Struktur hilft dabei, dass die beiden völlig unterschiedlichen Bereiche reibungslos miteinander kooperieren.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Gutes DevOps bedeutet nicht, dass jeder den Job des anderen macht – ein Wir-Gefühl ist aber unabdingbar.
(Bild gemeinfrei: NESA by Makers / Unsplash)

DevOps ist zunächst einmal eine tolle Sache. Die nahtlose Zusammenarbeit zwischen Entwicklung und IT-Betrieb wurde entwickelt, damit Silos eliminiert und Teams enger kooperieren können, so dass Software schneller erstellt, getestet und bereitgestellt werden kann.

Das Konzept hat jedoch viel mehr zu bieten, als nur eine Philosophie und eine eingängige Abkürzung. Denn die Strukturkomponente reicht viel weiter, insbesondere dann, wenn man das Gesetz von Conway berücksichtigt. Dieses besagt, dass die Architektur eines Systems gleichzeitig die Kommunikationsstrukturen der Organisation abbildet, die das System umsetzt. Das bedeutet, das Kommunikation essenziell ist, um DevOps zu realisieren.

Die einzige Möglichkeit festzustellen, ob die in einem Unternehmen vorhandene Struktur für DevOps funktioniert, besteht tatsächlich darin, dem Bauchgefühl zu folgen und sich die ehrliche Frage zu stellen: Funktioniert die Zusammenarbeit wirklich? Arbeiten Dev und Ops perfekt zusammen, so dass die Geschäftsziele erreicht oder gar übertroffen werden?

Was das für einzelne Unternehmen im Detail bedeutet, variiert von Fall zu Fall. Deshalb hilft es, verschiedene Modelle in Betracht zu ziehen und zu analysieren. Führt man sich die Vor- und Nachteile der einzelnen Bereiche vor Augen und berücksichtigt dabei das Gesetz von Conway, lassen sich bessere Lösungen für die speziellen Anforderungen der jeweiligen Teams finden.

Grundsätzlich verfolgten Dev- und Ops-Teams in der Vergangenheit eher unterschiedliche Ziele. Die Softwareentwicklung musste schnell erfolgen, der IT-Betrieb war jedoch eher auf Stabilität ausgerichtet. Damit sich aus diesem Gegensatz tatsächlich Vorteile ergeben, müssen bei der Teamstruktur mehrere Faktoren berücksichtigt werden:

Bestehende Silos: Gibt es Produktgruppen/Teams, die unabhängig voneinander arbeiten?

Technische Führung: Wer leitet die Teams und wie ist deren Branchenerfahrung? Haben Dev und Ops die gleichen Ziele oder leiten sich diese von der individuellen Erfahrung der jeweiligen Führungskräfte ab?

IT-Betrieb: Ist der IT-Betrieb vollständig auf die Unternehmensziele ausgerichtet oder wird er nur als Konfiguration von Servern bzw. als Unterstützung des Entwicklungsteams angesehen?

Wissenslücken: Verfügt die Organisation heute über die notwendigen Fähigkeiten und die Humanressourcen, um die DevOps-Struktur zu ändern?

Verschiedene Szenarien der Zusammenarbeit

Damit eine Kultur für DevOps gelingen kann, stehen Kollaboration, Flexibilität und Transparenz im Vordergrund. Doch die Realität sieht oftmals anders aus:

Dev und Ops sind völlig voneinander getrennt

In diesem Fall arbeiten beide Teams in ihrer Blase und haben keinen Einblick in den Arbeitsablauf des jeweils anderen Teams. Durch diese vollständige Separation mangelt es an Zusammenarbeit, Transparenz und Verständnis. Dabei sind genau dies die entscheidenden Faktoren für die Effektivität, die DevOps ausmachen und über die sie verfügen sollten.

Im Wesentlichen läuft dies auf eine gegenseitige Schuldzuweisung hinaus: „Wir wissen nicht, was die anderen dort machen, wir haben unseren Teil geleistet und jetzt ist es an ihnen, dies zu vervollständigen…" An dieser Stelle lohnt sich ein zweiter Blick auf das Gesetz von Conway: In einer solchen Organisation mangelt es nämlich eindeutig an guter Kommunikation.

Letztlich bedeutet das, dass eine Struktur geschaffen worden ist, die genau dies widerspiegelt – und das höchstwahrscheinlich sogar, ohne es zu merken. Das ist eindeutig kein gutes Beispiel für eine gelungene DevOps-Strategie.

DevOps-Mittelsmann

Bei dieser Teamstruktur gibt es immer noch separate Dev- und Ops-Teams, zusätzlich aber auch ein „DevOps“-Team, das als eine Art Moderator beide Seiten miteinander verknüpft. Dieses Konzept kann durchaus eine vorübergehende Lösung sein, mit dem Ziel, Dev und Ops künftig kohärenter zu machen.

Ops steht allein

In diesem Szenario werden Dev und DevOps zusammengeführt, während Ops isoliert bleibt. Solche Organisationen betrachten Ops immer noch als reine Admin und Unterstützung ohne eigenen Wert. Sie leiden jedoch unter grundlegenden Betriebsfehlern und könnten viel erfolgreicher sein, wenn sie den Mehrwert erkennen würden, den Ops mitbringt.

Die Bedeutung der Führung

Angenommen, in einem Unternehmen wird die Dysfunktion zu 100 Prozent durch das Gesetz von Conway bestätigt, so dass die Kommunikation erheblich verbessert werden muss, um auch die DevOps-Struktur zu optimieren. Wie lässt sich das realisieren? Das Geheimnis liegt in der Art und Weise, wie Führungskräfte ihr Team leiten.

Initiativen für Veränderungen in der Organisation sind bekanntermaßen schwierig: Es muss zum einen ein unternehmensweites Buy-in geben, zum anderen müssen sich viele Abteilungen auf eine Vorgehensweise einigen. Veränderungen sind selbst bei den idealsten Szenarien nicht einfach zu implementieren, geschweige denn in Organisationen, in denen die Kommunikation nicht an erster Stelle steht. Einige der wichtigsten Merkmale für ein Scheitern sind:

Widerstand gegen Veränderung

Geringe Veränderungsbereitschaft

Geringes Engagement der Mitarbeiter

Die Transformationale Führung, also die Führung durch konkrete Vorbildfunktion, hat einen direkten Einfluss darauf, wie Teammitglieder auf Veränderungen in Prozessen, Technologien, Rollen und Denkweisen von DevOps reagieren. Wenn es also darum geht, bestimmte Rollen und deren Funktionen zu definieren, empfiehlt das Team von Puppet folgende Maßnahmen:

IT-Manager: Vertrauensaufbau zu Kollegen in anderen Teams, Schaffung eines Lernklimas sowie Freiraum für kontinuierliche Verbesserung, Delegation von Verantwortlichkeiten an Teammitglieder

Entwickler-Manager: Vertrauensaufbau zu Ops, frühzeitiges Einbeziehen in den Planungsprozess

Systemingenieur: Automatisierung schwieriger Prozesse

Qualitätsingenieur: Bereitstellung von Informationen zu Skalierung, Leistung und Staging-Umgebungen

Entwickler: Planung der Bereitstellung neuer Funktionen anhand des Feedbacks von Ops und gemeinsame Zusammenarbeit an Bereitstellungsprozessen

Ops miteinbeziehen

Operations, der IT-Betrieb also, ist eine Disziplin mit eigenen Methoden. Denn nur weil modernes Cloud-Hosting die Bereitstellung von Servern einfacher als je zuvor macht, ohne dass ein Ende eines SCSI-Kabels von einem anderen getrennt sein muss, bedeutet dies noch lange nicht, dass jeder sofort ein Ops-Master ist.

Was Ops für den Software Development Life Cycle (SDLC) bringt, ist Zuverlässigkeit, Leistung und Stabilität. Entwickler können die Produktionsumgebung unterstützen, indem sie ihre Fähigkeiten einsetzen, um Prozesse zu automatisieren. Echte DevOps hingegen spielen die Stärken beider Seiten aus.

Dies bedeutet jedoch nicht, dass Entwickler die Produktion verwalten. Dev und Ops können in direktem Konflikt miteinander stehen, da beide Teams auf sehr unterschiedliche Weise Akzente setzen: einerseits Operationen, bei denen die Verfügbarkeit im Vordergrund steht, andererseits Entwicklung, bei der die Bereitstellung von Funktionen im Vordergrund steht.

In jedem Fall gilt: Verfügbarkeit erfordert Vorsicht, Vorsicht ist das Gegenteil von Geschwindigkeit, aber beide Teams können voneinander lernen und von ihren Erfahrungen profitieren. Ops ist im SDLC also ein Verbündeter und keineswegs ein Hindernis.

Achtung Lücke

Zurück zum Gesetz von Conway: Es ist wichtig, zum einen zu analysieren, wie die Teams kommunizieren und zum anderen, objektiv darüber nachzudenken, was verbessert werden soll und welches Ziel verfolgt wird. Denn Tools allein können kulturelle Probleme nicht überwinden.

Unternehmen haben neue Strukturen eingeführt, um bestimmte Ergebnisse zu erzielen. Sie verstehen die Verbindung zwischen der Organisationsstruktur und der von ihnen erstellten Software. So setzt sich die Struktur von Netflix und Amazon z.B. aus mehreren kleinen Teams zusammen, von denen jedes als kleiner Teil des Systems autonom agiert. Doch Teams mit einer monolithischeren Codebasis können nicht auf diese Weise arbeiten.

Um das DevOps-Modell von Netflix zu übernehmen, müssten auch sie eine Microservices-Architektur verwenden. Microservices und Container ermöglichen ein DevOps-Modell, das schnell iteriert und innerhalb bestimmter Gruppen mehr Autonomie bietet. Entsprechend hat die Architektur der Code-Umgebung einen großen Einfluss auf die Zusammenarbeit von Teams.

Ein idealer DevOps-Lebenszyklus zeichnet sich durch eine Teamstruktur aus, die die Zusammenarbeit und Transparenz zwischen den Dev- und Ops-Teams erleichtert sowie Tools zur Automatisierung von Prozessen bereitstellt. Gutes DevOps bedeutet nicht, dass jeder den Job des anderen macht. Sollten demnach Entwickler Ops beherrschen? Nicht unbedingt.

Viele dachten anfangs, das Ziel von DevOps sei es, die Abteilungen Dev, QA und Ops in einem einzigen Team zu vereinen: Alle müssen alles tun und – boom – es folgt daraus sofort eine Innovation. Es überrascht wenig, dass diese Strategien scheiterten.

Fazit: Spezialisten können einen Mehrwert schaffen, aber ein Mangel an Kohärenz zwischen den Entwicklungs- und Operationsprozessen führt im Laufe der Zeit zu unnötigen Funktionsstörungen. Es sollte nicht ein wir und sie geben – es sollte ein uns geben. Eine Organisation, die auf diese Weise kommuniziert, wird unweigerlich eine Struktur aufbauen, die ähnlich funktioniert. Die ideale DevOps-Teamstruktur ist die, mit der Teams effektiv zusammenarbeiten und die Barrieren zwischen Code und Produktion beseitigen können.

* Daniel Gruesso ist Produktmanager bei GitLab. Er konzentriert sich auf die Infrastruktur- und Operationsfunktionen von GitLab, einschließlich Kubernetes, Serverless und Auto DevOps.

Dieser Beitrag stammt von unserem Partnerportal Dev-Insider.de.