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.
- Bernd Wachter, Capgemini
„DevOps ist einer der zentralen Bausteine, um Software schneller releasen zu können, Agilität, DevOps und Cloud werden in Summe die IT-Landschaft so verändern, wie sie in den vergangenen Jahren nicht verändert worden ist. Die Kunst dabei ist, die Transformation vom projekt- zu einer produktorientierten Organisation aktiv zu gestalten. Und das ist kein rein technologisches Thema, sondern ein primär kulturelles, das bis in die Führungsebenen hineinreicht und oft unterschätzt wird. Deshalb scheitert die erfolgreiche Umsetzung von DevOps derzeit noch bei vielen Unternehmen in Deutschland.“ - Mark Aichholz, IBM
„Es ist wichtig, die Brücke zwischen Business und IT zu schlagen. Ein probates Mittel dafür ist, die Menschen beim Kunden zusammenzubringen und in Workshops herauszuarbeiten, wo das Business die IT sieht. Wie weit bin ich vom Bild eines perfekten agilen Unternehmens entfernt? Wo verliert man die meiste Zeit, wo ist die Qualität nicht ausreichend, und wo schmerzt es das Business am meisten? Ohne begleitenden Schulungs- und Überzeugungsprozess wird es schwierig, DevOps über die Fläche auszurollen.“ - Mark Hlawatschek, ATIX
„Ein aufgezwungener Ansatz funktioniert nicht, weil DevOps eine Kultur ist. Das Team muss verstehen, dass es Verantwortung haben will und am Ende auch tragen muss. Es geht bei der Entscheidung für DevOps nicht um Ja oder Nein, sondern um die Frage, warum man DevOps machen möchte. Es ist auch nicht die Frage, mit welcher Hardware ein Kulturwandel vollzogen wird. Es braucht die Zusammenarbeit von Entwicklung und Betrieb sowie Automatisierungslösungen. Eine funktionierende DevOps-Kultur ist ausschlaggebend für den Erfolg digitaler Geschäftsmodelle. Die Geschwindigkeit, mit der neue Softwareversionen veröffentlicht werden können, ist einer der wichtigsten Erfolgsfaktoren.“ - Ulrich Eschbaumer, CGI
„Das Thema DevOps ist aktuell ein Hype, bei dem man nicht auf der grünen Wiese anfängt. Es muss mit Kompetenz und jahrelangem Know-how implementiert werden, weshalb der Altersdurchschnitt der Beteiligten relativ hoch ist. Die Umstellung in den Köpfen ist dabei eine der wesentlichen Herausforderungen. Eine andere liegt in der Hybridsituation aus agilen und klassischen Vorgehensweisen. Diese zu verheiraten und zusätzlich noch Geschwindigkeit aufzunehmen ist eine echte Challenge.“ - Donald S. Fitzgerald, EasiRun
„Um die Implementierung von DevOps als Strategie zu rechtfertigen, benötigt man deutliche Mehrwerte, und die kommen hauptsächlich vom damit erreichten verbesserten Erfolg im Markt. Im Markt entscheidet nur einer über Qualität und Vorteile: der Kunde! Erfolgreiche Implementierungen von DevOps-Strategien und -Prozessen realisieren die Qualitätsansprüche von Kunden nicht durch die Geschwindigkeit, wobei Patches und Releases täglich beziehungsweise stündlich rausgehen – ganz im Gegenteil: Wenn alle Beteiligten in die Wertschöpfungskette eingebunden sind, ihre Beiträge leisten und das Bewusstsein entwickeln, dass der Kunde über die Qualität entscheidet, wird die Wahrnehmung für Qualität als Ziel geschärft – auch die des Kunden.“ - Markus Eisele, Red Hat
„DevOps hat seine Wurzeln in der Open-Source-Kultur. Die hohe Geschwindigkeit, die heute durch kürzere Produktionszyklen und die Automatisierung bei der Infrastrukturbereitstellung angestrebt wird, spielt in der Open-Source-Gesellschaft seit vielen Jahren eine herausragende Rolle. Allerdings wird hier aufgrund der großen Community viel offener kommuniziert, nach ganz anderen Regeln und mit weniger Bürokratie, also in einer offenen Kultur. Das Kultur-Thema ist letztlich auch der Dreh- und Angelpunkt, an dem Unternehmen immer wieder sehen, warum Pilotprojekte scheitern.“ - Peter Schmidt, PKS Software
„Es gibt kein Patentrezept für die Einführung von DevOps, denn die beteiligten Personen – junge und langjährig erfahrene Softwareentwickler, IT-Abteilung und Fachbereich, Entscheider und Umsetzer – sind über ganz unterschiedliche Aspekte für solch ein Vorhaben zu motivieren. Hier braucht es also neben IT- und Tool-Experten vor allen Dingen auch das Wissen um die Belohnungssysteme der Menschen und darüber, wie man Teams so zusammenstellt, dass der Projekterfolg programmiert ist. Für ein Pilotprojekt werden häufig die engagiertesten Mitarbeiter aus den einzelnen Abteilungen eingebunden – damit ist ein initialer Erfolg quasi garantiert. Doch die Einführung beziehungsweise der Roll-out gestaltet sich umso schwieriger. Gerade bei den Legacy-Systemen gibt es in den Unternehmen viele Kopf-Monopole mit Klumpenrisiko; gerade diese Mitarbeiter muss man mit auf die Reise nehmen, um von DevOps dauerhaft als Unternehmen zu profitieren.“ - Wilfried Cleres, Fujitsu
„Bei der Einführung von DevOps gibt es drei wichtige Punkte. Der erste ist die Ist-Aufnahme: Wo stehe ich heute mit meiner Tool-Landschaft? Zweiter Punkt: Vergiss die Menschen nicht. Nimm alle mit, sonst kann man die Kultur nicht umsetzen. Und drittens: Entwickelt gemeinsam den künftigen Bebauungsplan mit den wichtigsten Zielen. Wichtig ist, dass diese auch erreichbar sind. Lieber weniger Ziele setzen, die dann aber auch erreicht werden können.“
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. (hv)