DevOps: Überleben zwischen ITIL® & Agilität

(ITIL® ist ein eingetragenes Warenzeichen der AXELOS Limited.)

Sind DevOps und ITIL® unvereinbar?

Nach Meinung einiger Leute sind DevOps und ITIL® miteinander unvereinbar.
Vorneweg: Es ist definitiv kein „Free Lunch“, DevOps in einer ITIL®-geprägten IT-Service-Organisation zu etablieren – womöglich noch in Kombination mit agilen Vorgehensweisen – umgekehrt kann es, wie in meinem Buch „DevOps Strategies“ gezeigt, gerade für traditionelle IT-Service-Organisationen vorteilhaft sein, gegenüber DevOps-getriebenen Veränderungen offen zu sein und somit längst fällige Veränderungen einzuleiten.

Worin soll die Unvereinbarkeit liegen?

Du solltest Dich fragen, worin genau denn diese Unvereinbarkeit liegen möge, bevor Du Dich auf die Mission begibst, DevOps in einer Organisation einzuführen, die nach in ITIL® beschriebenen Best Practices organisiert ist.

Man könnte argumentieren, dass DevOps denselben Bereich adressiert, wie es auch die ITIL® Service Lifecycle Stage „Service Transition“ tut. Während ITIL® die Prozesse, Funktionen, Rollen und KPIs beschreibt, behandeln DevOps & Continuous Delivery die weichen Faktoren (CALMS) und die automatisierte Integration sowie Auslieferung von Software. Allerdings behandelt DevOps die Software-Entwicklung nicht als Black-Box, sondern betrachtet Software bereits im Quellcode-Stadium, der am Anfang einer jeden Continuous Delivery steht.

Für ITIL® existiert Software – grob gesagt – nur als Deploy-bares und hoffentlich wohldokumentiertes Software-Paket, dass es zu installieren und zu betreiben gilt, einschließlich der Einspielung periodischer Maintenance-Releases.

Aus alleiniger Sicht der (insbesondere agilen) Software-Entwicklung können und werden sich der Change Management-Prozesse weit einfacher gestalten können, als in ITIL® beschrieben. Oder anders -richtiger- ausgedrückt: Die in ITIL® beschriebenen Prozess-Schritte und Funktionen können in Bezug auf die Software-Entwicklung soweit verschlankt und entrümpelt werden, dass sie auch agilen Software-Entwicklungsprozessen gerecht werden
Keinesfalls darf man aufgrund einer falsch verstandenen „ITIL®-Kompatibilität“ versuchen, krampfhaft jeden Prozess-Schritt und jede in ITIL® erwähnte Betriebsfunktion auch im Unternehmen abzubilden- Es stellt sich dem Autor wie eine Krankheit dar, wenn Organisationen krampfhaft meinen, die i ITIL® beschriebenen Prozesse, Funktionen und Rollen 1:1 umsetzen zu wollen.

Diese Punkte alleine würden eher für die Vereinbarkeit, mindestens aber für eine mögliche Koexistenz von ITIL® und DevOps und einem Berührungspunkt sprechen. Dieser wäre der erwähnte Transition Lifecycle Phase.

Aber es gibt noch einen anderen Aspekt:

DevOps entstammt der agilen Software-Entwickler-Szene Szene, während die ITIL®-Bücher nur den IT-Betrieb im Fokus haben.
ITIL® erkennt zwar das Problem von Silo-Strukturen, geht aber weiterhin von funktional getrennten Teams aus – cross-funktionale Teams, wie in der agilen Welt propagiert, sind ITIL® fremd.
Allerdings sind die in ITIL® beschriebenen Best Practices eben nur dies – Best Practices, die keinen Anspruch auf Anpassung und Veränderung haben.

Antipattern bei der DevOps-Einführung in konventionell aufgestellten Unternehmen

Die Tatsache, dass sich zur Sicherstellung eines ordnungsgemäßen IT-Betriebes funktional getrennte Teams und Strukturen etabliert haben, muss nicht heißen, dass dies immer so bleiben muss. Diese Trennung geht bisweilen sehr weit – auch über die ITIL® Best Practices hinaus, wenn z.B. DNS-Einträge und IP-Adressen in verschiedenen Abteilungen vergeben und verwaltet werden. Derartige Strukturen haben mit effizienter Organisation nichts zu tun, sind aber gar nicht so selten, wie der Autor aus eigener Erfahrung weiß. Sie stehen nicht nur agilen Vorgehensweisen im Weg, sondern auch der Effizienz herkömmlicher Organisationsstrukturen und -Verfahren. Mit sind mehrere IT-Service-Organisationen bekannt, in denen die definierten Workflows nur dann funktionieren, wenn:

  •  Sich die Vertreter der beteiligten Departments/Teams inoffiziell zu kurzen Meetings treffen, In denen der Staus der jeweiligen Aufgabe festgehalten wird
  •  Alle beteiligten ihre Commitments erneuern
  •  Und die vielfältigen Impediments identifiziert und angegangen werden.

Wenn es trotz definierter Prozesse und Workflows nur auf der Basis inoffizieller Kommunikation und jeder Vorgang in einen „Hidden Process“ ausartet, kann die Organisation -überspitzt gesagt- auch gleich SCRUM im Service Management einführen…. Let’s give it a try.. Die Organisation könnte nun an den Stellen mit dem höchsten durch übermäßige funktionale Trennung hervorgerufenen Leidensdruck ansetzen.

DevOps-Antipattern 1: Beibehaltung oder Neueinführung funktional getrennter Teams

Aber auch ohne die Einführung agiler Vorgehensweisen in Teilen oder in der gesamten „ITIL®-Organisation“ wird es im Bereich des Produktionsüberganges (Transition) zur Zusammenstellung von (neuen) Teams aus Software-Entwicklern, DevOps-Engineers und Operators kommen.

D.h. es werden u.U. andere Teams Personen abgeben müssen oder verlieren Personen, insbesondere dann, wenn die funktionale Trennung zwischen Teams aufgehoben werden sollen. Um diesen „Verlust“ zu begrenzen und altgediente Mitarbeiter auf weiterhin mit Führungsposten zu versorgen, kommt es dann regelmäßig zum Aufbau neuer Silo-Strukturen. z.B. in Form von DevOps-Teams – einem Widerspruch in sich.

Derartige „irre“ Management-Aktionen zu stoppen ist schwierig, denn es geht um Einfluss, Geld und Gesichtswahrung.

Es ist leider so, dass höhere Gehaltsklassen automatisch mit Personalführungsaufgaben einher gehen. Dabei scheint es oftmals unerheblich zu sein, wie schlecht die Personalführung ist. Mit hervorragender fachlicher oder technischer Leistung lässt sich gemeinhin nicht so viel Geld verdienen wie mit mieser Menschenführung. Derartige Unternehmen haben erhebliche Probleme motivierte Spezialisten für DevOps und agile Entwicklung anzuwerben, während das Management an den ineffizienten Strukturen und Teamleitern festhält.

Gesellschaften mit weniger starren stark hierarchischen Strukturen sollten es leichter haben, solche Änderungen durchzuführen als die noch deutlich stärker hierarchisch geprägten Gesellschaften aufstrebender Staaten. Allerdings sehe ich diesen Wettbewerbsvorteil schwinden.

DevOps-Antipattern 2: Verfehlte Sourcing-Strategie

Ein weiteres Antipatteren bei der DevOps-Einführung ist es, den Titel des DevOps-Engineers oder „DevOps“ an vorhandenen Personen zuzuweisen, ohne das oder bevor diese die notwendigen Qualifikationen erlangt haben – und diesen Mitarbeitern dann nicht die notwendigen Weiterbildungsmaßnahmen angedeihen zu lassen.

D.h.: Bei der DevOps-Einführung muss sich immer zusätzlichen personal, zumindest kurzzeitig als externe Mitarbeiter, aufgebaut werden:

  • Entweder handelt es sich hierbei um bereits qualifizierte DevOps-Mitarbeiter .
  • Oder um konventionelle Fachkräfte, damit bereits vorhandene Mitarbeiter die Zeit zur Weiterbildung erhalten

An Betriebsprozessen interessierte Software-Entwickler und Software-Architekten bringen oft den Großteil der notwendigen Voraussetzungen für einen DevOps-Engineer bereits mit, während altgediente Service-Management-Spezialisten und Admins eine ungleich steilere Lernkurve bewältigen müssen, wenn es um die Aneignung von Kenntnisse in Software-Entwicklung geht. Ich bitte um Nachsicht, wenn diese Aussage sehr verallgemeinernd klingen – in vielen Fällen weisen sie aber in die richtige Richtung. Es müssen gezielt Mitarbeiter mit Potential gefördert und gefordert werden, ohne Rücksicht auf vorhandene Teamgrößen und Verantwortungsbereiche.

TL;DR

  1. Die DevOps-Einführung hat weitreichende Konsequenzen, ist nicht umsonst und mit Änderungen von Personalstrukturen verbunden. Diese werden von den betroffenen Mitgliedern der Team- und Abteilungsleiter-Ebene oft nur widerwillig akzeptiert, wenn diese Umstellungen mit Nachteilen für diese Personen verbunden sind.
  2. Die Integration von DevOps in konventionellen IT-Service-Strukturen scheitert oft am mangelnden Willen, die nach ITIL® strukturierten Prozesse zu entschlacken und unnötige funktionale Trennungen aufzuheben.
  3. Ein weiteres Impediment bei der DevOps-Einführung stellt eine verfehlte oder nur halbherzige Sourcing-Strategie dar – sowie für bereits vorhandenes als auch neues Personal.

Wenn diese und andere Hindernisse bei der DevOps-Einführung überwunden werden können, stellt einer erfolgreichen Etablierung von DevOps in ITIL®-geprägten IT-Service-Organisationen keine Unmöglichkeit dar.

Das könnte Dich auch interessieren …

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.