ITSM und DevOps – Freund oder Feind?

«Wir machen kein ITSM mehr – wir sind nun ein DevOps-Shop». «ITIL war uns zu bürokratisch und zu prozesslastig – wir müssen uns auf die digitale Zukunft ausrichten. Da hat ITIL keinen Platz mehr».  So oder ähnlich tönt es hier und dort. ITSM oder DevOps wird vielfach als Grundsatz- und Glaubensfrage hochstilisiert und die beiden Konzepte werden gerne gegenseitig ausgespielt. So als ob man sich entscheiden muss, auf welche Seite der beiden Lager man sich nun schlagen soll. Entweder-oder – es gibt kein dazwischen.

Man hört sie ja zu Hauf, die Geschichten mit den bürokratischen Prozessen, welche den ganzen Ablauf verkomplizieren und vor allem schwerfällig machen. Insbesondere der Release – und Change Management Prozess mit dem langwierigen und mühsamen «Beantragen und Bewilligen» von Änderungsanträgen sowie deren breiten Diskussion in CABs, welche nur monatlich tagen. Das lässt sich nun mal nicht mit dem Konzept des «Continuous Development» und «Continuous Delivery» von DevOps vereinen. Andererseits denkt die ITSM-Fraktion über DevOps, dass dort eine Je-Ka-Mi Stimmung herrscht und jegliche Nachvollziehbarkeit flöten geht. In Organisationen mit grosser Regulationsdichte schlicht undenkbar.

Muss man sich wirklich für oder gegen das eine oder das andere entscheiden? Ich glaube nicht – vielmehr bin ich der Überzeugung, dass es beide Konzepte braucht, um in Zukunft erfolgreich zu sein. Anstelle das Kind mit dem Bade auszuschütten, muss ITSM und auch DevOps richtig verstanden und entsprechend richtig umgesetzt werden. ITIL als de-facto Standard für ITSM hat zum Ziel, Services für den Kunden so bereitzustellen, dass der Business-Value, die Geschäftsergebnisse optimiert werden. Der Kunde und sein erwarteter Mehrwert bilden den Fokus, auf welchen sich alle Betrachtungen über den gesamten Lebenszyklus der Services auszurichten haben – von der Strategie, über Design, Transition und Operation.

DevOps hat genauso das Ziel, einen Mehrwert für das Business zu liefern. Der Fokus hier liegt insbesondere in den höheren Release Zyklen, dem schnelleren und stabileren Bereitstellen von neuen Services und Businessanforderungen. Wichtiger Grundsatz ist hier, dass die Anforderungen aus Betrieb, Sicherheit, Compliance möglichst an den Anfang der Serviceentwicklung eingeflossen werden (Shift left) und nicht erst zu einem späteren Zeitpunkt in einem CAB zur lähmenden Auflage gemacht wird. Zudem sollen die manuellen Schritte wie Paketisieren, Testen und Deployen durch eine integrierte Automation ersetzt werden.

Ein grosses Plus spricht für DevOps, dass das Team die Verantwortung über den gesamten Valuestream – von der Entwicklung bis zur Auslieferung und des Betriebes trägt. In ITSM wird oft nachgesagt, dass sich die Leute hinter ihren Rollen und Prozessen verstecken können. DevOps bricht hier die Silos auf und nimmt jeden einzelnen in die Verantwortung.

Auch nach erfolgreichem Deployment bleiben in der Organisation immer noch Aufgaben im Bereich Service Desk, Support oder auch Service Request Handling, welches den Tagesbetrieb einer IT-Organisation prägt. Zudem gilt es die verschiedenen Leistungen und den Verbrauch von Ressourcen über die verschieden involvierten Lieferanten zu überwachen und zu steuern. Hier wird man auch immer wieder auf die Prinzipien von ITSM oder Service Integration and Management (SIAM) zurückgreifen wollen, weil diese Fragestellungen in DevOps nicht abgedeckt werden.

Auch das Zusammentragen der Anforderungen, insbesondere der Non-Funktionalen Anforderungen aus Sicht des Business, des Betriebes oder der Security lässt sich mit Hilfe der ITSM-Prinzipien im Business Relationship Management und Service Design gut mit dem DevOps-Konzept verbinden. Es ist also nicht entweder ITSM oder DevOps – es ist ein notwendiges Zusammengehen.

Die Prinzipien des agilen Manifests sind für ITSM-Organisationen ein wichtiger Weckruf. ITSM hat sich zu oft hinter der Mauer der Produktion vor den Entwicklern versteckt. Es wird Zeit, dass diese «Walls of Confusion» eingerissen werden und die Zusammenarbeit und Kommunikation aller beteiligten Teams verbessert wird. Richtig verstanden und angewendet sind ITSM und DevOps keine widersprüchlichen Ansätze. Das Prinzip der Service-Automation liegt im Kern von beiden Konzepten. DevOps kann wesentlich dazu beitragen, ITSM besser zu machen und den Fokus weg von den formalisierten Prozessen hinzu Mehrwert-bringenden Services zu lenken. Und auch ITSM kann mit seinen Prinzipien den Einstieg in die DevOps-Kultur vereinfachen. Beides ein echter Gewinn für das Business.

3 Comments
  • Dierk Söllner

    12. June 2017 at 16:05

    Hallo Martin,
    wieder einmal ein toller, lesenswerter Beitrag. Thematisch und was die Überschrift angeht, liegen wir auf einer Wellenlänge. Ich bin als Referent auf dem itSMF Deutschland Live Event am 20. Juni geladen. Thema meines Vortrages: „DevOps: Feind oder Freund des IT Servicemanagements? – Ein Beitrag zur agilen Zusammenarbeit zwischen Entwicklung und Betrieb“ Da haben wir zeitgleich ähnliche Gedanken…

    Die Inhalte meines Vortrages habe ich in einem Beitrag im itSM-Heft zusammengefasst: https://www.itsmf.de/services/mitgliederzeitschrift/aktuelles-heft-und-heftarchiv/itsm201600/40-2017.html

    LG Dierk

  • Martin Andenmatten

    12. June 2017 at 16:16

    Hallo Dierk,

    danke für das Feedback. Lustig, dass wir die gleichen Titel verwenden 🙂 War nicht Absicht von meiner Seite. Mich dünkt es wichtig, dass nicht das eine Konzept gegen das andere ausgespielt wird. Jedes an seinem Platz. Aber dafür richtig.

    Liebe Grüsse
    –Martin

  • Norman Merten

    1. July 2017 at 14:19

    Hallo Herr Andenmatten,

    Sie haben da eine interessante Sicht auf die Kombination von DevOps und ITIL. Ich glaube ebenfalls, dass es keine Schwarz-Weiss-Sicht geben darf zwischen diesen beiden Sichten auf die IT-Abteilung. So wie es Rob England bereits erfasst hat, ist aus meiner Sicht ein kleiner Glaubenskrieg beider Läger entstanden. Siehe: http://www.itskeptic.org/kamu

    Sicherlich ist ITIL in der Version 2011 bereits sechs Jahre alt, was für die IT eine lange Zeit ist, aber dennoch haben sich einige Prozesse die letzten 30 Jahre als hilfreich erwiesen. Revolution anstatt Evolution ist zwar schnell gesagt, aber dann auch wirklich hilfreich?!

    Ich bin zwar noch nicht wirklich mit meiner Thesis zu dem Thema fertig, möchte mich aber für Ihre Ansichten in diesem Blogbeitrag bedanken, da diese ebenfalls bei mir ein Platz erhalten werden.

    Viele Grüße aus dem Norden Deutschlands

    Norman Merten

Post a Comment