Das Wichtigste vorweg: DevOps ist kein Framework und kein Standard, der kodifiziert in einem Buch nachzulesen ist. Zehn Personen zu fragen, was DevOps ist, würde mit grosser Wahrscheinlich in zehn unterschiedlichen Antworten münden. Diese Herausforderung erweist sich gleichzeitig als Segen. DevOps ist eine Bewegung, ein «Grassroot Movement» und ebenso eine experimentierfreudige Community, welche sich laufend weiterentwickelt. Die Basis bildet dabei immer eine gemeinsame Philosophie und ein gemeinsames Ziel, nämlich «schneller» und «besser» zu werden. Wie bei jedem Hype üblich, wird auch DevOps inzwischen marketingdienlich für alles Mögliche verwendet und die eigentliche Philosophie von DevOps geht dabei verloren. Der erste kritische Erfolgsfaktor bei einer DevOps Transformation ist daher zu verstehen, was die DevOps Philosophie ausmacht und woher sie kommt.
1) Die Essenz von DevOps verstehen
Firmen wie Netflix, Etsy und Spotify – die sogenannten «Unicorns» – haben DevOps in den Anfängen geprägt. DevOps entsprach ganz einfach der Kultur, der Art und Weise wie dort Dinge angepackt wurden. Die Basis dafür bildete zunächst die agile Entwicklung um Produkte herum, d.h. in kleinen selbstorganisierten Teams, mit end-to-end Verantwortung (you build it, your run it), inkrementell und adaptiv. Agile Entwicklung macht aber erst richtig Sinn mit DevOps. Der eine Aspekt war dabei, nicht jedes Mal 2 Wochen auf eine Testumgebung warten zu müssen (Frage: Wie lange dauert dann ihr Sprint?), daher der Druck Richtung Cloud, Infrastructure as a Code und Microservices. Ein weiterer Aspekt war die Durchsetzung einer neuen ‚Definition of Done‘, d.h. bei jedem Check-In werden alle Tests automatisiert durchgeführt und dadurch schnelle Feedbackzyklen erreicht, so dass Software jederzeit in einem «releaseable State» ist – dann spricht man von Continuous Delivery. Das Resultat: Kürzere Time to Market und gleichzeitig hohe Stabilität.
Einen entscheidenden Schritt machte die DevOps Bewegung, als grössere, traditionell geprägte Firmen (die sogenannten «Horses») angefangen haben, sich für das erfolgsversprechende Modell der Unicorns zu interessieren und auf ihre Situation zu adaptieren. Und das ist dann die Geschichte, welche wir alle kennen: Die funktionale Trennung von Entwicklung und Betrieb, Bestrebung diese mit gemeinsamen Zielen, einem gemeinsamen «Flow» aufzubrechen, mit kontinuierlichen Feedback-Loops und konsequenter Automatisierung.
2) Das eigene «Warum DevOps?» erkennen, daraus eine Vision und Ziele für die relevanten Bereiche ableiten und die Zielerreichung messbar machen
DevOps ist nie das Ziel, sondern Mittel zum Zweck. Die erste Frage ist daher: «Warum DevOps?» und diese Frage für die konkrete Situation, in der Sie stecken, zu klären. Dadurch wird auch das nötige Dringlichkeitsgefühl erzeugt. Schon J.P. Kotter hat durch seine Studien früh erkannt, dass ohne diesen «Sense of Urgency» 50 Prozent aller Transformationen bereits am Anfang scheitern.
Für DevOps gibt es mindestens zwei gute Gründe:
- Digitalisierung: Ihr nächster härtester Konkurrent könnte ein Startup mit einer disruptiven App sein. Diese Firmen sind fähig, sehr schnell mit neuen und qualitativ hochwertigen Dienstleistungen an den Markt zu gehen und so schnell neue Ideen am Markt zu testen. Die Zeit wird es zeigen, aber vermutlich wird keine Branche davon verschont bleiben.
- Die IT-Abteilung in Ihrem Unternehmen ist gespalten; die Entwicklung will Flexibilität und der Betrieb strebt nach Stabilität und das Business hätte am liebsten beides. Spaltung und zersiedelte Prozesse überall. Wo ist hier der Value Stream «end to end»? So kann es nicht weitergehen.
Aus diesem «Warum», das in jedem Unternehmen eine andere Ausprägung kennt, gilt es nun eine Vision und konkrete Ziele zu entwickeln. Im Fokus steht die Verbesserung des Time to Market und der Stabilität. Die formulierten Ziele sollten messbar gemacht werden. Nur so können Sie wissen, wo sie stehen und ob Sie sich während der Umsetzung verbessern. Dabei sollte auch nicht die ganze IT in den gleichen Topf geworfen werden. DevOps kann vor allem für die IT Services relevant sein, über die sich das Unternehmen gegenüber dem den Mitbewerbern differenziert. Dort ist DevOps matchentscheidend für den Erfolg des Unternehmens, Geschwindigkeit und gleichzeitige Stabilität sind Markt-Differenziatoren. Aus genau diesem Gedanken heraus haben einige Unternehmen begonnen sich Richtung «bi-modale IT» zu entwickeln, d.h. die Aufsplittung in eine «schnelle» und «langsame» IT. Dieser Schritt ist oft notwendig, aber auch umstritten, da sich so schnell eine «Zwei-Klassen-IT» entwickeln kann und so wieder neue Silos entstehen.
3) Teams entlang von Value Streams organisieren
DevOps versucht den Graben zwischen Entwicklung und Betrieb vor allem dadurch aufzubrechen, indem die Sicht der Wertschöpfungskette, des sogenannten «Flows», eingenommen wird. Beginnend mit der der Vision, über die Anforderungen bis hin zum Deployment. Die Basis bildet dabei der agile Flow (z.B. Scrum). DevOps hat diesen um Continuous Delivery erweitert, d.h. durch entsprechende Testautomatisierung und Feedback-Loops kann Software immer in einem «releaseable State» gehalten werden.
Dies erfordert neue Zusammenarbeits-Modelle, für die agile Community jedoch nicht ganz so neu. Eine enge Zusammenarbeit entlang des «Flows» heisst, dass Teams, die vorher funktional getrennt waren und z.B. über «Hand-Offs» kommuniziert haben, näher zusammenrücken müssen. Ein immer häufiger anzutreffender Ansatz ist die Bildung von Squads. Das sind kleine selbst-organisierte Teams, welche die volle Verantwortung für ein Produkt übernehmen. Mehrere Squads werden dann in sogenannte «Tribes» zusammengefasst. Diese neue Form der Zusammenarbeit kann auch auf virtuellem Weg erfolgen, d.h. die Leute verbleiben funktional in Ihrer Linie.
4) Kultur
Kultur ist einer der Grundwerte von DevOps und eine auf Lean und Agile ausgerichtete Kultur ist eine der wichtigsten Voraussetzungen für den Erfolg von DevOps; denn «Culture eats Strategy for Breakfast». Dabei geht es nicht nur darum – wie vorgängig beschrieben – die Teams entlang von Produkten und Value Streams auszurichten, sondern auch eine neue Organisations- und Führungskultur durchzusetzen. Weg vom klassischen Management (Command & Control) hin zu selbstorganisierten Teams mit einer starken Verbesserungskultur und iterativem Vorgehen. Weg vom Manager, hin zum Servant Leader/Coach, welcher die Vision vorgibt und die richtigen Fragen stellt:
5) Die Reise Richtung Continuous Delivery, Automatisierung und Infrastructure as a Code beschreiten
Die einleitend beschriebenen «Unicorns» hatten insofern einfache Voraussetzungen, weil sie auf der grünen Wiese eine idealtypische DevOps Infrastruktur und Continuous Delivery Prozesse etablieren konnten. Konkret heisst dies:
- Infrastructure as a Code: Eine Weiterentwicklung des Cloud Gedankens. Entwicklungs-, Test- und Produktionsumgebung können in beliebigen Konfigurationen sehr schnell zur Verfügung gestellt werden; sprichwörtlich abgerufen durch eine Codezeile
- Automatisierung: Test-, Deployment- und andere Prozesse weisen einen hohen Automatisierungsgrad auf
- Continuous Pipeline und Continuous Delivery: Immer wenn der Entwickler einen Code eincheckt, werden alle notwendigen Tests automatisiert durchgeführt und die Bereitstellung erfolgt via Infrastrucutre as a Code. Der Entwickler bekommt dadurch sehr schnell Feedback – Fail often, fail early. Software ist auf diese Weise immer in einem releasable State.
Nun ist es allerdings so, dass die meisten Unternehmen in einer ganz anderen Situation stecken: Legacy überall, vielfältige Schnittstellen und ein tiefer Automatisierungsgrad. Oft kommt von dieser Seite das Argument, dass so ein Setup in einem Enterprise Umfeld gar nicht möglich ist. Aber eben: DevOps ist kein einmaliges Projekt, sondern eine Reise die nie aufhört. Das kann mit kleinen Massnahmen beginnen, welche in die oben beschriebene Richtung zeigen: Beispielsweise erste Prozesse zu automatisieren, um die Durchlaufzeiten zu beschleunigen. Oder erste Infrastrukturkomponenten in die zu Cloud migrieren, um die Bereitstellungszeiten zu verkürzen. Entscheidend ist, damit anzufangen und diese Reise kann gut und gerne einige Jahre dauern. Diese Reise nicht anzutreten wäre falsch, denn sonst tut es ein anderer. Und: In der heutigen Digitalen Economy ist es nicht der grosse Fisch der den kleinen frisst, sondern der schnelle Fisch frisst den langsamen.
