Es ist die geschäftskritischste Anwendung der DZ Bank und sie muss rund um die Uhr funktionieren: die Handelsplattform. Etwa 1000 Benutzer führen darauf Käufe und Verkäufe aus, weitere 2000 nutzen die Handelsplattform unter anderem für die Risikoüberwachung und das Erstellen von Berichten. Wenn die Plattform stillsteht, dann ist das Geschäft der zweitgrößten Geschäftsbank Deutschlands gefährdet. Und dennoch fasste die IT-Leitung der DZ Bank – der rund 800 Genossenschaftsbanken in Deutschland angeschlossen sind – vor wenigen Jahren einen mutigen Entschluss: Sie startete eine Standardisierung der Prozessabläufe für alle Software-Entwicklerteams, die Einführung reproduzierbarer und revisionsfähiger Prozesse sowie die Beschleunigung der Freigabe neuer Software-Funktionen.

Und die Neuerungen wurden ausgerechnet direkt auf die so wichtige Handelsplattform angewendet. Dazu kam: Der neu konzipierte Prozess wurde an einem einzigen Wochenende ausgerollt.

Die Deutsche Zentral-Genossenschaftbank hat sich für einen Weg entschieden, den derzeit viele Unternehmen unterschiedlichster Größe gehen: Sie setzt bei der Software-Bereitstellung auf das DevOps-Konzept.

Damit geht die DZ Bank ein Thema an, das viele Betriebe rund um den Erdball und quer durch alle Branchen bewegt: Um auf dem Markt relevant zu bleiben, ist es unerlässlich, dass die Innovationszyklen immer kürzer werden. „Die Umstellung von klassischen Methoden auf agile(re) Ansätze ist in diesem Wettlauf gegen die Zeit ein elementares Werkzeug“, so die klare Aussage der Wirtschaftsprüfungs- und Beratungsgesellschaft PricewaterhouseCoopers in ihrer Studie „Realitätscheck DevOps – Vor welchen Herausforderungen stehen Unternehmen bei der Einführung“.

Doch was genau verbirgt sich hinter DevOps? Der Begriff ist nicht eindeutig bestimmt. Grundsätzlich beschreibt DevOps eine kombinierte Rolle im Unternehmen, die sowohl die Entwicklung (Development) als auch den Betrieb von Software (Operations) umfasst. „Am besten bringt das für mich der von Amazon geprägte Ansatz auf den Punkt: ,You build it, you run it‘“, erklärt Vassil Hristov. Damit ist gemeint, dass jedes Team nicht nur für das Schreiben der Software verantwortlich ist, sondern auch für deren Betrieb, so der Co-Founder des IT-Beratungsunternehmens Zest Labs. Damit bringe der DevOps-Ansatz viele Vorteile gegenüber dem alten Ansatz mit verschiedenen Silos von Entwicklern und Systemadministratoren, bei dem ein Team die Software entwickelt und sie – im Idealfall gut dokumentiert – an die Systemadministratoren übergebe. „Sie müssen dann dafür sorgen, dass die Software richtig und unterbrechungsfrei läuft.“

Wenn es dann aber einmal zu Problemen komme, dann verursache das in der Regel hohen Abstimmungsaufwand zwischen den Teams. Wenn hingegen das Team, das die Software schreibt, auch für den Betrieb verantwortlich sei, dann fielen nicht nur die langen Kommunikationswege weg. „Plakativ gesprochen: Wenn man weiß, dass das eigene Handy nachts klingelt, wenn etwas nicht richtig funktioniert, ist man auch motivierter, dafür zu sorgen, dass die Software stabil läuft“, fasst Vassil Hristov zusammen.

Eine laut Hristov weitere sehr verbreitete Interpretation von DevOps ist das von Google geprägte Konzept der so­genannten Site Reliability Engineers (SRE). Dort gebe es weiterhin Teams, die sich auf das Betreiben von Software fokussieren, aber anders als beim klassischen Systemadmi­nistrator setze man bei SRE mehr auf Automatisierung und Observability, also Beobachtbarkeit. „Kombiniert mit modernen Technologien – zum Beispiel Cloud, Kubernetes, Microservices – erlaubt es der Ansatz, schneller Fehler zu beheben. Im Idealfall erkennt und behebt das System Fehler alleine.“

DevOps bezeichnet ein Organisationsmodell, das darauf abzielt, Applikationen durch ein Team vollumfänglich zu betreuen – „von A wie Anforderungsanalyse bis hin zu Z wie Zero Downtime“, ergänzt Lutz Keller. Das Zusammenführen der Verantwortlichkeiten in einem Team führe zu äußerst kurzen Feedback-Schleifen, deren Ergebnisse durch ebenfalls sehr kurze Deployment-Zyklen schnell in Produktion gebracht werden könnten. Dafür kommen laut dem Leiter DevOps bei der IT-Beratung Consol Methoden wie Con­tinuous Integration/Continuous Delivery (CI/CD) zum Einsatz. Der Hauptvorteil laut Keller: „Dem Anwender beziehungsweise dem Kunden werden Verbesserungen viel schneller zugänglich gemacht.“

Frank Haumann, Partner beim Dienstleister Red Reply, unterstreicht, es sei wichtig, DevOps nicht als Technologie zu verstehen, sondern als Organisationsmodell. Noch treffender sei, DevOps als „Kultur“ zu  bezeichnen. „Im Vordergrund steht die sehr enge Zusammenarbeit von Development und Operations.“

Diese Art der Zusammenarbeit bei der Software-Entwicklung führt zu Veränderungen wie einem agilen Mindset und einer agilen Unternehmenskultur, in der Mitarbeiter auch Fehler machen dürfen. So erkennen Software-Developer, aber auch Produktentwickler Fehlerquellen schneller und können durch den offenen Austausch im Team bessere Lösungen entwickeln. „Dass bei DevOps Entwicklung und Betrieb zusammenarbeiten, ist eine bewusste Entscheidung der Organisation. Das Team steht im Zentrum und es erhält alle nötigen Technologien und Prozesse für die enge Zusammenarbeit – mit möglichst wenigen Medienbrüchen“, ergänzt  Aian Hundegger, Manager und Expertise Lead bei der Management- und Technologieberatung Campana & Schott. Alle Beteiligten hätten entsprechend Zugriff auf die genutzten Informationen und Dokumente.

Nisha Lehmann untermauert die Vorteile von DevOps mit konkreten Zahlen: „Traditionelle Ops sind im Schnitt 41 Prozent zeitaufwendiger als DevOps, auch weil sie 21 Prozent mehr Zeit mit Bugfixing und Optimierung verbringen“, so die Managerin für Customer-Success bei Merkle, einer Agentur mit Fokus auf der Transformation der Customer-Experience. DevOps bearbeite Support-Fälle zudem 60 Prozent schneller und könne so ein Drittel mehr Zeit in die Verbesserung der Infrastruktur stecken. „Das bemerken auch die Unternehmen: Von den DevOps-Adoptern berichtet über die Hälfte von verbesserter Kooperation und fast jeder Vierte von höherer Code-Qualität.“ Ihr Fazit: DevOps sei effizienter und spare Kosten. Durch die Automatisierung von Konfigura­­tion, Bereitstellung, Tests, Warnmeldungen und Überwachung könne ein kleines DevOps-Team dieselben Anwendungen warten, für die früher ein viel größeres Team nötig war.

Häufig wird in einem Atemzug mit DevOps auch der Begriff Agilität genannt. Während es bei DevOps um Verantwortlichkeiten geht, versteht man unter Agilität Methoden wie Scrum oder Kanban. Diese ermöglichen es, schnell auf neue Anforderungen zu reagieren. Und hier zeigt sich auch, weshalb DevOps und Agilität meist zusammengehören: Die beiden Felder ergänzen sich hervorragend. „Während mit DevOps die notwendigen Strukturen geschaffen werden, sorgen die agilen Vorgehensmodelle für die passende Prozessgrundlage“, erläutert Lutz Keller von Consol.

Agilität spielt aber nicht nur in der Software-Welt, sondern in der Projektarbeit generell eine wichtige Rolle. Zwar liegen die Ursprünge zum Beispiel des Scrum-Ansatzes in der Software-Entwicklung, er ist jedoch universell einsetzbar. „Der ,Teile und herrsche‘-Ansatz, der den kurzen Scrum-Sprints zugrunde liegt, ist ja schon seit der Römerzeit verbreitet und lässt sich problemlos auf andere Gebiete anwenden“, so Vassil Hristov. Für ihn beschreibe Agilität, Aufgaben und Probleme systematisch anzugehen und zu lösen. Bei DevOps gehe es hingegen primär um die Aufteilung der Verantwortung und des Wissens innerhalb des Teams, mit einem zusätzlichen Fokus auf Automatisierung. „Es gibt durchaus agile Teams, die aus verschiedenen Gründen den DevOps-Ansatz nicht leben“, so Hristov, „genauso wie es Teams gibt, die noch ein Wasserfallmodell befolgen und trotzdem auf DevOps-Elemente im Alltag setzen.“

„Agilität ist die Fähigkeit eines Teams oder einer Organisation, trotz einer sich ständig verändernden Welt regelmäßig nutzenstiftende Ergebnisse zu erzeugen. Es zählt also nicht nur die schnelle Anpassungsfähigkeit, sondern auch der Fokus auf das Endergebnis“, erklärt Aian Hun­degger. DevOps hingegen sei das Mittel zum Zweck, um dieses Endergebnis zu erreichen – „also eine mögliche Methode im Produktentwicklungsbereich, kontinuierlich System-Updates aufzuspielen, ohne den laufenden Betrieb aufzuhalten“.

„Lasst uns mal schnell agil werden und unsere Produkte schneller auf den Markt werfen“ – so oder ähnlich denken viele Unternehmen. DevOps scheint momentan als eine Art Wunderwaffe angesehen zu werden. Doch ganz so einfach ist es nicht. Zunächst sollten sich Unternehmen darüber klar werden, welches Problem sie mit DevOps eigentlich lösen möchten, so der Rat von PwC. Ein fundierter Beweggrund sei das A und O, um eventuell auftretende Startschwierigkeiten zu vermeiden und alle Beteiligten zu überzeugen.

Sehr häufig wird DevOps vorrangig genutzt, um die Effizienz der IT zu erhöhen. Das ist jedoch zu kurz gedacht: Oberstes Ziel sollte sein, die Effizienz des gesamten Unternehmens zu steigern, indem Marktanforderungen frühzeitig erkannt und Kundenbedürfnisse erfüllt werden.

Der DevOps-Ansatz ist ideal, wenn es zum Beispiel da­rum geht, auf Software basierende Business-Prozesse schnell in die Praxis zu bringen. Wichtig sind Anpassungen sowohl in der Organisatio, etwa flache Hierarchien, als auch bei den Verantwortlichkeiten für den Roll-out eines Software-Produkts oder eines Dienstes. „Die Technologie ist im Zusammenspiel mit der Software-Entwicklung die Basis, damit dies möglich ist. Aktuell liegt ein Fokus auf den Betriebskosten. Hier verspricht DevOps ein Modell zu sein, das hilft, Kosten einzusparen“, so Frank Haumann von Red Reply. Dies gelte insbesondere dann, wenn man versucht, Kostenreduktionen im Bereich Operations zu realisieren, „in dem die Entwickler gemäß des Leitsatzes ,You build it, you run it‘ auch Verantwortung für den Betrieb der erstellten Lösung liefern“.

Übrigens: Die in vielen Unternehmen nach wie vor eingesetzten Legacy-Strukturen sind kein Hindernis für den DevOps-Ansatz, auch wenn im DevOps-Zusammenhang häufig von modernen Infrastrukturen wie der Cloud die Rede ist. „DevOps lässt sich auch für Legacy-Strukturen einsetzen“, ist Frank Haumann überzeugt, „weil es eine Kultur ist, die auf jede Art von Technik angewendet werden kann.“ Schwierig bis unmöglich werde es jedoch, eine DevOps-Kultur in stark regulierten Umfeldern wie der Gesundheitsbranche, dem Luftfahrtsektor oder in der Finanzindustrie einzuführen – „in diesen Bereichen bestehen oft sehr strikte Regularien, die von diversen Behörden überwacht werden.“

Nichtsdestotrotz wird DevOps – und vor allem das eingangs erwähnte SRE – häufig mit neuen Technologien wie Cloud, Containern und Microservice-Architekturen in Verbindung gebracht. Doch der fundamentale Ansatz hinter DevOps ist Vassil Hristov zufolge unabhängig von den Tools und dem Technologie-Stack. Er teilt die Meinung von Frank Haumann und sagt, dass „nichts dagegen spricht, auch bei Legacy-Systemen die Prozesse so umzustellen, dass die Verantwortung von Entwicklung und Betrieb von Software besser verteilt ist, Silos abgebaut werden und ein erhöhter Automatisierungsgrad gefördert wird“. Als Beispiel nennt er Gitlab und IBM, die an einer DevOps-Lösung für Mainframe-Entwickler arbeiten. „Das zeigt, dass der Ansatz durchaus auch bei Legacy-Technologien angewendet werden kann.“

Es gibt aber durchaus auch Felder, in denen der DevOps-Ansatz wenig sinnvoll ist. DevOps ist zum Beispiel nicht notwendig, wenn es keine oder nur langsame und vorhersehbare Veränderungen gibt. Das ist mitunter in manchen Behörden, im Bildungssektor, bei klassischen Software-Produkten, etwa im Office-Bereich,  oder auch in der Lebensmittelbranche der Fall. Komplexe und schnell zu verändernde Produkte, wie große Konzerne sie entwickeln oder einsetzen, erfordern jedoch DevOps. Denn hier geht der Erfolgsweg für Software-Releases oder Produkt-Releases nur über Trial und Error.

Ein weiteres Beispiel wäre Software, die beim Kunden vor Ort installiert ist – die also nicht zentral in der Cloud oder in wenigen Instanzen läuft. Bei einem Produkt, das beim Kunden installiert wird, braucht man natürlich viel mehr Ressourcen für den Betrieb der Software, gegebenenfalls auch für verschiedene Plattformen und verschiedene Versionen des Produkts. Ein kleines Team dürfte nicht in der Lage sein, die Software zu entwickeln und sie gleichzeitig auf Hunderten heterogenen Kundensystemen zu betreiben.

In der Theorie sind die Konzepte  DevOps und Agilität ziemlich attraktiv. Doch die Einführung im eigenen Unternehmen erfordert oft einschneidende Veränderungen hinsichtlich der Unternehmenskultur. Vor allem die herkommliche Art des Arbeitens mit streng abgegrenzten Kompetenzbereichen verträgt sich anfangs möglicherweise  nicht mit dem DevOps-Ansatz. Wichtige Bestandteile einer DevOps-Kultur sind Mut, Vertrauen und Aufgeschlossenheit – damit gemeint ist der berühmte Blick über den Tellerrand, technologisch wie menschlich. Zudem bedarf es einer positiven Fehlerkultur, die Raum für Experimente lässt, und einer mentalen Bereitschaft für Veränderung.

Darüber hinaus ist es in jedem Fall hilfreich, wenn ein Unternehmen bereits Erfahrung mit agilen Entwicklungsmethoden hat, bevor es sich mit DevOps beschäftigt. „In einem klassischen Wasserfallmodell wird eine Organisationsform, die häufiges Deployen, kurze Feedback-Loops und eine Gesamtverantwortung für Entwicklung und Betrieb unterstützt, kaum von Vorteil sein“, so Lutz Keller von Consol. Er betont, zunächst sei es wichtig, dass ein Unternehmen den Schritt zu DevOps auch tatsächlich gehen will. Nicht selten stehe das Management der Einführung von DevOps und den damit verbundenen umfangreichen Maßnahmen kritisch gegenüber. Oftmals seien weitreichende organisatorische Anpassungen notwendig, etwa beim Festlegen gemeinsamer KPI-Vorgaben, bei Planungsprozessen, dem Erwartungsmanagement, dem Personalbedarf oder beim Aufbau der für die Entwicklung nach DevOps-Methoden benötigten Skills. „Und dann sollte die nötige Zeit gewährt werden. DevOps ist eine Organisationsform, in die viele Unternehmen hineinwachsen oder hineingewachsen sind. Ein kontinuierlicher Verbesserungsprozess und eine positive Fehlerkultur sind dabei wichtige Bestandteile.“

Die Einführung von DevOps bedeutet also größere Veränderungen in der Organisation und rüttelt somit an den häufig lieb gewonnenen Strukturen. Das stößt bei den Beteiligten oft auf Unverständnis. In den ersten Stadien der Transformation sind daher Ausdrücke wie „die vom Betrieb“ oder „die von der Entwicklung“ noch an der Tagesordnung und sollten die Projektverantwortlichen und -beteiligten nicht gleich abschrecken. Wie in anderen Bereichen und Projekten in Unternehmen, so sorgt auch die Zusammenlegung von Teams bei der DevOps-Einführung für eine Auflösung vertrauter Hoheitsgebiete – Zuständigkeiten müssen teilweise abgegeben werden und neue Aufgaben kommen hinzu. Für so manchen Betroffenen kann das erst einmal schwierig sein.

Das bestätigt Aian Hundegger von Campana & Schott: „Das größte Hindernis sind traditionelle Strukturen.“ So müsse man es in vielen Unternehmen überhaupt erst einmal schaffen, dass Entwicklung und Betrieb zusammenkommen. Es fehle häufig das Verständnis dafür, dass für gute Ergebnisse Abstimmungen nötig sind. „Entsprechend sind strukturelle Voraussetzungen für die Zusammenarbeit zu schaffen, etwa Zeitfenster und Räumlichkeiten.“ Unternehmen sollten hier nicht zu viel vorgeben, da sich die Prozesse erst einspielen müssen. Dies dauert nach Hundeggers Erfahrung oft länger als ein Jahr. Der Reifegrad für DevOps entwickele sich erst durch viele kleine Schritte weiter.

Für Unternehmen jeder Größe ist es wichtig, sobald sie sich für eine DevOps-Kultur entschieden haben, konsequent und mutig am Ball zu bleiben. Dabei muss nicht gleich am ersten Tag ein großer Umschwung passieren – „viel eher sollte in kleinen Iterationen vorgegangen werden“, rät Lutz Keller. Für erste Gehversuche lohnt es sich oft, ein Pilotprojekt in einem Team zu starten.

Kleinere Unternehmen mit überschaubarer IT-Abteilung holen sich dafür am besten Hilfe von außen, denn es gibt viel zu beachten: Eine methodische Vorgehensweise stellt sicher, dass alle notwendigen Schritte umgesetzt und alle Beteiligten auch emotional mit ins Boot geholt werden. Die Liste der Aufgaben umfasst Bereiche wie Analyse, Definition von Meilensteinen und eines Ziels, Bestimmung eines Kernteams, Entscheidung für einen Technologie-Stack, Definition der Testverfahren, Festlegen geeigneter Tools und Methoden für ein wirklich agiles Projektmanagement und Software-Engineering sowie den notwendigen Know-how-Transfer.

Manager und Expertise Lead Aian Hundegger von Campana & Schott fügt hinzu, dass Unternehmen bei der Einführung des DevOps-Ansatzes zudem weitgehend automatisierte Technologien für die Produktintegration benötigen, die den laufenden Betrieb nicht beeinträchtigen. Dies erfordere Funktionen für Risikomanagement, schnelles Zurücksetzen zum vorherigen Systemstand sowie integrierte Tests und schnelle Fehlerbehebung. Zur Verbesserung der Qualität seien dann regelmäßige Messungen der Funktionalität, Performance und Fehlerquote nötig.

Ein häufiges Problem besteht in der Praxis darin, dass der Operations-Bereich keine agilen Methoden einsetzt, sondern transaktional arbeitet, meist mit einem Ticket-System. Das bremst die Software-Entwicklung aus, wenn es darum geht, neue Applikationen auszurollen, ob für Test- oder Produktivzwecke. „DevOps soll die Zusammenarbeit zwischen Entwicklung und Betrieb verbessern, sodass der Operations-Teil viel mehr eingebunden ist und nicht nur Tickets am anderen Ende der Leitung bearbeitet“, erläutert Roman Borovits, Senior Systems Engineer DACH bei dem Cloud-Sicherheits-Unternehmen F5.

Wie beschrieben, erfordert der DevOps-Ansatz eine Kultur mit geteilter Verantwortung. Das, so Aian Hundegger, bedeutet, „dass die Zuständigkeiten zwischen Entwicklung, Betrieb und Sicherheit nie strikt voneinander getrennt sind“. Jeder sei für den Bereich und das Gesamtprojekt verantwortlich.

Entwickler und Engineers sind zwar weiterhin Spezialisten auf ihrem Gebiet, jedoch müssen sie zunehmend über ein Verständnis der Zusammenhänge in anderen Bereichen verfügen. Immer wichtiger werden dabei auch Soft Skills, um Informationen zu teilen und Prozesse abzustimmen. Denn DevOps erfordert einen intensiven Austausch mit anderen Teammitgliedern und Abteilungen. Und das erweist sich manchmal als nicht leicht: So müssen Entwickler zum Beispiel gemachte Fehler offenlegen, damit sie nicht noch einmal passieren. Hinzu kommen die Offenheit für neue Prozesse und neue Arten der Zusammenarbeit sowie die Kundenzentriertheit.

Das Ziel sollte in jedem Fall sein, dass beide Bereiche im Unternehmen, also Software-Entwickler und Systemadministratoren, ein ähnliches Skill-Level erreichen. Natürlich kann nicht jeder ein Experte auf allen Gebieten werden und es ist auch unvermeidlich, dass ein Teammitglied sich mit einem Thema deutlich besser auskennt als andere. „Es sollte jedoch vermieden werden, dass Wissen so gebündelt wird, dass nur einzelne Individuen bestimmte Probleme lösen können“, betont Vassil Hristov von Zest Labs.

In der Praxis bedeutet das, dass sich einerseits der Java-Entwickler damit auseinandersetzen muss, wie man seine Applikation nicht nur lokal auf dem Laptop zum Laufen bringt und wie man erkennen kann, ob sie korrekt funktioniert, wenn sie auf einem Server läuft. Auf der anderen Seite sollte ein Systemadministrator in der Lage sein, bei Problemen in den Code einer Applikation schauen zu können und zu verstehen, was gemacht werden muss, um das Problem zu beheben. Kurzum: Es müssen unterschiedliche Technologien an Menschen mit unterschiedlichen Profilen herangebracht werden.

Die Automatisierung bei der Software-Bereitstellung schreitet immer schneller voran. Dadurch werden DevOps-Ansätze immer einfacher umsetzbar. Derzeit sind zwar noch Experten nötig, aber in ein paar Jahren wird DevOps zum normalen Handwerkszeug für Entwickler gehören, ist sich Aian Hundegger von Campana & Schott sicher. Dadurch würden die Grenzen zwischen den Bereichen zunehmend verschwimmen und die teamübergreifende Zusammenarbeit werde intensiviert. „Die Folge: Es gibt weniger Klein- und mehr Großprojekte, da alle auf dieselben Ziele hinarbeiten. Die Produktentwicklung erfolgt dabei aber verstärkt in kleinen Schritten anstelle eines großen Release.“

Mit dem Thema DevOps muss man sich als Unternehmen intensiv auseinandersetzen und die Einführung einer solchen Kultur ist nichts, was sich von heute auf morgen erledigen lässt. „DevOps ist ja schnell mal auf die Visitenkarte geschrieben – aber deswegen ist es noch lange nicht gelebte Kultur“, resümiert Roman Borovits von F5. Wichtig sei, zu verstehen, dass der Erfolg zu einem Großteil an den zwischenmenschlichen Faktoren hängt und nicht an der Implementierung oder Änderung eines Tools. „Jede Veränderung im Unternehmen kann positive und negative Effekte erzeugen. Es ist in jedem Fall anzuraten, einen angestrebten Kulturwandel professionell zu begleiten.“

Nach Ansicht von Nisha Lehmann von der Agentur Merkle wird sich das Thema DevOps in den nächsten zehn Jahren vor allem in großen Unternehmen weiter durchsetzen und zum unangefochtenen Standard der Projektbereit­stellung werden. Außerdem werde der Ansatz zunehmend auch benachbarte Technologieaspekte integrieren. Dazu zählten zum Beispiel Cybersicherheit, Künstliche Intelligenz und die Cloud.