Wird eure DevOps-Transformation jemals abgeschlossen sein?

Vielleicht habt ihr inzwischen schon erkannt, dass eine DevOps-Transformation nicht nur Softwareentwicklung und IT-Betrieb umfasst. DevOps bedeutet heute unternehmerisches Denken auf höchster Ebene. Ein wesentlicher Teil von DevOps ist, Verantwortung für die Ergebnisse eurer Arbeit zu übernehmen, diese Ergebnisse zu verstehen und sie unmittelbar in eure Entscheidungen einfließen zu lassen.

DevOps gehört in die C-Suite

Die wirkungsvollste Form von DevOps findet in der C-Suite statt, denn die besten DevOps-Transformationen beziehen alle ein und erfordern den Blick auf das große Ganze. Ohne diese Perspektive bleibt euer DevOps in der digitalen Transformation auf einzelne Teams beschränkt, wird langsamer und teurer und führt nicht zu optimalen Ergebnissen.

Die C-Suite kann die gesamte Organisation mobilisieren, damit sie als eine Einheit arbeitet, ohne dass Teams erwarten, dass andere mögliche Probleme später lösen. Dafür braucht jedes Team eine DevOps-Mentalität und muss Verantwortung für die Ergebnisse seiner Arbeit übernehmen – bis hin zu Deployments in die Produktion und zur Wartung. DevOps entstand in der IT, wo es Entwicklern und IT-Betrieb ein gemeinsames Ziel gab: wiederkehrende Prozesse automatisieren, Kosten senken und kürzere Markteinführungszeiten ermöglichen.

Heute kann DevOps sein volles Potenzial nur in der C-Suite entfalten. DevOps sollte Entscheidungen des Top-Managements unterstützen – etwa zu Innovationen, neuen Produkten und neuen Märkten – und einen schnellen Betrieb fördern. Automatisierte Kennzahlen sollten dabei belegen, dass es funktioniert.

Eure DevOps-Transformation sollte ein Enddatum haben

Die vollständigen Ergebnisse werden erst erreicht, wenn die Transformation zu einer sich organisch weiterentwickelnden Organisation abgeschlossen ist. Deshalb müsst ihr dieses Ziel von Beginn eurer Transformation an verfolgen und einfordern. Damit die Transformation jemals abgeschlossen werden kann – weil eure Organisation auf allen Ebenen, einschließlich der Entscheidungen der C-Suite, als fortschrittliche DevOps-Organisation arbeitet –, braucht sie ein Enddatum.

Damit eure DevOps-Transformation ein Enddatum haben kann, solltet ihr sorgfältig überlegen, bevor ihr verteilte interne DevOps-Abteilungen aufbaut. Plant zumindest voraus, was mit eurer Organisation geschieht, wenn die Transformation abgeschlossen ist. Andernfalls riskiert ihr DevOps-Team-Silos (siehe „Anti-Typ B“ in DevOps Topologies), bei denen die Verantwortung für die Umsetzung von DevOps beim DevOps-Team liegt – und nicht bei jedem Team in eurer Organisation.

Stattdessen sollte eine DevOps-Transformation als eine Reihe klar abgegrenzter Projekte verstanden werden, die innerhalb eines vorab vereinbarten Zeitrahmens umgesetzt werden. Am Endpunkt – dem Enddatum – hat eure Organisation alle Vorteile von DevOps übernommen und setzt sie im Arbeitsalltag um und teilt sie.

Die vier Phasen einer DevOps-Transformation enden mit einem Enddatum

Warum setzen Unternehmen ihrer DevOps-Transformation kein Enddatum?

Unternehmen machen ihre DevOps-Transformation vor allem dann zu einem dauerhaften Unterfangen, wenn sie interne DevOps-Experten einstellen und in bestehende Teams integrieren oder ein neues DevOps-Team aufbauen.

Das hat den unmittelbaren Vorteil, zunächst günstiger zu wirken als die Beauftragung einer Beratung. Langfristig ist es jedoch teurer, weil diese Mitarbeiter auf eurer Gehaltsliste bleiben und ihr nach Abschluss der DevOps-Transformation neue Projekte für sie finden müsst. Die Gefahr besteht darin, dass eure eigenen DevOps-Engineers nach dem ersten Teil der Transformation an DevOps-Verantwortlichkeiten festhalten, die eigentlich im Team oder in der gesamten Organisation geteilt werden sollten – obwohl sie für effiziente Entwicklungsarbeit besser eingesetzt wären.

Aber ist es nicht der beste Weg, DevOps-Wissen nach Abschluss der Transformation zu bewahren, interne DevOps-Experten einzustellen? Das mag so wirken, weil die DevOps-Experten Teil eurer Abteilung bleiben. Natürlich besteht bei der Zusammenarbeit mit Beratern das Risiko, dass sie ihr Wissen mitnehmen und ihr dadurch von weiterer Beratung abhängig bleibt. Interne Experten haben jedoch ihren Preis: Wenn DevOps-Experten dauerhaft Teil eurer Organisation sind, vermittelt das anderen Mitarbeitern – einschließlich der C-Suite –, dass DevOps-Verantwortlichkeiten nicht bei ihnen liegen. Das verringert die Wirksamkeit eurer Softwareproduktion, eurer Entwicklungsteams und eurer DevOps-Transformation erheblich.

Die Vorteile einer DevOps-Transformation mit Enddatum

Einige Vorteile habe ich bereits angesprochen. Hier sind weitere Gründe, das ernst zu nehmen.

1) Eine Transformation mit Enddatum senkt langfristig die Kosten und macht sie transparenter: Ihr habt eine Kostenschätzung dafür, was jeder klar abgegrenzte Schritt oder jedes Vorhaben eurer Transformation kostet.

2) Das Ergebnis einer Transformation sollte eine organisationsweite DevOps-Maschine sein. Wenn ihr diese Maschine mit externer Unterstützung aufbaut, denkt daran: Die Bausteine dieser Maschine sind eure Entwickler und das technische Management. Sie funktioniert erst, wenn diese Entwickler DevOps sehr gut beherrschen. So bleibt das DevOps-Wissen, das für die Wertschöpfung in eurer Organisation relevant ist, intern. Andernfalls könnte man argumentieren, dass die DevOps-Transformation nicht abgeschlossen ist.

Wenn ihr beispielsweise eine DevOps-Transformation mit einer DevOps-Beratung beginnt, profitiert ihr sofort von den Best Practices der Organisationen, mit denen diese Beratung zuvor gearbeitet hat – zugeschnitten auf eure Anforderungen. Wenn ihr einzelne Mitarbeiter einstellt, endet ihre Erfahrung aus anderen Organisationen, sobald sie ihre Arbeit bei euch beginnen.

3) Geschwindigkeit ist sehr wichtig. Kürzere Durchlaufzeiten sind ein Vorteil, den Branchenführer weltweit bereits haben. Das macht DevOps zu mehr als einem Nice-to-have und ist einer der Gründe, warum es zu einem Ziel für Führungskräfte wird. Mit einem Enddatum erkennt ihr an, dass die DevOps-Transformation kein fernes Ziel ist, sondern ein Endziel, das immer mehr Organisationen bereits erreicht haben – und das eure Organisation so schnell wie möglich erreichen möchte.

Eure DevOps-Transformation sollte ein Enddatum haben. Hat sie bereits eins?

Ihr müsst kein neues Team in eurer Organisation schaffen, das von Anfang an nicht nötig gewesen wäre, nur damit eure Organisation effektiver arbeitet. DevOps bedeutet nichts anderes als eine gute Strategie, eine offene und unterstützende Kultur, Verantwortungsübernahme, den Austausch von Best Practices und die Automatisierung von allem, was sich automatisieren lässt. DevOps ist keine eigenständige Einheit und sollte daher auch keine eigene Abteilung sein.

Skeptisch? Der erste Schritt ist eine DevOps-Bewertung mit Roadmap – auch wenn ihr eure DevOps-Transformation intern umsetzen möchtet. Wenn ihr mehr darüber erfahren möchtet, sprecht uns an.