Moderne Anwendungsbereitstellung im Unternehmen Organisatorische Aspekte der DevOps-Kultur

Autor / Redakteur: Christian Rentrop / Stephan Augsten

DevOps vereint Prozesse, Technologie und Mitarbeiter. Um den DevOps-Gedanken optimal durchzusetzen, ist es sinnvoll, die Organisationsstruktur in Unternehmen neu auszurichten und für eine regelrechte „DevOps-Kultur“ im Unternehmen zu sorgen.

Firmen zum Thema

Ein solides DevOps-Team ist cross-funktional und mit Expertise aus den verschiedensten Unternehmensbereichen ausgestattet.
Ein solides DevOps-Team ist cross-funktional und mit Expertise aus den verschiedensten Unternehmensbereichen ausgestattet.
(Bild: Free-Photos / Pixabay )

Das Schlagwort DevOps bezeichnet eine deutlich engere Zusammenarbeit von Softwareentwicklung und IT-Betrieb. Statt zuvor klar getrennter Abteilungen gilt es, eine möglichst große Schnittmenge zwischen den einzelnen Bereichen zu schaffen, um maximale Synergieeffekte zu erzielen.

In vielen Unternehmen bleibt es jedoch beim bloßen Buzzword-Bingo: Man spricht von DevOps, meint aber eigentlich nur eine bessere Produktqualität. Gerade in Deutschland ist es oft nicht einfach, die Strukturen in Unternehmen oder Fachbereichen zu ändern – doch genau das ist notwendig, um eine effiziente DevOps-Kultur einzuführen.

Es gibt verschiedene Ansätze, die DevOps-Kultur im Unternehmen zu etablieren. Allerdings sind diese nicht selten zum Scheitern verurteilt, wenn die traditionelle Unternehmensstruktur nicht vollständig neu konzeptioniert wird.

Bestehende Trennungen der Fachabteilungen müssen eingerissen, die Organisationsstruktur optimiert, Hierarchien neu gedacht und Abläufe überarbeitet werden. Das ist ein nicht selten schmerzhafter Prozess. Gerade in Software-Unternehmen, die bereits lange existieren, hat es der DevOps-Gedanke daher schwerer, als es sein müsste.

DevOps in der Praxis: Von jedem etwas

Letztlich bedeutet DevOps, dass die Verzahnung der Abteilungen Development und IT-Operations, also Entwicklung und Betrieb, deutlich verbessert wird. Allerdings ist DevOps deutlich mehr als nur eine Verzahnung dieser beiden Bereiche. Ein solides DevOps-Team ist cross-funktional und mit Expertise aus den verschiedensten Unternehmensbereichen ausgestattet.

Neben der Entwicklung und dem IT-Betrieb sollten auch Kenntnisse aus den Bereichen Qualitätsmanagement, Marketing und Business-Development mit an Bord sein, um ein holistisches Umfeld zu schaffen. Dessen Ziel steht von vornherein fest: Es soll das bestmögliche Produkt entwickelt werden.

Synergiepotenzial nutzen

Leider ist es nach wie vor in vielen Unternehmen Usus, Produkte von A nach B nach C durchzureichen. Das schafft unnötige Schleifen bei der Entwicklung und verursacht damit Kosten. Zudem, und das wiegt schwerer, kann diese „klassische“ Vorgehensweise ein wirklich gutes Endprodukt verhindern oder zumindest verzögern.

Schließlich gilt auch bei der Softwareentwicklung das Sprichwort „viele Köche verderben den Brei“ – und wenn jede Fachabteilung regelmäßig vorhandenes wiederkäut, kommt es am Ende zu einem großen Flickenteppich aus Kompromissen. Eine gut gepflegte DevOps-Kultur nutzt hingegen vorhandenes Synergiepotential.

Alte Hierarchien aufbrechen

Essenziell ist dabei nicht nur die Aufstellung eines DevOps-Teams oder der Zusammenlegung zweier vorhandener Dev- und Ops-Abteilungen zu einer. Vielmehr müssen die Organisationsstruktur und das Hierarchiesystem überdacht und überarbeitet werden. Möglich wird das nur, wenn die Hierarchien möglichst flach sind – und das gesamte DevOps-Team einem gemeinsamen Ziel zuarbeitet.

Die Struktur sollte möglichst einfach gehalten werden, denn bei der Softwareentwicklung spielt das sogenannte Conway’s Law eine gewisse Rolle: Organisationen tendieren dazu, Systeme zu entwickeln, die ihre eigene Kommunikationsstruktur widerspiegeln. Soll ein Produkt also möglichst einfach und logisch sein, verursachen komplexe Hierarchien und Strukturen nicht selten das Gegenteil.

Das richtige Umfeld schaffen

Damit sich die gewünschten Synergieeffekte nicht in der Kommunikation aufreiben, ist es natürlich wichtig, dass ein DevOps-Team auch gewisse Freiheiten besitzt und nicht von anderen Fachabteilungen „gestört“ wird. Das bedeutet, dass das DevOps-Team als Gesamtheit betrachtet werden muss, die ihrerseits die nötige Infrastruktur als Service zur Verfügung haben muss.

Nicht direkt per DevOps eingebundene Abteilungen wie die Unternehmens-IT müssen etwa dafür sorgen, dass das DevOps-Team reibungslos arbeiten kann, indem sie beispielsweise die für das Entwickeln und Testen von Software notwendige Infrastruktur zur Verfügung stellt. Das können zum Beispiel virtuelle Maschinen sein, die sich schnell und einfach kopieren und nutzen lassen.

Gerade altbackene Sicherheitsrichtlinien können sich hier als Hemmschuh erweisen. Ein funktionierendes DevOps-Team sollte auch „spielen“ können und nicht dazu gezwungen werden, für jede noch so kleine Änderung wieder mit externen Fachbereichen kommunizieren zu müssen.

Alternative Möglichkeiten der Organisation

Damit das funktioniert, existieren verschiedene Modelle von DevOps in der freien Wirtschaft: DevOps bedeutet nicht zwangsläufig, dass Development und IT-Operations zusammengelegt werden müssen, allerdings ist dieses Modell sehr beliebt, weil es effizient ist.

Statt der Zusammenlegung ist aber auch eine „zwingende Kollaboration“ der Fachabteilungen denkbar: Dazu werden die Abteilungen zu einer engen horizontalen Kooperation angehalten, bei der sich beide Bereiche die Entwicklungen so lange hin und her spielen, jeweils mit Feedback, bis sie „reif“ sind, nach oben durchgereicht zu werden.

Ebenso ist es denkbar, nur die Teamleiter in einer Art Mini-DevOps-Team zu sammeln, die dann vorhandene klassische Fachabteilungen koordinieren. Eine solche Struktur hat den Vorteil, dass alle Organisationsstrukturen zunächst beibehalten werden können, was natürlich Kosten spart. Im Zweifel ist das aber natürlich keine reine Interpretation des DevOps-Gedankens.

Site Engineers einsetzen?

Ebenfalls denkbar – und bei manchen sehr großen Organisationen wie Google bereits praktiziert – ist der Einsatz sogenannter Site-Reliability-Engineers (SRE). Dabei handelt es sich um Entwickler mit Erfahrungen im Bereich Operations, die mit den bisherigen Entwickler- und IT-Teams zusammenarbeiten und diese quasi überprüfen.

Ein Team aus SREs arbeitet automatisch als DevOps-Team, weil die Mitarbeiter ja beide Bereiche im Hinterkopf haben. Dieses Team wiederum kann als Brücke zwischen vorhandenen Operations- und Development-Abteilungen eingesetzt werden oder eine völlig neue DevOps-Abteilung bilden.

(ID:47333598)

Über den Autor

 Christian Rentrop

Christian Rentrop

IT-Fachautor