Im Rahmen des Führungskreis Softwareentwicklung durfte ich einen Workshop zum Thema DevOps organisieren. Thomas Schissler von AgileMax ist mit uns auf den Weg zur agilen Organisation gegangen.
Was ist DevOps?
Der Begriff DevOps wurde ursprünglich von Patrick Debois geprägt und meint die bessere Zusammenarbeit von Entwicklung und Betrieb. Aktuelle Wortspiele wie „DevSecOps“ oder „BizDevOps“ zeigen, dass es im Kern jedoch um die Ausweitung agiler Prinzipien auf den Unternehmenskontext dreht. Diese Erweiterung spielt sich sowohl auf der organisatorischen als auch auf der technischen Seite ab.
DevOps – Die organisatorische Seite
Fast jede Organisation besteht aus horizontal geschnittenen Teams oder Abteilungen oder Bereichen: Entwicklung, Einkauf, Produktion, Vertrieb, usw. Wir packen also alle Fachleute in einen Raum und lassen sie miteinander arbeiten. Neuerdings auch Chapter genannt. Der große Nachteil daran, wir bilden zahlreiche Schnittstellen zwischen den Abteilungen, auf dem Weg zur Befriedigung des Kundenbedürfnisses. Kein Wunder das Konzepte wie Prozessmanagement einen großen Hype erlebt haben, um die Schnittstellen sauber zu klären.
Um diesen systembedingten Nachteil zu umgehen, werden z.B. bei Projekten vertikal geschnittene Teams eingesetzt. Alle Fachleute, die zur Befriedigung des Kundenbedürfnisses erforderlich sind, werden in ein Team entsendet, auch Squad genannt. Bei SCRUM sind dies z.B. Entwickler, Kunde (Product Owner) und Moderator (SCRUM Master). Bei DevOps kommen Leute aus dem Bereich Infrastruktur dazu. Ähnlich dem Grundgedanken von Obeya bei Toyota, dem War Room zur Produkt- und Prozessentwicklung.
Die Vorteile sind klar, schnelle Kommunikation, kurze Entscheidungswege und Fokus auf das Kundenbedürfnis. Die Nachteile dürfen allerdings auch nicht verschwiegen werden. Standards, und damit effiziente Prozesse, sind in mehrere vertikalen Teams schwer aufrecht zu erhalten. Die grundsätzliche Spannung zwischen einer Intern und Extern bleibt bestehen, sie wird nur ins Team verlagert.
Die richtige Frage an dieser Stelle lautet also: Welche Kommunikation möchte ich stärken? Die Antwort darauf hat aber auch direkte Auswirkungen auf die technische Seite.
DevOps – Die technische Seite
Das Gesetz von Conway aus dem Jahre 1968 besagt, dass die Strukturen von Systemen durch die Kommunikationsstrukturen der sie umsetzenden Organisationen vorbestimmt sind. Kurzum, wir replizieren uns selbst! Horizontale Teams werden Systeme bauen, mit Schnittstellen zwischen den Teams. Vertikale Teams werden Systeme bauen, die vermutlich schwerer zu skalieren sind. Wenn ich es nun mit DevOps ernst meine, stellt sich die Frage, wie kann ich vertikale Teams technisch unterstützen?
An dieser Stelle möchte ich nur einige Schlagworte nennen, hier gibt es viel bessere Experten als mich. Was mir jedoch wichtig ist, alle diese Werkzeuge haben zum Ziel, die Abhängigkeiten zwischen Teams zu verringern und damit vertikale Teams zu unterstützen:
- MicroServices
- Polyglotte Datenbanken
- Open Source
- Self-Contained Systems
- Automatisiertes Deployment
- Unterbrechungsfreie Updates
- Tests in Production
- Monitoring
- Container/Docker
- usw.
Fazit
Spannend an DevOps ist für mich zum einen die aufgezeigte Verbindung von Organisation und Technologie. Zum anderen zeigt DevOps einen konkreten Weg zu einer agileren Organisation auf:
Ein Gedanken lässt mich aber nicht ganz los. Bei aller Begeisterung für agile Konzepte, sie scheinen „nur“ eine Lösung für den Sonderfall komplexer Aufgaben (siehe CYNEFIN) zu sein. Für komplizierte Aufgaben scheint die klassische Hierarchie, die auf Effizienz ausgelegt ist, die bessere Lösung zu sein. Schau dir dazu auch das passende Experiment an. Die Kernfrage lautet also, welches Werkzeug, für welches Problem?
Dr. Patrick Fritz
Kommentar verfassen