Was Ihre Pipelines über Ihre Organisationsstruktur aussagen

Eines der mit DevOps verbundenen „Gesetze“ stammt von einem Programmierer namens Melvin Conway. Sein Gesetz wurde 1967 eingeführt und besagt schlicht: „Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu erstellen, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.“

Ich habe das Wort „Systeme“ betont, weil Conways Gesetz zu oft nur auf Apps angewendet wird. Zu Softwaresystemen. Tatsächlich jedoch umfassen „Systeme“ alles von Apps bis hin zu den integrierten Pipelines, die diese bereitstellen und einsetzen. Ihre Pipelines.

Wenn wir über die Einführung von DevOps-Methoden auf der Bereitstellungsseite (also der Produktion) sprechen, müssen wir uns auch der damit verbundenen Prinzipien wie dem Conway-Gesetz bewusst sein. Denn dieses Gesetz gilt für die Gestaltung von Bereitstellungspipelines ebenso wie für die Apps, die damit auf den Markt gebracht werden.

Möglicherweise erinnern Sie sich an zwei Fragen aus unserem State of Application Services 2019. Die erste Frage bezog sich auf die Organisationsstruktur der IT – kombinierter Betrieb, Einzelfunktion oder funktionsübergreifende Teams. Wir stellten fest, dass fast die Hälfte (46 %) der über 2.000 Befragten als Teams mit nur einer Funktion organisiert waren. Kombinierte Betriebe belegten mit 37 % einen respektablen zweiten Platz. Funktionalübergreifende Teams sind weniger verbreitet: Nur 15 % der Befragten arbeiten in solchen Strukturen.

Dies ist jetzt wichtig, da wir uns nun mit der Untersuchung des Status der Automatisierung der Bereitstellungspipeline befassen. Denn die Ergebnisse spiegeln eindeutig die Dominanz von Teams mit nur einer Funktion wider.

Die hier dargestellten Daten zeigen einen inkonsistenten Automatisierungsaufwand, der nicht dazu beitragen wird, das Ziel von fast der Hälfte (48 %) der Befragten im Hinblick auf die digitale Transformation zu erreichen – nämlich Apps schneller und häufiger bereitzustellen. Die Ungleichheit zwischen diesen etablierten Domänen innerhalb der IT ist ein existentieller Beweis dafür, dass Conways Gesetz auf jedes System überall anwendbar ist.

Bei genauerem Hinsehen stellen wir fest, dass etwas mehr als jeder Zehnte (11 %) nur eine dieser Domänen automatisiert hat. Jeder Vierte (25 %) hat es geschafft, zwei oder drei Domänen zu automatisieren. Und etwas mehr als jeder Fünfte (21 %) hat alle vier primären Domänen automatisiert, die für die Fertigstellung einer vollautomatischen automatisierte Bereitstellung erforderlich sind.

Ein erheblicher Prozentsatz – 42 % – hat genau NULL dieser Domänen automatisiert.

Die ungleiche Automatisierung der Bereitstellungspipeline ist ein wichtiger Teil des Time-to-Value-Puzzles, denn jedes Mal, wenn Sie in der Pipeline auf einen manuellen Prozess stoßen, kommt es zu einer Verzögerung. Diese Verzögerung verlängert die Wertschöpfungszeit (oder, wenn Sie so wollen, die Markteinführungszeit). Die Unterschiede in den Raten verdeutlichen die Auswirkungen, die es hat, wenn Organisationen in einer „Teamstruktur mit nur einer Funktion“ verharren, denn wir erleben eine Automatisierung einzelner „Silos“, bei der die Interaktion mit dem Rest der Pipeline kaum oder gar nicht berücksichtigt wird.

Aus diesem Grund sind Mischbetriebe bzw. funktionsübergreifende Teamstrukturen zu bevorzugen. Denn die Kommunikationskanäle zwischen den IT-Domänen werden zu einem Peer-Prozess, der die Gestaltung eines Systems, das mehrere Belange umfasst, erleichtert. Wenn eine Pipeline (ein System) von einem Team entworfen wird, kann dieses die Pipeline als Ganzes und nicht nur in ihrer Einzelheit betrachten.

Die Automatisierungsarbeit selbst kann (und sollte wahrscheinlich) von Fachexperten übernommen werden. Aber das Gesamtdesign und die Integrationsmethoden (APIs) müssen in einem offenen, kollaborativen Team entwickelt werden. Andernfalls endet es mit Automatisierungssilos, die dem Geschäftsziel, schneller und häufiger auf den Markt zu kommen, vielleicht dienen, vielleicht aber auch nicht.

Wenn es bei Ihren Versuchen, Produktionspipelines zu automatisieren, zu Verzögerungen oder Umwegen kommt, sollten Sie einen Schritt zurücktreten und die vorhandenen Organisationsstrukturen und deren Auswirkung auf die Gestaltung dieser Pipeline betrachten. Möglicherweise stellen Sie fest, dass Sie sich für effektivere Organisationsstrukturen einsetzen müssen, um die Bemühungen zu unterstützen, bevor Sie etwas effektiv automatisieren können.