DevOps als Aufgabe für das Change-Management

DevOps hat den Hype-Status hinter sich gelassen und ist in der IT-Welt angekommen. Für die Zusammenarbeit zwischen Software-Entwicklern (Development) und IT-Administration (Operations) ist in der täglichen Praxis allerdings mehr notwendig, als nur ein paar Meetings und Tools aufeinander abzustimmen. Das Kunstwort DevOps steht vielmehr für einen Schulterschluss zwischen den Mitarbeitern dieser beiden Bereiche.

Das Konzept dahinter versucht, den traditionellen Graben zwischen diesen beiden wichtigen IT-Sektoren zu überwinden, der schlicht aus Zielkonflikten resultiert: Der Entwicklungsbereich ist stark daran interessiert, die implementierten Features möglichst kurzfristig an die Nutzer der Software auszuliefern. Dem IT-Betrieb ist vorrangig an einem kontinuierlichen und sicheren Betrieb der gesamten IT-Landschaft gelegen. Software-Updates stellen in diesem Sinn stets einen Eingriff in das laufende System dar, der dessen Stabilität bedroht. Statt kurzfristiger und häufiger Releases werden lange Laufzeiten und umfassend geplante Updates bevorzugt.

Diese lange geläufige Form der Arbeitsteilung scheint überholt zu sein. Software hat in der digitalen Welt einen ganz anderen Stellenwert als noch vor einigen Jahren. Statt lediglich ein digitales Werkzeug zu sein, ist Software heute sehr oft der Treiber von Innovationen. Unternehmen konkurrieren um die besten Produkte auf dem Markt und setzen dabei zunehmend auf innovative IT-Lösungen. Damit Software diese Aufgabe erfüllen kann, muss sie passgenau und zeitnah zu Verfügung stehen. Aufgrund einer hohen Dynamik in vielen Märkten nimmt auch der Bedarf an kurzfristigen Anpassungen und spezialisierten Software-Lösungen zu.

Mit anderen Worten: Für langwierige und komplizierte Prozesse zur Erhebung der Anforderungen, einer umfassenden Planung, einer lang andauernden Implementierung bis hin zu einer schrittweisen Einführung in den Produktivbetrieb ist heute in aller Regel keine Zeit.

DevOps zielt genau darauf ab, die Prozesse in Unternehmen von der Entwicklung über die Bereitstellung in der Produktion bis zur Wartung von Software so miteinander zu verzahnen, dass die beschriebenen Herausforderungen gelöst werden können. Das wird nur dann gelingen, wenn die gegenläufigen Ziele einer agilen Software-Entwicklung und der Anspruch eines sicheren, stabilen Betriebs in Einklang gebracht werden. Die Vorteile von DevOps lassen sich daher so zusammenfassen:

Geschwindigkeit: Bei richtiger Anwendung ist man in der Lage, den Kunden schneller innovative Software-Lösungen bereitzustellen. Im Zuge der digitalen Transformation kann dies ein wichtiger Faktor im Wettbewerb sein. Auch Updates können schneller in die Produktion gebracht werden.

Zuverlässigkeit: IT-Lösungen werden insgesamt zuverlässiger, wenn es gelingt, sie schneller an sich ändernde Bedingungen anzupassen.

Zusammenarbeit: Die Nutzer der IT unterscheiden nicht nach Entwicklung und Betrieb. Die künstliche Schnittstelle wird überwunden und den Anwendern wird ein durchgängiges Produkterlebnis geboten. Die Vermeidung von Schnittstellen erhöht die Effizienz.

DevOps setzt auf neuere technologische Ansätze wie Continuous Integration, Continuous Delivery, Microservices und Infrastruktur in Form von Code. Diese stehen jedoch nicht im Vordergrund.

DevOps ist keine Technologie, sondern vielmehr eine Kultur im Unternehmen beziehungsweise im betreffenden Projekt. Diese Kultur muss von allen Beteiligten gewollt und gelebt werden. Die Grundpfeiler sind gegenseitiger Respekt und Vertrauen. Angetrieben werden die Beteiligten von dem gemeinsamen Ziel, das Projekt ständig zu verbessern. Erfolge und Misserfolge werden nicht einzelnen Personen, sondern dem Team zugeschrieben. Voraussetzung ist, dass sich die Personen und das Team als Ganzes stetig den neuen Herausforderungen anpassen.

DevOps ist zwar ein Thema, das in der IT angesiedelt ist, hat aber im Kern mit der Entwicklung der Organisation zu tun, Stichwort „Change-Management“. Change-Management beschäftigt sich mit Problemen und Fragen hinsichtlich der Veränderungen der Prozesse in einem Unternehmen. Es plant die Veränderungen, führt den Wandel durch und  stabilisiert und kontrolliert die erreichten Ergebnisse. Im Mittelpunkt stehen die Menschen. Strukturen und Prozesse können sich nur ändern, wenn die Mitarbeiter für die Veränderungen offen sind und sie unterstützen.

Oft stehen aber nur wenige Beteiligte den anstehenden Veränderungen ohne Vorbehalt gegenüber. Die meisten reagieren mit Widerstand. Es liegt in der menschlichen Natur, dass Veränderungen als unbequem, überraschend, beängstigend und bedrohlich angesehen werden. Mehrere Gründe sprechen für eine - zunächst - ablehnende Haltung, zum Beispiel fehlendes Problemverständnis, mangelndes Vertrauen in die Führungskräfte, ungenügende Kommunikation, Angst vor zusätzlicher Arbeit und die Sorge, nicht ausreichend qualifiziert zu sein.

In der Praxis gilt es, diese Widerstände schrittweise abzubauen. Change-Management basiert darauf, die Mitarbeiter offen über die Ursachen des Wandels zu informieren, ihnen die Notwendigkeit klarzumachen und sie am Wandel zu beteiligen.

DevOps ist schon länger ein Trendthema. Trends implizieren stets große Erwartungen. Bei DevOps bestand die Hoffnung darin, dass sich damit wie von Geisterhand die Planungs- und Abstimmungsprobleme zwischen Entwicklung und Betrieb bei der Bereitstellung von Software auflösen würden. Man müsse nur ein paar Tools einführen, etwas besser zusammenarbeiten, ein paar Abstimmungen etablieren und schon gehe es voran. Die Realität aber sieht anders aus. In einer Umfrage des Analystenhauses  Gartner gab ein Großteil der Befragten an, dass DevOps ihre Erwartungen nicht erfüllt hat. Auch Trendmesser wie der Gartner Hype Cycle sehen DevOps als Thema offenbar wieder in der Versenkung verschwinden. Ist das Ganze also erledigt und kehren wir zur Tagesordnung mit den üblichen Zuständigkeiten zwischen den besagten Abteilungen zurück? Auf keinen Fall!

Da DevOps kein Thema ist, das durch einen technischen Ansatz getragen wird, erledigt es sich auch nicht von selbst. An der Notwendigkeit der intensiven Zusammenarbeit hat sich nichts geändert. Die Anforderungen an Software, deren Entwicklung und Bereitstellung haben sich nun einmal grundlegend gewandelt, sodass man die sich daraus ergebenden Fragen nicht mit den Konzepten von gestern beantworten kann. DevOps ist lediglich ein Begriff für eine sich ändernde Arbeitsweise in der IT. Dass diese Änderungen nicht leicht und ohne Reibung erfolgen können, versteht sich von selbst. Änderungsprozesse brauchen Zeit und vor allen die Bereitschaft und Unterstützung des Managements. Gerade größeren Unternehmen mit etablierten Organisationstrukturen und Prozessen fällt ein Wandel, wie ihn die Etablierung von DevOps darstellt, schwer. Gelegentlich wird auch mit den Besonderheiten der deutschen Arbeitskultur argumentiert. Folgende Gründe erschweren aus diesem Blinkwinkel den notwendigen Kulturwandel:

Expertentum statt Generalisten: Das hohe Maß an Spezialisierung wie Programmierer, Administrator, Tester, Architekt ist nicht immer hilfreich in einem DevOps-Team. Die Teammitglieder müssen lernen, auch inhaltlich über den Tellerrand zu blicken. Die Mitarbeiter sollen Experten auf ihrem Gebiet bleiben, aber sich auch für die Belange des gesamten Prozesses öffnen und dafür verantwortlich sein.

Strenge Hierarchien: Teams haben eine kaum ausgeprägte Hierarchie. In DevOps-Teams sollen die Mitglieder vertrauensvoll zusammenarbeiten. Etablierte Hierarchien sind hinderlich. Führungskräfte müssen in der Lage sein, die Dev­Ops-Transformation voranzutreiben. Wichtig sind Experimentierfreude, visionäres Denken und Inspiration der Teammitglieder.

Bürokratie: Was nicht dokumentiert ist, existiert nicht. Unternehmen, die diesem Credo folgen, werden es schwer haben, eine schnittstellenlose Zusammenarbeit zu etablieren. Es geht nie um formale, sondern stets um inhaltliche Fragen. Bürokratische Hürden, zum Beispiel interne Dokumentationen, sollten auf ein minimales Maß reduziert werden.

Perfektionismus: Die kurzfristige und regelmäßige Auslieferung von Software hat das Ziel, den Kunden schnell an der Weiterentwicklung des Produkts teilhaben zu lassen. Der Grundgedanke lautet: Die Vorteile eines schnellen Releases sind größer als die möglichen Nachteile, dass die aktuelle Version noch nicht vollständig ausgereift ist. Kleinere Fehler im Betrieb werden wiederum durch das nächste kurzfristig folgende Update behoben.

Diese Vorgehensweise kann dem traditionellen Anspruch und der lange gepflegten Praxis widersprechen, dass man nur umfassend erprobte Produkte zum Kunden gibt. Kunden und Anbieter müssen lernen, dass die Teilhabe an frühen Innovationen im Wettbewerb oft mehr wiegt als ein ausgereiftes, aber veraltetes Produkt.

Die Punkte unterstreichen, dass DevOps eine Aufgabe des Managements ist und kein technischer Ansatz. Der Lernprozess muss auch deswegen von der Entscheiderebene aus ini­tiiert werden, sonst bleibt er stecken.

Zwar muss eine DevOps-Strategie stets unternehmens- oder projektindividuell umgesetzt werden, dennoch lassen sich einige grundsätzliche Empfehlungen ableiten:

Ein Ziel, ein Weg, ein Prozess: Das Ziel ist die schnelle Bereitstellung qualitativ hochwertiger Software. Daran müssen Entwickler, Tester und Betriebler arbeiten. Es sollte ein durchgehender Prozess von der Anforderungsdefinition bis zur Überwachung der Produktion aufgestellt werden. Durchgängigkeit vermeidet Schnittstellen durch Zuständigkeiten in der Organisation. Anders gesagt: Zuständigkeit und Verantwortung enden nicht mit der Erledigung von Aufgaben, die zur eigenen Profession passen.

Mit einem Projekt starten: Bevor DevOps in der gesamten Organisation umgesetzt wird, ist es ist ratsam, die Arbeitsweise mit einem überschaubaren Projekt und einem kleineren Team zu erproben. Das Management muss dabei die neuen Wege des Teams ausdrücklich unterstützen. Wie bei jeder Veränderung wird es Widerstände zu überwinden geben. Das Management kann hier seine Erfahrungen aus anderen Veränderungsprojekten gewinnbringend einsetzen.

Team bilden: Veränderungsprozesse leben von den Personen. Um erfolgreich ein Projekt auf der Basis von DevOps zu etablieren, braucht es ein Team aus den richtigen Leuten. Initial kann es sinnvoll sein, die Verantwortlichen zusammenzubringen. Das können zum Beispiel ein Vertreter des Managements, ein Projektmanager, ein Entwicklungsleiter und ein Verantwortlicher aus dem operativen Bereich sein. Das interdisziplinäre Team muss bewusst geformt werden.

Tooling ist sekundär: Natürlich wird man neue Tools einsetzen. Auch neue Techniken des Deployments wie Docker vereinfachen die Bereitstellung von Software erheblich. Doch eine Entwicklung hin zu DevOps kann man nicht kaufen, die Anschaffung von Tools löst noch keine Pro­bleme.

Fortschritt messen: Man muss die Entwicklung verfolgen und die Fortschritte messen. Anhand von Kennzahlen wie der Zahl der Releases oder der Zeit von der Anforderung bis zur Produktion eines Features geben bei aller Unschärfe eine Orientierung über erreichte Erfolge.

Bei der Umsetzung der theoretischen Ansätze in die Praxis muss man an vielen Stellen pragmatisch vorgehen. Ganz im Sinn eines agilen Arbeitens kann die Planung für weitere Zeiträume nur grob sein und muss mit dem Projektfortschritt immer wieder angepasst werden. In vielen Bereichen wird DevOps auch einfach gelebt, etwa wenn Entwickler den kompletten Lifecycle einer Software betreuen. In diesen Fall ist das Ziel selbstverständlich auch erreicht, unabhängig davon ob man von DevOps spricht oder nicht.

Nehmen wir den Bereich IT-Dienstleistungen. Deren Geschäftswelt verändert und erweitert sich im Rahmen der digitalen Transformation. Die Innovationsfähigkeit der IT wird in Zukunft einen entscheidenden Beitrag dazu leisten, wie erfolgreich ein Unternehmen auf den Märkten agieren kann.

Software-Anbieter und Software-Entwicklungsunternehmen müssen sich neu ausrichten und können sich nicht länger ausschließlich auf die technischen Aspekte fokussieren. Gefragt sind vielmehr ganzheitliche Lösungen, die Probleme unter Einbeziehung der Möglichkeiten der Digitalisierung neu lösen.

Folgt man diesem Gedanken, dann wird klar, dass DevOps hier eine wichtige Rolle spielen muss. Die IT kann den gewünschten Beitrag nur leisten, wenn sie umfassende Lösungen von der Idee bis hin zum Betrieb bereitstellt.

DevOps ist keine technische Erfindung, sondern die Antwort auf die erforderlichen Anpassungen bei der Konzeption, der Entwicklung und dem Betrieb von Software. Statt in Abteilungen und Zuständigkeiten zu denken, ist es erforderlich, dass man dem Kunden eine durchgängige Lösung bietet. Software ist die Ressource der modernen Produktion.

Wann ist DevOps in der Praxis angekommen? Ganz einfach: Wenn niemand mehr darüber redet, das heißt, wenn es selbstverständlich geworden ist, dass das Team vom Konzept bis zum Support zuständig ist. Das Team sind wiederum alle Mitarbeiter. Den Wandel muss das Management initiieren und begleiten. Das Unternehmen muss den Weg zur Kulturveränderung bereiten.

Tim Friedrich ist Head of Operations and Support bei ApiOmat, Anbieter einer Multi-Experience-Plattform. Im Interview be­gründet er, warum DevOps einen ganzheit­lichen Ansatz erfordert.

com! professional: DevOps zielt auf eine verbesserte Zusammenarbeit von Development (Dev) und Operations (Ops). In welchen Projekten spielt das bei Ihrer Arbeit eine Rolle?

Tim Friedrich: Die meisten unserer Mitarbeiter sind von Hause aus Entwickler. Dennoch wollen wir den kompletten Lifecycle unterstützen und können dabei nicht formal an einer Aufgabentrennung festhalten. Bei den Mitarbeitern handelt es sich gewissermaßen um ein autonomes Team, das sich selbst um die eigene Infrastruktur kümmert. Dadurch werden künstliche Schnittstellen und Wartezeiten vermieden.

Friedrich: Die Mitarbeiter des Teams übernehmen neben den Aufgaben der Entwicklung nun auch einige Aufgaben, die man nach dem bisherigen Verständnis dem IT-Betrieb zugeordnet hätte: das Festlegen der Deadlines zur Bereitstellung, das eigentliche Deployment inklusive der Veröffentlichung des Projekts in den Produktivbetrieb und Teile des Supports im Live­Betrieb.

Friedrich: Es genügt nicht mehr, einfach „nur“ Software-Entwickler zu sein. Um den gesamten Software-Lifecycle abzudecken, sind auch umfassende Kenntnisse in Theorie und Praxis über den IT-Betrieb inklusive Bereitstellung, Produktion und Support notwendig. Die Mitarbeiter müssen stets bereit sein zu lernen und ihr Wissen auch in für sie bisher unbekannten Domänen zu erweitern.

Friedrich: Der Kunde braucht keine einzelne Software. Er benötigt eine umfassende digitale Lösung für sein spezielles Problem. DevOps vermeidet Schnittstellen zwischen den Zuständigkeiten und beschleunigt den gesamten Prozess erheblich. Das spart letztendlich auch Kosten, vor allem aber stellt es die Lösung zeitnah bereit und verschafft möglicherweise Wettbewerbsvorteile.

com! professional: Gibt es Tools, die bei Ihren Projekten zum Erreichen der DevOps-Ziele beitragen?

Friedrich: Als Erstes ist Docker zu nennen. Die Virtualisierungs-Software revolutioniert quasi den gesamten Prozess von der Entwicklung bis zum Deployment. Damit sind wir in der Lage, die gesamte notwendige Infrastruktur in allen Phasen effektiv und leichtgewichtig zur Verfügung zu stellen. Andere Tools, wie Jenkins als Build-Werkzeug, verwenden wir projektindividuell.

Friedrich: DevOps geht mit agilem Arbeiten Hand in Hand. Alle Beteiligten müssen diesen Weg wollen und sich auf Veränderungen und eine ganzheitliche Zuständigkeit einlassen.