Über unsMediaKontaktImpressum
Martin Beims 19. April 2016

ITIL und DevOps machen IT fit für die Digitalisierung

Es gibt kaum einen Begriff, der im Moment in allen Bereichen der Wirtschaft so intensiv thematisiert wird wie "Industrie 4.0". Themen wie die Digitalisierung der Geschäftsprozesse und das Internet der Dinge (IoT) dominieren die Diskussionen in den Medien und auch an den Kaffeemaschinen der Unternehmen.

Natürlich sind die IT-Abteilungen und auch IT-Dienstleister in besonderem Maße von den unzweifelhaft bevorstehenden Veränderungen betroffen, denn Sie müssen die technischen und organisatorischen Voraussetzungen für das Alles schaffen. Das Dilemma ist, dass die immer schneller fortschreitende Entwicklung der Anforderungen immer kürzere Innovationszyklen in der IT erfordert. Gleichzeitig sollen bestehende IT Services natürlich weiterhin stabil und vor allem wirtschaftlich betrieben werden.

DevOps und ITIL: Mehr als eine technische Herausforderung

Interessant ist, dass IT-Organisationen nicht mehr – wie häufig in der Vergangenheit – fast ausschließlich in technischen Kategorien denken, um dem zu begegnen. Stattdessen denken CIOs darüber nach, wie die bestehende – oft an ITIL [1] orientierte – Organisation den neuen Anforderungen gerecht werden kann. Ideen dazu gibt es viele. Auffällig sind die vielen Methodiken, die sich an bestehenden IT Service Management-Frameworks (ITSM [2]) wie ITIL oder Normen wie ISO/IEC 20000 orientieren und sich entweder die Vereinfachung der Thematik durch bloßes Weglassen oder aber eine Anpassung des ITSM durch die Kombination mit agilen Ansätzen auf die Fahnen schreiben. Wie viel davon "Surfen auf der Buzzword-Welle" ist und wie viel Substanz übrig bleibt, wird sich zeigen. In jedem Fall fehlen in dem Wettberb auch die großen Beratungsgesellschaften mit neuen Begriffsideen nicht.

Ein Beispiel dafür ist die schon etwas ältere aber derzeit wieder kontrovers diskutierte Idee  einer "IT der zwei Geschwindigkeiten". Das Konzept der bimodalen IT von Gartner [3] sieht zwei verschiedene Betriebsmodi der IT vor: Einen, der dafür sorgt, dass alles zuverlässig läuft und keine Betriebsunterbrechungen auftreten. Einen weiteren, der neuen Herausforderungen des Geschäftes schnell begegnen und im Zweifel auch mit disruptiven Umbrüchen im Unternehmen umgehen kann.

Es stellt sich allerdings die Frage, wie das in der Praxis funktionieren soll. Zwei verschiedene Modi? Wie soll die IT zuverlässig funktionieren, wenn Innovation und Betrieb voneinander getrennt werden? Wer soll denn dann die Innovationen zuverlässig betreiben und wer die Transition in den Betrieb sicherstellen? Und woher kommen die Ideen für Innovationen, wenn nicht aus dem Betrieb mit seinem direkten Kontakt zu den Nutzern? Letztlich wird sich durch diese mögliche Trennung der Betriebsmodi der Grundsatz "höhere Geschwindigkeit = höheres Risiko" nicht einfach aufheben lassen.

IT-Operations: Genauer Hinsehen lohnt sich

Lösungen für diese Herausforderungen lassen sich durchaus in den klassischen ITSM Methoden wie ITIL finden. Man muss sich allerdings die Mühe machen, abseits der populären Themen und Prozesse, wie Service Desk, Incident Management, Change Management, Service Level Management usw. zu suchen. Da wird das Zusammenspiel zwischen Betrieb und Entwicklung durchaus thematisiert und interessante Lösungsansätze für die Zusammenarbeit beschrieben.

Im Buch Service Operation [4] werden als Beispiel die Funktionen des IT-Operation Management und des Application Management beschrieben. In beiden Funktionen ist eine wichtige Aufgabe, den Kontakt zu den Kunden zu halten und neue oder geänderte Anforderungen und Bedürfnisse zu erkennen. Ein wesentliches Ziel des IT-Operation Management ist es, die bestehenden Services bei gleichbleibender Stabilität durch regelmäßige Überprüfungen und Anpassungen zu verbessern. Betrachtet man die Funktion Application Management, wird besonders deutlich, dass bereits hier die Voraussetzungen für die Zusammenarbeit von Betrieb und Entwicklung (DevOps) geschaffen werden. Die aktuellen Begrifflichkeiten sucht man dort allerdings vergeblich, weil diese Themen auch medial weniger im Fokus standen als heute. Abb.1 zeigt, dass bereits damals die enge Verzahnung von Entwicklung und Betrieb vorgesehen war und gefordert wurde. Während des klassischen Application LifeCycle sind an allen Aktivitäten beide Bereiche in unterschiedlicher Gewichtung beteiligt, was hier durch die verschiedenen Schattierungen dargestellt wird.

Zusätzlich ist in der ITIL-Literatur eine direkte Schnittstelle des Application Management zum Service Design beschrieben, damit die Erfahrungen aus dem Betrieb frühzeitig in die Entwicklung einfließen können. Betrachtet man die wesentlichen Aktivitäten und Ziele dieser Funktion, so wird auch eine enge Verbindung zur Anwendungsentwicklung deutlich:

  • Identifikation funktionaler Anforderungen an die Applikationen im Betrieb
  • Unterstützung bei Design und Verteilung der Applikationen
  • Unterstützung bei der kontinuierlichen Verbesserung durch direktes Feedback
  • Identifizieren von Fehlern und deren schnelle Behebung
  • Unterstützung bei Make-or-buy-Entscheidungen

Der Unterschied zu den heute diskutierten DevOps-Gedanken, auf die ich weiter unten noch detaillierter eingehe, ist im Wesentlichen der betrachtete Zeithorizont für notwendige Anpassungen. In den klassischen ITSM-Methoden wird der Grundsatz verfolgt, möglichst lange veränderungsfreie Betriebsphasen zu schaffen, um so die Geschäftsprozesse möglichst selten zu beeinträchtigen. Heute spielt die Geschwindigkeit und Frequenz bei der Umsetzung neuer oder geänderter Anforderungen eine deutlich größere Rolle. Zudem wird der alte Grundsatz "mehr Veränderungen = weniger Stabilität" in den heutigen agilen Umgebungen in Frage gestellt. Grundlage ist die Annahme, dass die Änderungen durch die erhöhte Frequenz auch weniger komplex und damit besser kontrollierbar werden.

Neue Herausforderungen erfordern neue Überlegungen

Lässt sich diese Herausforderung also mit den bereits etablierten Methoden ohne große Korrekturen einfach so meistern? Die Antwort ist leider: Nein, so einfach geht es wohl doch nicht. Aber es lassen sich dort wertvolle Hinweise und Erfahrungen zu diesem Thema finden. Sie vereinfachen die Zusammenarbeit, helfen, Missverständnisse aufzulösen und das Knirschen an der Schnittstelle zwischen Entwicklung und Betrieb zu reduzieren.

Themen, die in jedem Fall geklärt werden müssen, sind: Wer entscheidet eigentlich darüber, was wann in Betrieb geht? Wie ist die Schnittstelle zwischen Change Management und Entwicklung gestaltet? Wie stellen wir sicher, dass Applikationen, die wir entwickeln, auch mit den vorhandenen Fähigkeiten und Ressourcen betreibbar sind? Wie können wir aus dem laufenden Betrieb Informationen für die Entwicklung identifizieren? Niemand ist näher am täglichen Erleben der Anwender als der Betrieb. Das ermöglicht es, wertvolle Informationen für die Service-Erbringung zu sammeln. Auf diese Weise können Wünsche und Bedürfnisse der Nutzer zu strukturierten Anforderungen aggregiert werden und sind ein wertvoller Input für die Entwicklung neuer und die Verbesserung vorhandener Services.

Mit den steigenden Ansprüchen an dieses Zusammenspiel zwischen Entwicklung und Betrieb rücken auch Konzepte wie DevOps mehr und mehr in den Blickpunkt. Sie sind gut dafür geeignet, vorhandene Schnittstellen (die sich leider zu oft den Teilbegriff "Schnitt" redlich verdienen) zu verbessern. Derartige agile Vorgehensweisen behandeln schon in ihrer grundlegenden Ausrichtung den Umgang mit sehr dynamischen Umgebungen. Statt um starre Strukturen und Abläufe geht es um Tempo und das Management kontinuierlicher Veränderung. Klassische Methoden wie ITIL bilden dafür einen gut geeigneten Rahmen, sozusagen die Leitplanken, zwischen denen sich Veränderungen abspielen.

Was ist eigentlich DevOps?

Eine Definition dieses Begriffs ist nicht ganz so einfach, denn es ist keine in sich geschlossene Methode im eigentlichen Sinne, sondern eher so etwas wie eine Philosophie für die Zusammenarbeit zwischen Entwicklung und Betrieb. Dabei gibt es einerseits prozessuale Betrachtungen, wie zum Beispiel den Grundsatz, den Betrieb möglichst früh und konsequent in die Entwicklung einzubinden. Andererseits geht es auch um technische Aspekte, wie zum Beispiel ein hoher Automatisierungsgrad bei Tests und Deployment. Die IT soll in die Lage versetzt werden, flexibler auf die sich immer schneller verändernden Anforderungen und Rahmenbedingungen im geschäftlichen Umfeld reagieren zu können. Auf einen Satz heruntergebrochen soll DevOps dazu beitragen, die Time-to-Market neuer Produkte und Services zu reduzieren, ohne die Servicequalität und die IT-Sicherheit zu beeinträchtigen.

Trotz neuer Herangehensweise müssen natürlich Changes an der Betriebsumgebung gewissenhaft geplant, getestet und in die Produktion integriert werden. Hier kommen wieder die klassischen ITSM-Methoden ins Spiel, die den Betriebsteams aus jahrelanger Erfahrung geläufig sind. Allerdings verschiebt sich die Art dieser Integration: Statt langfristiger Release-Zyklen von Monaten oder gar Jahren, soll ein kontinuierlicher Fluss kleinerer Veränderungen und Bug Fixes geschaffen werden. Eine der Konsequenzen aus DevOps ist also eine erheblich höhere Release-Frequenz. Die Herausforderung dabei ist die organisatorische Umsetzung, denn die Bereiche Entwicklung und Betrieb sind in den meisten IT-Organisationen weit davon entfernt, eng zusammenzuarbeiten. Eine einfache Idee für den Einstieg sind gemischte Teams, welche die Verantwortung über den kompletten Lebenszyklus eines neuen Service oder einer Applikation von der Idee über Entwicklung, Deployment bis zur kontinuierlichen Verbesserung für die Benutzer erhalten. Abb.2 zeigt das Zusammenspiel von Entwicklung und Betrieb während des Lebenszyklus' eines Services oder einer Applikation.

Fokus auf die Anforderungen der Nutzer

Durch die enger verzahnte Art der Zusammenarbeit und die stärkere Fokussierung auf die Anforderungen der Nutzer ändern sich in der Konsequenz auch die Ziele und Kennzahlen für die beteiligten Teams. Statt der etablierten, oft technisch orientierten Kennzahlen für Entwicklung und Betrieb, gilt es, Ergebniskennzahlen für die gemeinsamen Aktivitäten zu finden. Interessant für die Kunden können beispielsweise Messgrößen sein, die erfassen, wie lange es von einer Idee oder einer konkret formulierten Anforderung bis zum funktionierenden Service dauert. Wichtig bei der Definition gemeinsamer Kennzahlen sind dabei in erster Linie die Kundenorientierung und die teamübergreifende End-to-End-Verantwortung für die Ergebnisse.

Der Chef ruft: Jetzt ist alles agil!

Die beschriebenen Veränderungen sind eine Herausforderung sowohl für die Führungskräfte als auch für alle Beteiligten, die bisher nur sehr wenige Berührungspunkte zwischen den verschiedenen Teams hatten. In der Regel liegen diese vor allem im Deployment und der Abnahme neuer Applikationen. Im Gegenteil: Die Trennung zwischen Entwicklung und Betrieb hat sich inzwischen jahrzehntelang manifestiert. Der Großteil der heutigen IT-Spezialisten in beiden Welten hat das im gesamten Berufsleben nie anders kennengelernt. Es ist also kaum zu erwarten, dass sich diese Denkmuster von heute auf morgen einfach ohne große Anstrengung aufbrechen lassen, indem der Chef fröhlich über den Flur läuft und: "DevOps" oder "Jetzt ist alles agil" ruft. Hier sind gut geplante Veränderungsprojekte gefragt, innerhalb derer die Menschen kontinuierlich begleitet, befähigt, motiviert und bei den anstehenden Neuerungen nicht alleine gelassen werden.

Neben diesen organisatorischen und menschlichen Komponenten kommen nun auch wieder die Prozesse ins Spiel. Sowohl die agilen Entwicklungsprozesse als auch die klassischen Servicemanagement-Prozesse müssen so gestaltet werden, dass sie teamübergreifend gelebt werden. Noch wichtiger werden die gemeinsamen Prozesse, wenn der Betrieb nicht von den unternehmenseigenen Ressourcen sondern von einem externen Serviceprovider geleistet wird. Die Zusammenarbeit in den Prozessen ist hier zwar ganz ähnlich (oder sollte es zumindest sein), es spielen jedoch zusätzlich vertragliche Aspekte eine Rolle. Und es werden mit der Überwachung und der Steuerung externer Partner neue Fähigkeiten von der IT-Abteilung verlangt. Auch hier gibt es wieder Verbindungen zu den klassischen Methoden, in denen die Steuerung externer Dienstleister beschrieben wird (z. B. ITIL Supplier Management).

Parallel zu den Prozessen und zur Prozessautomatisierung müssen die technischen Voraussetzungen für deutlich beschleunigte Test- und Deployment-Zyklen geschaffen werden. Für diese Automatisierung der Deployment Pipeline entwickelten sich aus dem ursprünglichen Gedanken der Continuous Integration (CI), wo es im Wesentlichen um automatisiertes Kompilieren und Verteilen ging, Continuous Delivery (CD) und Continuous Deployment (CDE) um den Grad der Automatisierung sukzessive zu erhöhen. Heute kann in vielen Fällen der komplette Deployment-Zyklus (kompilieren, Funktionstests, Performance-Test, Integrationstests, Acceptance Test, Release) automatisiert abgebildet werden. Typische Werkzeuge die hier zum Einsatz kommen sind Ansible [5], Jenkins [6], das Cloud-basierende Docker [7] und noch einige mehr.

Fazit

Ein genauerer Blick auf ITIL in Verbindung mit DevOps lohnt sich in jedem Fall. Etablierte Methoden können durchaus dabei helfen, ganz aktuelle Themen zu adressieren und die IT fit für die Digitalisierung im Zeitalter der globalen Vernetzung aller Produktionsfaktoren zu machen. Die Frage, ob man sich für klassische ITIL-Prozesse oder agile Ansätze entscheiden sollte, stellt sich aus meiner Sicht nicht. Je nach Bedarf lassen sich Elemente aus beiden Ansätzen (und vielen weiteren) perfekt kombinieren. Ganz wie die Werkzeuge in einem guten Werkzeugkasten. Wichtiger als jede Methode und jedes Werkzeug ist es, die beteiligten Menschen von Beginn an in bevorstehende Änderungen einzubinden. Nur wenn die Akteure einen echten Nutzen erkennen, werden sie den Weg mitgehen und ihre wertvolle Erfahrung aktiv einbringen. So schaffen wir es als IT, einen ganz unaufgeregten Beitrag zu den großen Themen dieser Zeit zu leisten: Industrie 4.0 und Digitalisierung.

Quellen
  1. Wikipedia: ITIL
  2. Wikipedia: IT-Service-Management (ITSM)
  3. Gartner
  4. Great Britain: Cabinet Office, 2013: ITIL Service Operation - German Translation: Office of Government Commerce
  5. Ansible
  6. Jenkins
    Informatik Aktuell: Von Continuous Integration zu Continuous Delivery mit Jenkins Pipeline
  7. Docker

Autor

Martin Beims

Martin Beims ist Impulsgeber für Service-Management und Service-Innovation in Deutschland. Er ist Gründer der aretas GmbH in Aschaffenburg und des Online Magazins "Der Service Kompass".
>> Weiterlesen
Buch des Autors:

botMessage_toctoc_comments_9210