Die neue Welt: Was bedeuten Agile und DevOps für ITSM und ITIL®?

Von Charles T. Betz und Christoph Goldenstern

Man muss schon unter einem Felsen leben, um in letzter Zeit den Einfluss von Agile und DevOps auf die IT nicht bemerkt zu haben. Von Start-ups bis hin zu den größten Unternehmen der Welt verändern Agile und verwandte Techniken die Art und Weise, wie IT geplant, aufgebaut, bereitgestellt und betrieben wird.

Was bedeutet dieser Wandel für die Fachleute des IT-Service-Managements und ihren bevorzugten Rahmen - ITIL? Viel. DevOps hat die Diskussion auf unerwartete Weise verändert. Beispielsweise wurde lange Zeit davon ausgegangen, dass Veränderungen der Feind der Stabilität sind, und so entschieden sich Unternehmen für seltene, "gut geplante" Releases - was nie so gut zu funktionieren schien.

Dann kam DevOps auf. "10 Deploys pro Tag bei Flickr" war der erste Aufschrei im Jahr 2009. Müssen die Systeme nicht ständig abstürzen? Nein, das taten sie nicht. Wenn Continuous Delivery gut verstanden und richtig durchgeführt wird, verbessert sich die Systemstabilität. Nur für Startups aus dem Silicon Valley, oder? Im September 2016 stellte die Barclays Bank fest, dass ihre Dienste umso stabiler sind, je häufiger ihre 800 agilen Anwendungsteams bereitstellen. Auf allen Ebenen ist klar, dass kleinere, inkrementelle Änderungen an komplexen Systemen ein geringeres Risiko darstellen und die Stabilität fördern. Darüber hinaus ermöglicht die schnelle Rückmeldung dieser kleinen, inkrementellen Änderungen eine neue Lernkultur, die auf dem Testen von Hypothesen basiert, indem sie (im Sinne von Lean Startup) dem Kunden schnell ein Minimum Viable Product liefert.

Was geschieht und was könnte dies für ein etabliertes Unternehmen im Vergleich zu einer Start-up-Organisation bedeuten? Eine Möglichkeit, die Auswirkungen von Agile und DevOps zu verstehen, ist ein Skalierungs- oder "Emergenz"-Modell. Das Problem mit Frameworks wie ITIL und COBIT ist, dass sie auf Unternehmensebene präsentiert werden. Im Rahmenwerk wird zwar darauf hingewiesen, dass es an die Bedürfnisse des jeweiligen Unternehmens angepasst werden sollte, aber wie genau dies geschehen soll, wird oft den Beratern überlassen. Was für ein großes Unternehmen funktioniert, ist für ein Start-up-Unternehmen vielleicht nicht sinnvoll. Verne Harnish stellt in seinem Buch "Scaling Up" fest, dass es bei bestimmten Unternehmensgrößen natürliche Cluster von Firmen gibt:

• 1-3 Mitarbeiter
• 8-12 Mitarbeiter
• 40-70 Mitarbeiter
• 350-500 Beschäftigte
• 2.500-3.500 Beschäftigte

Der Skalierungsprozess kann uns helfen, die aktuellen Debatten in der Branche zu verstehen, z. B. "DevOps versus ITIL". Denken Sie in diesem Sinne über IT-Prozesse nach. Würden Sie einem Unternehmen mit 10 Mitarbeitern einen umfassenden Änderungsmanagementprozess empfehlen? Könnten Sie ein Unternehmen mit 3.000 Mitarbeitern ohne einen solchen Prozess führen? Zu welchem Zeitpunkt würden Sie einen solchen Prozess einführen, und warum? Welche anderen Prozesse würden Sie einführen und wann?

Agile funktioniert gut in kleineren Kontexten. Es ist teamorientiert, und Unternehmen aller Größenordnungen erkennen zunehmend, dass das kollaborative Team der Ort der Wertschöpfung ist. Fundierte Untersuchungen haben gezeigt, dass kollaborative Kulturen alle anderen Kulturen (einschließlich der Wettbewerbskulturen) übertreffen. Ein 10-Personen-Unternehmen ist ein Team, aber ein 50-Personen-Unternehmen muss sich als ein "Team von Teams" verstehen. Die Frage ist, wie wir den "Klebstoff" für all diese Teams bereitstellen können, damit wir die Ausrichtung nicht verlieren. Je mehr wir "lose gekoppelt" sind (im Sinne der Ingenieurskultur von Spotify), desto mehr müssen wir mit gemeinsamen Ansätzen, die die Zusammenarbeit und Problemlösung erleichtern, "eng verbunden" sein.

Dies mag offensichtlich erscheinen, aber mit zunehmender Größe der Unternehmen hat sich eine Spezialisierung nach Funktionen durchgesetzt:

• Marketing
• Forschung und Entwicklung
• Vertrieb
• Betrieb und Service
• Back Office (Finanzen, HR, IT)

Darüber hinaus gibt es innerhalb jeder Funktion Unterspezialisierungen (z. B. spezialisiert sich die IT weiter in Anwendungs- und Infrastrukturteams; die Infrastrukturteams spezialisieren sich in Server, Speicher, Netzwerke, 24 x 7 NOC usw.).

Die IT-Abteilung organisiert sich selbst als "Auftragsnehmer", sowohl in ihrer Beziehung zum Unternehmen als auch intern. Anwendungsteams reichen beim Infrastrukturteam "Tickets" ein, um beispielsweise benötigte Ressourcen anzufordern. Dieses Modell kann zu einigermaßen stabilen IT-Systemen und -Diensten führen, die jedoch oft nur langsam geliefert werden und sich nur langsam ändern. Funktionale Silos und nicht das Denken in End-to-End-Prozessen sind die Norm, was ein wenig ironisch ist, denn das ist nicht das, was Frameworks wie ITIL befürworten.

Die digitale Transformation stellt heute Silos in Frage und durchbricht sie. Da marktnahe Produkte immer mehr Informationstechnologie enthalten, konvergiert die "Back-Office"-IT mit Forschung und Entwicklung sowie allgemeinen Abläufen und Dienstleistungen. Da die IT nun für das Überleben eines Unternehmens entscheidend ist, muss sie besser auf die Bedürfnisse des Marktes reagieren können. Stabilität ist nach wie vor erforderlich, aber stabile Systeme, die den sich schnell ändernden Marktanforderungen nicht gerecht werden, sind wertlos.

Funktionale Silos erfordern Übergaben. Übergaben führen zu Verzögerungen und verlangsamen die Reaktionsfähigkeit. Funktionale Silos neigen dazu, eine "Wir-gegen-die"-Haltung gegenüber den Teams zu entwickeln, die sie betreuen und von denen sie Dienstleistungen anfordern. Aus diesem Grund fördern agile Methoden Teams mit unterschiedlichen Fähigkeiten: wie Marty Cagan in seinem einflussreichen Buch sagt, Inspiriert: Wie Sie Produkte schaffen, die Kunden lieben, Das Team muss mindestens in der Lage sein, ein Produkt zu drei notwendigen Qualitäten zu führen:

• Ist es wertvoll?
• Ist sie brauchbar?
• Ist es machbar?

Ein Team, das Ergebnisse in Übereinstimmung mit diesen drei Dimensionen erzielen kann, kann als "Full Stack" bezeichnet werden. Scrum und andere agile Methoden betonen immer wieder, dass das Team in der Lage sein muss, im Allgemeinen eigenständig und mit minimalen externen Abhängigkeiten und Blockaden zu arbeiten.

Eine weitere gängige Praxis lautet: "Sie bauen es, Sie führen es aus". Dies ist eine gute Praxis und eine große Veränderung im Vergleich zu den alten Tagen, als die Entwickler wenig Verantwortung für das Schreiben von Software übernahmen, die tatsächlich in der Produktion eingesetzt werden konnte. Im Wesentlichen verschiebt sich der Schwerpunkt von einem vertikalen IT-"Fabrikmodell" zu einem eher "horizontalen Managementansatz". Hier trägt das Team die End-to-End-Verantwortung, einschließlich einiger der traditionelleren ITIL-Disziplinen wie Incident- und Problem-Management.

Wie der CTO von Amazon, Werner Vogels, sagte: "Die Übertragung von Betriebsverantwortung an Entwickler hat die Qualität der Dienste sowohl aus Sicht der Kunden als auch der Technologie erheblich verbessert." Jetzt tragen die Entwickler zunehmend "den Pager" und haben den Anreiz, Software zu schreiben, die stabil und skalierbar ist, gut funktioniert und die Erwartungen der Benutzer an die Funktionalität erfüllt.

Wohin mit ITIL?

Es hat sich gezeigt, dass diese teambasierten Ansätze bemerkenswert gut funktionieren. Deshalb beeilen sich große und kleine Unternehmen auf der ganzen Welt, Agile und DevOps zu übernehmen.

Auf der Ebene des "Teams der Teams", der großen Organisationsebenen, müssen Kommunikation und Zusammenarbeit jedoch teamübergreifend erfolgen. Wir können versuchen, die Notwendigkeit einer solchen Kommunikation zu minimieren, aber woher wissen Sie, dass nicht irgendwann zwei Änderungen aufeinanderprallen werden? Teamübergreifende Prozesse zur Koordinierung und Synchronisierung von Aktivitäten müssen sich schnell auf die kritischen Informationen konzentrieren, die für den Betrieb von entscheidender Bedeutung sind und eine minimale, aber unerlässliche Qualitätskontrolle bieten (z. B. die Ereignis- oder Problemanalyse).

Ein gemeinsamer Ansatz für die Problemlösung in den Teams beseitigt einige der Barrieren zwischen Vorfall-, Problem- und Änderungsmanagement. Wenn alle "dieselbe Sprache der Problemlösung und -ausführung sprechen", wird die "tote Zeit" ineffektiver oder sich wiederholender Aktivitäten minimiert und die Art und Weise der Datennutzung und -weitergabe verbessert.

Änderungsmanagementt

Da ITIL seit langem einen rigorosen Änderungsprozess befürwortet, ist es für viele Befürworter von Agile und DevOps zu einem Hindernis geworden. Die Verlangsamung des Durchsatzes von Änderungen (wozu das ITIL-Änderungsmanagement tendiert) hat jedoch nicht mit der Stabilität der Systeme korreliert.

Um ITIL gegenüber fair zu sein, werden kontinuierliche Aktualisierungen einer Anwendung oder eines Dienstes, deren Plattform im Allgemeinen stabil ist, als "Standard"-Änderungen betrachtet, die keiner Diskussion oder Genehmigung bedürfen. Nichts in ITIL steht dem entgegen. Die Realität in zu vielen Unternehmen besteht jedoch darin, die Entwickler warten zu lassen", indem eine ein- oder zweiwöchige Änderungskontrollkadenz verwendet wird.

Wenn die Betriebsingenieure für die Durchführung der erforderlichen Änderungen in der Produktion verantwortlich sind, kann eine Verzögerung der Änderung auf zu viel laufende Arbeit zurückzuführen sein und nicht auf einen Mangel an teamübergreifender Synchronisierung (wie z. B. ein zweiwöchentliches Change Approval Board Meeting zur Risikobewertung). Da jedoch immer mehr Teams nach dem Prinzip "Du baust es, du führst es" arbeiten, wird die Implementierung von Produktionsänderungen durch den Betrieb als nicht wertschöpfend angesehen. Sogar die häufig zitierte "Aufgabentrennung" hat an Bedeutung verloren. (Siehe das DevOps Audit Defense Toolkit, das vom DevOps-Evangelisten Gene Kim und dem IT-Auditor James DeLuccia mitverfasst wurde).

Mehr als Veränderungsmanagement

Wie haben agile und DevOps-Teams ITIL über das Änderungsmanagement hinaus erlebt? Teams, die den Betrieb verwalten, einschließlich der Helpdesk-Funktion und der 24x7-Zentren (die zwei verschiedene Dienste sind), neigen dazu, ITIL-Schulungen und -Terminologie zu übernehmen und haben Serviceteams, die als funktionale Silos arbeiten.

Diese Silos werden mit Kommentaren wie "Wir haben nicht genug Leute, um jedem Entwicklungsteam ein eigenes Betriebspersonal oder Infrastrukturingenieure zu geben!" verteidigt. Dies geht jedoch am Sinn moderner Cloud-basierter DevOps-Praktiken vorbei und lässt wichtige Aspekte des IT-Service-Managements außer Acht. ITIL befürwortet die Erstellung von Servicekatalogen, die häufig für das "Frontend" von Infrastrukturdiensten verwendet werden. In der Vergangenheit wurden diese Dienste durch einen Service-Request-Management-Prozess unterstützt, der oft mit manueller Arbeit verbunden war (z. B. ein Ingenieur, der eine Anfrage für einige neue Server analysierte).

Cloud- und Microservices-Ansätze verändern das Gesicht des Service Request Managements mit einem konsistenten, katalogbasierten Frontend und einem vollständig automatisierten Service. Was ist das Amazon- oder Azure-Cloud-Portal anderes als ein Servicekatalog mit einem hohen Automatisierungsgrad? Self-Service und Automatisierung stärken die Funktionsteams und befreien die Infrastrukturteams von den meisten On-Demand-Beratungs- und Engineering-Services, sodass sie sich auf den Aufbau und die Aufrechterhaltung einer gemeinsamen Self-Service-Infrastruktur konzentrieren können.

Übergang zum Unternehmensmaßstab

Was passiert, wenn eine agile Denkweise auf eine echte Unternehmensgröße übertragen wird? Abgesehen von der Notwendigkeit, ein "Team von Teams" zu koordinieren, gibt es Probleme mit dem Risikomanagement, der Governance und mehr. Die Geschäftskontinuität, das Problemmanagement und die Reaktion auf größere Zwischenfälle werden zu kritischen Fragen. Kepner-Tregoe ist der Ansicht, dass insbesondere das Management von Großereignissen spezielle Fähigkeiten erfordert, um das Unternehmen vor katastrophalen Schäden und Verlusten zu schützen. Diese "Lückenbüßer-Fähigkeit", um das Ausbluten zu stoppen, wenn es zu größeren Ausfällen kommt, erfordert Spezialisten mit einer Kombination aus hervorragender Problemlösung sowie Moderations- und Kommunikationsfähigkeiten, da das Umfeld naturgemäß unter hohem Druck steht und eine Vielzahl von Interessengruppen zu befriedigen ist.

Außerdem können es sich Unternehmen in diesem schnelllebigen Umfeld nicht leisten, weiterhin die gleichen alten Probleme zu lösen. Die Einführung von Agile- und DevOps-Prinzipien in einem Unternehmen mit einem unüberwindbaren Rückstand an offenen Problemen (und damit einem steigenden Aufkommen an Vorfällen) ist ein riskantes Unterfangen. Damit Agile und DevOps erfolgreich sind, müssen Unternehmen das Problemmanagement ernst nehmen und Ressourcen für die Suche nach der Ursache von Problemen bereitstellen. Die Rückführung des Problem-Managements in das Team-Backlog, gleichberechtigt mit neuen Anwender-"Stories", ist eine neue Best Practice.

Auf der anderen Seite besteht ein Risiko der Skalierung darin, dass das Unternehmen so viele Prozesse implementiert, dass die so wichtige Teamerfahrung gestört wird. Mehrere Prozesse, die mehr durch die Notwendigkeit der Verwaltung/Dokumentation als durch den Wert ihrer Ergebnisse bestimmt werden, können die Teamleistung blockieren, und ihr Zusammenhalt und ihre Fähigkeit, einen Mehrwert für den Kunden zu liefern, verschlechtern sich.

Zusammenfassend

Die ITSM-Praktiken haben der neuen Agile/DevOps-Welt viel zu bieten. Sie bieten eine Ausrichtung auf Sprache und bewährte Praktiken. Servicekataloge, Change-, Incident- und Problem-Management sind alle relevant. Unternehmen sollten sich jedoch davor hüten, ITSM als Argument zu benutzen, um Strukturen und Prozesse gegenüber den Serviceergebnissen zu betonen, wodurch ein Teil der ursprünglichen Absicht von Frameworks wie ITIL verloren geht. Ein serviceorientierter Ansatz, der sich an den Ergebnissen der Anwender orientiert, ist seit langem Teil der ITSM-Philosophie, und Servicemanager, die diesen Fokus beibehalten und in der Lage sind, "Qualitätsdenken mit Geschwindigkeit" anzuwenden, werden auch weiterhin erfolgreich sein. Letztendlich geht es um die Kundenerfahrung und den täglichen Moment der Wahrheit, wenn sie mit Ihren digitalen Systemen in Berührung kommen, sowohl in Bezug auf Qualität als auch auf Stabilität.

Über Kepner-Tregoe

Kepner-Tregoe ist führend auf dem Gebiet der Problemlösung. Seit mehr als sechs Jahrzehnten hat Kepner-Tregoe Tausenden von Unternehmen weltweit geholfen, Millionen von Problemen durch eine effektivere Ursachenanalyse und Entscheidungsfindung zu lösen. Kepner-Tregoe arbeitet mit Unternehmen zusammen, um Kosten erheblich zu senken und die betriebliche Leistung zu verbessern durch
Problemlösungsschulung, Technologie und Beratungsdienste.