In dieser Folge spreche ich über die Verbindung von DevOps und ITIL4. Seit Anfang 2019 ist das erprobte Framework ITIL in einer agilen, neuen Version verfügbar. Genauso wie DevOps seit langem ITSM-Ansätze integriert, referenziert ITIL4 nun auch auf agile und DevOps-Ansätze.
Aus einem Kundenprojekt heraus habe ich einen Workshop zur Verbindung der beiden Ansätze konzipiert, den ich als Inhouse-Veranstaltung und als offenes Seminar anbiete. Zusätzlich habe ich einige Fachartikel zu diesem Thema veröffentlicht und berichte in dieser Podcastfolge aus meinen Projekten sowie den Erfahrungen und Inhalten des Workshops und der Veröffentlichungen.
In dieser Episode diskutiert Dierk Söllner die Synergien zwischen DevOps und ITIL4 und wie diese in der Praxis umgesetzt werden können. Er reflektiert seine Erfahrungen aus Workshops und Projekten, wo er die Integration dieser Ansätze in IT-Organisationen gefördert hat. Dabei stellt er heraus, wie DevOps und ITIL4, trotz scheinbar gegensätzlicher Herangehensweisen, durch ihre Prinzipien und Methoden effektiv kombiniert werden können, um moderne IT-Herausforderungen zu bewältigen und eine Kultur der kontinuierlichen Verbesserung und Zusammenarbeit zu fördern.
Inhalt
- Einführung in die Thematik von DevOps und ITIL4
- Hintergrund und Entwicklung von ITIL4
- Vergleich und Synergien zwischen DevOps und ITIL4
- Praktische Beispiele und Workshop-Erfahrungen
- Erörterung der Prinzipien von ITIL4 und DevOps
- Diskussion über die Integration beider Frameworks in IT-Organisationen
- Überlegungen zur Teamgestaltung und Arbeitskultur
- Vorschau auf die nächste Folge
Shownotes
Artikel für Teil 1: Hybride IT-Organisationen mit ITIL4 und DevOps
Artikel für Teil 2: ITIL und DevOps im Zusammenspiel
Beschreibung ITIL4 und DevOps Workshop
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps Auf die Ohren und ins Hirn. Ein Podcast rund um DevOps Von Dirk Söllner.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begleite Unternehmen auf dem Weg zu einer hochperformanten IT-Organisation.
Als Berater, Trainer und Coach mache ich Teams und Menschen erfolgreich, um die aktuellen Herausforderungen bewältigen zu können.
DevOps umfasst für mich kulturelle, organisatorische, prozessuale und technische Aspekte.
Diese diskutiere ich mit Experten aus der Praxis oder in einer Short-Story. Heute eine Short-Story.
DevOps und ITIL4 – starke Partner für moderne IT-Organisationen.
Entstanden ist diese Idee zu diesem Podcast und zu der Schulung.
Vor etwas über einem Jahr, Februar, März 2019, ich war in einem Kundenprojekt und habe DevOps-Teams ausgebildet, begleitet.
Und irgendwann kam eine der Verantwortlichen aus einem DevOps-Team auf mich zu und sagte,
Mensch Dirk, ich habe ein Problem. Wir haben den Betrieb bei uns und wir müssen jetzt mit dem Betrieb stärker zusammenarbeiten.
Und die erzählen etwas davon, dass sie ITIL haben.
Dass sie unsere Post-its nicht brauchen, dass sie unsere agile Vorgehensweise nicht brauchen, dass sie sich an ihre Prozesse halten.
Und just zu dem Zeitpunkt, also Anfang 2019, kam ITIL4 auf den Markt.
Ich hatte für mich persönlich schon lange entschieden, dass ITIL nicht mehr so mein Thema ist, weil es einfach zu prozessorientiert ist, zu starr ist.
Aber dazu später vielleicht nochmal ein bisschen mehr. Auch die Sichtweise auf ITIL.
Also insofern, ich habe dann für mich entschieden.
Du kümmerst dich mal um das neue ITIL4.
Das soll ja ein agiles Service-Management sein.
Und nach dem ersten Einstieg, nach ein paar Diskussionen, auch mit ein paar Beraterkollegen, habe ich gedacht, da steckt ganz schön was drin.
Ich habe also das Thema ITIL4 und DevOps kombiniert für diesen Kunden.
Wir haben einen Workshop gemacht, einen ersten Workshop, wo wir quasi paritätisch DevOps-Vertreter und ITIL-Vertreter zusammengesetzt haben, also Betriebsvertreter.
Und?
Für den Kunden handelt es sich um Administratoren, um Experten, die mit Microsoft arbeiten.
Diese beiden Parteien haben wir quasi in einem Workshop an einen Tisch gesetzt.
Ich habe beide Ansätze, beide Sichtweisen dargestellt und wir hatten einen sehr intensiven Austausch.
Und ich glaube, das Wichtigste war, dass beide Seiten verstanden haben, schon damals, dass sie eben aufeinander zugehen müssen, dass sie miteinander arbeiten müssen.
Und wenn ich sage schon damals.
Dann ist das jetzt im Rückblick natürlich schon ganz normal oder scheint für mich ganz normal, dass diese beiden Parteien miteinander reden.
Denn beide Seiten und beide Ansätze sagen ja auch, der andere, ich brauche die Arbeit des anderen.
Also dieses Thema Short Story heute, DevOps und ITIL4, starke Partner für moderne IT-Organisationen, ist für mich über ein Jahr alt.
Ich habe dann aus diesem Kunden-Workshop einen zweiten Workshop gemacht für den Kunden.
Wir haben also nochmal eine andere Besetzung zusammengerufen, hatten auch mehr Manager, Geschäftsleitung mit dabei.
Und dann habe ich für mich überlegt, Mensch, da kann man doch noch mehr draus machen.
Und so habe ich dann zum Ende des Jahres 2019 dort einen Eintages-Workshop entwickelt, den ich auch online mittlerweile anbiete.
In der Anfangsphase 2019, Ende 2019 war es natürlich ein Präsenz-Workshop.
Jetzt hat Corona.
Dafür gesorgt, dass ich das Ganze auch online anbiete.
Und letzte Woche hatte ich wieder einen DevOps und ITIL4-Workshop.
Wie gesagt, der erste Online-Workshop.
Und ich habe gedacht, Mensch, das, was ich dort erzähle, kann ich ja auch mal in so eine Podcast-Folge packen.
Und bei der Vorbereitung des Podcasts habe ich festgestellt, da ist noch eine Menge Material, was für zwei Podcast-Folgen reicht.
Also, ich werde in dieser Folge ITIL4 und DevOps vergleichen.
Zusammenbringen, oder zumindest ein Versuch starten, das zusammenzubringen.
Und werde in der nächsten Folge, also im nächsten Monat für den Juni dann, ja, diese Punkte durchgehen, die ich in meinen beiden Artikeln entsprechend erwähnt habe.
Also, zwei Podcast-Folgen zu den Themen DevOps und ITIL4.
Zwei starke Partner für moderne IT-Organisationen.
Ich gehe also in diesem Podcast so ein bisschen durch den Workshop durch, durch den eintägigen Workshop.
Und nehme dort die Inhalte aus dem Workshop, die auf zwei Veröffentlichungen aufbauen.
Zwei Artikel, die ich veröffentlicht habe bei Informatik Aktuell.
Der regelmäßige Hörer wird das schon wissen.
Die Leute, die mir folgen, werden die Inhalte dieser beiden Artikel kennen.
Ich werde die natürlich auch wieder in den Shownotes verlinken.
Und diese beiden Artikel und auch der Workshop, die fangen im Prinzip an, indem sie darstellen, wo und wie ITIL4 und DevOps zusammenpassen.
Ich glaube, die meisten, die…
Diese Begriffe ITIL und DevOps als das erste Mal hören, sagen sich, boah, das passt nicht zusammen.
DevOps klingt eher hip, klingt modern, klingt schnell und agil.
Eines, was wir ja auch gerade in der IT-Welt so hören seit einigen Jahren schon.
Und ITIL klingt erstmal stark, klingt prozessorientiert, klingt wie so eine richtige Mauer.
Und deswegen ist es für mich wichtig, in der Anfangsphase dieses Podcastes und danach auch in den Schulungen,
oder in der Schulung, ITIL4 darzustellen.
Und bei ITIL4 hat sich einiges geändert, sodass ich denke und auch das in der Schulung rüberbringe, dass ITIL4 und DevOps sehr gut zusammenpassen.
Ich mache das in der Schulung und habe es auch in den beiden Artikeln gemacht, indem ich die beiden Prinzipien der Frameworks dargestellt habe.
Also ITIL4 kommt mit sieben Guiding Principles, wie sie das so schön nennen.
DevOps hat in der Variante…
Mit der ich zusammenarbeite, mit der DASA, der DevOps Agile Skill Association, hat DevOps sechs Prinzipien.
Und wir alle kennen das, dass Prinzipien einfach wichtig sind, um eine Basis zu legen.
Und jedes moderne Framework, jeder moderne Ansatz hat heute eben ein paar Prinzipien, die als Basis da sind, die einfach die Grundlage legen.
Insofern werde ich gleich so ein bisschen die Prinzipien von ITIL4 und DevOps vergleichen, gegenüberstellen.
Ein bisschen spoilern kann ich schon.
Es gibt bis auf einen Unterschied eigentlich eine sehr, sehr große Überdeckung.
Das heißt, so weit sind diese Ansätze und Frameworks gar nicht mehr auseinander, wenn ich mir mal in Ruhe die Prinzipien angucke.
Und wenn ich mit den Prinzipien durch bin, wenn ich mit dem Vergleich durch bin, dann ist eigentlich aus meiner Sicht klar,
dass beide Frameworks, beide Ansätze sehr gut nutzbar sind.
Warum? Warum nicht nur eins?
Auch das ist etwas, was ich noch herausarbeite.
Und was ich auch in der Schulung herausarbeite und glaube, was eigentlich auch allgemein anerkannt ist oder sein sollte.
Wir haben in der heutigen Zeit kein Framework mehr, keinen Ansatz mehr, das alleine dafür genutzt werden kann, die Herausforderungen zu lösen, die wir in der IT haben.
Das heißt, eigentlich geht es aus meiner Sicht in der heutigen Zeit darum, aus den verschiedenen Frameworks, aus den verschiedenen Ansätzen sich das Beste herauszupicken und das geschickt zu kombinieren.
Und wenn ich sage geschickt kombinieren.
Dann ist das ja genau ein Ziel meines Workshops und eben auch ein Ziel dieses Podcasts, ein bisschen was zur Kombinationsmöglichkeit zu sagen.
Das heißt, unter der Prämisse, dass sich die beiden Ansätze und Frameworks ergänzen, kann man aus meiner Sicht sieben Punkte oder sieben Schritte ableiten, wie man diese beiden Frameworks kombiniert.
Und für mich ist da der erste Punkt, der wichtigste Punkt zum Start ist, dass Dev und Ops also.
Betrieb und Entwicklung oder Projekte zusammenarbeiten.
Das heißt, das, was wir gemeinhin als Wall of Confusion kennen, wenn also Projekte oder Entwicklung irgendetwas fertiggestellt hat und dann, wie wir so schön sagen, über den Zaun wirft und dann der Betrieb damit zurechtkommen muss.
Das ist, glaube ich, der erste Schritt, den man gehen muss.
Das heißt, dass die IT wirklich eine gemeinsame Sicht darauf bringt und gemeinsame Sicht heißt, dass sie gemeinsam liefert.
Ich glaube, solange ich in der IT bin, geht es immer schon darum, dass man den Kunden im Blick hat oder haben sollte.
Und letzten Endes ist auch einem Kunden egal oder einem Anwender egal, warum etwas nicht funktioniert oder funktioniert.
Der sieht die IT als Ganzes, was aus meiner Sicht natürlich auch logisch ist.
Das heißt, der erste Punkt, den ich nach der Zusammenführung der beiden Prinzipien, den ich bearbeiten werde, ist das Thema Zusammenarbeit ist der Schlüssel zum Erfolg.
Dev und Ops Entwicklung.
Projekte und Betrieb müssen zusammenarbeiten.
Der zweite Schritt ist eigentlich auch, wie ich finde, logisch.
Und da wir in der IT ja auch immer so schön mit irgendwelchen Abkürzungen und neuen Buzzwords um uns werfen, gibt es dafür auch schon eins.
Ich sage erst mal meinen deutschen Titel.
Das Business muss eingebunden werden.
Das heißt, wenn sich die IT gefunden hat, wenn Dev und Ops zusammenarbeiten und ein Zusammenarbeitsmodell gefunden haben, egal wie das aussieht,
dann geht es darum, dass das Business eingebunden wird.
Das Business muss eingebunden werden.
Das Business muss eingebunden werden.
Das Business muss eingebunden werden.
Das Business muss eingebunden werden.
Das Business muss eingebunden werden.
Bis Dev Ops als Schlagwort.
Also wer mal nach bis Dev Ops googelt, der wird dort auch viel Beschreibung finden.
Das heißt, der Dev Ops Ansatz ist schon erweitert worden um das Business.
Und das ist der Punkt 2, den ich gleich noch ein bisschen besprechen werde.
Der nächste Schritt ist dann etwas, was aus meiner Sicht der IT 4 und Dev Ops zusammenbringt, also auch fachlich zusammenbringt.
Das ist nämlich das Thema Orientierung an Wertschöpfungsketten.
Dev Ops hat immer schon eine Wertschöpfungskettenorientierung mit sich gebracht,
weil Dev Ops ja ziemlich viel auch aus dem Lean Management kommt,
weil auch das ganze Thema Automation ja eigentlich auch immer eine Wertschöpfungskette betrachtet.
Das heißt, fachlich finden wir ziemlich viel zum Thema Wertschöpfungsketten in Dev Ops.
Und IT 4 mit der neuen Version hat auch Wertschöpfungsketten quasi nach oben gehoben.
Jeder von euch.
Wird kennen den ITIL Service Lebenszyklus und diese Lebenszyklus Phasen sind etwas, was mit ITIL 4 über Bord geworfen wurde.
ITIL 4 orientiert sich jetzt auch in einem übergreifenden Modell an Wertschöpfungsketten.
Service Value Chain wird das dort genannt.
Und insofern bringt der Punkt 3 Orientierung an Wertschöpfungsketten den fachlichen Schulterschluss der beiden Ansätze.
Punkt 4, den ich näher besprechen werde, ist Mehrwertaufunternehmung.
Unternehmensniveau schaffen, da geht es darum, dass wir natürlich ein paar Dinge beachten müssen,
wenn wir zusammenarbeiten, wenn wir unseren Kunden, wenn wir unseren Unternehmen Wert liefern.
Das ist ja das, was wir aus den Wertschöpfungsketten herausbringen.
Also diesen Mehrwertaufunternehmensniveau zu schaffen, das ist der vierte Punkt.
Und ich habe hier eben schon ein bisschen gespoilert.
Bis auf einen Punkt sind die Prinzipien der beiden Frameworks, der beiden Ansätze eigentlich relativ deckungsgleich.
Und ein Punkt ist unterschiedlich, das ist das Thema, wie baue ich eine Organisation auf.
Ich kann natürlich viele Möglichkeiten finden, zusammenzuarbeiten, aber ich brauche auch immer eine Aufbauorganisation.
Klassischerweise kennen wir das, da kommt ja auch viel Kritik her, ist das Thema Silo und einzelne Abteilungen, Bereiche.
Die Prozesse werden unterteilt, werden abgeschnitten.
Es gibt viele Schnittstellen.
Und das ist eben etwas, was aus meiner Sicht DevOps ausmacht, im Unterschied zu ITIL 4.
DevOps orientiert sich ganz klar an dem Thema Teams zu bilden.
Also fünfter Punkt, den ich behandeln werde, ist Teams bilden die operative Grundlage.
Und nach dem Thema Teams werde ich das Thema Automation noch streifen.
Ich habe hier im Podcast einige Folgen auch schon gehabt, die sich mit dem Thema Automation beschäftigen.
Insofern werde ich hier nochmal ganz kurz darauf eingehen.
Wie gesagt, aber der sechste Punkt meiner sieben Punkte, meiner sieben Schritte ist das Thema Automation.
Das ist eine Herausforderung.
Warum ist das eine Herausforderung und warum passt das hier sehr schön rein?
Wenn wir uns gleich mit den Prinzipien beschäftigen von ITIL 4, dann finden wir auch das Thema Automation.
Und im Unterschied zu DevOps ist die Automation in ITIL 4 noch ergänzt um den Punkt Optimieren.
Das heißt, ITIL 4 hat eben zum Beispiel ein Prinzip Optimieren und Automatisieren.
Und auch da, denke ich, ist eine sehr schöne fachliche Kombination möglich.
Automation ist eigentlich ein Kernthema von DevOps und ITIL bringt die eigene Sicht darauf oder ITIL 4 bringt die eigene Sicht darauf.
Also Automation ist eine Herausforderung.
Punkt 6.
Und ganz zum Schluss Pragmatismus ist angesagt.
Ich werde bei diesem Punkt auf ein paar Projektbeispiele aus ein paar Projekterfahrungen noch eingehen.
Also es ist auch ganz interessant bis zum Schluss dabei zu beginnen.
Und Pragmatismus ist angesagt.
Das ist für mich eben ein ganz wichtiges Learning auch aus meiner, ich glaube, schon über 20-jährigen Projekterfahrung oder Beratererfahrung.
Man muss einfach mal machen.
Man muss einfach tun.
Man muss umsetzen.
Ich glaube, wir haben heute weniger Zeit denn je, uns über grundlegende Dinge zu streiten, wenn sie uns bremsen.
Natürlich muss man ein gemeinsames Glossar finden.
Also die Begrifflichkeiten müssen abhängen.
Wir müssen insgesamt auch ein paar Regeln festlegen, wenn wir zusammenarbeiten bis DEV und OBS.
Aber trotzdem, bei all dem dürfen wir nicht vergessen, Pragmatismus ist angesagt.
Machen es, wie wir wollen, nur krasser.
Also Ärmel hochkrempeln und loslegen.
Ja, das machen wir jetzt auch.
Ärmel krempeln oder hochkrempeln und loslegen.
Ich habe gesagt, erster Teil des Workshops, der Schulung und somit auch der nächste Teil in diesem Podcast ist das Thema,
Vergleich der beiden Ansätze über die Prinzipien, also auf einem ziemlich hohen Level.
Aber für mich ist das eben, wie gesagt, ein ganz wichtiger Punkt, weil in beiden Fällen wir Prinzipien haben,
die das Denken und das Arbeiten und den Aufbau und all das, was wir tun, einfach beschreiben.
Also Prinzipien legen die Grundlage.
Ich habe gesagt, Eitel hat sieben Prinzipien, die fest beschrieben sind.
Und DEV OBS ist ja kein fertiges.
Und festes Framework.
Deswegen gibt es bei DEV OBS im Prinzip erstmal keine Prinzipien.
Aber es gibt, denke ich, eine ganze Reihe von Organisationen, die sich da drüber Gedanken gemacht haben.
Ich hatte eben gesagt, die DEV OBS Agile Skill Association hat das Thema DEV OBS auch mit Prinzipien belegt.
Dort gibt es sechs.
Und wenn man sich die Prinzipien anschaut von Eitel 4 und DEV OBS, dann findet man, wie gesagt, starke Überschneidungen, große Überschneidungen.
Und ich fange mal mit dem.
Mit dem ersten Prinzip an aus Eitel 4.
Das heißt Wertorientierung oder Werteorientierung.
Und das passende in DEV OBS dazu heißt aus meiner Sicht Customer Centric Action.
Was heißt Wertorientierung in Eitel?
Alles, was die Organisation unternimmt, sollte direkt oder indirekt mit dem Wert für die Organisation selbst,
deren Kunden und anderen Stakeholdern in Beziehung gesetzt werden.
Das heißt hier fokussiert Eitel.
Eitel 4 auf einen Wertstrom, auf die Orientierung an Werten für die Organisation.
Und ich habe es ja eben schon gesagt, Kunden, Stakeholder.
Also es gibt eine ganze Reihe von Menschen, von Personen, von Personengruppen, die auf den Wert achten.
Und mit diesem Prinzip kommt schon der erste Schritt, der erste Blick auf das Thema Wertstrom und auf die Wertschöpfungsaktivitäten der Organisation.
Was ich ganz wichtig finde, ist in dem Umfeld.
Die Aussage von Eitel 4, dass Werte unterschiedlich sein kann.
Ich kann natürlich den Wert bemessen an Umsatz, an Kundenbindung oder Wachstum.
Und je nachdem, wie der Wert meines Kunden beschrieben wird, auf welchen Wert mein Kunde fokussiert, muss ich mich ihm auch entsprechend anders ausrichten.
Und was ich immer hier als Beispiel bringe, ist auch das Thema, weswegen so eine Wertorientierung wichtig ist.
Und das ist nämlich das Thema Spotify.
Ich habe Spotify ja schon in meinem Podcast mit Christoph Schmiedinger sehr interessant besprochen.
Das Spotify-Modell, auch wenn es kein wirkliches Modell ist, aber wird ja gern so verkauft.
Das Spotify-Modell wird sehr gerne genutzt, um DevOps-Organisationen aufzubauen.
Und was man dabei eben aus meiner Sicht häufig vergisst, abgesehen davon, dass man es einfach nur kopiert, aber es nicht kapiert,
ist, dass Spotify mit diesem Modell oder mit dieser Art…
…zu arbeiten, auf Wachstum ausgerichtet war.
Spotify hat mit dem eigenen Wachstum einen Wert vorangestellt, nämlich Wachstum.
Und nicht Deckungsbeitrag und nicht positive Ergebnisse.
Das heißt, sie haben in Kauf genommen, dass sie Geld verbrennen quasi.
Dafür wollten sie aber wachsen.
Und das ist zum Schluss natürlich hinaufgegangen.
Das heißt, wenn ich eine Wertorientierung Wachstum habe, dann muss ich mich vielleicht anders aufstellen und anders agieren.
Als wenn ich den Wert Deckungsbeitrag habe beispielsweise oder Gewinn.
Das passende DevOps-Prinzip heißt Customer-Centric Action.
Das heißt, ich muss oder soll alle Aktivitäten meiner Serviceerbringung an dem Kunden orientieren.
Im Unterschied zur Wertorientierung bei Eitel habe ich hier den Kunden ganz stark in Bezug.
Aber auch da, wenn ich alle Aktivitäten der Serviceerbringung auf meinen Kunden ausrichte, komme ich auch zu einer Wertstromorientierung.
Und was dort Interessantes ist, aus meiner Sicht immer auch das Thema Feedback-Zyklen in dieser Organisation zu verringern.
Das heißt, Feedback-Zyklen mit Kunden und Anwendern zu verkürzen.
Und da kann man sich ja unter anderem auf das Drei-Wege-Modell von Gene Kim beziehen oder das nutzen.
Also, Punkt 1, Werteorientierung aus Eitel passt sehr gut zum Prinzip Customer-Centric Action aus dem DevOps-Umfeld.
Zweiter, zweites Prinzip.
Das Thema ist das Thema Optimieren und Automatisieren.
Ich hatte das eben schon gesagt, das ist das Prinzip aus Eitel.
Das heißt, Eitel sagt ganz klar, Organisationen müssen den Wert der Arbeit, die von ihren menschlichen und technischen Ressourcen geleistet wird, maximieren.
Sprich, wenn ich die Wertorientierung habe, muss ich den Wert meiner Arbeit daran eben entsprechend maximieren.
Und was ich interessant finde in dem Umfeld ist eben nicht nur Blindlinks.
Zu automatisieren oder einfach komme, was wolle zu automatisieren.
Da haben wir vielleicht gleich noch den Blick auf das DevOps-Prinzip.
Nein, bevor eine Aktivität effektiv automatisiert werden kann, sollte man sie in dem Maße optimieren, wie es möglich und sinnvoll ist.
Und es gibt ja auch den schönen Spruch, wenn ich einen Scheiß-Prozess automatisiere, dann ist es ein Scheiß-automatisierter Prozess.
Und man möge mir dieses Gossenwort verzeihen.
Aber das ist, glaube ich, ein ganz wichtiger Punkt.
Also insofern hier Eitel 4 sagt, optimieren und automatisieren.
Und das DevOps-Prinzip dazu heißt, automate everything you can.
Das heißt, all das, was man automatisieren kann, sollte man automatisieren.
Es geht natürlich darum, schnelle Lieferzyklen zu realisieren, schnell Feedback zu bekommen.
Das habe ich ja eben auch schon gesagt bei dem Customer-Centric-Action, schnell Feedback bekommen.
Und über diesen Weg auch kontinuierliche Verbesserungen zu unterstützen.
Natürlich kann ich mit dem Thema Automatisierung auch die Qualität steigern.
Ich kann den Durchsatz erhöhen.
Ich kann natürlich auch Qualität erhöhen, indem ich Tests automatisiere, indem ich viele Dinge automatisiere.
Und ganz wichtig, Automation umfasst dabei nicht nur den Entwicklungsprozess.
Also es geht nicht nur darum, Code schnell in die Produktion zu bekommen.
Nein, es geht auch darum.
Es geht darum, die Infrastruktur zu automatisieren.
Infrastructure as Code hier als Beispiel dazu oder als Begriff dazu.
Also zweites Thema, Systemautomation oder Automatisieren, haben wir auch die beiden passenden Prinzipien.
ITIL sagt, optimieren und automatisieren.
DevOps sagt, automate everything you can.
Dann kommen wir jetzt zu zwei ITIL-Prinzipien, denen zwei DevOps-Prinzipien quasi so als Paar jeweils gegenüberstehen.
ITIL sagt als Prinzip, Zusammenarbeit und Sichtbarkeit fördern.
Das heißt, es geht darum, dass ITIL hier darauf fokussiert und darauf abhebt, dass ich, wenn ich eine Initiative starte, Kooperation pflegen soll, Zusammenarbeit fördern soll.
Und dass eben, dass das besser ist als eine Silo-Aktivität.
Jeder Bereich, jede Abteilung optimiert für sich.
Dann komme ich natürlich zu einem Suboptimum an der Stelle.
Und ITIL 4 sagt eben ganz klar oder fordert über das Prinzip Zusammenarbeit und Sichtbarkeit fördern.
Arbeitet zusammen, informiert euch, schafft Verständnis füreinander, schafft Vertrauen füreinander.
Und dazu kann man natürlich auch oder sollte man auch Ergebnisse sichtbar machen an der Stelle.
Und ITIL 4 explizit nennt hier dann auch DevOps, Lean und Agile als mögliche Lösungsansätze.
Also hier hat ITIL 4 Dinge aufgegriffen, die wir aus dem DevOps-Umfeld schon kennen.
Also Zusammenarbeit und Sichtbarkeit fördern als erstes Prinzip von ITIL, was wir hier zusammenbringen mit den passenden DevOps-Prinzipien.
Das andere heißt ganzheitlich denken und arbeiten.
Das heißt, wir sollten auf jeden Fall anerkennen, dass kein Service, kein Prozess, den wir haben, keine Praktik, keine Abteilung und auch kein Supplier allein da stehen.
Wir arbeiten immer in irgendeiner Form zusammen.
Das geht schon los vorne bei der Betrachtung nach einem mit einem Wertschöpfungsprozess.
Und wenn ich nicht zusammenarbeite, werden die Ergebnisse beeinträchtigt.
Das heißt, alle Aktivitäten sollten sich auf die Wertschöpfung konzentrieren.
Dazu heißt es eben auch ganzheitlich denken und zusammenarbeiten.
Da kommen so Punkte rein, dass ich ein Verständnis entwickeln muss, wie alle Teile zusammenarbeiten, wie auch ein Supplier zum Beispiel mitliefert, wie ein Supplier in meinem Wertstrom unterstützt.
Ich muss durchgängig Transparenz schaffen und die Ergebnisse entsprechend umsetzen.
Und dann gibt es dazu zwei DevOps-Prinzipien.
Das erste, was wir da nutzen können, ist Create with the end in mind.
Das heißt also, hier hebt DevOps schon ein bisschen darauf ab, dass ich Teams mit einer Gesamtverantwortung bilde.
ITIL geht schon ein bisschen in die Richtung und sagt, löst Silo-Aktivitäten auf oder Silo-Denken auf.
DevOps ist hier, wie ich finde, ein bisschen konkreter und sagt ganz klar Teams.
Baue Teams mit einer Gesamtverantwortung.
Die Teams haben dann diese Gesamtverantwortung für ein Produkt, für einen Service, für einen Kunden, je nachdem, wie ich das entsprechend zuordne, wie ich die Verantwortung zuordne.
Und mit diesem Prinzip entwickle ich mich als Organisation auch weg von einer prozessorientierten Vorgehensweise hin zu einer produktorientierten Organisation.
Create with the end in mind heißt weg von einer prozessorientierten Vorgehensweise.
Weg von einer prozessorientierten Vorgehensweise hin zu einer produktorientierten Organisation.
Und wenn man sich da so ein bisschen umschaut, dann sind ja sehr viele Unternehmen gerade genau auf diesem Weg.
Das heißt, dass sie Teams aufsetzen, dass sie produktorientierte Teams aufsetzen, die für einen bestimmten Bereich, also für ein Produkt, für einen Service oder auch für einen Kunden die Gesamtverantwortung tragen.
You build it, you run it.
Das ist bestimmt auch ein kleines Bon mot, was der eine oder andere gehört hat.
Die, die das bauen, die das entwickeln, müssen es auch betreiben.
Ich glaube, der eine oder andere kann sich ja auch schon die Konsequenzen daraus vorstellen, kann sich die Vorteile daraus vorstellen.
Die Teams werden dann zum Beispiel zum Experten oder zu Experten in Problemlösung.
Es geht nicht darum, eine Lösung quasi durch ein nachgelagertes Team finden zu lassen, sondern das, was in meinem Produkt, was ich, wofür ich verantwortlich bin, gerade nicht funktioniert.
Dafür muss ich auch die Lösung dafür finden.
Und das muss ich dann herbeiführen oder die Lösung finden.
Also, create with the end in mind als eines von zwei DevOps-Prinzipien, die wir mit den ITIL-Prinzipien zusammenbringen.
Das andere Prinzip heißt end-to-end-responsibility.
Das heißt, hier gehe ich so ein bisschen mehr, auch wenn es vom Begriff her erstmal ähnlich klingt wie das andere Prinzip, gehe ich dahin, dass ich Entwicklung und Betrieb trenne.
Also prinzipiell sage Entwicklung und Betrieb oder Projektarbeit und Betrieb.
Wird nicht mehr getrennt, sondern ich habe dafür die verantwortlichen Teams.
Und im Sinne einer vertikalen Integration hebe ich genau diese Trennung entsprechend auf.
Von der Wiege bis zur Bahre gibt es auch den schönen Spruch.
Das heißt also, ein Team ist verantwortlich für ein Produkt von der Entwicklung bis zur Außer-Dienst-Setzung.
Und mit dieser end-to-end-responsibility, also mit der Zusammenführung dieser Tätigkeiten,
geht einher auch das Thema stabile Tätigkeiten.
Das heißt also, ich fokussiere auch viel mehr auf das Thema Mensch, auf die Erfolgsfaktoren von Teams, auf eine gemeinsame Teamleistung.
Also insofern, kurz nochmal zusammengefasst, ich habe die Prinzipien Zusammenarbeit und Sichtbarkeit fördern und ganzheitlich Denken und Arbeiten aus dem ITIL-Kontext.
Und ich habe aus dem DevOps-Umfeld create with the end in mind und end-to-end-responsibility aus dem ITIL-Kontext.
Und ich habe aus dem DevOps-Umfeld create with the end in mind und end-to-end-responsibility aus dem ITIL-Kontext.
Und ich habe aus dem DevOps-Umfeld create with the end in mind und end-to-end-responsibility aus dem DevOps-Umfeld.
Die passen, wie ich finde, eben auch sehr gut zusammen.
Es gibt dann bei ITIL noch drei weitere Prinzipien, die wir sehr schön zusammenfassen können mit einem Prinzip in dem DevOps-Umfeld.
Der Vollständigkeit halber diese drei aus dem ITIL-Umfeld.
Erstes Prinzip in diesem Kontext finde ich sehr schön, dort beginnen, wo man steht.
Es ist also in der Regel nicht notwendig, etwas völlig Neues zu erstellen.
Ich muss nicht immer wieder überlegen, was kann man alles Tolles Neues machen.
Ich muss nicht immer wieder überlegen, was kann man alles Tolles Neues machen.
tolles Neues machen, sondern Eitel 4 fordert, ich finde eigentlich ganz banal, aber trotzdem
nicht immer berücksichtigt, was ist denn schon da, wo befinde ich mich, was kann ich schon
nutzen und was ich dort interessant finde, ist das Thema, wie bewerte ich das denn, das
heißt, wie bewerte ich, wo ich mich gerade befinde und Eitel sagt, natürlich, da muss
ich etwas messen, also ich muss konkret zahlen, messen, ich muss mit Fakten arbeiten, aber
die direkte Beobachtung ist immer die bevorzugte Option, das heißt, es geht nicht darum, nur
anhand von irgendwelchen Kennzahlen oder Messungen zu entscheiden, wo man gerade steht, sondern
die direkte Beobachtung sollte ich auch immer mit einbringen, natürlich ist das schwierig,
wenn ich verteilte Teams habe, wenn ich quasi für jede Beobachtung durch Deutschland oder
durch die Welt reisen müsste, aber trotzdem, die direkte Beobachtung ist immer die bevorzugte
Option.
Ich werde nachher noch eine Methode.
Darstellen, wo ich da im Prinzip, die ich dazu nutzen kann, Value Stream Mapping, also
die Wertstromanalyse und auch da gehe ich ja mit den Menschen in die Diskussion, in
den Workshop und schaue, was machen sie jetzt schon so, wo stehen sie jetzt.
Also, erstes Prinzip in dem Kontext hier, dort beginnen, wo man steht von Eitel, zweites
Prinzip, das klingt so ein bisschen ähnlich oder dockt daran an, auf Einfachheit und Praktikabilität
achten, das heißt also auch da.
Vielleicht für den einen oder anderen eine Abkehr von alten Denkmustern.
Wenn ich etwas unnötig komplizieren will, dann kann ich natürlich versuchen, für jede
Ausnahme eine Lösung zu finden.
Wenn ich also einen Prozess designe, wenn ich eine Applikation baue, kann ich versuchen,
für jede Ausnahme eine Lösung zu finden und dann wird es unnötig kompliziert.
Und Eitel 4 fordert hier eigentlich immer, die minimal mögliche Anzahl von Schritten
zu verwenden, um das Ziel zu erreichen.
Ich sollte ergebnisorientiert denken und dann praktische Lösungen zu entwickeln.
Und diese praktischen Lösungen, die führen dann eben zu den wertvollen Ergebnissen.
Das, was ich eben gesagt habe, Value Stream, die Wertstromanalyse, die Wertstrombetrachtung,
die werde ich gleich noch erläutern.
Und genau das ist das, wo ich da entsprechend drauf achte.
Einfachheit ist in dem Sinne der beste Weg, um schnelle Erfolge zu erzielen.
Und dann kann ich eben nach und nach Dinge erweitern.
Nach und nach.
Dinge dazu packen, aber wie gesagt, nicht von Anfang an unnötig kompliziert machen.
Drittes Prinzip in dem Eitel-Kontext hier heißt, sich iterativ entwickeln und Feedback einbeziehen.
Auch große Initiativen, auch große Programme müssen iterativ durchgeführt werden.
Und da wird dem einen oder anderen aus dem agilen Umfeld, wenn die Ohren klingeln, iterativ,
das ist ja quasi der agile Begriff, also in kleinen Schritten vorwärts gehen und inkrementell
in kleinen Schritten.
Dann in kleinen Schritten das Ergebnis liefern.
Das heißt, es geht darum, dass wir in kleinen Schritten vorwärts gehen und das Gesamtergebnis
auch in kleinen Schritten entwickeln.
Und dort hat Eitel 4 das Thema oder das Konzept Minimum Viable Product aufgegriffen.
Auch etwas, was wir aus dem agilen Umfeld, aus dem Lean Startup Umfeld kennen.
Und Eitel 4 sagt für sich, ein MVP, ein Minimum Viable Product, ist ein Produkt mit nur den nötigsten Funktionen.
Um frühe Kunden zufriedenzustellen und Feedback für die künftige Produktentwicklung zu geben.
Also hier schnell eine Lösung schaffen, schnell an den Markt gehen, schnell den Kunden zufriedenstellen.
Und es wird von manchen noch mal missverstanden, von manchen Damen und Herren an der Stelle.
Es heißt nicht, dass ich mit Bananen-Software an den Markt gehe.
Es heißt auch nicht, dass der Kunde für mich die Tests übernimmt.
Das heißt aber nur, dass ich mit einem…
mit einem kleinen Funktionsumfang starte, der aber schon funktionieren muss,
der schon durchgängig funktionsfähig sein muss.
Also, diese drei Prinzipien, dort beginnen, wo man steht, auf Einfachheit und Praktikabilität achten
und iterativ entwickeln und Feedback einbeziehen, die Eitel-Prinzipien.
Das DevOps-Prinzip, das passende dazu heißt Continuous Improvement, kontinuierliche Verbesserung.
Das gab es in Eitel früher auch schon, da gab es sogar ein eigenes Buch,
aber in DevOps ist es natürlich sehr viel stärker in das tägliche Doing
und in Rollenverantwortung und in Meetings überführt worden.
In dem agilen Umfeld kennen wir das ja auch.
Das heißt, Continuous Improvement als DevOps-Prinzip passt sehr schön zu den eben beigenannten.
Der aufmerksame Zuhörer wird es gemerkt haben, es fehlt noch ein DevOps-Prinzip.
Und das DevOps-Prinzip heißt Cross-Functional Autonomous.
Teams, also Cross-Funktionale Autonome Teams.
Und das ist ein Thema, was ich, ich habe das vorhin schon angedeutet, in Eitel in der Form so konkret nicht sehe.
Wie gesagt, Eitel fordert schon, dass die Silos abgebaut werden sollen,
aber die Orientierung, dass ich Teams aufbaue und die Verantwortung in die Teams lege,
das gibt es aus meiner Sicht bei Eitel nicht in der konkreten Form.
Und deswegen habe ich dann nachher auch dazu nochmal im Detail so ein paar Punkte dann dazu,
aber wie gesagt, DevOps-Prinzip, vier Cross-Funktionale Autonome Teams finden wir in Eitel nicht.
Und warum dann dieses Prinzip oder was bedeutet das?
Aus meiner Sicht ist das schon die Weiterentwicklung agiler Ansätze.
Das heißt, in dem agilen Umfeld habe ich natürlich auch jetzt schon Cross-Funktionale Autonome Teams,
die, wenn ich den Scrum-Guide mal anschaue,
natürlich eigentlich auch für den Betrieb von Produkten zuständig sind.
Aber natürlich wurde das aus meiner Wahrnehmung oder in meiner Wahrnehmung noch nie so konkret zu Ende gedacht.
Also diese Cross-Funktionalen Autonome Teams kriegen jetzt einfach quasi nur ein bisschen Betriebsaufgabe mit dazu.
Ich sage das mal bewusst in Anführungsstrichen, weil so einfach ist es ja nicht,
einfach nur so ein bisschen Betrieb mit dazu zu machen.
Aber letzten Endes im DevOps-Umfeld heißt es, dass wir die Cross-Funktionalen Autonome Teams nutzen
und dazu agile Ansätze weiterentwickeln.
Wir kommen dazu zu dem ganz wichtigen Punkt.
Wie müssen denn die Menschen gestaltet sein, die in solchen Teams arbeiten?
Und da gibt es dieses schöne T-Shape-Modell.
Das heißt, ich muss versuchen, meine Mitarbeiter, die ja häufig als Spezialisten ausgebildet wurden,
die sich als Spezialisten sehen, dahin zu bringen, sich ein bisschen breiter aufzustellen, breiteres Wissen,
sich anzueignen, über den Tellerrand hinaus zu gucken.
Das ist dieses schöne T, was ich mir vorstelle.
Das heißt, der obere, waagerechte Strich ist das breite Wissen,
situationsübergreifend, problemübergreifend zu denken und verschiedene Dinge zusammenzubringen.
Und dann muss ich natürlich auch als Spezialist in die Tiefe abtauchen.
Das heißt, das ist der vertikale Strich im T.
Ich muss mit dem Spezialwissen dann auch mal nach unten durchstoßen.
Aber wie gesagt, es geht darum, dass ich nicht ein I, sondern ein T bilde.
Und das breite Wissen ist etwas, was ich für die Mitarbeiter haben muss.
Und ich, wenn ich das DevOps-Prinzip der cross-funktionalen, autonomen Teams weiterentwickele,
was ich eben nicht nur für die Mitarbeiter haben muss, sondern eigentlich auch für das gesamte Team.
Also ich muss mein Team eigentlich nicht nur eigentlich, ich muss mein Team cross-funktional und autonom besetzen und nicht nur Spezialisten.
Wir alle kennen das.
Die IT-Helden in einem meiner Lieblingsbücher, also Phoenix Project,
alle, die mich kennen, wissen, dass ich dieses Buch liebe.
Und dort gibt es den schönen IT-Held Brent.
Ich spoiler mal ein bisschen.
Alle in der Parts Unlimited aus diesem Buch Phoenix Project denken, Brent ist der Held.
Natürlich ist Brent der Held.
Und Brent kann alle Probleme lösen, weil sich aber alle daran gewöhnt haben, auf Brent zu warten und Brent hinterher zu telefonieren.
Und wenn wir über cross-funktionalen Autonomen,
autonome Teams sprechen und über T-Shape, dann reden wir darüber, dass wir diese Brands, diese IT-Helden abschaffen, vermeiden.
Das heißt, weg von IT-Helden, die nicht die Lösung des Problems, sondern die Ursache des Problems sind.
Die Art, wie IT-Helden arbeiten, wie sie groß geworden sind, wie sie natürlich auch Zustimmung und Bestätigung bekommen,
ist in der heutigen Zeit nicht mehr zeitgemäß.
Das heißt, mit Cross-Funktionalität.
Mit cross-funktionalen autonomen Teams, mit einer T-Shape, mit einem T-Shape-Ansatz versuche ich zu kompetenzorientierten Teams zu kommen.
Ich versuche, eine Feedback-Kultur aufzubauen.
Ich versuche, Teams in die Verantwortung zu bringen.
Und insofern ist es eben genau etwas, was ich in ITIL 4 nicht finde, zumindest nicht als Prinzip.
Tada, jetzt ein kleiner Tusch.
Das war der Vergleich, die Zusammenführung der ITIL 4 Prinzipien und DevOps Prinzipien.
Und ich hoffe, dass das informativ war, dass auch bei euch, bei den Zuhörern, da der ein oder andere Gedanke nochmal hängen geblieben ist.
Und ich glaube, was meine größte Hoffnung wäre, dass ihr für euch entscheidet und das auch in euer Unternehmen oder in eure Arbeit reintragen könnt,
dass diese beiden Ansätze und Frameworks mittlerweile eigentlich nah beieinander sind.
Zumindest, wenn man sich die Prinzipien anschaut und die Grunddenkmalen.
Und ich habe das vorhin schon mal zu Beginn so ein bisschen angedeutet.
Ich will das nochmal ein bisschen klarer sagen.
DevOps hat eigentlich ja immer schon IT-Service-Management-Praktiken aufgenommen.
Denn wenn ich Ops im Namen stehen habe, dann muss ich natürlich auch Betrieb sicherstellen.
Und ich denke, da geht bei der Organisation von Betrieb gerade in großen Unternehmen und professioneller Organisation, da geht kein Weg an ITIL dran vorbei.
ITIL 4 verpackt die bisherigen jahrzehntelangen Erfahrungen sehr schön.
Und sehr modern, sage ich mal, in einem agilen Gewande.
Und andersherum, ITIL 4 in der neuen Version hat es, wie ich finde, geschafft, die alten Prozesse, die alten Sichtweisen, die alten Erkenntnisse vor allen Dingen zu überführen.
In ein, wie ich habe es eben schon gesagt, modernes Gewand.
Und dabei eben auch sich zu eröffnen für agile Prinzipien, für agile Ansätze.
Und dort also dann mit der Zeit zu gehen.
Damit man nicht mit der Zeit geht.
Gut, genug Kallauer zum Abschluss heute hier.
Wie gesagt, das war der Podcast für den ersten Teil, für den ersten Artikel, den ich geschrieben habe.
ITIL 4 und DevOps, die ich auf der Prinzipien-Ebene zusammengebracht habe.
In der nächsten Folge, die im Juni dann erscheinen wird, geht es darum, wie kann ich das dann umsetzen?
Also wenn ihr jetzt verstanden habt oder meine Workshop-Teilnehmer verstanden haben, dass das gar nicht so weit auseinander ist.
Dass man miteinander reden sollte.
Zum Beispiel, dass auch die Aussagen der beiden Ansätze sehr, sehr nah beieinander sind.
Also wenn diese Erkenntnis da ist, dann ist ja die Frage, wie bringe ich das dann zusammen?
Also wie starte ich?
Und das war in den Workshops, die ich ja zu Beginn dieses Podcasts schon mal angesprochen habe, von Anfang an eine große Diskussion.
Sowohl bei den Workshops, die ich als offene Seminare anbiete, wo wir Teilnehmer aus verschiedenen Organisationen haben.
Wie auch in den Inhouse-Workshops bei den Unternehmen.
Es kommt eigentlich sehr schnell der Punkt zusammen, dass man miteinander reden muss.
Und das wird auch der erste Schritt sein, den ich dann im nächsten Podcast besprechen werde.
Und ich habe zu dem Punkt noch ein bisschen mehr dann zu sagen.
Also insofern mal so ein bisschen Vorfreude an euch alle oder für euch alle auch für den nächsten Podcast.
Da wird es dann konkret, wie ich das entsprechend umsetze.
Was auch so vielleicht meine Erfahrungen sind.
Sowohl aus den Workshops.
Als auch in den Projekten, denen ich tätig bin.
Ich werde sehr häufig genau für diese Thematik gesucht oder gerufen, dass ich eben verbinde.
Sowohl vielleicht als Moderator, als Workshop-Leiter, aber vor allen Dingen auch auf der fachlichen Ebene.
Also ich freue mich auf die nächste Folge und freue mich auch, wenn du dann weiterhin mit dabei bist.
Und ich freue mich auch über Rückmeldungen.
Es gibt viele, die mir schreiben, die vielleicht so ein, zwei Nachfragen haben.
Aber ich bin immer offen und freue mich über Rückmeldungen bei Twitter, wo man mir folgen kann.
Bei LinkedIn, bei Xing, per E-Mail.
Und da dieser Podcast ja auch auf einer eigenen Webseite gehostet wird, auch da kann man kommentieren.
Also ich freue mich auf eure Rückmeldungen.
Ich freue mich auf eure Rückfragen.
Und vielleicht habt ihr ja auch Themen, die ihr gerne mal in so einem Podcast hören wollen würdet.
Könnt ihr gerne auch.
Könnt ihr gerne auch eure Themenwünsche senden.
Und natürlich habt ihr vielleicht auch selber Themen und wollt selber mal Gast sein in dem Podcast.
Auch da würde ich mich über Rückmeldungen freuen.
Ich sage vielen Dank fürs Zuhören und bis zum nächsten Mal.