Von Charles T. Betz und Christoph Goldenstern
Man müsste schon hinter dem Mond leben, um die Auswirkungen von Agile und DevOps auf alles rund um IT in letzter Zeit verpasst zu haben. Von Start-ups bis zu den größten Unternehmen der Welt verändern Agile und verwandte Methoden die Art und Weise, wie IT geplant, entwickelt, bereitgestellt und betrieben wird.
Was bedeutet diese Transformation für Fachleute im IT-Service-Management und ihr bevorzugtes Framework – ITIL? Eine Menge. DevOps hat die Diskussion auf unerwartete Weise verändert. So ging man lange davon aus, dass Veränderung der Feind von Stabilität sei, und daher entschieden sich Organisationen für seltene, „gut geplante“ Releases – was jedoch nie besonders gut zu funktionieren schien.
Dann kam DevOps. „10 Deploys a Day at Flickr“ war 2009 der erste Schlachtruf. Da müssen die Systeme doch ständig abstürzen? Nein, taten sie nicht. Wenn Continuous Delivery gut verstanden und korrekt umgesetzt wird, verbessert sich die Systemstabilität. Nur für Start-ups im Silicon Valley, richtig? Im September 2016 erklärte die Barclays Bank, dass ihre Services umso stabiler sind, je häufiger ihre 800 agilen Anwendungsteams deployen. In jeder Größenordnung ist klar: Kleinere, inkrementelle Änderungen an komplexen Systemen sind weniger riskant und fördern die Stabilität. Zudem ermöglicht das schnelle Feedback dieser kleinen, inkrementellen Änderungen eine neue Lernkultur, die auf dem Testen von Hypothesen basiert, indem (in Lean-Startup-Begriffen) Minimum Viable Products schnell zum Kunden gebracht werden.
Was passiert hier, und was könnte das für ein etabliertes Unternehmen im Vergleich zu einem Start-up bedeuten? Eine Möglichkeit, die Auswirkungen von Agile und DevOps zu verstehen, ist ein Skalierungs- bzw. „Emergenz“-Modell. Das Problem bei Frameworks wie ITIL und COBIT ist, dass sie auf Unternehmensebene präsentiert werden. Das Framework kann zwar sagen, dass es an die Bedürfnisse des jeweiligen Unternehmens angepasst werden soll; wie genau das zu tun ist, wird jedoch oft Beratern überlassen. Was für ein großes Unternehmen funktioniert, ergibt für ein Start-up möglicherweise keinen Sinn. Verne Harnish stellt in seinem Buch Scaling Up fest, dass es natürliche Cluster von Unternehmen bei bestimmten Größen gibt:
- 1–3 Mitarbeitende
- 8–12 Mitarbeitende
- 40–70 Mitarbeitende
- 350–500 Mitarbeitende
- 2.500–3.500 Mitarbeitende
Der Skalierungsprozess kann uns helfen, aktuelle Debatten in der Branche zu verstehen, etwa „DevOps versus ITIL“. Denken Sie in diesen Kategorien über IT-Prozesse nach. Würden Sie einem Unternehmen mit 10 Personen ein vollumfängliches Change-Management-Verfahren empfehlen? Könnten Sie ein Unternehmen mit 3.000 Personen ohne ein solches Verfahren betreiben? Ab welchem Punkt würden Sie eines einführen – und warum? Welche weiteren Prozesse würden Sie einführen und wann?
Agile funktioniert in kleineren Kontexten gut. Es ist teamorientiert, und Unternehmen jeder Größe erkennen zunehmend, dass im kollaborativen Team Wert geschaffen wird. Gut etablierte Forschung zeigt, dass kollaborative Kulturen allen anderen Kulturen (einschließlich wettbewerbsorientierter Kulturen) überlegen sind. Ein Unternehmen mit 10 Personen ist ein Team, aber ein Unternehmen mit 50 Personen muss sich als „Team aus Teams“ verstehen. Die Frage ist: Wie schaffen wir „den Klebstoff“ für all diese Teams, damit die Ausrichtung nicht verloren geht? Je „lockerer gekoppelt“ wir sind (in den Begriffen der Engineering-Kultur von Spotify), desto stärker müssen wir durch gemeinsame Ansätze „eng abgestimmt“ sein, die Zusammenarbeit und Problemlösung erleichtern.
Das mag offensichtlich erscheinen, aber wenn Unternehmen wachsen, besteht das Muster darin, sich nach Funktionen zu spezialisieren:
- Marketing
- Forschung und Entwicklung
- Vertrieb
- Betrieb und Service
- Backoffice (Finanzen, HR, IT)
Darüber hinaus gibt es innerhalb jeder Funktion Unterspezialisierungen (z. B. spezialisiert sich die IT weiter in Anwendungs- und Infrastrukturteams; Infrastrukturteams spezialisieren sich in Server, Storage, Networking, 24 x 7 NOC usw.).
Die IT organisiert sich als „Auftragnehmer“, sowohl in der Beziehung zum Business als auch intern. Anwendungsteams reichen beispielsweise „Tickets“ beim Infrastrukturteam ein, um benötigte Ressourcen zu erhalten. Dieses Modell kann IT-Systeme und -Services hervorbringen, die einigermaßen stabil sind, aber sie sind oft langsam in der Bereitstellung und langsam in der Veränderung. Funktionale Silos statt End-to-End-Prozessdenken sind die Norm – was etwas ironisch ist, weil Frameworks wie ITIL genau das nicht propagieren.
Heute stellt die digitale Transformation Silos infrage und durchbricht sie. Da marktnahe Produkte zunehmend mehr Informationstechnologie enthalten, konvergiert „Backoffice“-IT mit Forschung und Entwicklung sowie dem allgemeinen Betrieb und Service. Da IT inzwischen entscheidend für das Überleben eines Unternehmens ist, muss sie schneller auf Marktanforderungen reagieren. Stabilität ist weiterhin erforderlich, aber stabile Systeme, die schnell wechselnde Marktbedürfnisse nicht erfüllen, sind wertlos.
Funktionale Silos erfordern Übergaben. Übergaben verursachen Verzögerungen und verringern die Reaktionsfähigkeit. Funktionale Silos entwickeln häufig eine „Wir-gegen-die“-Haltung gegenüber den Teams, die sie bedienen, und gegenüber den Teams, von denen sie Leistungen anfordern. Deshalb fördern agile Methoden multifunktionale Teams: Wie Marty Cagan in seinem einflussreichen Buch Inspired: How to Create Products Customers Love, sagt, muss das Team mindestens in der Lage sein, ein Produkt in Richtung drei notwendiger Eigenschaften zu steuern:
- Ist es wertvoll?
- Ist es nutzbar?
- Ist es machbar?
Ein Team, das Ergebnisse im Einklang mit diesen drei Dimensionen liefern kann, kann als „Full-Stack“ bezeichnet werden. Scrum und andere agile Methoden betonen immer wieder, dass das Team grundsätzlich in der Lage sein muss, eigenständig zu arbeiten – mit minimalen externen Abhängigkeiten und Blockaden.
Eine weitere aktuelle Praxis lautet: „You build it, you run it.“ Das ist eine gute Praxis und eine große Veränderung gegenüber früher, als Entwickler Software „über die Mauer warfen“ und der Betrieb sie dann laufen lassen sollte – wobei Entwickler wenig Verantwortung dafür übernahmen, Software zu schreiben, die tatsächlich produktiv betrieben werden kann. Im Kern verschiebt sich der Schwerpunkt von einem vertikalen IT-„Fabrikmodell“ hin zu einem eher „horizontalen Management“-Ansatz. Hier trägt das Team End-to-End-Verantwortung, einschließlich einiger traditioneller ITIL-Disziplinen wie Incident- und Problem-Management.
Wie Amazon-CTO Werner Vogels bekanntlich sagte: „Entwicklern operative Verantwortung zu geben, hat die Qualität der Services erheblich verbessert – sowohl aus Kunden- als auch aus Technologiesicht.“ Entwickler „tragen“ nun zunehmend „den Pager“ und werden dazu angehalten, Software zu schreiben, die stabil, skalierbar und gut betreibbar ist – zusätzlich dazu, die Erwartungen der Nutzer an die Funktionalität zu erfüllen.
Wohin mit ITIL?
Diese teambasierten Ansätze haben sich als bemerkenswert wirksam erwiesen – deshalb beeilen sich Organisationen, groß wie klein, weltweit, Agile und DevOps zu übernehmen.
Auf der Ebene „Team aus Teams“ großer Organisationen müssen Kommunikation und Zusammenarbeit jedoch teamübergreifend stattfinden. Wir können versuchen, den Bedarf an solcher Kommunikation zu minimieren, aber irgendwann stellt sich die Frage: Woher wissen Sie, dass zwei Änderungen nicht kollidieren? Teamübergreifende Prozesse zur Koordination und Synchronisierung von Aktivitäten müssen sich schnell auf die kritischen Informationen konzentrieren, die für den Betrieb entscheidend sind und eine minimale, aber wesentliche Qualitätsprüfung ermöglichen (z. B. die Incident- oder Problem-Beschreibung).
Ein gemeinsamer Ansatz zur teamübergreifenden Problemlösung baut einige Barrieren zwischen Incident-, Problem- und Change-Management ab. Wenn alle „dieselbe Sprache für Problemlösung und Umsetzung“ sprechen, minimiert das die „Leerlaufzeit“ ineffektiver oder repetitiver Aktivitäten und verbessert die Art und Weise, wie Daten genutzt und geteilt werden.
Change-Management
Da ITIL seit Langem einen strengen Change-Prozess propagiert, ist es für viele Agile- und DevOps-Befürworter zu einem Hindernis geworden. Doch eine geringere Durchsatzrate von Änderungen (was ITIL Change Management tendenziell bewirkt) korreliert nicht mit Systemstabilität.
Fairerweise muss man sagen: Kontinuierliche Updates an einer Anwendung oder einem Service, dessen Plattform insgesamt stabil ist, gelten als „Standard“-Changes, die keine Diskussion oder Genehmigung erfordern. Daran hindert ITIL nichts. Die Realität in zu vielen Organisationen ist jedoch, Entwickler „warten zu lassen“, indem ein ein- oder zweiwöchiger Change-Control-Rhythmus verwendet wird.
Wenn Operations Engineers dafür verantwortlich sind, die erforderliche Änderung in der Produktion umzusetzen, kann eine Verzögerung bei Changes eher aus zu viel Work in Process resultieren als aus mangelnder teamübergreifender Synchronisierung (wie etwa der Nutzung eines zweiwöchentlichen Change Approval Board-Meetings zur Risikobewertung). Da jedoch immer mehr Teams nach dem Prinzip „You build it, you run it“ arbeiten, wird es als nicht wertschöpfend angesehen, wenn der Betrieb Produktionsänderungen implementiert. Selbst das häufig zitierte Thema „Segregation of Duties“ ist in den Hintergrund getreten. (Siehe das DevOps Audit Defense Toolkit, mitverfasst vom DevOps-Evangelisten Gene Kim und dem IT-Auditor James DeLuccia.)
Über Change Management hinaus
Über Change Management hinaus: Wie haben Agile- und DevOps-Teams ITIL erlebt? Teams, die den Betrieb verantworten – einschließlich Helpdesk-Funktion und 24 x 7-Zentren (zwei unterschiedliche Services) – übernehmen häufig ITIL-Schulungen und -Terminologie und betreiben Serviceteams als funktionale Silos.
Diese Silos werden mit Aussagen verteidigt wie: „Wir haben nicht genug Leute, um jedem Entwicklungsteam eigenes Betriebspersonal oder eigene Infrastruktur-Engineers zu geben!“ Das verfehlt jedoch den Kern moderner cloudbasierter DevOps-Praktiken und übersieht wichtige Aspekte des IT-Service-Managements. ITIL befürwortet die Einrichtung von Servicekatalogen, die häufig als „Front-End“ für Infrastruktur-Services dienen. Historisch unterstützt ein Service-Request-Management-Prozess diese Services, oft mit manueller Arbeit (z. B. wenn ein Engineer eine Anfrage nach neuen Servern analysiert).
Cloud- und Microservices-Ansätze verändern das Service Request Management durch ein konsistentes, katalogbasiertes Front-End und vollständig automatisierte Services. Was ist das Amazon- oder Azure-Cloud-Portal anderes als ein Servicekatalog mit einem hohen Automatisierungsgrad? Self-Service und Automatisierung stärken funktionale Teams und entlasten die Infrastrukturteams von den meisten ad-hoc Beratungs- und Engineering-Leistungen, sodass sie sich auf den Aufbau und den Betrieb einer gemeinsamen Self-Service-Infrastruktur konzentrieren können.
Skalierung auf Unternehmensebene
Was passiert, wenn eine agile Denkweise auf echte Unternehmensebene übertragen wird? Über die Notwendigkeit der Koordination eines „Team aus Teams“ hinaus gibt es Probleme mit Risikomanagement, Governance und mehr. Business Continuity, Problem Management und die Reaktion auf Major Incidents werden zu kritischen Themen. Aus Sicht von Kepner-Tregoe erfordert insbesondere das Major Incident Management spezialisierte Fähigkeiten, die das Unternehmen vor katastrophalen Schäden und Verlusten schützen. Diese „Stop-the-bleeding“-Fähigkeit, bei großen Ausfällen die Lage schnell zu stabilisieren, erfordert Spezialisten mit einer Kombination aus exzellenter Problemlösung sowie Moderations- und Kommunikationskompetenz – aufgrund des naturgemäß hohen Drucks und der Vielzahl an Stakeholdern, die es zufriedenzustellen gilt.
Zudem können es sich Organisationen in diesem schnelllebigen Umfeld nicht leisten, immer wieder dieselben alten Probleme zu lösen. Agile- und DevOps-Prinzipien in eine Organisation mit einem unüberwindbaren Backlog offener Probleme (und damit steigenden Incident-Volumina) einzuführen, ist riskant. Damit Agile und DevOps erfolgreich sind, müssen Organisationen Problem Management ernst nehmen und Ressourcen dafür bereitstellen, die Ursachen von Problemen zu finden. Problem Management in den Team-Backlog zurückzuführen – auf Augenhöhe mit neuen User Stories – ist eine aufkommende Best Practice.
Auf der anderen Seite besteht ein Risiko der Skalierung darin, dass die Organisation so viele Prozesse implementiert, dass das entscheidende Teamerlebnis beeinträchtigt wird. Mehrere Prozesse, die stärker durch den Bedarf an Administration/Dokumentation als durch den Wert ihrer Ergebnisse getrieben sind, können die Team-Delivery blockieren, und Kohäsion sowie die Fähigkeit, Kundennutzen zu liefern, verschlechtern sich. Diese Art von Leistungsabfall ist ebenfalls ein Unternehmensrisiko – möglicherweise das größte bei der Skalierung.
Fazit
ITSM-Praktiken haben der neuen Agile-/DevOps-Welt viel zu bieten. Sie schaffen eine gemeinsame Ausrichtung in Sprache und bewährten Praktiken. Servicekataloge sowie Change-, Incident- und Problem-Management sind alle relevant. Organisationen sollten jedoch darauf achten, ITSM nicht als Begründung zu nutzen, Struktur und Prozess über Service-Ergebnisse zu stellen und damit einen Teil der ursprünglichen Intention von Frameworks wie ITIL zu verlieren. Ein servicezentrierter Ansatz, der sich an den Ergebnissen für Nutzer orientiert, ist seit Langem Teil der ITSM-Philosophie, und Service Manager, die diesen Fokus behalten und „Quality Thinking at Speed“ anwenden können, werden weiterhin erfolgreich sein. Letztlich geht es um das Kundenerlebnis – und um den täglichen Moment der Wahrheit, wenn Nutzer Ihren digitalen Systemen begegnen, sowohl in Bezug auf Qualität als auch Stabilität.
Über Kepner-Tregoe
Kepner-Tregoe ist führend in der Problemlösung. Seit über sechs Jahrzehnten hat Kepner-Tregoe Tausenden von Organisationen weltweit geholfen, Millionen von Problemen durch effektivere Ursachenanalyse und bessere Entscheidungsfähigkeiten zu lösen. Kepner-Tregoe arbeitet mit Organisationen zusammen, um Kosten deutlich zu senken und die operative Leistung zu verbessern – durch
Trainings zur Problemlösung, Technologie und Beratungsleistungen.