DevOps

ITIL® oder DevOps, oder was?

Mit der Übernahme von ITIL® durch Capita und dem Aufbau des Joint-Venture Unternehmens Axelos herrscht eine gewisse Unsicherheit über die Zukunft von ITIL®, dem Best Practice Rahmenwerk für Service Management. Ist es nun das Ende oder gibt es einen Neu-Anfang, oder geht es einfach weiter wie bisher? Diese Frage interessiert wohl eher diejenigen, welche am Framework mitverdienen und weniger die Kundenorganisationen, welche ihre Organisationen nach den Empfehlungen von ITIL® ausrichten.

Mit ITIL® wurde der Fokus der IT-Organisationen auf das Business und die Anwender gelegt und weniger auf das, wie man etwas intern macht. Die Definition des Services ist ja bekanntlich „Eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird“.  Es geht bei ITIL® also darum, alles zu tun, damit der Kunde glücklich ist – und intern möglichst keinen Schaden anzurichten.

Die Geschichte von ITIL® kommt auch aus dem IT-Betrieb, wo die schützende Hand auf die Services gelegt wird. Seit der Version 3 hat man den Blickwinkel auf die gesamte IT Organisation gelegt und gefordert, dass bereits bei der Strategie, dann beim Design und schliesslich in der Transition alle peinlichst darauf achten, dass alle Voraussetzungen geschaffen werden, damit der Betrieb, respektive das Bereitstellen der Services gemäss Kundenvorstellung erbracht werden kann. Wie das technisch funktionieren soll, ist aus Sicht ITIL® völlig nebensächlich.

Nur, die Welt dreht sich viel schneller als das die strukturierte Vorgehensweise von ITIL® erlaubt. Grosse Organisationen haben heute bis zu 10 mal am Tag Deployments durchzuführen. Amazon beansprucht nach eigenen Angaben alle 11 Sekunden ein Rollout. Hat hier die Phase Service Transition überhaupt noch eine Bedeutung?

DevOps
DevOps mit den Beziehungen zwischen Entwicklung, technischer Betrieb und Quality Management

ITIL® scheint hier viel zu behäbig. Seit einigen Jahren geistert nun ein neuer Ansatz durch die IT-Organisationen: DevOps. Dieser Ansatz versucht, mit schnelleren Entwicklungszyklen eine engere Zusammenarbeit mit dem Betrieb zu ermöglichen. Mehr noch, der Entwickler und der Betreiber sitzen quasi am gleichen Tisch und es wird keine eigentliche Gewaltentrennung mehr ermöglicht. Dafür sind aber die Veränderungen schneller beim Kunden und der Anspruch des Business nach Flexibilität sichergestellt. In der heutigen Zeit von Apps und Mobilität ist das Business fehlertoleranter geworden, als das die versierten ITIL Service Manager wahrhaben wollen.

Viele sehen in den DevOps-Anhängern Leute der Y-Generation, welche mit einer Chaos-Mentalität alle mühsam aufgebauten Regeln der Kunst in der IT untergaben wollen. Eine Art Hype-Bewegung, welche sich rasch wieder legt?  Genau wie ITIL® hat sich aber DevOps hartnäckig gehalten, weil der Anspruch an Apps und deren unmittelbaren Umsetzung einen dynamischeren Ansatz zwischen Entwicklern und Betreibern zwingend macht.

Ist ITIL® nun des Teufels – und DevOps die Rettung? So schwarzweiss kann man dies wohl nicht sehen. Es sind unterschiedliche Ansätze, welche sich ergänzen und nicht ersetzen. ITIL® hat eine schützende Hand auf den Services und will die Kunden vor Schaden bewahren. DevOps will mit der Dynamik die für das Unternehmen zwingend notwendige Beweglichkeit gewährleisten. Es sind zwei Herzen in der Brust des CIOs, denen er gerecht werden muss: Stabilität und Time-to-Market.

Wie soll nun ITIL® mit seinen 5 dicken Büchern mit jeweils 400-500 Seiten einen dynamischen Ansatz erlauben? Viele Anhänger der Version 2 von ITIL® stöhnen noch heute über den Umfang, den die Version 3 mit sich gebracht haben und viele Organisationen beschränken sich nach wie vor auf den Umfang der Version 2 Prozesse. Man sieht den Wald vor lauter Bäumen nicht mehr.

Wenn die Frage aufkommt, wie lange eine vollständige Umsetzung der ITIL-Disziplinen im Durchschnitt dauert, dann muss ehrlich geantwortet werden, dass es sich um mehrere Jahre handeln wird. Diese Aussicht schreckt jeden Sponsor zurück und niemand will so lange auf Veränderungen warten. Und gerade Organisationen, welche mehrfach am Tag Deployments durchführen müssen, haben dafür nur ein müdes Lächeln übrig.

Agil auf Veränderungen reagieren zu können, ist eine der wesentlichen Ansprüche an Service Provider. Darum haben Ansätze wie DevOps oder auch Scrum diesen grossen Zulauf, weil sie den Durchlauf von Service-Entwicklungen beschleunigen, was offenbar ITIL® eher verhindert. Dies ist im Grunde die willkommene Steigerung der Effizienz, wenn damit aber nicht auf dem Buckel des Servicebetriebs schnellere Entwicklung mit schlechterer Qualität produziert wird.

Service Management greift viel weiter. Der Fokus liegt beim Kunden und seinen Erwartungen. Der Wandel von einem technologiefokussierten IT-Provider hin zu einem kundenfokussierten Service Provider dauert seine Zeit und kann nicht mit dem Betätigen eines Schalters erreicht werden. Der CSI-Ansatz bietet hier aber die Möglichkeit, eine Implementierung mit kleinen Schritten vorzunehmen.

Der fünfte Band von ITIL, das „Continual Service Improvement“ wird bei vielen Implementationen auch als letzte Hürde angesehen. Sogar im fünfstufigen Maturity-Modell von CMMI oder TIPA ist erst ab Stufe 5 der kontinuierliche Verbesserungsansatz verankert. Hier muss ein Umdenken bei den Service Managern und ITIL-Anhängern stattfinden. CSI gehört an den Anfang. Anstatt den grossen Wurf zu versuchen, indem alle Prozesse und Services in einem Programm angegangen werden, ist es heute geschickter, kleinere Umsetzungspakete zu schnüren. Auch im Rahmen von Prozessimplementierungen bin ich der festen Überzeugung, dass mit wenigen Definitionen bereits gestartet werden kann und durch strukturierte Feedbacks im Rahmen eines CSI-Ansatzes der Prozess kontinuierlich verbessert werden kann. Weniger ist oft mehr und besser, als zehn Initiativen zu starten und keine zu Ende zu führen. Man darf zudem nicht ausser Acht lassen, dass sich auch das Umfeld laufend verändert, was wiederum Einfluss auf das Service Management-System, auf das Controlled Service Environment (CSE), hat.

Aus diesem Grunde plädiere ich darauf, den CSI-Ansatz als primäre Methode in der IT-Organisation zu verankern und die entsprechenden Phasen in der Service Management-Planung zu institutionalisieren. Ganz von Anfang an – bevor nur auch ein Prozess eingerichtet wird. CSI und DevOps passen dann auch ideal zusammen und ergänzen sich gegenseitig. Damit kann mit der Service-dominierenden Sicht von ITIL® der Fokus auf den Kunden und seine Bedürfnisse aufrecht erhalten bleiben, während mit DevOps die Silos zwischen Entwicklern und Betreibern aufgebrochen werden können, um dynamische Veränderungen zu ermöglichen.


 

6 Kommentare zu «ITIL® oder DevOps, oder was?»

  1. Die Rechtevergabe an Axelos und der damit verbundene Auftrag „Geld zu verdienen“ wird sicher eine Zensur in der Historie der Bemühungen, Ordnung im organisatorischen Chaos von IT-Kundenorganisationen zu stiften, bedeuten. Richtig ist sicher die Fragestellung, in welche Richtung sich das Engagement, das Geschäft verändert. Zurzeit noch spekulativ.

    Vieles, was rund um das Framework gerade in letzter Zeit publiziert wurde, erinnert so sehr an das hier in Bayern bekannte „Fingerhakeln“. So in etwa hat es mir ein CIO bei einem Abendessen mal vermittelt. Berater und Anbieter streiten sich über Feinheiten, die in der Praxis so recht niemanden interessieren. Sollen sie doch machen, so die schelmische Aussage meines Gesprächspartners, dann lassen uns die Framework-Rhetoriker wenigstens in Ruhe. Das war noch bei der Vorspeise!

    Später, wir waren beim ersten Hauptgang, diskutierten wir über den tatsächlich messbaren wirtschaftlichen Nutzen der Ambitionen, sich mit Hilfe von ITIL® verbessert aufzustellen. Mein CIO erkannte ein grandioses Missverhältnis zwischen Aufwand und Nutzen. Warum eigentlich, so seine Frage, quält man technisch versierte Menschen mit Fragen der Organisation. Kann man denn nicht die Jungs machen lassen, was sie am besten können: programmieren, administrieren und monitoren?

    Noch vor Ende der „Secondi Piatti“ waren wir uns über zwei Gedankengänge einig: entweder man separiert die systemnahen Prozesse (wir sagen Support-Prozesse) für einen verbesserten Betrieb oder aber man ordnet die „Best/Good Practices“ einer Service Einheit zu, die sich ausschließlich um den oberhalb des Systemmanagement angedachten virtuellen Layer kümmert. So eine Service Organisation eben.

    Die Nachspeise haben wir wegen der schlimmen Energiebilanz ausgelassen und uns beim abschließenden Kaffee darauf verständigt, dass wir uns mit neuen Wegen raus aus dem Dilemma der Unternehmens-IT auseinandersetzen müssen. Eine neue Version der 5 Bücher, gar ein neues Framework oder dunstige Worthülsen erschienen meinem Gesprächspartner wenig förderlich. Allerdings – eine wirklich eigene Lösung konnte auch er nicht präsentieren.

    Müssen wir demnach die Waffen ob des vielen ITIL® oder des Unvermögens bezüglich des innovativen Einsatzes des Frameworks strecken?
    Ein klares Nein!

    Zunächst sollten wir erst einmal tatsächlich Service Management in den Mittelpunkt unser Überlegungen stellen und uns tunlichst von den vielen (in meinen Augen) Fehlinterpretationen der Empfehlungen verabschieden. Stattdessen gibt es die Option, sich mit dem Geschäftsmodell des „Service Providing in der IT“ auseinanderzusetzen. Service Provider gibt es als Vorbilder und zur Anleihe in anderen Branchen mehr als genug, sodass wir in der IT nicht bei null anfangen müssen und schon gar keine neuen Bücher nebst Zertifizierungen brauchen. Diese Gelddruckerei gehört reformiert oder abgeschafft.

    Service Management für IT-Leistungen, so würde ich es mal nennen, stellt nach meiner Auffassung ein neues Geschäftsmodell für die Unternehmens-IT dar und verändert nachhaltig bekannte Betriebsmodelle. Über Standardisierungen und Automatisierungen (ich erinnere an das „T“ im Kürzel IT) lassen sich Servicebeiträge so portionieren, dass deren Leistungserbringung und die Qualitätslevel gleichermaßen zuverlässig und berechenbar geregelt sind. Damit lassen sich vergleichsweise problemlos externe Angebote in die Erbringungskette integrieren oder auch wieder herausnehmen. Nichts ist für die Ewigkeit in unserer Branche.

    Die Fähigkeit, das Geschäftsmodell überhaupt gestalten zu können (hier verweise ich auf das „C“ im CMM(I) Modell) wird über Berufsbilder wie Service Designer, Sourcing & Supplier Manager, Service Delivery Manager usw. erlangt. Natürlich, deren Rolleninhaber sind Fachexperte, Verkäufe, Analyst, Vermittler, Qualitätsverantwortlicher, Trainer, Konfliktlöser und ewig Lernender.

    Was oberflächlich nach mehr Personal und aufgeblähter Organisation aussieht, ist bei genauerem Hinsehen eine Entschlackung hinlänglich bekannter Organisationsformen in der Unternehmens-IT. Jede einzelne IT-Einheit muss sich als selbständiger Supplier bewähren oder wird durch Externe ersetzt. Kommunikationsarme „Nerds“, „handmade IT“ oder organisatorische Fürstentümer werden keine Chance haben, sich zu behaupten. Jede Menge Unternehmenslenker könnten diesen Vorstellungen sicher viel abgewinnen.

    Ob jetzt die Zusammenführung von Entwicklungsschritten und Betrieb einen weiteren Ausweg eröffnet, darf bezweifelt werden. Warum? Der Vorteil der Trennung sind bisher „zu schnelle Zyklen“ in der Produktivsetzung, insbesondere neuer Software/Module/Funktionen usw. Denn das als „try and error“ bekannte Verfahren schafft vielmehr Fehler, Nacharbeit und Patchwork.

    Als nachvollziehbar empfinde ich die Ansicht, dass das Business in Zeiten von Apps und Mobilität fehlertoleranter geworden ist. Man stelle ich einen Investmentbanker vor, der in der Mittagspause via Smartphone und mit einer DevOpApp größere Transaktionen abwickelt und dabei wenig Aufmerksamkeit auf Währung, Tausendersetzung und Rundungsdifferenzen legt.

    Ich würde mir wirklich gut überlegen, ob flächendeckend derartige Überlegungen so sinnvoll sind. Sicher, schnelle Release-Zyklen („time to market“) sind eine wesentliche Qualitätsanforderung an die IT. Aber so schnell wie „agil“ mit „hemdsärmelig“ verwechselt wird, könnte ein „legalisierter“ DevOps-Ansatz nach hinten losgehen und den Flüchtigen in unserer Zunft Tür und Tor öffnen. Und weitere Reputation der IT in den Unternehmen kosten.

    Irgendwie kommt mir das Ganze wie eine Minestrone vor, von jedem etwas und sicher auch gut schmeckend. Aber, beim besagten Abendessen mit einem CIO stand diese nicht auf der Karte (sofern ich mich recht erinnere).

    Viele Grüße
    Peter Bergmann

  2. Vielen Dank, werter Kollege für Ihren wertvollen Beitrag. Die Veränderung ist bekanntlich die einzige Konstante. Und erstens kommt es immer anders als zweitens das man denkt. Der einzige Fehler den man nie begehen sollte, ist darauf zu vertrauen, dass alles bleibt, wie es ist, nur weil es gerade so schön ist. Die Qualität wird immer hinterher hecheln und nie ein gemachtes Nest vorfinden. Wäre dies der Fall, dann hätten wir ja Stillstand.

  3. Veränderung = Das Salz des Vergnügens.
    (Friedrich von Schiller)
    Stillstand kann man in unserer Branche definitiv mit Rückschritt gleichsetzen. Insofern sind Bewegungen schon seit mehr als 3 Dekaden Bestandteil unserer Entwicklungen.

    Nur allzu häufig sitzen gelangweilte Worthülsenkreativlinge am Kamin beim Whisky (scottish like) im Hotel und sinnieren über eine neue ganz, ganz tolle Idee, mit akrobatischen Übungen die IT-Lemminge hinter sich zu vereinen. Mit irgendwas müssen ja die Folien für die nächsten Auftritte gefüllt werden.

    “Time to Market” klingt doch als anerkannte, valide Anforderung, auch und gerade an die IT. Der wird ja ohnehin nachgesagt, dass sie häufig viel zu langsam agiert.

    Rolle vorwärts, noch 2x, dann das Ganze wieder zurück, um gleich noch einmal nach vorn schon abzurollen, damit aus dem Schwung heraus wieder über den Kopf die Rolle über funktioniert, um dann gleich wieder voller Tatendrang gleich einen Triple nach vorn hinzulegen, der außerhalb des Scope landet, damit mindestens in 4 aufeinanderfolgenden Übungen die Rolle zurück gelingt. Ok – wir schwitzen, waren in Bewegung, haben Muskelkater und uns tun die Knochen weh. Viel hat sich seit Beginn unserer Leibesübungen verändert … und was wurde erreicht?

    Nicht alles was neu ist, ist auch gut!

    Die Erfahrungen zeigen sehr deutlich, dass jede Menge an Initiativen regelrecht verpufft ist. Die IT hat gegenüber jede Menge Sympathien verspielt, nur weil mit schöner Regelmäßigkeit neue Plastikwörter in Umlauf gesetzt wurden und sich schlussendlich nicht wirklich etwas verbessert hat.

    Aus der Entwicklung heraus wohltuend getrennte Prozesse zusammenzuführen geht definitiv zu Lasten der Qualität. So wie gerne agil mit hemdsärmelig verstanden bzw. interpretiert wird, schwant mir da nichts Gutes. Betrieb ist Betrieb, Entwicklung ist Entwicklung. Von diesen Prinzipien anderer Industrien sollten wir in der IT lernen. Denn wir sind die noch eher junge Branche.

    Man stelle sich vor, ein Autobauer will ein neues Modell unbedingt zu einem frühen Zeitpunkt in den Markt drücken und vereint Entwicklung (inkl. Tests) mit dem Fahrbetrieb. Niemand würde das akzeptieren, ich glaube, es wäre schon aus Zulassungsgründen nicht möglich.

    Wenn wir also mit neuen Ideen, Frameworks, Vorgehensmodellen, Process-Maps, Methodensets oder Ähnlichem den Markt beglücken wollen, dann bitte, bitte nicht um des Veränderns, sondern des Verbesserns willen. Es stände unserer Branche gut zu Gesicht, mit endlich mehr Professionalität aufzufallen.

  4. Liebe Kollegen,
    nur 3 kurze Anmerkungen zu der vorstehenden Diskussion:
    1. “Agil” und “hemdsärmelig” stehen nur bei denjenigen in einem Zusammenhang, die sich bislang erfolgreich geweigert haben, die Effekte von seriös geplanten und umgesetzten agilen Vorhaben zur Kenntnis zu nehmen. Inzwischen liegen eine Vielzahl an Erfahrungen über agil angelegte und erfolgreich durchgeführte IT-Lösungen vor. Beispiele hierzu können am 25.09.2013 im Rahmen des CloudOps Summit 2013 in Frankfurt (www.cloudops.de) diskutiert werden.
    2. Auch beim Thema “Agilität” sollte man Bodenhaftung bewahren und “das Kind nicht mit dem Bade ausschütten”. Es gibt inzwischen mehrere Veröffentlichungen, die sich damit auseinandersetzen, in welchem Zusammenhang klassische Methoden und in welchem agile Methoden ihre jeweiligen Stärken und Schwächen zeigen. Für mich ergibt sich daraus die Konsequenz, dass wir zukünftig wohl intensiv übe eine “IT der 2 Geschwindigkeiten” nachdenken müssen.
    3. Bei Vergleichen mit anderen Industrien sollten wir immer sehr aufmerksam hinschauen. In der Automobilindustrie wird nicht die Verschmelzung von Entwicklung und Fahrbetrieb realisiert, sondern logischerweise und erfolgsbehaftet die intensive und frühzeitige Zusammenarbeit zwischen Entwicklung und Produktion um schnell am Markt sein zu können bzw. die Zusammenarbeit zwischen Entwicklung und Maintenance (Wartung / Reparatur), um eine effektive und effiziente Verfügbarkeit des Services Mobilität gewährleisten zu können. An diesen Lösungsansätzen sollten wir uns in der IT orientieren.

  5. Richtig – jede Methode, jeder Ansatz, jede Idee bringt immer etwas Fortschrittliches und Verbesserndes mit sich. Gerade unsere Branche hat durch die enorme Geschwindigkeit durch Neuartiges profitiert.

    Schaut man sich die Komplexität der 7+n Schichten in der IT-Architektur, wie gewachsen sagt der Metzger, so hat sich die Organisation in der IT nur selten mitentwickelt. Das ITIL(R) Framework war dazu eine richtige Antwort – Leute organisiert euch, macht die Service-Erbringung berechenbarer, verlässlicher. Nach mehr als einer Dekade intensiver Bemühungen stellen Analysten fest, dass die operativen, betriebsnahen Prozesse halbwegs etabliert sind. Von Servicekultur, flexiblen, ja agilen Organisationsformen wenig zu sehen.

    Im Projektmanagement existieren viele Methoden – mir fallen mindestens vier Größere davon ein. Ja, wir besitzen alle irgendwo Zertifikate, sind trainiert und ambitioniert. Aber auch hier verweise ich auf Statistiken, dass die überwiegende Zahl der IT-Projekte als gescheitert gilt (nicht immer gilt als Krierium der Ruf nach Mehdorn).

    DevOps wird jetzt ins Feld geführt (besser: gehypt), um vor allem die Anforderung “time-to-market”, sofern sie wirklich besteht. Die Verschmelzung von Entwicklungsphasen mit dem (produktiven) Betrieb würde nach meiner Einschätzung zu einem Qualitätsverlust führen. Ob das Business diesbezüglich tatäschlich fehlertolerant ist, muss verprobt werden.

    Ja, der 80:20-Ansatz ist häufig zielführender, als die unendliche Perfektion. Aber den Scope einer Lösung auf 80% zu lenken und diese dann fehlerfrei bereitzustellen wäre auch schon ein hoher Anspruch, mit dem leider viele IT-Projekte zu kämpfen hätten.

    Ich selbst bin gerade an einem Projekt mit agilem Vorgehensmodell beteiligt. Das funktionierte eine zeitlang recht gut, bis… Was dann geschah sah zunächst recht hilflos aus und musste dann vorgehenstechnisch auf eine segmentierte und regulierte Vorgehensweise korrigiert werden. Mit positivem Verlauf derzeit und erfolgreichem Ausgang (hoffe ich).

    Mein Fazit dazu: neue Methoden, Wege, Modelle usw. sind immer zu begrüßen und zu nutzen. Das bitte aber professionell und nicht mit dem Tolerieren von möglichen Unzulänglichkeiten, usw. Qualitätseinbußen.

    Noch mal ein Blick auf andere Branchen: habe gestern während einer Autofahrt interessiert zugehört, als in eimem Feature das Interesse der Pharmaindustrie mit schnellem “time to market” für neue Medikamente besprochen wurde. Die Grundaussagen Vieler klangen irgendwie gleich: trotz der Schnelllebigkeit, des (berechtigten) wirtschaftlichen Interesses und des Drucks von Lobbyisten dürfen keine Konzessionen an Genauigkeit, Gründlichkeit und Verläßlichkeit gemacht werden. Wie bei den Autobauern auch, für die habgar ausgetestete neue Modelle undiskutabel wären.

    Was lernt die IT davon?

  6. Da sind wir uns zum Glück ja alle einig. Veränderung tut gut und ist bitter nötig. Es braucht die einen, welche mit dem Kopf durch die Wand wollen, um endlich die Silo-Mentalität aufzubrechen. Und es braucht die anderen, die mahnend das aufkommende Kopfweh beschwören und dass man doch behutsamer sein soll.

    Ich halte den Standpunkt, offen für neue Entwicklungen zu sein. Dass das Business alles Schneller, Besser und Billiger haben will, ist nicht erst heute so. Die Spirale dreht sich weiter – und wenn es jemand schafft, dann hat er Vorteile. Mit Schönheit alleine ist heute kein Blumentopf mehr zu gewinnen – und Geld dafür gibt es auch nicht mehr viel. Collateralschaden gehört zum Risikoverständnis 🙂

    Wesentlich ist, dass nicht die Methoden und Prozesse und Tools alleine im Fokus der Diskussion sein sollte – sondern, dass der Auftrag, der Service an das Business optimal geliefert wird. Methoden, Prozesse und Tools sind nur das Werkzeug. Und wenn eine Schaufel mal nicht mehr so richtig greift, dann nimmt man eine andere – oder versucht es mit dem Pickel, die Krusten aufzulockern (…)

    Wie sagte schon Antoine de Saint-Exupery: “Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen, um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre sie die Sehnsucht nach dem weiten, endlosen Meer.„

    Aber es ist schon richtig – Firmen darf man nicht Abenteuern überlassen. Dazulernen und alte Zöpfe abschneiden gehört aber nun mal zu einer fortschrittlichen Kultur. Die Industrialisierung durch die IT hat das Business heute weiter gebracht. Nun trifft es die IT selbst – und das ist auch gut so.

    Daher bin ich nicht der Meinung, das so Methoden wie DevOps so rasch wieder untergehen. Totgesagte leben bekanntlich immer etwas länger.

Kommentar verfassen

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert