DevOps und IT Service Management

In der jüngsten Zeit häufen sich die Diskussionen und Anfragen zu Projekten rund um das Thema DevOps und IT Service Management. Was da allerdings an Diskussionsbeiträgen im Netz und Gesprächen herumgeistert, ist oftmals haarsträubend naiv, zeigen sie doch eine gewisse Unkenntnis, insbesondere in der agilen Community, was IT Service Management eigentlich leistet, besonders im Bereich IT-Compliance. Zeit und Grund genug, sich einmal mit der Thematik, dem Stand der Dinge und den Herausforderungen in einem Blog zu befassen.

Basics

IT Service Management oder ITSM abgekürzt, braucht man eigentlich nicht mehr zu erläutern, es hat sich als Best Practice in der IT seit mindestens 20 Jahren etabliert. Es ist ein Modell, welches die zuverlässige Bereitstellung von Informationstechnologie als Serviceleistung an den Kunden als Ziel propagiert. Die ITIL-Bücher sind die Manifestation des Modells, wobei in ITIL die kontinuierliche Verbesserung der Leistung durch Prinzipien des Qualitätsmanagements eine zentrale Rolle spielt. Der Standard ISO/IEC 20000 für Service Management nimmt die ITIL-Konzepte auf und generalisiert sie zu überprüfbaren Kriterien für ein funktionierendes Service Management schlechthin, also nicht nur IT Service Management, sondern auch z.B. Customer Service Management.

DevOps ist der Begriff für ein neues Paradigma zur engen Verknüpfung von agiler Softwareentwicklung (Dev) und IT-Betrieb (Ops), das sich konsequenterweise aus der ständig zunehmenden Frequenz von auszuliefernden Software-Releases aus agilen Projekten ergeben hat. Im Vordergrund steht bei DevOps auf der Betriebsseite oftmals das Continuous Provisioning, weil es im Interesse aller Beteiligten ist, wenn Funktionsinkremente aus agilen Sprints möglichst schnell in die Hände des Kunden gelangen. Ein weiterer Treiber der Entwicklung zu DevOps sind Microservice-orientierte und 12-Faktor-kompatible Anwendungsarchitekturen (s. a. Blog-Artikel Cloud Management), wo die eingesetzten Container Orchestration-Plattformen eine inkrementelle Weiterentwicklung geradezu herausfordern und die Grenzen zwischen Entwicklungs- und Betriebsaspekten kaum mehr sichtbar sind.

Zwischen Dev und Ops steht bei vielen Unternehmen oftmals die IT-Compliance, insbesondere wenn das Unternehmen einer Branche angehört, die aufsichtsrechtlich einer Überwachung unterliegt, wie u.a. Banken und Versicherungen. Aber auch nicht behördlich beaufsichtigte Konzerne, deren Jahresabschluß z.B. einer Testatspflicht unterliegt, müssen sich in der Regel jährlich auch einer IT-Prüfung durch ihren Wirtschaftsprüfer unterziehen. Hier liefert ITIL den notwendigen Rahmen, um die internen Kontrollen in der IT zu etablieren, die von Aufsicht oder Prüfer eingefordert werden. Diese Kontrollen kann und darf auch eine agile Entwicklung bei aller gewünschten Schnelligkeit nicht umgehen, daher gibt es für eine Verweigerung der Verbindung von DevOps und IT Service Management überhaupt keinen plausiblen Grund.

IT-Anforderungen durch Aufsichtsbehörden und Wirtschaftsprüfer

In Deutschland und anderen europäischen Mitgliedsländern veröffentlichen die Finanzaufsichtsbehörden Leitfäden zu den IT-Anforderungen aus Sicht der Aufsichtsbehörden, in Deutschland die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) z.B. mit den Bankaufsichtlichen Anforderungen an die IT (BAIT) und einer Konsultation zu den Versicherungsaufsichtlichen Anforderungen an die IT (VAIT) oder in Österreich mit dem FMA-LEITFADEN – IKT-Sicherheit in Kreditinstituten. In diesen Leitfäden steht auf dem ersten Blick die IT-Sicherheit im Vordergrund.

Nun, was bedeutet eigentlich IT-Sicherheit? Sie umfasst Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität, d.h. es geht nicht nur um Geheimhaltung. Mit Integrität und Verfügbarkeit geht es auch u.a. um den Schutz gegen Manipulation von Programmkode und Daten und der Zuverlässigkeit des IT-Betriebs, deshalb geben diese Leitfäden breitgefächerte Anforderungen von der IT-Strategie über den Aufbau der Organisation bis hin zur Durchführung von IT-Projekten vor.

Für „normale“ Konzerne sind die Anforderungen übrigens nicht geringer: das Institut der Wirtschaftsprüfer in Deutschland e. V. (IDW) prüft in seiner Checkliste zur Abschlussprüfung bei Einsatz von Informationstechnologie (IDW PH 9.330.1) im Wesentlichen ähnliche Anforderungen an die IT-Abteilung wie die Aufsichtsbehörden.

Die Prozesse in ITIL liefern nun exakt das Rahmenwerk für die Qualitätskontrollen und Aufzeichnungen zur Dokumentation der Abläufe, die diese Anforderungen auch beinhalten. Nicht umsonst schreibt die österreichische Finanzmarktaufsicht auch u.a. ITIL als Empfehlung in seinen Leitfaden, die Bafin verwendet allerorten ITIL-Begriffe in seinen IT-Anforderungen.

Wenn nun jetzt und in Zukunft DevOps in Banken, Versicherungen und Konzernen zum Einsatz kommen sollen, wie möchte man dieses Paradigma ohne eine Kombination mit ITSM regulatorisch konform betreiben? Das ist genau die Frage, die sich viele Unternehmen derzeit stellen. Die Antwort ist: ohne ITSM geht‘s nicht.

Stand der Dinge bezüglich DevOps mit ITSM

Liest man relevante Beiträge im Netz zu agiler Softwareentwicklung und DevOps, kann sich des Eindrucks nicht erwehren, dass ITSM für die agile Community so etwas wie den Beelzebub darstellt, der alles Agile im Keim erstickt und zunichte macht. Der Ruf nach Bimodalität wird allerorten abgesondert, um die Agilität nicht dem Diktat von Prozessen und Standards der alten Welt unterwerfen zu müssen. Dabei ist Scrum auch nur ein Vorgehensmodell für Projektmanagement, welches inzwischen in der Praxis weitgehend prozessual standardisiert ist, allerdings immense Vorteile kreiert, in dem es viel Raum für Interaktivität und Selbstverantwortlichkeit innerhalb von Projekten schafft.

Zwei veröffentliche Ansätze ragen zu diesem Themenbereich heraus: der „The Agile Service Management Guide“ von Jayne Gordon Groll und die Arbeit der Organisation DevOps Agile Skills Development (DASA). Ersterer ist ein Aufruf zur einer sehr radikal agilen Interpretation von Service Management im Sinne des Lean Managements, wobei ITSM-Prozesse nach dem Prinzip eines „minimum viable process“ laufend gestaltet und verändert werden, wobei man sich fragen muss, wie das in der Praxis funktionieren soll. Der zweite ist ein durchaus vernünftiges Konzept zur Integration von DevOps und ITSM auf prozessualer und organisatorischer Ebene bis hin zu einer vollständigen Aufhebung der Grenzen zwischen Entwicklung und Betrieb (ganz im Sinne des Begriffs DevOps!), welches auch durch ein umfassendes Curriculum von Schulungen und Zertifizierungen hinterlegt ist.

Beiden gemeinsam ist aber dieser unterschwellige Tenor, dass das agile Paradigma nun zur Rettung des IT Service Managements antreten und den „old school“ ITSM-Anhängern zeigen muss, wo heutzutage der Hammer hängt. Dem muss entgegengehalten werden, dass ITSM wie wir es in der Umsetzung in den Unternehmen kennen, die Softwarearchitekturen und Entwicklungsparadigmen der letzten 30 Jahre widerspiegelt, dass dies jedoch mitnichten eine intrinsische Eigenschaft von IT Service Management als solches ist. Dass ITIL mit der Zeit geht, haben schon die Veränderungen in ITIL v2 nach ITIL v3 gezeigt, besonders im Bereich Change und Release Management (v2) zur Service Transition (v3).

Die oftmals etwas enge Sicht auf ITIL

Der Verdacht kommt manchmal auf, dass nur ganz wenigen IT-Spezialisten klar ist, was IT Service Management nach ITIL tatsächlich umfasst. Es ist nicht nur Incident und Problem Management und vielleicht noch Change und Release Management. Nein, das moderne ITIL ist ein High-Level-Modell für IT als Business Unit für IT Service Provider, von der IT-Strategie bis zum Lieferantenmanagement. Auch deshalb eignet es sich so einzigartig – in Kombination mit anderen Standards wie ISO 27001, sollte man nicht unerwähnt lassen – als Grundlage für IT-Anforderungen. Damit sollte auch dem/der letzten agilen JüngerIn klar sein, dass er/sie nicht an ITSM vorbei können.

Die Sache mit der Kontrolle, der Verantwortung und der Überprüfbarkeit

Und hier kommt dann wieder das Thema IT-Compliance ins Spiel. Die Prüfer wollen Kontrollen in Prozessen sehen und Verantwortlichkeit bzw. Zuständigkeit für Aktivitäten. Damit dieses für die Prüfer überprüfbar ist, müssen die Vorgänge beschrieben und die Ergebnisse dokumentiert sein. Wer den Stand der Prozessdokumentation in den meisten Unternehmen kennt, der wird sich nicht vorstellen können, dass es möglich ist, hoch dynamisch („agil“) wesentliche ITSM-Prozesse laufend bei Bedarf anzupassen. Evolution, selbstverständlich und unbedingt. Jedem agilen Projekt seine eigene ITSM-Geschmacksrichtung nach Bedarf, undenkbar.

Wenn das Manifest von DASA postuliert

• • • Customer Centric Action („Service utility“)
    • Create with the End in Mind („product-oriented organisation“: Produkte = Services)
    • End-to-End Responsibility („You build it, you run it!“)
    • Cross-Functional Autonomous Teams („T-shape skills“ = breite & tiefe Kompetenzen)
    • Continuous Improvement („fail fast, fail often“)
    • Automate Everything You Can („Speed“)

dann kann sich dem jeder ITSM-Experte sofort anschließen. Und auch der Tatsache, dass Entwicklung und Betrieb enger zusammenarbeiten und gemeinsam Verantwortung für den Service übernehmen sollten. Also, lasst uns das Beste aus beiden Welten zusammenbringen.

Fazit

Es tut sich was, auf beiden Seiten von Dev und Ops, das ist gut und richtig so. Wir erleben jedoch erst die Anfänge eines neuen Paradigmas, die wie immer geforderten Best Practices für DevOps sind beileibe noch nicht gefestigt. Entwickler wie Betriebler müssen auch ITIL und ITSM besser verstehen lernen, nämlich dass es keine definitive Blaupause für den konkreten IT-Betrieb ist, die starr ist und unter allen Umständen einzuhalten ist. Interessanterweise war es ein Vorwurf, den man ITIL in der Vergangenheit immer gemacht, dass es zu wenig konkret und zu High-level wäre. Die konkrete Interpretation von ITIL haben immer in erster Linie die Hersteller von ITSM-Tools und die ITIL-Berater geprägt, sie steht nicht in den Büchern selbst.

Besser ist es, ITIL als eine Sammlung von Herangehensweisen zu verstehen, mit dem man die Leistung und Qualität von Services absichern und verbessern kann sowie eine Grundlage für (Begriffs)Definition der wesentlichen Mechanismen um dies zu erreichen. Wie man nun diese Mechanismen in einer hoch dynamischen, agilen Umgebung umsetzt, ist eine Frage des jeweiligen Unternehmens. Aber IT-Compliance mit DevOps ohne ITSM funktioniert nicht.