Die meisten Unternehmen haben DevOps für sich entdeckt und wollen ein neues Miteinander von IT und Fachabteilungen etablieren. Dabei werden oft Fehler gemacht. [...]
Die Vorteile, die DevOps für Entwicklung und Betrieb von softwaregetriebenen Geschäftsmodellen verspricht, sind gewaltig. Unternehmen können neue Produkte oder auch zusätzliche Funktionen bestehender Produkte schneller auf den Markt bringen. Mitunter gelingt es sogar, wichtige Trends zu eigenen Gunsten mitzuprägen.
In Märkten, die sich immer schneller drehen, wird Geschwindigkeit zum entscheidenden Faktor. Laut der IDC-Studie „DevOps in Deutschland 2020“ nutzen vier von fünf Unternehmen DevOps, weitere planen den Einsatz. Rund 40 Prozent der Befragten wollen damit die Agilität in der Entwicklung steigern und schneller werden, so ein Ergebnis. Ein weiteres Ziel ist für 37 Prozent die erhöhte Kundenzufriedenheit, indem Firmen im laufenden Entwicklungsprozess auf neue Anforderungen der Kunden reagieren können.
Soweit die guten Vorsätze, doch die IDC-Studie stellt auch fest, dass es an der Umsetzung oft hapert. Nur 19 Prozent der Betriebe entwickeln derzeit mehr als die Hälfte ihrer Applikationen mit Hilfe von DevOps. Hier gibt es also offenbar noch viel Luft nach oben. Das Zögern hängt auch mit der Art und Weise zusammenhängt, wie DevOps in den Unternehmen eingeführt wird. Das häufige Motto: Das Tool hat Vorrang. Und Tools gibt es reichlich, viele erfüllen ihren Zweck auch sehr gut. An den verfügbaren Werkzeugen liegt es also nicht, wenn die Einführung von DevOps an Grenzen stößt.
DevOps berührt breites Spektrum von Aspekten
Neue Methoden über Tools einzuführen, auf die weder die Strukturen noch die Beschäftigten eingestellt sein können, hat noch selten zum Erfolg geführt. Oft wurde auf die Weise viel Geld verbrannt, und es wurden reichlich Narben hinterlassen. Firmen, die so vorgehen, denken meistens nicht daran, dass die unternehmensweite Einführung eines DevOps-Modells ein Unternehmen fundamental transformiert. Das betrifft Strategien, Unternehmenskultur, Prozesse, Organisation, Infrastruktur und Architektur. Fast alles wird angefasst – und umgekrempelt. Tools sind also nur ein Baustein innerhalb einer umfassenden Veränderungsstrategie.
Am Anfang steht die Strategie: Hier sollten klare Aussagen zu den gewünschten Zielen von DevOps gemacht werden. Die Strategie gibt den Kern für den langfristigen Erfolg von DevOps vor. Sie beantwortet zentrale Fragen wie: Warum machen wir das überhaupt? Warum können wir nicht so weiterarbeiten wie bisher? Welchen konkreten Nutzen versprechen wir uns? Wie sehen unsere Ziele aus? Diese Ziele können vielfältig sein. Sie reichen von der Steigerung der Wettbewerbsfähigkeit über bessere Produkte, mehr Teamqualität und eine erhöhte Mitarbeiterzufriedenheit bis hin zu schnelleren Marktreaktionszeiten und optimierten Produkten.
Der nächste Stolperstein liegt in der Kultur: DevOps bedeutet einen kulturellen Wandel! Um die Methode erfolgreich umzusetzen, müssen sich Haltung und Mindset von Mitarbeitern und Führungskräften grundlegend ändern. Die wichtigste Aufgabe besteht darin, Autonomie und Eigenverantwortung in den selbstorganisierten Produktteams aufzubauen. Diese müssen mehr Freiräume bekommen und selbst entscheiden können, welche neuen und verbesserten Software-Features gut für ihr Produkt sind.
Eine DevOps-Führungskraft sollte sich als der sprichwörtliche Servant Leader verstehen, der perfekte Rahmenbedingungen für den Erfolg des Teams schaffen muss. Damit müssen manche Menschen in verantwortlichen Positionen ihre Einstellung komplett ändern. Übrigens sollten auch Zielsysteme diesen Wandel widerspiegeln, indem sie Kollaboration, fortlaufendes Lernen, kontinuierliche Verbesserung und Eigenverantwortung belohnen.
Produkte ersetzen Projekte
Eine weitere entscheidende Veränderung ist die Art und Weise, wie Softwareentwicklungsprojekte ablaufen. Im Grunde genommen gibt es keine Software-Projekte mit einem klaren, vorher festgelegten Anfang und Ende mehr. Das ist ein fundamentaler Eingriff in etablierte Denkstrukturen. Softwareentwicklung war bisher stets ein Projektgeschäft, basierend auf ausgefeilten Phasenmodellen für Software-Produktentstehungsprozesse. Am Anfang stand ein Anforderungskatalog und am Ende wurde die Software an den Betrieb übergeben. Ein Projekt wurde beendet, ein nächstes konnte beginnen.
Mit DevOps gibt es aber kein Projektende und kein finales Handover mehr, denn DevOps geht nicht von Projekten, sondern von Produkten aus. Diese werden über ihren gesamten Lebenszyklus hinweg von der ersten Codezeile bis zum End-of-Life von einem Produktteam sowohl entwickelt, gelauncht und betrieben als auch kontinuierlich verbessert, bis sie schließlich nicht mehr benötigt oder durch ein besseres Produkt ersetzt werden.
Mit der Etablierung von langfristig zusammen arbeitenden Produktteams entfällt die Notwendigkeit, Mitarbeiter aus getrennt voneinander arbeitenden Fachbereichen phasenweise zusammenzuwürfeln – ein in Projektorganisationen übliches Vorgehen. DevOps-Produktteams sind von Natur aus cross-funktional zusammengesetzt, sie decken gemeinschaftlich alle Fähigkeiten ab, die für Entwicklung, Test, Administration und Management eines hervorragenden IT-Produkts erforderlich sind. Eine scharfe Trennung der Rollen ist innerhalb dieser Teams nicht mehr zwingend erforderlich.
DevOps auch Frage der Architektur
Auch wenn DevOps nicht allein durch den Einsatz von Tools zum Leben erweckt werden kann, bleibt die Nutzung einer entsprechenden Toolchain eine entscheidende Voraussetzung für eine erfolgreichen Umsetzung. Die Toolchain stellt eine Kombination von aufeinander aufbauenden und verknüpften Werkzeugen dar, um eine DevOps-Prozesskette technisch zu unterstützen.
Viele dieser Tools sind Open Source verfügbar – eine wichtige Voraussetzung dafür, dass das Thema DevOps Fahrt aufnehmen kann. Eine typische Toolchain sollte in jedem Falle Werkzeuge für Continous Integration/Continous Deployment (CI/CD) enthalten, um damit Software-Artefakte automatisieren, bauen, integrieren, testen und verteilen zu können. Ergänzt wird die DevOps Toolchain um ganze Tool-Ökosysteme zu Themen wie Containering, Testautomatisierung und Collaboration, um nur ein paar Beispiele zu nennen.
Die wichtige Rolle der Architektur wird – anders als der Tool-Bedarf – gerne übersehen. Die Architektur eines Produkts muss eine DevOps-Arbeitsweise erst einmal zulassen. Konkret bedeutet das etwa, dass auch mehrere Produktteams oder mehrere Teams rund um ein und dasselbe Produkts selbstständig voneinander arbeiten und entscheiden können. Mögliche Abhängigkeiten gilt es weitestgehend zu vermeiden. Die Architektur muss hierfür Voraussetzungen schaffen, indem Softwarefunktionen modularisiert und entkoppelt voneinander nutzbar gemacht werden. In historisch gewachsenen Systemlandschaften mit oftmals monolithischen Legacy-Systemen ist das ein nicht immer einfaches Unterfangen.
Parallele und unabhängige Entwicklerteams
Das Idealbild einer DevOps-orientierten Architektur stellen Microservices dar. Eine serviceorientierte Architektur kann zumindest als Vorstufe gelten. Generell ist eine Systemlandschaft sinnvoll, die in kleinen, möglichst autonomen Diensten organisiert ist. Diese sind jeweils für sich lauffähig und greifen auch nicht aufeinander zu. Sie werden von ihrer Applikation orchestriert. Beim Ausfall eines Dienstes kann der Rest dennoch weiterarbeiten. Entwicklerteams können parallel und weitgehend unabhängig voneinander einzelne Microservices entwickeln, ergänzen und verändern.
Das neue Denken in Produkten spiegelt sich in der Architektur wider: Für Software-Module, die wiederverwendbare Enabler-Funktionen wie zum Beispiel „Billing“ umsetzen, ist genau ein Product Owner verantwortlich, auch wenn diese Funktion mehrfach verwendet wird und keiner Kundenanwendung eindeutig zugeordnet werden kann. Der Product Owner achtet darauf, dass Produkte mit Billing-Bedarf nicht mehr individuell und proprietär angebunden werden, sondern ihnen eine einheitliche, einmal definierte Schnittstelle gleichermaßen zur Verfügung steht.
Dementsprechend werden Billing-Funktionen nicht mehr zu 100 Prozent maßgeschneidert für einzelne Applikationen sein. Andererseits wird einer Inflation von Sonderwünschen an Entwicklungen Einhalt geboten, von denen fünf Jahre später oft keiner mehr weiß, wie und wofür sie erstellt wurden. Stattdessen wird Wert auf ein solides Schnittstellenmanagement gelegt, um skalierbare, wartbare und mandantenfähige Dienste zu ermöglichen, die unabhängig voneinander klare Aufgaben verfolgen und kontinuierlich optimieren.
DevOps ist ein Instrument für den organisatorischen Wandel von isolierten Gruppen zu kollaborativen Teams mit geteilter Eigentümerschaft, einem gemeinsamen Ziel und kollektiver Verantwortung. Um die optimale DevOps-Struktur zu erreichen, sollten Unternehmen nicht zuerst und schon gar nicht ausschließlich nach geeigneten Tools suchen. Vielmehr gilt es, eine Strategie zu haben und die Unternehmenskultur sowie das Mindset der Mitarbeiter zu ändern. Außerdem gilt es, die Prozesse und Organisationsstrukturen anzupassen, die Systemarchitektur zu adaptieren und – lediglich ergänzend dazu – die geeigneten Tools auszuwählen und die Transformation zu starten. Erst dann ist ein Unternehmen reif für DevOps – und wird von den vielen Vorteilen profitieren.
*Dietmar Bernreuther ist Associate Partner bei der Managementberatung Detecon. Er hat bereits mehrere DevOps-Projekte in der Automobilindustrie und in anderen Branchen begleitet.
Be the first to comment