DevOps: Eine Gefahr oder die Zukunft für IT-Service-Management?

Der digitale Wandel beeinflusst die Unternehmenslandschaft stark. Auch im IT-Service-Management stehen Entscheider zahlreichen neuen Herausforderungen gegenüber. Die Verzahnung von Entwicklung und Betrieb, auch Development and Operations, kurz DevOps, spielt eine immer größere Rolle. Häufig stellen sich die Verantwortlichen jedoch eine Frage: Ist DevOps eine Gefahr oder die Zukunft des IT-Service-Managements (ITSM)? Zu den Ursachen für etwaige Bedenken zählt unter anderem die Infragestellung der Stabilität des IT-Betriebes. Angebote aus der Cloud werden mit einem Angriff auf die eigene IT gleichgesetzt und gestandene ITIL-Change-Manager können sich eine weitere Verkürzung und Vereinfachung der Prozesse nicht mehr vorstellen. Dabei lässt sich bei Betrachtung des Bereichs „Entwicklung und Betrieb von Applikationen“ feststellen, dass es zahlreiche Gründe gibt, sich mit den Inhalten von DevOps zu befassen. Veränderungen im IT-Service-Management stellen dabei stets eine Notwendigkeit dar.

Alles im Rahmen

Der Druck auf die IT steigt. Im Gegensatz zu den bereits bestehenden Frameworks wie ITIL, COBIT oder Scrum existieren weder Rechteinhaber noch Institutionen als inhaltlicher Eigentümer von DevOps. Das bedeutet: Es gibt keine allgemeingültigen Definitionen und Vorgaben, was eine IT-Organisation tun sollte, um die DevOps-Ansätze effektiv umzusetzen. Mittlerweile hat sich eine eigene Community gebildet, die sich mit DevOps auseinandersetzt sowie die zugrunde liegende Philosophie stetig als Open Source weiterentwickelt. Die DevOps Agile Skills Association (DASA) unterstützt diese Bewegung mit einem Ausbildungskonzept und hat in diesem Zusammenhang sechs Prinzipien aufgestellt. Sie geben einen ersten Rahmen vor, wie eine IT-Organisation sich und vor allem ihre Mitarbeiter in Richtung DevOps entwickeln sollte.

Customer-Centric Action

Im Vordergrund des ersten Prinzips, Customer-Centric Action, stehen kundenzentrierte Aktionen im DevOps. Das bedeutet, dass die Feedbackzyklen mit Kunden und Anwendern immer kürzer und direkter werden. Nahezu alle Aktivitäten der Serviceerbringung orientieren sich mittlerweile am Kunden. Um hierauf optimal einzugehen, benötigen IT-Organisationen die Fähigkeit, sich kontinuierlich weiterzuentwickeln und schnell auf sich verändernde Einflüsse zu reagieren. Aus Sicht des ITSM bedeutet dies natürlich vor allem eins: Veränderung. Auch wenn Frameworks wie beispielsweise ITIL sowohl Kunden als auch Anwender mit der Serviceorientierung in den Mittelpunkt stellen, umfasst der DevOps-Gedanke noch mehr. Demnach erhält ein Team die volle Verantwortung für einen Service („You build it, you run it!“). Zudem wird die Organisation so gestaltet, dass das Feedback des Kunden viel intensiver eingeholt und verarbeitet werden kann. Allerdings haben in bestehenden ITSM-Organisationen die verantwortlichen Service Owner beziehungsweise -Manager selten ausreichend Mittel sowie Befugnisse, die Kundenbedürfnisse auch umzusetzen. Vielmehr ist durch ein Business-Service-Team rund um einen Service sowie ein Produkt in DevOps eine zielgerichtetere Gestaltung innerhalb einer DevOps-orientierten Organisation möglich.

Create with the End in Mind

Der zweite Grundsatz befasst sich mit der Überführung der klassischen prozessorientierten Vorgehensweise mit individuellen Rollen und Funktionen in eine produktorientierte Organisation. Das Ziel: Die Lieferung funktionierender Produkte an den Kunden sowie die Handlung nach einer entsprechenden Denkweise. Diese Zielsetzung manifestiert sich in der passenden Organisation. Die im ITSM anzutreffende Prozessorganisation mit Arbeitsteilung und Fokussierung auf Aktivitäten ist einer hohen Kundenzufriedenheit nicht zuträglich. Vielmehr verfolgen die einzelnen Prozessteilnehmer eigene Ziele und sind häufig nur an der Ausführung der ihnen beschriebenen Prozessschritte interessiert. Der Blick über den Tellerrand fehlt. In einer an DevOps-Ideen ausgerichteten IT-Organisation hingegen wandelt sich die Orientierung vom Spezialistentum hin zu einer Ausrichtung an Arbeit und Ergebnis. Auch die Organisation verändert sich dabei von der Funktionsorientierung zu einem teambasierten Aufbau. Zeitgleich wird der Fokus von Projekten auf Produkte verschoben. Arbeitsorganisation bezieht sich demnach zukünftig mehr auf Teams als auf Einzelne.

End-to-End Responsibility

Aus Sicht von DevOps bedeutet die Ende-zu-Ende-Verantwortung (Prinzip drei), dass die bisher bekannte Trennung von Entwicklung und Betrieb zugunsten von voll verantwortlichen Teams verändert wird. Die Teams entwickeln und betreiben Services, leisten Support und übernehmen demnach eine größere Verantwortung. In Betrachtung des ITSM fungiert diese Variante ergänzend zu den Prinzipien eins und zwei. Die herkömmlich in Prozessen und Abteilungen aufgeteilten Aktivitäten sowie die aufgesplittete Verantwortung werden in einem Service-Team zusammengeführt. Dieses sogenannte Business-Service-Team führt alle Tätigkeiten für die Entwicklung und den Betrieb eines Service durch. Ihm obliegt die gesamte Verantwortung.

Cross-Functional Autonomous Teams

Ein weiterer Aspekt in der DevOps-Philosophie ist die Weiterentwicklung agiler Ansätze mit crossfunktionalen, autonomen Teams. Als wohl bekanntestes Framework zählt Scrum, das ebenfalls auf diese Art der Organisation setzt. Um eine hochwertige Serviceerbringung sicherzustellen, ist ein umfassendes Set an Wissen und Fähigkeiten notwendig, sprich: Ein sehr gutes T-Shape-Profil wird anstelle des klassischen IT-Spezialisten benötigt. In der praktischen Umsetzung tauchen hier die ähnlichen Probleme auf, wie sie bereits im ITSM bekannt sind. Die Anforderungen an die Mitarbeiter wandeln sich noch stärker und es bedarf einer intensiven sowie umfangreichen Personal- und Organisationsentwicklung. Es gilt, auch die erfahrenen Mitarbeiter mitzunehmen und ihnen entsprechendes Know-how (beispielsweise Teamfähigkeit und Kommunikationsskills) an die Hand zu geben. Die Erfahrungen aus einer Neuausrichtung der Mitarbeiter an Prozess- und Serviceorientierung können anschließend auf Team- sowie Kundenorientierung angewendet werden.

Continuous Improvement

Beim Ansatz der kontinuierlichen Verbesserungen wird das Anpassen der modernen IT-Organisationen an die sich permanent verändernden Bedingungen thematisiert (Prinzip fünf). Dazu zählen beispielsweise Kundenanforderungen, technologische Rahmenbedingungen, Gesetze und Verordnungen. DevOps setzt dabei auf die Prinzipien von Lean Management, um Verschwendung zu vermeiden, Kosten zu senken und Liefergeschwindigkeiten zu erhöhen. Zudem rückt eine neue Fehlerkultur für Unternehmen in den Mittelpunkt, bei der die Lerneffekte aus Fehlern positiv bewertet werden:. Im Fokus steht die Förderung von Innovationen und Experimenten. So ergibt sich die Möglichkeit, die agilen Prinzipien und Erfahrungen zu integrieren. Kontinuierliche Verbesserungen sind in agilen Ansätzen stärker etabliert sowie in der alltäglichen Arbeit verankert.

Automate Everything You Can

Das sechste Prinzip setzt auf die Automatisierung aller Tätigkeiten. Damit werden unter anderem schnellere Lieferzyklen realisiert, die wiederum zu einem sofortigen Feedback durch die Kunden führen. Die Automation umfasst dabei nicht nur den Entwicklungsprozess, sondern auch die dazugehörige Infrastruktur. Der Begriff „Infrastructure as code“ beschreibt demnach eine neue Art der Servicelieferung. In Bezug auf das ITSM ist die Automation besonders positiv zu bewerten. Dabei wird die Lebenszyklusphase Service-Transition aktiv unterstützt und miteinbezogen. Zu den nützlichen Impulsen zählen die einfachere und sichere Aktualisierung des CMS, die bessere Unterstützung des Release-Managements sowie die stärkere Fehlervermeidung im Change-Management. Die Verlässlichkeit von Prozessen und deren Ergebnisse steigen mit dem Wachstum der Automatisierung.

Handlungsfelder

Die Prinzipien machen deutlich, dass es nicht ausreicht, DevOps allein mit einer Automatisierung beziehungsweise dem Aufbau einer Continuous-Delivery-Pipeline gleichzusetzen. Automation ist zwar ein wichtiger Bestandteil, muss jedoch um weitere Aspekte ergänzt werden. Durch die aufgeführten und in der Praxis im Einsatz befindlichen Frameworks ergeben sich verschiedene Handlungsfelder, die einer vollständigen Betrachtung und Umsetzung bedürfen. Auch die Schaffung einer entsprechenden Kultur für DevOps, die unter anderem die beiden unterschiedlichen Sichtweisen von Betrieb und Entwicklung aus traditioneller Sicht zusammenführt, zählt zu den wichtigen Aufgaben für Führungskräfte. Dafür sind Prozesse abzustimmen sowie eine passende Organisation aufzubauen. Zudem muss eine kontinuierliche Verbesserung als passende Mischung etabliert werden. Darüber hinaus gilt es, die Mitarbeiter, die bisher in traditionellen, klar abgegrenzten Strukturen gearbeitet haben, abzuholen und in die neue Arbeitsweise mit neuen Aufgaben und Verantwortlichkeiten zu transformieren und dabei aktiv zu begleiten.

Mitarbeiter mitnehmen, Innovationen fördern

Bei der Verwendung von DevOps stehen unterschiedliche Ziele im Fokus. So sollen zum einen Innovationen wie auch Produktivität gefördert, die Kommunikationsqualität gesteigert und zum anderen Administrationsaufwände reduziert werden. Letzteres führt dazu, dass mehr Freiräume für weitere Aufgaben sowie Innovationen und insbesondere für die kundenorientierte Ausrichtung der IT entstehen. Unternehmen sind angehalten, strategische IT zu betreiben, die zukunftsfähig und vor allem transparent ist. Eine erfolgreiche Umsetzung ermöglicht bis zu 40 Prozent Produktivitätssteigerung. Hierbei ist es jedoch stets von großer Wichtigkeit, die Beteiligten einzubinden.

Arbeit neu denken

In Zeiten des Wandels steht auch die Arbeit an sich vor Veränderungen. Mehr und mehr in den Fokus rückt rollenbasiertes Arbeiten. Unterstützend wirken Steuerungsinstrumente wie beispielsweise AQRO (kurz für Active Qualified Human Resource Organization), das Blind- und Fehlleistungen in einem Unternehmen deutlich reduziert und Transparenz sowie Freiraum für Kreativität und Innovation schafft. Dabei wird der Schwerpunkt von der Linien- auf die Projektorganisation und das agile Umsetzen von Themen verlagert. Die AQRO-Methode gestaltet das Umfeld der Mitarbeiter dabei so, dass diese konzentriert, fokussiert und ohne Unterbrechungen am Stück arbeiten und Aktivitäten umsetzen können. Dabei ist die Abteilung für Kunden, Kollegen und externe Partner jederzeit erreichbar. Pro Mitarbeiter wird so einerseits die Motivation deutlich erhöht sowie die Produktivität des Einzelnen im Durchschnitt um mehr als eineinhalb Stunden täglich gesteigert. Damit gewinnen Unternehmen wöchentlich fast einen ganzen Arbeitstag pro Mitarbeiter, der für zusätzliche Umsetzungen von Kundenanforderungen zur Verfügung steht. AQRO ist dabei eine Methode, die jede Rolle eines Mitarbeiters berücksichtigt und diesem auch genug Zeit einräumt, sodass sich Qualität und Effizienz erhöhen. So steigen in Zeiten der digitalen Transformation nicht nur die Produktivität und die Transparenz, es wächst auch die Innovations- und insbesondere die Umsetzungskraft sowie -geschwindigkeit der IT.

Die Rollen und Verantwortlichkeiten sind in dem Ansatz eindeutig geklärt und jederzeit flexibel anpassbar, sodass die Methode die stressfreie und risikominimierte Implementierung von DevOps wesentlich unterstützt. Irritationen sowie Verunsicherungen der Mitarbeiter werden bei der gleichzeitigen Verwirklichung von DevOps und AQRO vermieden, sodass die Vorteile von DevOps bereits beim Umsetzungsstart voll ausgeschöpft werden können. Dabei ist es sinnvoll, die Mitarbeiter in den Wandel mit einzubeziehen. Basis dafür ist entsprechendes Vertrauen, das Vorgesetzte gegenüber ihren Teams entgegenbringen müssen. Das verbessert die Zufriedenheit, das Wohlbefinden und damit auch die Motivation der Belegschaft. Das Ergebnis: höhere Produktivität und Kundenorientierung und dank gesteigerter Motivation auch verbesserte Qualität. Transparenz bezüglich der Aufgaben und Verantwortlichkeiten, welche die Mitarbeiter durch die Kombination von DevOps und AQRO erhalten, schaffen Sicherheit und einen definierten Handlungsrahmen. Das wiederum ist die Basis für Mitarbeitermotivation, Produktivität, Kreativität und Kundenorientierung.

Clever kombiniert

Oftmals stehen die Verantwortlichen einer Vielzahl von Problemen in Zusammenhang mit DevOps gegenüber. Eine der Schwierigkeiten ist die Durchführung des sogenannten „Mind Change“ bei den Mitarbeitern. Auch das Fehlschlagen des aktiven Änderungsmanagements stellt die Beteiligten vor Herausforderungen. Mit DevOps kommen neue Regeln – allerdings fehlt häufig noch das Verständnis, wie diese in der Organisation umzusetzen sind. Zudem sehen Manager und Mitarbeiter die neuen Regeln zumeist als reinen Luxus an. Diese Probleme können mithilfe der Kombination von DevOps und AQRO behoben werden. Denn der rollenbasierte Ansatz schafft die Voraussetzungen für mehr Transparenz und Innovationen. Aufgrund des Nutzens für die Mitarbeiter steigt die Erfolgsgarantie für den Mind Change in den Köpfen der Belegschaft ebenso wie für gelungenes Änderungsmanagement. Hinzu kommt die schnelle sowie verlässliche Implementierung neuer Regeln, die für den Erfolg absolut wichtig ist. In Kombination haben DevOps und AQRO vor allem ein Ziel: die Gewinnmaximierung mithilfe erhöhter Kundenorientierung und deutlich kürzeren Umsetzungsdauern durch die veränderte Arbeitsweise.

Rollen definieren

DevOps setzt dabei stets auf zuvor definierte Rollen. So können beide Seiten voneinander lernen und aufeinander zugehen. Der Service Owner ist für definierte Services verantwortlich und dient dem Kunden als Ansprechpartner für alle servicebezogenen Belange. Seine Verantwortung erstreckt sich über den gesamten Lifecycle des jeweiligen Services, reicht demnach von der Initiierung, Planung und Überführung in den Betrieb (Transition) über die Pflege der Serviceinhalte bis zum Support für die Anwender. Der Product Owner hingegen hat die konkrete fachliche Steuerung des Projektteams im Auge und fokussiert unter anderem auch auf einen optimalen Return on Investment für die Produktentwicklung. Den Business-Service-Teams mit der Produktverantwortung in Richtung Kunde und Anwender steht ein Plattform-Team zur Seite, das die Technologie für die Services liefert. Damit kann das IT-Service-Management DevOps nicht als Gefahr bewerten sondern vielmehr der Entwicklung hin zur Schatten-IT entgegenwirken und auch Entwicklungsteams ohne interne IT einen Betrieb anbieten.

DevOps als Zukunft des IT-Service-Managements

Die Betrachtung der Thematik macht deutlich: DevOps ist als eine Möglichkeit zu verstehen, das IT-Service-Management um agile und schlanke Prinzipien zu bereichern. Mithilfe der Prinzipien sind ITSM-Organisationen reaktionsfähiger und können die eigenen Erfahrungen besser einbringen. Klassische Ziele und Aktivitäten aus dem ITSM in DevOps verfeinern zeitgemäße Ansätze. IT-Operations- sowie Change-, Configuration- und Release-Management können beispielsweise durch die Automatisierung eine kontinuierliche Lieferung und eine Erhöhung des Releasezyklus erreichen und die erfolgreiche Produktivsetzung stärker absichern. Eine durch das gesenkte Fehlerrisiko verbesserte Überführung der Services in den operativen Betrieb hilft auch den Prozessen im Incident- und Problem-Management. Gerade hierbei ist es wichtig, dass die Mitarbeiter rollenbasiert arbeiten und wissen, welche Verantwortlichkeiten und Aufgaben sie in den jeweiligen DevOps beziehungsweise ITSM-Rollen haben, um diesen gerecht werden zu können.

Wenn DevOps in Verbindung mit ITIL als Framework und Vorgabe verstanden wird, gilt das in diesem Falle nicht. Auch wenn die Umsetzung mit mehr Aufwand verbunden ist, liefert DevOps keine Blaupause für die erfolgreiche Bewältigung der Schwierigkeiten, sondern gilt als Vorschlag für eine individuelle Anwendung. Die im agilen Umfeld häufig anzutreffenden Communities of Practice stehen auch für einen Brückenschlag zwischen Entwicklung und Betrieb zur Verfügung. In Gruppen wie diesen kann die Orientierung an DevOps-Prinzipien starten. Darauf folgt die gesteigerte Berücksichtigung der Betriebsinteressen. Die Anforderungen des Betriebs werden dann in der „Definition of Done“ der agilen Entwicklungsteams berücksichtigt. So lässt sich sicherstellen, dass die agile Softwareentwicklung schon von Beginn an eine reibungslose Produktivsetzung sowie einen ordnungsgemäßen Betrieb im Fokus hat, auch wenn noch keine Business-Service-Teams rund um den Service etabliert sind. Gleiches gilt für die Akzeptanzkriterien, die konkrete Kundenanforderungen formulieren und eine Erfüllung der Kundenwünsche auch im Betrieb gewährleisten müssen.

Vom Hasen und Igel

Betrachtet man nun die bisher erwähnten Prinzipien, so lässt sich feststellen, dass bei konsequenter Umsetzung der DevOps-Philosophie vom Ansatz einer bimodalen IT abzuraten ist. Denn: Es hilft nicht, einfach nur schneller zu sein. Das zeigt schon die Geschichte vom Hasen und Igel: Nur wer mit Köpfchen und im Team arbeitet, erreicht langfristig seine Ziele und eine bessere Work-Life-Balance. Im Fokus stehen Weiterentwicklung und Verbesserung. Zusätzliche Faktoren wie beispielsweise „Schnelligkeit“ kommen dann wie von selbst. Hochperformante IT-Organisationen erreichen die Codelieferung ums Zweihundertfache regelmäßiger, erzielen eine 24-mal schnellere Wiederherstellung bei Fehlern und haben eine über 2.500-fach kürzere Durchlaufzeit. Das Ergebnis: Stabilität und Geschwindigkeit lassen sich verbinden.

Vielmehr gestaltet die DevOps-Philosophie die Arbeit des IT-Service-Managements zeitgemäßer und erfolgreicher. Die Ziele und Erfahrungen aus bewährtem ITSM sollten dabei jedoch stets im Rahmen einer agilen Organisationsentwicklung mit erfahrenen Coaches in eine DevOps-Organisation überführt werden.

Quelle: Borgmeier Public Relations