In dieser Episode des DevOps-Podcasts werden die Herausforderungen und Strategien der Implementierung von DevOps in Unternehmen erörtert. Die Gäste Volkert Jung und Sebastian Schulze von der Direktgruppe teilen ihre Erfahrungen und diskutieren insbesondere die „DevOps Metro Map“ – ein Instrument zur Visualisierung und Strukturierung der vielfältigen Aspekte von DevOps. Die Diskussion beleuchtet die Bedeutung von Kultur, Prozessen, Technologie, Innovation und IT-Service-Management in DevOps und betont die Notwendigkeit eines kontinuierlichen Lern- und Anpassungsprozesses innerhalb von Unternehmen.
Inhalt
- Einführung und Vorstellung der Gäste
- Vorstellung von Volkert Jung und Sebastian Schulze von der Direktgruppe
- DevOps-Definition und Missverständnisse
- Diskussion über die irreführende Wahrnehmung von DevOps als Jobtitel
- DevOps in der Praxis
- Herausforderungen und Realitäten von DevOps in Unternehmensstrukturen
- Die DevOps Metro Map
- Entwicklung und Ziel der DevOps Metro Map zur Visualisierung von DevOps-Komplexität
- Wichtige Aspekte von DevOps
- Rolle von People, Process, Technology und Innovation in DevOps
- IT-Service-Management in DevOps
- Diskussion über die Integration und Bedeutung von ITSM in DevOps
- Zukunft von DevOps und die Metro Map
- Überlegungen zur kontinuierlichen Weiterentwicklung und Anpassung der DevOps-Strategien
- Abschluss und Dank an die Gäste
Shownotes
- Direktgruppe: Ein Beratungsunternehmen, das in den Bereichen IT-Infrastruktur, Softwareentwicklung und IT-Strategie tätig ist. Es ist bekannt für die Entwicklung der „DevOps Metro Map“. Leider konnte ich keine direkte URL zur „DevOps Metro Map“ finden, daher empfehle ich, die Hauptseite zu besuchen und gegebenenfalls direkt nach der Metro Map zu suchen. Direktgruppe Website
- DevOps Metro Map: Ein von der Direktgruppe entwickeltes Visualisierungstool, das die Komplexität von DevOps strukturiert. Eine spezifische URL ist nicht verfügbar
- Eric Ries – Lean Startup: Das Buch „Lean Startup“ von Eric Ries, das wichtige Prinzipien für die Entwicklung von Minimum Viable Products und Start-up-Strategien bereitstellt.
- IT-Service-Management (ITSM): Wichtig für die Implementierung von DevOps, ITSM ist ein zentraler Bestandteil für den effektiven IT-Betrieb. Informationen über ITSM und dessen Praktiken können auf Seiten wie AXELOS gefunden werden, die Best-Practice-Lösungen anbieten.
Transkript (automatisiert, daher keine Gewähr 🙂 )
DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zur vierten Folge vom DevOps-Podcast auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner. Ich begrüße Sie zur Folge, bei der wir heute zwei Gäste haben.
Wir haben heute den Volkert Jung und den Sebastian Schulze von der Direktgruppe.
Und ich glaube, ich muss gar nicht viel einleitend sagen.
Volkert, kannst du kurz dich vorstellen? Kannst du kurz die Direktgruppe vorstellen?
Das mache ich doch gerne. Hallo Dirk, hallo Alex. Vielen Dank, dass ihr uns eingeladen habt.
Mein Name ist Volkert Jung. Ich bin Berater und Prokurist in der Direktgruppe.
Und ich möchte kurz was zum Unternehmen sagen, damit wir auch gar nicht viel Zeit verlieren.
Und dann schnell zu unserem Fachthema übergehen.
Die Direktgruppe ist ein Beratungsunternehmen aus Hamburg.
Wir sind seit 1998 auf dem Markt an verschiedenen Standorten mit über 200 Beratern in verschiedenen Themenstellungen.
Sei es von der IT-Infrastruktur über die Softwareentwicklung zur IT-Strategie
bis hin zur Online-Marketing oder SAP-Beratung bieten wir hier ein weites Feld an.
Für unsere Kunden ist es ein sehr wichtiges Thema.
Für unsere Kunden erbringen wir unsere Leistungen im großen Teil recht individuell.
Und in dem Kontext haben wir halt immer wieder Berührungspunkte mit agilen Ansätzen gefunden.
Genau mit dem Übergang, wie bringe ich entwickelte Produkte in den Betrieb und halte all diese Themenzahlen für uns auf die Ansätze ein, die DevOps verfolgt.
Und in diesem Kontext…
Beraten wir jetzt auch unsere Kunden.
Und damit gebe ich das Wort gern zurück an Dirk, damit wir hier inhaltlich einsteigen können.
Doch zuvor vielleicht noch Sebastian, magst du auch noch zwei Worte zu dir sagen?
Ja, hallo, guten Abend.
Vielen Dank, Dirk und Alex, für die Möglichkeit, uns vorzustellen.
Mein Name ist Sebastian Schulze.
Ich bin in der Direktgruppe seit über acht Jahren bisher tätig als Softwareentwickler und Teamlead in der Softwareentwicklung.
Und mache jetzt seit Anfang 2017 das Thema DevOps und Transformationsberatung.
Ich komme aus dem softwareentwickelnden Bereich der Direktgruppe.
Deswegen liegt mir das in der DNA und kümmere mich eben vornehmlich um Fragestellungen der Digitalisierung von Softwareentwicklungsprozessen, das heißt Continuous Delivery.
Im Wesentlichen…
Und da spielt es natürlich eine große Rolle, dass die große Klammer DevOps, wie kriegen wir hier die Zusammenarbeit im Unternehmen wieder neu geregelt und verbessert?
Wie werden Unternehmen wandlungsfähiger?
Wie kriegen wir in die Unternehmen eine entsprechende Kultur und bilden entsprechende notwendige Haltungen bei den Mitarbeitern und Führungskräften aus?
Ja, sodass deren Unternehmen wieder wandlungsfähiger und schneller werden in der Produktion von Software und IT.
Sebastian Volkert, vielen Dank für die Vorstellung.
Herzlich willkommen auch von meiner Seite, Alex Lichtenberger.
Ja, auch heute wieder das Thema DevOps.
Und ja, DevOps, ich denke, es herrscht ja generell Einigkeit, was wir damit erreichen wollen, auch warum DevOps ein Thema wird.
Aber DevOps dann auch, wenn es um die Umsetzung geht, ist das sehr wichtig.
Es ist sehr komplex.
Und da kommen verschiedenste Elemente zusammen.
People, Process, Technology, aber auch methodisch.
Agile, der Sebastian hat es erwähnt, dann aber auch Lean und Service Management.
Ja, und da hat, denke ich, die Direktgruppe, und das wird auch das Thema heute, eine super Visualisierung gefunden, um diese Komplexität auch ein bisschen Struktur einzubringen.
Also mit ihrer Metro Map, das heute so im Fokus.
Bevor wir aber…
Bevor wir dann auf diese Metro Maps zu sprechen kommen, wir stellen ja inzwischen bei jedem Podcast unseren Gästen die Frage, was ist DevOps?
Also deshalb auch an euch, Sebastian Volkert, die Frage, was versteht ihr unter DevOps?
Kann man das definieren überhaupt?
Wie würdet ihr es definieren?
Ja, bitte.
Ich übernehme mal das Wort zuerst.
Ich nehme vornehmlich wahr, dass es…
…eine irrenführende Wahrnehmung gibt, weil viele glauben, dass DevOps ein Job ist oder eine Jobbeschreibung.
Man sieht das häufig jetzt so in Stellenanzeigen oder so, dass DevOps-Engineers gesucht werden, wo meines Erachtens dysfunktional versucht wird, das mit einer Stelle zu erschlagen.
Ich vergleiche das ganz gerne damit, dass man ja auch nicht als Unternehmen hingehen würde und sagen würde, dass man das mit einer Stelle zu erschlagen würde.
Ich würde sagen, wir stellen jetzt einen Zusammenarbeitsspezialisten ein, der zukünftig die gesamte Zusammenarbeit in einem Unternehmen verantwortet und durchführt.
Insofern wird es auch das Thema DevOps nicht schaffen, zumindest nach dem, was ich mir da so vorstelle und viele andere auch.
Es geht hier vielmehr um ein Mindset, was eben diese Prozesse…
…Culture miteinander in Beziehung setzt und es einfach aus dem Wunsch heraus entstanden oder heutzutage weiterverfolgt, dass Unternehmen schnell und handlungsfähig werden wollen, was das Thema Softwarelieferung angeht.
Wir nehmen das häufig fest, zumindest stellen das fest, das tue ich bei meinen Kunden auch, bei denen ich als Berater auftrete, dass dort häufig gewachsene hierarchische Unternehmen…
…Unternehmenstrukturen da sind, wo IT weniger Enabler ist, sondern sich über die Zeit aufgrund bestimmter Einflussfaktoren vielmehr als Blockierer oder Verwalter darstellt, in denen so Not-My-Job und Verweigerungshaltung an der Tagesordnung sind oder zumindest von den Leuten, die IT in diesen Unternehmen in Anspruch nehmen, den Business Units, den Fachabteilungen…
…dass da das Gefühl entstanden ist, wir kommen hier nicht weiter, wenn wir uns an unsere IT wenden, da braucht es Jahre und das haben natürlich Mitarbeiter wie Entscheider erkannt, dass das in der heutigen Welt mit der Geschwindigkeit, mit der entwickelt wird, dass das nicht mehr so ganz passt und dass wir hier erleben, dass kleine Startups in der Wertschöpfung, was jetzt neue Technologien…
…Nutzung oder auch neue Geschäftsmodelle angeht, die großen etablierten Konzerne, die eigentlich genug Manpower und genug Geld dafür hätten, abhängen, was die Innovationskraft angeht und im Zweifel auch deren Geschäftsmodelle angreifen und das will man sich natürlich hier nicht bieten lassen.
Ich will nicht sagen, dass DevOps nur aus dieser Konzernsicht motiviert ist, aber für uns wandelt es sich.
Von diesem Kerngedanken kriegen wir nicht auch Infrastruktur agil, das war ja mal Keimzelle dieser DevOps-Bewegung, nachdem man ja Agilität in der Softwareentwicklung schon lange Jahre praktiziert hat.
Aber das ist für uns die Realität. Wir sind da bei Unternehmen und müssen erklären, dass es eben nicht nur Technologie ist, die DevOps darstellt oder diesen Gedanken, dieses Mindset, häufig auch als Philosophie bezeichnet,
…sondern im Wesentlichen das Zusammenleben.
…das Zusammenleben von, na klar, Development Operations, aber auch dem Business, was wieder lernen muss, gemeinsam zu funktionieren für gemeinsame Wertschöpfung.
Back to the Roots, ja. Dann die Frage, wie seid, also ihr als Direktgruppe macht ja schon eine ganze Weile Beratung, Technologie, IT-Beratung. Wie seid ihr überhaupt zum Thema DevOps gekommen? Was waren da so die Treiber dafür?
Würde ich sagen, wir haben da Verschuldung.
Wir haben da verschiedene Anknüpfungspunkte, weil wir in der Direktgruppe ja durchaus verschiedene Arten von Beratungen anbieten, was in dem IT-Spektrum, Volker wird das gleich bestimmt ergänzen, für mich als jemand mit Softwareentwicklungs-DNA war das klar geworden in den letzten Jahren, dass eben rein dieses agile Entwickeln nicht ausreicht.
Wir haben dann festgestellt, wir müssen uns selber stetig erneuern.
In der Art, wie wir Softwareentwicklungsprojekte machen. Für uns gehört es zwar immer zum, war immer ein Teil davon, dass wir die Software, die wir selber entwickelt haben für unsere Kunden, meist auch selbst betrieben haben.
Das heißt, uns ist es relativ selten begegnet, dieses klassische Silo-Denken, aber wir haben festgestellt, dass natürlich auch in unserer eigenen Organisation diese Silos entstanden sind.
Und haben dann…
Selbst daran gearbeitet, wie wir das wieder reduzieren.
So sind wir rein aus praktischen Aspekten, weil wir das selber brauchten, um am Markt überhaupt konkurrenzfähig zu sein.
Haben wir dann aber festgestellt, es gibt viele andere Unternehmen auch, die sich mit diesen Fragestellungen plagen und die nicht damit gesegnet sind, diese Erfahrungen gemacht zu haben.
Beziehungsweise die einfach von der Organisation selbst, vielleicht nicht ganz so wendig.
Wie wir das sind und waren.
Deswegen haben wir gesagt, wir möchten gerne unsere Erfahrungen und die, die wir jetzt auch noch sammeln.
Ich möchte nicht sagen, dass wir da die Weisheit mit Löffeln gefressen haben.
Auch wir haben noch viel zu lernen.
Dass wir das unseren Kunden auch als ein neues Portfolio-Element anbieten.
Und die Dinge, die wir da jetzt lernen, selbst lernen und bei Kunden sehen und wie wir uns da weiterentwickeln, fließen.
Wir fließen dann wieder in unsere eigenen Software-Entwicklungsprozesse ein.
Deswegen ist das so ein sich selbst befruchtendes System.
Was einen ganz wesentlichen Aspekt, ich habe es jetzt schon mehrfach wiederholt in meiner Rede, begünstigt, nämlich dieses kontinuierliche Lernen.
Ich denke, das steht für mich jetzt ganz persönlich auch im Zentrum des Ganzen.
Und so sind wir eigentlich dazu gekommen, was wir jetzt da machen.
Und der Volkert hat da jetzt nochmal eine ergänzende Sicht, glaube ich, draus.
Da möchte ich dich bitten, ergänz das doch bitte nochmal.
Letztlich hast du ja gut dargestellt aus der Perspektive Software-Entwicklung, Software-Herstellung und Inbetriebnahme die Aspekte, die zu DevOps gehören.
Aus meiner Beratungswelt und meines Teams komme ich mehr aus der Betriebs- und Organisations- und auch aus der Prozessseite.
Und stelle halt auch hier fest, dass durch neue Technologien, vornean natürlich immer wieder genannt Cloud.
Computing, verschiedene Erwartungen daran gestellt werden.
Und eine der Erwartungen heißt Geschwindigkeit.
Bestehende IT-Organisationen von großen Unternehmen, denen fällt es halt sehr schwer, hier die technische Integration zu realisieren und dabei auch gleichzeitig schnell zu werden.
Und dieses Schnellwerden ist da meines Erachtens ein ganz wesentlicher Treiber für Initiativen im Kontext DevOps.
Projekterfahrungen, Projektmanagement-Erfahrungen sammeln sich dazu, indem man halt,
Scrum-Elemente anwendet und dann iterativ auch Non-Software-Entwicklungsprojekte durchführt.
Also vielleicht IT-Infrastrukturprojekte, Server-Konsolidierung, Rechenzentrums-Zuladenlegung oder ähnliches.
Trotzdem hapert es immer wieder an der Geschwindigkeit.
Und diese Thematik wollen wir hiermit gerne aufgreifen.
Und den Punkt sehen wir da drin.
Innovation ist vielleicht noch eine weitere Thematik.
Die halt aus der Betriebssicht und aus der Entwicklungssicht vielleicht noch teilweise sehr weit weg erscheint, weil ja doch in der Praxis im Allgemeinen die Unterstellung formuliert wird, die IT ist viel zu weit weg vom Business und viel zu weit weg an neuen Geschäftsmodellen, die idealerweise digital sein sollen.
Und aus diesen drei Sichten heraus jetzt mal ein stärkeres Zusammenrücken hervorzubringen.
Und das sind Aspekte, die wir auch mit DevOps verbinden.
So und das führte uns dann zu dem Gedanken, da eine Visualisierung zu schaffen.
Und Alex und Dirk, ich glaube, an der Stelle kommt jetzt auch gleich eure nächste Frage.
Welches Ziel habt ihr denn überhaupt mit dieser Meta-Map verfolgt?
Das ist eine wunderschöne Karte, aber was habt ihr als Ziel damit verfolgt?
Also wir standen ja vor der Frage, als wir jetzt das Thema DevOps als Portfolio-Punkt für uns aufgenommen haben.
Wie kriegt man eigentlich ein gemeinsames Verständnis davon?
Gerade weil wir selbst ja auch verschiedene Sichten innerhalb der Direktgruppe hatten, aber auch mit den Leuten, die wir außerhalb unserer Organisation gesprochen haben, gab es halt immer wieder verschiedene Auffassungen.
Und wir wollten hier eine Möglichkeit schaffen, diesen Begriff DevOps mit allem, was dazugehört, vielleicht eher nicht dazugehört, mal zu strukturieren und haben uns versucht,
an einer Darstellungsform.
Die erstmal Diskussionsgrundlage gibt.
Klarheit schafft über das, was wir darunter verstehen und das, was unsere Ansprechpartner, Kommunikationspartner, Kunden darunter verstehen und haben da verschiedene Dinge ausprobiert.
Man versucht ja immer gerne in hierarchischen Schemata zu denken, wie so eine Ordnerstruktur und daran haben wir uns die Zähne ausgebissen.
Und dann haben wir festgestellt…
Alles, was für uns zum Thema DevOps assoziiert werden muss, müssen wir anders darstellen.
Und so sind wir in diese MetroMap-Darstellung gekommen.
Also ich höre da auch heraus, ich habe verschiedene Dinge ausprobiert und das ist ein Resultat aus dem Entwicklungsprozess.
Und vielleicht auch zum, genau bevor wir zum Aufbau der MetroMap kommen, vielleicht an die Zuhörer, weil das ist ein Podcast, das heißt, ihr könnt die MetroMap nicht sehen.
Also es lohnt sich da, das vielleicht sich jetzt auch…
Vor Augen zu führen, also zum Podcast, also einen Link zur Grafik selber.
Es lohnt sich natürlich, das auch noch anzuschauen.
Aber jetzt vielleicht Frage an euch, Sebastian und Volker, könnt ihr mal so den Aufbau dieser MetroMap kurz erläutern?
Ja, im Wesentlichen haben wir festgestellt, wir haben verschiedene Achsen, auf denen ja eine Einordnung von Begriffen…
… im DevOps-Umfeld einzuordnen sind.
Wir haben jetzt drei große Bereiche, auf jeden Fall klar, Development, die Entwicklung, der IT-Betrieb, Operations.
Aber was uns ganz wichtig war, auch das Business mit reinzunehmen.
Weil aus unserer Wahrnehmung, das teilen ja auch viele andere, wenn man sich so umhört, darf ja IT nicht den Eindruck erwecken, es wäre ein Selbstzweck, sondern es muss immer einen Nutzen.
Deswegen halt der dritte Pol ganz oben, das Business.
In diesem Dreieck haben wir versucht, die Begrifflichkeiten, die sich hier finden, einzuordnen.
Sicherlich ist die Einordnung nicht ganz trennscharf.
Ich hatte ja eben schon ausgeführt, Kategorisierungen gelingen da nicht so einfach.
Man findet immer Argumente für und gegen.
Und es basiert ja jetzt auf keiner empirischen Untersuchung.
Sondern es ist halt eine Meinungsverwaltung.
Außerdem haben wir festgestellt, gibt es noch fünf weitere Achsen, die wichtig sind, immer gern im DevOps-Kontext wiederzufinden.
Das Thema People, Technology und Processes.
Wir wollten aber ganz klar noch zusätzlich reinnehmen, dass für uns das Thema Innovation ein ganz wichtiges ist.
Innerhalb von DevOps, was wir gerne separat herausstellen wollten.
Und zusätzlich ganz wichtig ist, ist das Thema IT-Service-Management.
Weil man darf DevOps jetzt nicht als etwas darstellen oder betrachten oder verstehen, was jetzt im luftleeren Raum neu entstanden ist.
Sondern was ja auch auf Bestehenden aufsetzt.
Und insbesondere das Thema IT-Service-Management ist da wichtig, weil da gibt es ja viele Ansätze, viele Lösungen auch in der Vergangenheit.
Und der Gegenwart, die wir da besonders herausstellen wollten, weil uns dazu auch viele Leute fragen.
Und diese fünf Achsen stellen für uns hier die, ich nenne es mal U-Bahn-Linien dar, um im Bild zu bleiben.
Und deswegen haben wir die miteinander verbunden.
So, das ist der Grundaufbau.
Außerdem haben wir einen Kern, den wir abgetrennt haben, wie eine solche Tarifzone.
Wo wir sagen, für uns gibt es einen gewissen Konsens.
Dass bestimmte Dinge eher im Kern…
…von DevOps liegen und andere wichtig auch dazu gehören, aber für uns jetzt nicht den Kern ausmachen.
Deswegen haben wir hier versucht, nochmal so eine zentrale Tarifzone einzuziehen.
Ja, das ist ja dann das Interessante bei einem Podcast.
Wir reden über irgendetwas, was die Zuhörer nicht sehen.
Aber was wir jetzt schon gehört haben, ist, es ist eine Art U-Bahn-Linienkarte, die nicht nur DevOps hat, sondern auch das Business hat.
Und im Kern haben wir eben quasi die Tarifzone 1.
Also die Tarifzone 0 mit den wichtigsten Themen.
Was ich sehr interessant finde, sind diese fünf U-Bahn-Linien.
Und ihr habt ja auch gesagt, dass ihr das nutzt, um in die Diskussion zu kommen, um Dinge zu besprechen.
Ich sehe zum Beispiel, ganz interessant, wenn wir mal auf die Beispiele eingehen, dass zum Beispiel Service Operations,
was ja auf der ITSM-Linie, auf der IT-Service-Management-Linie liegt, dass das nicht zum Kern gehört.
Also vielleicht gleich die Frage.
Das ist nicht Kern von DevOps aus eurer Sicht.
Also wie diese Map entstanden ist, ist tatsächlich, dass wir uns mit Leuten auseinandergesetzt haben, die jetzt bei uns in der Organisation sind und die auch von außen kommen, sprich Kunden insbesondere, mit denen wir diese Ansätze reflektiert haben.
Und zur Vollständigkeit gehört auch, dass wir sagen, wir leben oder wollen auch mit dieser DevOps-Metro-Map einen Gedanken von Continuous Service Delivery.
Das heißt, das ist nichts, wo wir sagen, das ist für alle Zeit fest, sondern wir bessern das regelmäßig nach.
Gerade wenn wir neuen Input kriegen, der uns überzeugt.
Jetzt konkret auf das Service Operations gegangen, war für uns das Verständnis, Service Operations ist jetzt etwas, was grundsätzlich keine ganz neue Idee ist.
Wir finden hier bestimmt viele Dinge, von denen der eine sagt, ja, neu oder andere nicht neu.
Aber tatsächlich, wenn man jetzt den Unterschied…
…macht zwischen dem auf derselben U-Bahn liegenden Security, sind wir jetzt der Meinung, nach aktueller Entwicklungslage in der Community, was definiert man in DevOps rein?
Dann hat man jetzt mit diesem Begriff DevSecOps, hat man jetzt diesen Security-Begriff mit drin.
Deswegen haben wir den jetzt als eingebaute Security mit in den Kern gezogen.
Das Thema Service Operations betrachten wir jetzt hier als Macher.
Das ist auch sehr nah assoziiert, weil, wie gesagt, wenn ich von Continuous Service Delivery spreche, dann muss ich diesen Service auch betreiben.
Wir sind aber der Meinung, dass das auf dieser IT-Service-Management-Linie nicht mehr zwingend dazugehört, weil das etwas ist, was ich in der Vergangenheit auch schon betreiben musste in diesem Kontext Operations.
Deswegen haben wir uns entschieden, dass das die erste Station außerhalb des Kerns ist.
Ihr habt ja dasselbe immer gesagt.
Vorher ist es schlussendlich ein Produkt von der Meinungsbildung.
Aber es ist ja, man hat wahrscheinlich dann jeder ein bisschen eine andere Meinung.
Gehört es jetzt noch dazu oder nicht?
Aber das Schöne, dass man dann anfängt, darüber zu diskutieren, wenn man so das vor sich hat.
Das war auch noch eine Frage fürs Verständnis, auch der Map.
Ich sehe es jetzt im Sinne so wie eine Metro mit den Linienstationen.
Das hat einen bestimmten Grund, dass es genau in der Reihenfolge, also wenn ich jetzt beispielsweise People,
da sehe ich in Chord, in Know-how, Transfer, Collaborative Culture, Collective Ownership.
Hat das da irgendwas auf sich mit dieser Sequenz?
Also dieses Ordnungsprinzip ist natürlich schwer und es lässt sich häufig was reindeuten.
Aber man muss jetzt auch sagen, dass bis auf einige Highlights, die bewusst gesetzt wurden,
durchaus sich da Argumente reindeuten.
Warum das eine jetzt neben dem anderen steht, zum Beispiel das Thema Resilienz und Anti-Fragile,
das ist jetzt auf der People-Linie gelandet, dass wir gesagt haben,
Anti-Fragile ist etwas stärker noch als Resilienz, aber genauso gut könnte man Argumente dagegen finden.
Was interessant da hervorzuheben ist, aus meiner Sicht, ist jetzt die räumliche Nähe von diesen,
von diesen U-Bahnen.
Wie zum Beispiel, du hast es eben rausgepickt, Collective Ownership und Common Metrics.
Das ist jetzt auf der einen Seite auf der People-Ebene, dieses Collective Ownership,
das heißt, dass wir uns auch gemeinsam den Gegenstand, in dem wir arbeiten,
und die Business-Ziele und die technologischen Lösungen zu eigen machen
und damit auch eine Eigenverantwortung tragen.
Und damit sowas geschehen kann,
wollen wir auf dieser Linie IT-Service-Management das Thema Common Metrics sehr nah dran platzieren,
weil wir durchaus feststellen, ich gehe jetzt mal in dieses Bild rein,
der Wall of Confusion, die ja in DevOps häufig bemüht wird,
wo halt eine Wand ist zwischen Dev und Ops, wo man sagt,
wenn wir nicht auf gemeinsam harmonisierte Ziele hinarbeiten und die entsprechend ja dann auch für uns messbar werden,
auch interdisziplinär, dann könnte es uns schwerer fallen,
diese Collective Ownership für uns zu etablieren oder anzunehmen.
Deswegen haben wir gesagt, na, da könnte es doch vielleicht einen solchen Umsteige-Bahnhof geben,
um weiter metaphorisch zu bleiben.
Ja, das wäre jetzt so ein Beispiel.
Oder vielleicht noch ein schnelles Beispiel hinterher.
Im Kern finden wir auch eine sehr nahe Verbindung oder sehr nah angeordnet,
das Thema Change-Management aus dem ITSM und das Thema Continuous Integration,
was wir jetzt eher auf der Prozesslinie haben.
Da gibt es häufig Diskussionen und irgendwie eine thematische Nähe, die wir darüber darstellen wollen.
Vielleicht kann ich da nochmal ergänzen, genau den Punkt, den du gerade eben genannt hast.
Auf dieser Prozessebene haben wir einerseits Continuous Integration und Continuous Delivery draufstehen
und das verbunden mit einem IT-Service-Management und Change-Management.
Da lässt sich ja wunderbar darauf diskutieren, wie skalieren wir einen Change-Management-Prozess etabliert,
nach Eifel, seit 1998 bei einem Kunden vielleicht implementiert.
Wie skalieren wir denn das in eine Landschaft, die fortwährend Pakete bereitstellt, Software-Pakete?
Wird jedes einzelne Paket ein Change?
Wie wird er autorisiert?
Muss der durch einen Change-Advisor-Report gehen?
Das sind Aspekte, die man halt hervorragend hier draufstellt.
Worauf diskutieren kann.
Und eben One-Size-Does-Not-Fit-All ist sicherlich auch ein Aspekt,
wo doch mitunter individuelle Lösungen zu finden sind, die dann auf die jeweilige Unternehmung anzupassen sind.
Diese Diskussionsgrundlage finde ich sehr wichtig und bekomme auch häufig dann die Frage,
wie ist das hier mit der Reihenfolge?
Und muss da dann halt auch als Prozessberater sagen,
das ist hier keine Prozesskette, die mit den Stationen abgebildet ist.
Und wenn man sich selbst als Fahrer einer U-Bahn oder Straßenbahn bewegt,
fährt man die auch selten immer von Startstation bis Endstation vollständig durch.
Man fährt vorwärts und rückwärts, man steigt um.
Das wollten wir hier auch entsprechend mit anregen, diese Analogie entsprechend weiterzutragen.
Und dann die Nähe der Stationen, die hat ja dann die Bedeutung.
Also man sieht es auch schön, zum Beispiel Continuous Monitoring,
Technology, ja, und das dann verknüpfen mit Incident Problem Management, macht absolut Sinn.
Oder wenn man sich die Innovation-Linie, die gelbe oben anguckt,
dann findet man eine räumliche Nähe, auch auf einer Linie, von dem Thema Lean Startup und Minimum Viable Product,
was ja da von Eric Ries in seinem Buch Lean Startup verortet wurde.
Und dann kommen wir schon recht bald zu Design Thinking.
Also so eine assoziative Nähe ist da grundsätzlich auch,
zu finden, auch bei Culture of Failure und Fast Feedback Loops.
Aber was wir nochmal unterstreichen wollen, wir sind dankbar für jedes Feedback,
was das nochmal klarer macht, ergeben uns aber jetzt nicht einer Hoffnung oder Jagende hinterher,
dass wir hier den heiligen Gral von DevOps haben, sondern wir freuen uns halt immer,
wenn da eine Diskussion in Gang kommt und wenn es da auch mal kontroverse Meinungen gibt.
Und das gelingt ganz gut.
Ja, eine Rückmeldung.
Eine Rückmeldung von mir, was mir sehr gut gefällt, ist, dass das Thema IT-Service-Management bei euch zum Kern mit dazu gehört.
Ihr habt wesentliche Prozesse mit drin im Kern.
Ihr habt überhaupt schon mal eine IT-Service-Management-Linie.
Also insofern finde ich das schon mal sehr schön, weil ich glaube,
dass DevOps schon auch eine Art Weiterentwicklung sein kann von IT-Service-Management,
wenn man sich einfach mal auf Frameworks bezieht.
Also insofern finde ich das als Rückmeldung dazu, Sebastian, schon sehr, sehr interessant.
Ja, also danke für die Vorlage, Dirk.
Denn das Thema IT-Service-Management liegt mir halt auch am Herzen und zeigt halt auch auf,
ja, das hat vielleicht einen leichten Charme mit Patina,
aber hat auch irgendwie eine Berechtigung, wenn es nicht als Selbstzweck verstanden wird.
Und an der Stelle bewegen wir uns hier.
Also ein Incident- und ein Problem-Management ist halt weiterhin wichtig
und auch ein Configuration-Management ist weiterhin wichtig.
Und das gehört halt auch unbedingt zu einem Kern,
so ein Verständnis.
Ja, schlussendlich sind das ja alles Hilfsmittel.
Und auch im IT-Service-Management hat es ein paar super Ideen, die DevOps unterstützen.
Und das ist schade dann, wenn die Diskussion dann zum Teil emotional geführt wird.
Dafür gibt es dann schon die Szene, die dann sagt,
ja, DevOps ist der Tod von IT-Service-Management.
Also das sehe ich nicht so.
Da stimme ich absolut euch auch zu.
Genau, also wir haben da ja auch lange drüber debattiert.
Und ich glaube, nicht nur persönlich,
sondern es sollte auch Konsens innerhalb der Direktgruppe sein.
Und das, was wir auch in unseren Veranstaltungen mit Kunden da als Feedback kriegen.
Irgendwo liegt die Wahrheit dazwischen.
Das heißt, IT-Service-Management stirbt damit nicht aus.
Aber bestimmte Konzepte, beziehungsweise die Umsetzung dieser Prozesse
müssen vielleicht neu gedacht werden unter dem Eindruck der Möglichkeiten der Automation.
Ja, und jetzt komme ich mit einem Hinweis.
Mit einer Frage, wenn man sich das anguckt.
Das Thema Cloud.
Das habt ihr zwar mit aufgenommen, sehr nett, aber es ist nicht zum Kern.
Warum gehört denn Cloud bei euch nicht zum Kern von DevOps?
Ja, interessante Frage.
Bist du nicht der Erste, Dirk, der das fragt?
Wenn man argumentiert, dass man sagt, wir haben software-definierte Infrastruktur,
dann ist es bestimmt ein wesentlicher Enabler von DevOps.
Ohne dieses würde es weniger Möglichkeiten haben.
Nämlich die technologischen Möglichkeiten, der Fortschritt treibt ja überhaupt,
dass wir so etwas wollen, was für uns hinter DevOps steckt und dass wir das können.
Also sprich, Geschwindigkeit aufnehmen und vielleicht auch mehr in Wegwerf zu denken
als in Wiederherstellung.
Ohne Cloud wäre das bestimmt nicht möglich.
Aber wir sind der Meinung, dass jetzt Cloud alleine, gerade vor dem Hintergrund,
derkt.
Ja, dieses Public-Cloud-Gedankens, der da ja am nächsten liegt,
nicht unbedingt notwendig ist, um so etwas wie DevOps zu betreiben
oder in dieser Richtung sich zu entwickeln.
Weil es durchaus auch andere Möglichkeiten gibt,
DevOps zu, oder Werte, die DevOps ausmachen,
in einem Unternehmen zu etablieren.
Dafür braucht man nicht unbedingt die Cloud.
Das heißt, wir wollten damit ganz deutlich machen,
dass man nicht aufgeben muss, nur weil es in einem Unternehmen,
in Klammern noch, keine Cloud-Strategie gibt.
Das ist der Gedanke dahinter.
Ja, ich wollte noch einen Punkt noch einmal ausführen.
Natürlich schauen wir jetzt auf diese Linie, die den Core von DevOps aufzeigt.
Aber das ist halt erstens keine harte Linie, sie ist gestrichelt dargestellt.
Und alles, was auf der Metro-Map zu sehen ist,
sind für uns DevOps-relevante Aspekte.
Und das mag sicherlich außerhalb der Map noch weitere Dinge geben,
die da auch zugehörig sein können.
Aber all das gehört dazu.
Und oft ist natürlich auch die Frage, womit fange ich denn an?
Wenn ich schneller, wenn ich meine Kultur mehr in Richtung Innovation bringen will,
wenn ich ein anderes Werteverständnis schaffen will,
brauche ich dafür Cloud?
Und die Antwort heißt, nicht unbedingt.
Hilft bestimmt.
Und auch…
Auch andere Aspekte, vielleicht Start-up-Aspekte,
die jetzt auf der Innovation-Linie liegen,
die brauche ich auch nicht unbedingt.
Das ist aber auch gestrichelt.
Ja.
Und wenn ich das als praktisch überlege,
wenn ich jetzt in die Diskussion würde gehen mit einer Map,
kann ich es immer kritisieren und jeder hat seine Meinung.
Aber ich glaube, eben darum geht es nicht,
sondern die Diskussion und dann eben auch eine Lücke zu erkennen.
Also wenn man zum Kunden sagt,
ah, okay, ja, aber…
Collaborative Culture,
da haben wir jetzt überhaupt noch nicht dran gedacht.
Und dann das zu erkennen und dann daraus auch so etwas wie Massnahmen abzuleiten,
ist es richtig?
Verwendet ihr das auch in dem Kontext?
Absolut.
Und gerade hier haben wir ja oftmals einen Startpunkt von Continuous Delivery
und agiler Entwicklung.
Ohne das Mindset, ohne Collaborative Culture wird es schwierig.
Und genau deshalb steht der…
Steht die Station halt im Core-Bereich, wo wir sagen,
ja, das ist ein Aspekt, über den man unbedingt nachdenken sollte,
wenn man sich hier mit diesen Ansätzen beschäftigt.
Continuous Testing, da ist es auch…
Gut, kann man jetzt abdiskutieren,
aber für mich ist eigentlich Continuous Testing
ein zentraler Enabler für Continuous Delivery.
Ich will ja Tests automatisieren, Feedback Loops.
Wieso habt ihr…
Müsste man das nicht ein bisschen weiter nach rechts verschieben?
Oder was ist das Argument?
Dass ihr es da draußen habt?
Berechtigte Frage.
So wie du es beschreibst, würden wir das…
Also kann ich dem folgen und würde ich auch sagen,
das kann genauso gut drin sein.
Wir haben das Gefühl gehabt bei der Einordnung,
dass das Thema Continuous Testing ähnlich wie Bildautomation
insofern nichts Neues ist,
als dass wir schon…
schon seit vielen Jahren, sage ich mal,
automatisierte Unit-Tests im Zusammenhang
mit Continuous Integration betreiben.
Vor dieser Argumentation würde ich selber auch infrage stellen,
was tut denn jetzt Continuous Integration da?
Das gab es ja auch schon vorher.
Im Zusammenspiel aber mit dem Change Management
und dann dieser Nähe zur Continuous Delivery
kriegt es, sage ich mal, eine neue…
irgendwie eine Ressistance, will ich gar nicht sagen,
aber etwas nochmal ein anderes Gewicht,
und gehört deswegen da rein.
Ähnliche Argumentationen kann man bestimmt auch
mit Continuous Testing führen.
Deswegen würde ich mich da jetzt persönlich
auch gar nicht so festlegen.
Ich stelle fest, es ist sehr nah am Rand,
an der Tarifzonen-Grenze,
und ich würde mal ganz stark hoffen,
dass da kein Kontrolleur kommt und meine Fahrkarte überprüft,
wenn ich da am Rande unterwegs bin.
Insofern tatsächlich muss man auch sagen,
hier sind wir wieder auf dem Thema Deutung,
und mir ist ganz wichtig, dass man das nicht vergisst.
Und wenn man genau diese Frage stellt,
dann bin ich der Meinung, ist man grundsätzlich
mit dem Thema DevOps und dem Mindset in der Umsetzung
schon gut unterwegs.
Wir haben das ja auch schon in verschiedenen Formaten,
auch in Social Media bereitgestellt,
und da haben wir zum Teil lebhafte Diskussionen gehabt,
insbesondere auch ein Feedback, was wir jetzt häufig wieder kriegen,
woran sich die Leute denken, dass wir das nicht machen,
woran sich die DevOps-Metro-Map messen lassen muss
oder wo sie gemessen wird.
Die Frage, super, dass es da eine Einordnung gibt,
super, dass man eine Übersicht hat,
dass man eben eine Besprechungsgrundlage hat
in bestimmten Situationen, um nichts zu vergessen
oder zumindest Dinge bewusst nicht weiter zu verfolgen
oder zurückzustellen.
Aber was es natürlich auch nicht beantwortet,
ist die Frage, wie komme ich denn jetzt
in eine DevOps-Transformation rein?
Da wäre man falsch verstanden, wenn man jetzt sagt,
ich setze mich jetzt hier in die rote Linie und fahre mal los,
und wenn ich am Ende angekommen bin, bin ich DevOps.
Die Endhaltestelle bei DevOps ist, glaube ich,
sowieso noch nicht gefunden allgemein.
Und ich denke, wenn man das konsequent weiterdenkt,
dann wird es sie auch nicht geben.
Aber hier muss man halt nochmal klar schärfen,
wir schicken uns hier nicht an,
eine Blaupause für eine DevOps-Transformation zu machen.
Das ist viel vielschichtiger,
wenn man in so einen Prozess einsteigt,
sondern hier geht es tatsächlich um eine begriffliche Sortierung,
Einordnung, Gesprächsgrundlage.
Und ich glaube halt auch,
dass die Anlässe je Unternehmen sehr individuell sind.
Und deshalb ist es eben nicht eine Perlenkette,
die aufgereiht ist, die man abfährt, um am DevOps-Ziel anzukommen,
sondern jede Kundensituation, die wir in der Vergangenheit erlebt haben,
war ganz individuell.
Jeder Kunde steigt an einer anderen Stelle ein
und an einer anderen Stelle steigt er wieder aus
und bewegt sich dann aber doch immer in diesem Kernbereich.
Also ich glaube, man kann diese Karte sicherlich sehr gut nutzen,
um in Workshops zu thematisieren,
dass vielleicht einzelne Gruppen die einzelnen Linien erklären müssen
und eine Reihenfolge erklären müssen und so weiter.
Das ist einfach ein guter Ansatzpunkt,
eine gute Möglichkeit, sich mit den Themen,
mit den Begriffen und mit anderen Dingen zu beschäftigen.
Wir reden ja häufig auch über das Erweitern des eigenen Horizonts.
Das heißt, wir müssen ja erstmal die Vertreter
aus dem Business Development und Operations
überhaupt auf eine Gesprächsgrundlage kalibrieren.
Und es ist ja im DevOps-Bereich ja immer dieses
über den Tellerrand hinausschauen,
mit den anderen sprechen, gemeinsam aneinandergehen.
Und das gelingt in dem Zusammenhang hier auch zumindest
als erstmal Einstieg, der noch nicht zu schwergewichtig ist,
wenn man die Vertreter an einem Tisch hat.
Ich wollte noch eine kurze Anekdote ergänzen.
Bei einem Kunden hängt die Metro-Map als Poster an der Wand
direkt neben dem dreijährigen Release-Kalender.
Also das Poster des Release-Kalenders hängt da nicht drei Jahre,
sondern zieht sich halt auch zu einem Zeitraum.
Und es ist mit Bewusst und Intention dort angehängt
und löst wunderbare Gespräche aus.
Wie passt das jetzt zusammen?
Wir haben einen Release-Kalender in einer klassischen Form
und wollen schnell werden, wollen Aspekte aufgreifen,
die dann auf der Metro-Map stehen.
Und wie schaffen wir das?
Ich finde, das sind sehr konstruktive Diskussionen,
die sich daraus ableiten.
Das ist schlussendlich ein super Instrument.
Und wie gesagt,
um in die Diskussion zu gehen.
Und ich denke auch,
wie eingangs gesagt,
DevOps hat so viele Dimensionen.
Und dann auch,
weil oft wird DevOps sehr einseitig,
als eine reine Tool-Geschichte.
Aber andere sehen es als eine reine Kultur-Geschichte.
Und dann kann so ein Bild helfen,
um das Wort zu benutzen,
um eine holistischere Sicht zu bekommen.
Dirk, hast du noch Fragen dazu?
Also ich habe keine Fragen.
Es sei denn, die Frage,
wie wird die Map in fünf Jahren aussehen beispielsweise,
das ist sicherlich interessant.
Also vielleicht trifft man sich ja mal wieder in dem Podcast hier.
Aber für heute, denke ich, hoffe ich zumindest,
haben unsere Zuhörer einfach auch interessiert gemacht an dieser Map,
dass sie sich die anschauen, dass sie die nutzen.
Und vielleicht auch wirklich in mehreren Büros mittlerweile
dann so eine DevOps-Metro-Map
neben einem dreijährigen Release-Kalender hängen.
Und wenn wir jetzt bei dem Metro-Map,
Analogie-Bild bleiben, kann man natürlich sagen,
eine neue Linie lässt sich natürlich hier in dieser Form
viel agiler schaffen, als wenn man sich das in der Realität vorstellt.
Wenn man bedenkt, wie lange der U-Bahn-Bau in Hamburg
in Richtung HafenCity gedauert hat
oder was die Stadt Köln zur Anbindung der Südstadt veranstaltet,
inklusive eines Stadtarchivs,
was dort in Mitleidenschaft gezogen wurde,
kommen wir hier, glaube ich,
relativ schnell in die Richtung.
Schnell voran, sagen aber auch,
die Stationen, die wir hier aufgesetzt haben,
die haben hier erstmal einen gewissen Bestand,
sind aber doch recht flink darin,
gegebenenfalls die Linien noch zu ergänzen.
Gut, dann sage ich Dankeschön von mir
und auf Wiederhören beim nächsten Podcast.
Alex, was haben wir beim nächsten Mal als Thema?
Ja, das ist noch nicht definitiv.
Also wir haben ein paar interessante Themen im Köcher,
aber wir können es im jetzigen Zeitpunkt noch nicht definitiv sagen.
Aber wir würden das dann auf unserer Webseite,
dann, wo bald es bekannt ist,
publizieren, wer als nächstes dran ist.
Aber möchte ich mich auch herzlich von meiner Seite bedanken.
Also ich denke, es war wieder eine weitere Inspiration,
also Thema DevOps.
Und ja, möchte mich herzlich bei den beiden Gästen bedanken,
Sebastian und Volkert,
dass ihr euch die Zeit genommen habt.
Ja, vielen Dank auch an euch, an euer Interesse.
Und ich bin natürlich sehr gespannt,
ob das jetzt auch bei den Hörern hier auf Resonanz stößt.
Und wäre natürlich sehr erfreut,
wenn da das eine oder andere an Feedback
vielleicht dann auch an uns zurückfließt.
Vielleicht wird dann auch Dirks Spannung aufgelöst,
wie das Ding denn jetzt in der Zukunft dann sich weiterentwickelt.
Ja, genau. Ich bedanke mich auch.
Und in diesem Fall an die Zuhörer, denen wurde noch nicht gedankt,
dass sie es jetzt soweit bis zum Abschluss dieser Podcast-Folge
mit uns aufgenommen haben.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Vielen Dank.
Wir freuen uns, wie gesagt, auf Interesse oder Feedback dazu,
um hier entsprechend Gedanken einfließen zu lassen
und die Diskussion vorzuführen.