Neues Jahr, selber Podcast: Falko, Dierk und Luca schauen auf 2021 zurück und denken darüber nach, was DevOps im Jahre 2022 wohl bedeuten mag.
Ist DevOps noch aktuell? Hat es sich in den vergangenen Jahren gewandelt (und wenn ja, wie)? Was erwartet Organisationen im Jahr 2022 im Bezug auf DevOps?
In dieser Podcast-Episode wird intensiv über die Integration und den aktuellen Stand von DevOps in Unternehmen diskutiert. Die Teilnehmer erörtern, inwiefern DevOps in der Unternehmenspraxis angekommen ist und welche Herausforderungen und Missverständnisse bestehen. Sie sprechen über verschiedene Herangehensweisen und Perspektiven, wie DevOps implementiert werden kann und welche Rolle kulturelle, organisatorische und technische Aspekte dabei spielen. Besondere Aufmerksamkeit gilt auch der Frage, wie Unternehmen DevOps effektiv umsetzen und welche Rolle individuelle Unternehmensbedingungen dabei spielen.
Inhalt
- Begrüßung und Einführung ins Thema
- Thesen zur Verbreitung von DevOps in Unternehmen
- Diskussion über DevOps-Implementierungen in verschiedenen Unternehmen
- Herausforderungen bei der Einführung von DevOps
- Rolle von ITIL 4 und SAFe im Kontext von DevOps
- Bedeutung der Unternehmenskultur und -organisation für DevOps
- Abrechnungsmodelle und wirtschaftliche Aspekte von DevOps
- Perspektiven für DevOps im Jahr 2022
- Schlusswort und Ausblick
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, Falko Werner und Luca Ingiarni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps Auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingiarni, Dirk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Und wir sind heute im neuen Jahr. Also alles Gute von uns für euch, für euch Hörer, für das neue Jahr 2022.
Und zu Beginn des neuen Jahres wollen wir eine Standortbestimmung wagen.
Was haben wir im vergangenen Jahr bei unseren Kunden und in der Szene wahrgenommen?
Und wie sehen wir DevOps im Jahr 2022?
Und wir hatten uns in der Vorbereitung auf dem Podcast überlegt, okay, jeder formuliert so zwei, drei Thesen, über die wir diskutieren.
Und wir haben schnell festgestellt, dass wir eigentlich zwei ganz coole Thesen haben, die eigentlich These und Antithese sind.
Das heißt, wir haben uns eigentlich geeinigt darauf, dass wir gesagt haben, wir haben eine These, die heißt, DevOps ist in den Unternehmen angekommen.
Und die zweite These ist, DevOps ist doch nicht in den Unternehmen angekommen.
Und über diese beiden Thesen oder Antithesen.
Wenn wir sprechen und vielleicht schafft man nachher ja auch noch eine Synthese, eine Zusammenführung.
Da schauen wir mal.
Aber das wollte es vielleicht zu meiner Seite aus gewesen sein.
Ich übergebe mal an Luca oder Falco.
Wer von euch will denn mal starten?
Ja, dann mache ich das doch.
Okay, dann machst du Falco.
Bingo!
Der Klassiker.
Zwei Sekunden warten reicht nicht.
Man muss fünf Sekunden warten.
Egal, schneiden.
Ja.
Ja, hallo.
Auch von mir ein gesundes neues Jahr.
Meine Corona-Infektion ist durch.
Insofern hoffe ich, dass es dabei bleibt und dass ihr das alle nicht durchmachen müsst.
Ich freue mich auch, mit Luca und Dirk mal wieder im Podcast zusammenzusitzen und finde die beiden Thesen, die Dirk gerade erwähnt hat, zum Stand von DevOps und ob oder ob es nicht in Unternehmen angekommen ist.
Ein spannendes Thema, so zum Beginn des Jahres.
Also vielen Dank für die Idee und ich übergebe.
An Luca.
Tja, was soll ich noch sagen?
Außer von mir natürlich auch ein gesundes Neues.
Ich bin schon sehr gespannt, was jetzt rauskommt bei diesen zwei Thesen.
Wir können ja mal anfangen mit der, ich sage jetzt mal mit der freundlicheren, dass wir sagen, DevOps ist in den Unternehmen angekommen.
Dirk, ist das so?
Naja, vielleicht kriege ich nur meine Filterblase mit bei Unternehmen, die uns beauftragen für DevOps-Trainings.
Das ist natürlich klar.
Wenn jemand sich nicht für DevOps interessiert, wird da auch kein Training gebucht.
Aber natürlich habe ich auch Kontakt zu anderen Unternehmen, zu anderen Ansprechpartnern.
Also ich glaube, dass DevOps schon in den Unternehmen angekommen ist.
Und angekommen heißt eben, dass aus meiner Sicht die Unternehmen, also die, die es betrifft natürlich, sich der Problematik bewusst sind und dass sie die Herausforderung erkennen und angehen.
Einfach mal so zwei, drei Beispiele, dass eben nicht nur wir für Trainings gebucht werden, sondern dass auch Gespräche stattfinden.
Wie könnte man denn DevOps unterstützen?
Also im Prinzip Projektanfragen, Beratungsanfragen.
Das ist so der eine Punkt.
Und der andere Punkt ist, dass ich sehe, in den Unternehmen, es werden Lösungsansätze ausprobiert und umgesetzt.
Das heißt also, es gibt die Unternehmen, die sagen, hey, wir machen jetzt DevOps.
Wir werden sicherlich noch klären, ob das DevOps ist, was die machen, wenn sie sagen, wir machen DevOps.
Aber zumindestens ist der Begriff angekommen.
Und wenn ich dann meinen lieben Bernd.
Grüßen darf an der Stelle, der auch sagt, DevOps ist angekommen.
Wir werden Bernd heute noch das eine oder andere Mal vielleicht erwähnen als Ideengeber,
der eben auch aus meiner Sicht als gestandener IT-Service-Management-Experte und Vertreter sagt,
DevOps ist jetzt da, wo vielleicht ITIL vor zehn oder 15 Jahren war.
Also wirklich als ein Begriff, als eine Philosophie, die in den Unternehmen wahrgenommen wird
und wo die Unternehmen sich dran setzen, das irgendwie anzugehen.
Ja, da sind wir natürlich tatsächlich ein bisschen in der Filterblase.
Die Unternehmen, die uns ansprechen, sind die Unternehmen, die sich mit DevOps beschäftigen.
Aber ich glaube, man erkennt es auch daran, dass diese Beschäftigung halt irgendwie ernsthafter wird,
fokussierter wird, dass das nicht nur als irgendwie so ein Randthema betrachtet wird,
dass man irgendwie mal so eine Handvoll Techies überlässt oder sowas,
sondern dass man das wirklich als Herausforderung für die Organisation als Ganzes begreift.
Was, glaube ich, ein ganz, ganz wichtiger Entwicklungsschritt ist.
Und das ist vielleicht so in der Rückschau die Entwicklung, die natürlich nicht erst 2021 angefangen hat,
aber die jetzt in vollem Gang ist, dass man weggeht von DevOps als Dev und Ops
und dass man stattdessen den Bogen noch viel weiter schlägt und noch viel weitere Teile der Organisation
und nicht nur der IT-Organisation mit einbezieht.
Insofern, da gebe ich dir recht, Dirk.
Falco, wie siehst du das?
Ja, ich sehe das.
Ich sehe, dass DevOps im engeren Sinne an vielen Stellen ein Thema ist.
Ob jetzt Teams so aufgesetzt werden, dass sie sowohl für bestimmte Funktionalitäten,
Umfänge in ihrem Bereich die Verantwortung für neue Funktionen, neue Erweiterungen und Entwicklungen übernehmen,
als auch an den Stellen, wo Service Support oder Betrieb Deployment einen Blick haben,
das ist aber aus meiner Sicht viel auf Team-Ebene platziert.
Dass es im Unternehmen angekommen ist, dass man DevOps in dem Blickfeld von Anforderungen vom Kunden,
vom Endkunden, vom Nutzer bis zur Realisierung dieser Anforderungen für diesen Endkunden
wirklich als durchgängiger Prozess, vielleicht auch mit…
… allen Aspekten, die zu DevOps gehören, so kam es im Hintergrund, kulturell, Lean, agile Entwicklung,
Measurement, kontinuierliches Verbessern, Experimentieren, sehe ich relativ selten.
Aber wir sind ja aktuell immer noch bei dem Punkt, DevOps ist ein Unternehmen angekommen,
also der Begriff, würde ich sagen, ja, Verständnis dafür an vielen Stellen auch.
Die Notwendigkeit für Automatisierung sehe ich an der Stelle ebenso bei vielen Unternehmen,
in der Wahrnehmung, in dem Punkt, wo ich sagen würde, es ist angekommen.
Ja, für mich ist auch ein Aspekt, das, was ich vorhin sagte, dass Lösungsansätze ausprobiert oder umgesetzt werden.
Das heißt, ich erlebe schon, dass Unternehmen DevOps-Teams gründen oder etablieren.
Vielleicht noch nicht ganz durchgängig, da gebe ich dir recht, Falco,
aber zumindestens werden DevOps-Teams gebildet oder DevOps-Projekte gebildet.
Klar, jetzt könnte man sagen, höre, Projekte, DevOps, widerspricht sich ja.
Können wir auch noch klären.
Aber einfach der Begriff und organisatorische Veränderungen, die werden entsprechend umgesetzt.
Und das macht man ja nicht zum Spaß.
Also ich denke, kein Bereichsverantwortlicher, kein Geschäftsführer oder kein Projektverantwortlicher,
kein Produktmanager wird mal ebenso aus Spaß sagen, hey, lass uns mal ein bisschen DevOps machen
oder lass uns mal DevOps machen.
Also das denke ich schon, dass eben die Unternehmen erkannt haben, sie müssen etwas verändern.
Wir sind an die Grenzen dessen gestoßen.
Was?
Was eine IT-Organisation leisten kann im Vergleich zu dessen, was sie auch wirklich leisten muss oder müsste.
Und du hast es eben gesagt oder ein bisschen angesprochen, Falco,
die Wert- und Kundenperspektive, die ist noch nicht ganz da, aber sie kommt schon ein bisschen näher.
Und es gibt eben auch ganz tolle Beispiele, wie das entsprechend umgesetzt ist.
Und da haben wir ja im nächsten Podcast, in der nächsten Folge ein tolles Beispiel,
wie DevOps wirklich umgesetzt werden kann oder könnte.
Also das ist eben für mich wirklich ein Zeichen, es ist angekommen, weil die Unternehmen etwas tun,
weil sie etwas verändern.
Und wir werden sicherlich auch gleich noch darüber sprechen, was sie vielleicht auch falsch machen
oder wo wir von Dingen berichten können, wo sie ihre Erfahrungen machen.
Das heißt, es anders zu machen, aber sie stellen sich dieser Verantwortung und stellen sich auch der Herausforderung,
Dinge wirklich mal anders zu machen und auch anders zu gestalten.
Ja, ich finde, zum Ersten hat Falco natürlich recht, wenn er sagt,
ganz häufig ist das auf der Team-Ebene schon viel mehr angekommen als auf größeren Organisationsebenen.
Aber andererseits spürt man eben auch Bewegung in diesem Thema,
zum Beispiel durch Bücher wie Team Topologies, das ja auch nicht 2021 rauskam,
aber zumindest meiner Wahrnehmung nach 2021 irgendwie sehr viel mehr Aufmerksamkeit,
erfahren hat, dass viele Organisationen jetzt merken, dass es eben keine Teamaufgabe
und es ist auch kein Projekt, so wie Dirk gesagt hat, sondern da geht es um viel, viel mehr,
dass sie sozusagen an die Grenzen der Sichtweise stoßen, dass DevOps eine technische Herangehensweise ist
und dass das jetzt zunehmend ausstrahlt auf weitere Bereiche der Organisation.
Und das beobachte ich auch in Gesprächen, auch in Trainings, dass die Leute dann sagen,
ach Donnerwette, jetzt wird mir alles möglich.
Okay, klar, was ich irgendwie schon wahrgenommen und erfahren habe in meiner Organisation,
jetzt verstehe ich langsam die Mechanismen, die da dahinter stehen.
Ja, stimmt. Das ist das, was ich auch feststelle.
Wir haben ja einige größere Kunden auch bei unseren Trainings sitzen.
Und das, was du sagst, die sagen, ah, alles klar, das verstehe ich jetzt, warum wir das so und so machen.
Interessant ist natürlich auch, fällt mir jetzt so auf,
dass wir natürlich häufig auch ältere Teilnehmer haben und dann sagen die,
boah, haben wir alles früher schon mal gehabt.
Also da kommt dann so dieser Effekt, na ja klar, vor 20 Jahren haben wir das gemacht oder vor 15 Jahren
und dann wurde es irgendwie getrennt, aber es macht irgendwie Sinn, das wieder zusammenzuführen.
Das heißt auch, das ist für mich ein Argument, dass DevOps in den Unternehmen angekommen ist,
weil sich nämlich eben Dinge sozusagen wieder etablieren, die vor Jahren mal etabliert waren,
aus verschiedenen Gründen.
Und ich sag mal, nicht mehr fortgeführt wurden, aber eben jetzt wieder aufleben oder wo man das wieder aufleben lässt
und da versucht doch wieder die Erfahrung von damals, die positiven Erfahrungen wieder entsprechend umzusetzen.
Aber was Luca sagte, ah, jetzt verstehe ich, was wir da machen oder warum wir das machen.
Und die Zustimmung kommt, es macht eigentlich Sinn.
Also es macht Sinn für die Teilnehmer.
Ja, das ist ja auch so. Es macht ja auch schlicht und ergreifend Sinn.
Ich meine, viele der Aspekte von DevOps.
Das sind ja auch eigentlich schon keineswegs mehr neu.
Man denke an Lean, das ja eigentlich vom Toyota-Produktionssystem kommt
und das wurde in den 30er Jahren in seinen Anfängen erdacht.
30er Jahren des 20. Jahrhunderts wohlgemerkt.
Insofern, das ist nicht mehr so wahnsinnig neu.
Dasselbe ist mit der agilen Vorgehensweise.
Ich meine, der Begriff agil ist immerhin auch schon 20 Jahre alt
und die dahinterstehenden Gedankengänge, naja, ich sag immer,
das Rad ist bestimmt nicht im Wasserfallprozess erfunden worden.
Tja, wer weiß. Warst du dabei?
Nee, aber ich habe gute Quellen.
Okay, gut. Dann bring die bitte mal. Die möchte ich sehen.
Genau. Nee, aber im Ernst, das sind einfach Herangehensweisen,
die sich, glaube ich, anbieten und die sich schon oft angeboten haben.
Und die Leute fühlen sich jetzt vielleicht wieder ermutigt,
Dinge zu tun, von denen sie das Gefühl haben, ja, das fühlt sich richtig an.
Ja, und ich meine, wir sind ja auch alle, die das Gefühl haben,
wir sind ja auch alle in so einem Buzzword-Bingo-Business unterwegs.
Also, das ist für mich auch ein Argument.
Das kann man jetzt gut oder schlecht finden.
Aber wenn ich so an so zwei, drei Kontakte von mir denke,
mit denen ich auch immer wieder im Austausch bin,
das sind alle drei in diesem Fall, also ich habe jetzt drei Menschen vor Augen,
die sind wirklich eingefleischte Service-Management-Profis.
Also, die sind wirklich stark auf ITIL beispielsweise ausgerichtet.
Und selbst die haben im letzten Jahr gesagt,
mehr oder weniger,
eindeutig, hey, wir machen bei uns jetzt DevOps.
Auch da wieder die Frage, was ist DevOps?
Das ist ja ein Punkt, wahrscheinlich, da können wir stundenlang diskutieren.
Deswegen fragen wir das ja auch alle unsere Gäste immer.
Aber auch da sage ich mal so, diese eingefleischten Service-Management-Profis,
also auch Experten, die auf Prozesse Wert legen,
die auf, vielleicht auf einen Wasserfall vielleicht eher Wert legen,
die auf Silos vielleicht aufgebaut sind, um ihre Prozesse drüber zu legen.
Selbst die reden davon,
dass sie jetzt DevOps machen und finde ich dann eben auch schon sehr interessant.
Und wie gesagt, wir sind ja immer noch bei dem Part,
DevOps ist in den Unternehmen angekommen.
Hängt das vielleicht auch damit zusammen,
wenn Service-Management-Spezialisten, erfahrene Kollegen über DevOps reden,
dass ITIL als verbreitetes Framework im Service-Management die Version 4
herausgebracht hat und da viele Themen, die auch mit Agile-Management,
die auch mit Agile-Management, die auch mit Agile-Management, die auch mit Agile-Management,
die auch mit Agilität zu tun haben, auch in dem Bereich Service-Management
einen höheren, ja, Wahrnehmungsgrad erhalten?
Das könnte natürlich sein, wenn ich jetzt so ein bisschen schubladenartig denke,
also die drei Kollegen mögen mir das verzeihen, dann könnten die ja eigentlich
auch sagen, hey, wir machen jetzt ITIL 4. Das wäre ja auch eine Argumentation,
wenn man auf dieser Begrifflichkeit bleibt. Aber und ITIL 4 hat ja auch ganz klar gesagt,
Lean-Praktiken übernehmen wir, wir übernehmen DevOps, also ITIL 4 hat sich quasi
so ein bisschen auch als übergreifendes Framework positioniert. Ich weiß gar nicht,
ob uns jetzt sozusagen so eine Framework-Diskussion weiterbringt. Aber was ich dabei rausnehme,
ist, dass zumindestens der Begriff von DevOps und das, was dahintersteckt,
dass das eben wahrgenommen wird und dass sich das auch bei Menschen in den Gesprächen widerspiegelt
widerspiegelt, die eben davon früher nichts wissen wollten. Also bei all diesen dreien Menschen
weiß ich, wie sie noch vor drei, vier Jahren wirklich so von wegen Agilität, bleibt mir weg damit,
so wie sie da entsprechend argumentiert haben.
Ja, wobei ich unterstellen würde, dass bestimmt eine Menge pragmatische Praktiker,
auch wenn die vielleicht noch in ITIL-Versionen geschult wurden, die das Wort DevOps zumindest nicht
ausgeführt haben, dass die sehr wohl natürlich Praktiken verwendet haben, die man jetzt vielleicht
DevOps nennt, aber die natürlich vor 10 oder 20 Jahren auch schon eine gute Idee waren.
Das erinnert mich so ein bisschen an meinen eigenen Werdegang, weil ich mache auch schon länger
DevOps, als ich das Wort DevOps kenne. Sondern ich habe halt Sachen gemacht, die für mich sinnvoll waren.
Und irgendwann habe ich gemerkt, es gibt noch mehr Leute, die das machen und die nennen das DevOps.
Also nenne ich es halt auch DevOps. Und ich glaube, so geht das ganz häufig. Wenn die Leute sich trauen,
das zu tun, was sinnvoll ist.
Dann landen sie ganz häufig bei Sachen, über die man halt auch in DevOps redet.
Ja, ich habe gerade nochmal darüber nachgedacht, bei unseren SAFe-Trainings, bei den Einführungstrainings von SAFe.
Da ist meine Wahrnehmung, dass dann auch Betriebsleute sitzen. Also SAFe kommt ja auch eher aus der agilen Seite,
als agiles Skalierungsframework. Und wenn dann die Betriebsleute da drin sitzen, dann kommt auch immer die Frage,
ja, wo sind wir denn da? Oder wo finden wir uns wieder? Also auch das ist, wie ich finde,
dann schon ein Punkt, wo man daraus ableiten kann, dass der Betrieb oder das Ops, wenn man jetzt wirklich das Ops nimmt,
dass das angekommen ist in dem Unternehmen im Sinne von, auch da, die Leute müssen wir auch einbeziehen.
Also die Lösung einer zukünftigen Organisation kann nicht darin liegen, Dev und Ops zu trennen.
Also ich muss, wenn ich, auch wenn ich agil skaliere, wenn ich ein Unternehmen nach SAFe ausrichten möchte, muss ich mir Gedanken machen,
wo platziere ich meine Betriebe?
Wo sind meine Betriebsleute? Wo finden die sich wieder?
Ja, das kann natürlich auch sein, dass ein Unternehmen sagt, wir machen DevOps, das ist bei uns angekommen.
Wir haben ein Programm, in dem verschiedene Teams zusammenarbeiten, bei dem letztendlich eine Gesamtverantwortung ist,
sowohl für die Weiterentwicklung, als auch für Test, als auch für den Betrieb, Support, Deployments und ähnliches.
Dass man sich aber dann trotzdem,
teamweise siloartig organisiert und sagt, wir machen zwar DevOps im Programm, aber wir haben ein Test-Team.
Wir haben ein Entwicklungsteam, wir haben ein Architektur-Team und wir haben ein Betriebsteam.
Wir haben vielleicht auch noch ein Support-Team, die dann die Support-Fälle aufnehmen und dann an die entsprechenden Entwickler oder Tester oder Architekten auch weiterreichen.
Also so ein Kommunikations- oder Service-Desk-Team.
Ist das dann etwas, was ihr als DevOps ist im Unternehmen angekommen, bewerten würdet?
Oder ist das was, wo ihr sagt, nee, eigentlich ist das noch nicht DevOps?
Also, wenn ich mal meine persönliche Sicht darauf ausbreiten darf.
Ich finde, wenn das im Einzelfall sinnvoll umgesetzt ist, ja, dann ist das auf jeden Fall DevOps.
Ich meine, die wesentlichen Aspekte von DevOps zeichnen sich doch dadurch aus, dass ich diesen Kundenfokus habe.
Dass ich den Produktfokus habe.
Und wenn ich den am besten abbilden kann, zum Beispiel in einem zentralen Service-Desk, dann ist das doch voll okay.
Was wäre denn die Alternative?
Angenommen, ich weiß auch nicht, das ist ein großes Produkt und das wird von 20 Teams gebaut und der arme Nutzer, der ein Problem hat, müsste jetzt wissen, welches von den 20 Teams er anrufen soll, damit dieses Team seine Ende-zu-Ende-Verantwortung wahrnehmen kann.
Das ist doch in niemandes Sinne.
Insofern, solange eine vernünftige Kommunikation möglich ist.
Auch klar ist, dass die Entwicklungsteams nicht die Verantwortung dann irgendwann mal abgeben an ein Support-Team oder sowas.
Dann ist das doch voll okay zu sagen, wir delegieren hier gewisse Kommunikationsaufgaben, zum Beispiel im Sinne des Kunden, im Sinne der Teams.
Aber wir behalten unsere Flexibilität, wir behalten unsere Feedback-Schleifen.
Wir gehen auf die drei Wege von Gene Kim, mit Systemdenken und Rückkopplungsschleifen und kontinuierlichem Lernen.
Dann ist das doch voll okay.
Aus meiner Sicht ist das ein wunderbarer DevOps-Ansatz.
Ja und jetzt kommen wir so ein bisschen in diese zweite These, in die Anti-These, würde ich ja Falkos Frage dazu mal nutzen.
Ich würde Luca erstmal zustimmen, dass ich das auch als DevOps sehen würde, weil ich ja der Meinung bin, DevOps heißt, es gibt keinen eindeutigen DevOps-Zielzustand.
Das würde ja heißen, ich führe DevOps ein und der, der mich kennt aus meinen Trainings, der weiß, dass ich nicht der Freund davon bin, etwas einzuführen.
Das heißt nämlich immer, ich habe einen Zielzustand, einen Endzustand erreicht und da bin ich ja wie gesagt kein Freund von.
Das heißt, ich denke schon, dass es sinnvoll ist, wenn man sich dieser Probleme bewusst ist, die wir haben und die zu DevOps führen und da muss man ein bisschen ausprobieren.
Natürlich kann man Dinge umsetzen, die sozusagen erprobt sind, sonst bräuchte man ja auch Trainer nicht, sonst müsste man über das Thema gar nicht sprechen.
Aber wie gesagt, es gibt nicht die Ideallösung, es gibt vielleicht Zwischenschritte und insofern glaube ich, um auf deine Frage einzugehen Falko,
wir sind schon, das ist schon angekommen, wenn man so etwas tut, aber es ist eben noch nicht quasi am Ende angekommen.
Es ist noch nicht fertig, weil ich eben auch glaube, dass es eben einen fertigen Zustand vielleicht jetzt aktuell noch gar nicht gibt.
Also wenn das für euch okay ist, dann würde ich sagen, dann lasst uns jetzt mal in die Antithese wechseln, nämlich den Punkt, DevOps ist noch nicht angekommen.
Denn das, was ich in den Unternehmen, in den Trainings erlebe und ich denke, das geht euch genauso, ist, da kommt die Frage immer.
Habt ihr mal ein Beispiel dafür oder hast du mal ein Beispiel dafür? Wie machen das denn andere?
Und da kann ich natürlich versuchen, aus Projekten zu erzählen, aber es gibt aus meiner Sicht oder ich habe kein wirklich Beispiel, wo ich sagen würde, das ist jetzt, weiß ich nicht, 90% DevOps oder 100% DevOps.
Es sind überall Erlebnisse aus einem kleineren Umfeld, auch aus einem größeren Umfeld und wie gesagt, wir haben ja nächste Woche, wollte ich gerade sagen, nächsten Monat haben wir ja wieder ein Beispiel,
wo Dinge umgesetzt werden, die aber eben auf bestimmte Rahmenbedingungen abzielen, die bestimmte Voraussetzungen erfüllen und deswegen glaube ich eben, dass es so ein, es fehlt noch ein richtiges, cooles DevOps, was man sozusagen nutzen kann.
Und dann ist die Frage, geht das überhaupt? Also gibt es das überhaupt? Denn DevOps ist ja kein Framework und es ist, insofern gibt es auch keine gefertige Blaupause, das heißt, die Unternehmen und die Verantwortlichen und auch die Teilnehmer in den Trainings,
die suchen aus meiner Sicht händeringend fertige Komplettprodukte, also so können wir das nehmen und so machen wir das, so wie das ja Safe anbietet im anderen Kontext, aber da habe ich eben ein fertiges Konstrukt und auch da erleben wir oder erlebe ich, dass die Unternehmen sagen, ja, wir nutzen Safe, aber wir machen nicht alles von Safe.
Also, lange Rede, kurzer Sinn, ich glaube, dass das, was ich an DevOps gut finde, dass es kein fertiges Framework ist, das ist die Herausforderung für die Unternehmen.
Dass es eben nichts Fertiges gibt, sie müssen eigene Erfahrungen sammeln und das ist natürlich in wirtschaftlich schwierigen Zeiten eine Herausforderung, wenn ich nicht sofort ein tolles Ziel aufzeigen kann.
Da stimme ich dir auch völlig zu, Dirk. Man merkt das ja dann auch häufig, dass DevOps halt doch ein bisschen zu sehr auf die leichte Schulter genommen wird und zwar lustigerweise, obwohl sie es jetzt immerhin schon viel ernsthafter angehen und nicht nur als reine Technologie und Automationsspiel, wie sie sehen.
Ich meine, ungeachtet dessen, dass es ja jetzt in vielen Organisationen auch die Stellenbeschreibung eines DevOps-Ingenieurs gibt, wo ich mich immer frage, was das sein soll, gemessen an der Perspektive von DevOps, die Dirk und Falko und ich beispielsweise vertreten.
Ja, genau.
Du hast DevOps-Ingenieurin gesprochen, also ich kriege auch Anfragen, da sucht ein Unternehmen ein DevOps.
Genau.
Dann frage ich immer.
Wir können auch zwei oder drei DevOps kaufen.
Genau.
Richtig.
Wenn wir einen halben oder ein Dreiviertel DevOps wollen oder 100 Gramm oder so, ich habe mir sogar den Spaß auch mal gemacht, die Antwort zu senden, aber ich habe dann keine Antwort auf meine Antwort bekommen.
Wer weiß, warum.
Ja, also Jonathan Hall von Tiny DevOps, das ist übrigens auch ein sehr hörenswerter Podcast, muss ich sagen, der hat einen ziemlich coolen Kunstgriff.
Wenn er eine Stellenbeschreibung für einen DevOps-Ingenieur liest, dann ersetzt er überall das Wort DevOps mit Zusammenarbeit und dann schaut er, ob die Stellenbeschreibung dann immer noch Sinn macht.
Und wenn ja?
Dann war es eine gute Perspektive auf DevOps.
Wir haben ja noch ein paar Punkte nachher.
Genau.
Aber um mal meinen Gedankengang zu Ende zu kriegen, die ich vor circa einer Minute mal irgendwie angefangen hatte.
Obwohl das Bewusstsein mittlerweile schon gewachsen ist, dass DevOps halt nicht nur eine rein technische Sache ist, glaube ich, unterschätzen immer noch sehr viele Unternehmen das.
Weil wenn man das wirklich ernsthaft…
Wenn man das wirklich ernsthaft betreibt, wenn man diese Agilisierung, diese DevOps-Lichung tatsächlich bis zum Ende führt, dann strahlt das notwendigerweise auf nahezu alle Bereiche des Unternehmens aus.
Wenn ich diesen Kundenfokus wirklich durchhalten will, dann macht das ja nicht irgendwie an den Grenzen der IT-Organisation halt, sondern dann nimmt das höchstens seinen Anfang.
Wenn ich agil Produkte plane, dann muss das zwingend irgendwie einen Einfluss darauf haben, wie ich budgetiere und so weiter und so weiter.
Wie ich mit meinen Zulieferern zusammenarbeite.
Welche Art von Verträgen ich überhaupt abzuschließen in der Lage bin.
Und was man da für einen riesen Fass aufmacht, ich glaube, das ist bei vielen Unternehmen, das ist denen noch nicht so richtig bewusst.
Und das ist dann häufig, glaube ich, auch der Punkt, wo es dann anfängt wehzutun.
Dass dann diese Spannungen entstehen, dass sie sagen, also die IT-Organisation, die ist jetzt ja irgendwie total agilisiert und verdevopselt und alle anderen machen weiter wie bisher und irgendwie klemmt das.
Oder sehe ich das zu negativ oder habt ihr auch diese Beobachtung gemacht?
Doch, ich sehe schon, dass das so…
In der Form immer wieder auftaucht, dass man letztendlich häufig mit der IT anfängt.
Und an den Stellen, wo ich vorhin gesagt habe, so Team-Ebene, man versucht letztendlich Cross-Funktionale oder Feature-Teams aufzusetzen, die den Blick haben, der von Anfang der Entwicklung, von vielleicht auch einer beschriebenen Anforderung, User-Story, Feature, Epic, was auch immer, hin zu einem für den Endkunden nutzbaren Ergebnis.
Ergebnis.
Einem funktional freigegebenen, releasten und funktionierenden Feature geht.
Dass man aber den Punkt auch weiter früher ansetzen muss, dass man überlegen muss, welches Feature welche Priorität haben soll, wie man letztendlich auch verschiedene Umsetzungswege vielleicht priorisiert, dass man vielleicht Dinge kleiner schneidet, dass man experimentiert, dass man im engen Kontakt mit dem Kunden auch Feedback sammelt.
Das ist was, wo halt…
Bei diesem noch nicht angekommenen Aspekt von DevOps noch eine ganze Menge an freien Schritten sind, die in Unternehmen zu gehen sind, wo letztendlich noch Luft für Entwicklung bleibt.
Und das ist letztendlich der Weg, den diese Unternehmen, die angefangen haben, den Weg in Richtung DevOps zu gehen, halt auch gehen müssen.
Das heißt, da kommen ja dann auch diese Aspekte wieder raus.
Diese Erweiterung.
Diese Erweiterung des Akronymes oder des zusammengesetzten DevOps-Worts in Richtung Business bis DevOps oder Einbeziehung von Security, DevSecOps oder ähnliche Bereiche, die letztendlich genau darauf dann immer wieder fokussieren, dass es allein die Entwicklung und der Betrieb halt nicht sein können.
Was halt auch häufig bei DevOps nicht erwähnt wird, dass dazwischen ja irgendwo auch eine Art von Testing stattfindet.
Also eigentlich ist das klassische DevOps ja eigentlich…
Ein DevTestOps, ohne dass es halt irgendjemand erwähnt.
Das heißt, man muss den Wertstrom an sich in den Fokus setzen, in den Blick von dem Kundenwunsch oder dem Kundenbedürfnis im besten Fall noch bis hin zu der Erfüllung genau dessen.
Und dabei kann man natürlich viele Dinge optimieren, zum Beispiel durch Automatisierung, durch Vereinfachung von Prozessen, dass man nach Wertschöpfung analysiert, dass man in die Richtung geht.
Um wirklich auch die Teamorganisation und die Kommunikationsprozesse, die es geben muss, um diesen Entwicklungsprozess abzubilden, entsprechend auch in der Aufbauorganisation wiederzuspiegeln.
Und da hapert es halt bei vielen Unternehmen.
Und da gibt es natürlich dann die Punkte, wo man in die Aktivität gehen muss.
Ja, finde ich interessant.
Also das Thema Wertstrom spricht ja auch genau das an, was eben…
Und das ist halt auch wirklich ein Grund, warum das eben noch nicht angekommen ist, weil sich die Unternehmen eben organisatorisch noch nicht darauf ausrichten können oder wollen.
Das können wir vielleicht nachher nochmal ein bisschen besprechen, weil mir ist noch ein anderer Punkt gerade eingefallen, als du angefangen hast, die Begriffe sozusagen zu sezieren und zusammenzusetzen.
Dev und Ops.
Und in der Anfangsphase deiner Ausführungen habe ich auch gedacht, Mensch, stimmt.
Es ist auch die Frage, woher kommt eine DevOps-Initiative?
Und da erlebe ich natürlich…
Und da erlebe ich zwei unterschiedliche Richtungen.
Also ich habe Kunden, die kommen aus der Dev-Ebene.
Das heißt, die Entwickler sagen, wir möchten jetzt die Ops-Leute mit dazunehmen.
Also wir möchten DevOps machen, aber getrieben aus der Entwicklung.
Und ich sehe Unternehmen, die treiben quasi DevOps oder da kommen DevOps-Initiativen zustande aus dem Ops-Bereich.
Das heißt, der Betrieb sagt, wir möchten agiler werden.
Auch da immer die Frage ist, was bedeutet das für sie?
Und das sehen sie unter DevOps.
Denn einen interessanten Punkt…
Und der wird meines Erachtens gar nicht so vielen Leuten bekannt.
Der Begriff DevOps und die Initiative zu DevOps kommt eigentlich aus dem Ops-Bereich.
Also es ist nicht so, dass die Dev-Leute irgendwann mal gesagt haben vor 10, 15 Jahren, lass uns mal ein bisschen Ops dazunehmen, sondern der Begriff DevOps, auch die DevOps Days, sind ja eigentlich entstanden durch Menschen, die aus der Ops-Welt gekommen sind und die Ops-Welt anders gestalten wollten, indem sie gesagt haben, lass uns doch mal ein bisschen Agilität mit dazunehmen.
Also insofern, auch da wieder mal kurz gesagt, es ist deswegen noch nicht angekommen, weil es immer aus meiner Sicht eine Richtung gibt.
Also ein Bereich von Dev oder Ops versucht, den anderen Bereich zu integrieren, versucht da zusammenzukommen.
Und das hat dann manchmal auch vielleicht noch ein kleines Geschmäckle, wenn die anderen damit kommen und man das deswegen, auch wenn es vielleicht gut wäre, halt so ein bisschen skeptisch betrachtet.
Ja, das ist…
Da habt ihr echt ganz viele wahre Sachen.
Und aus meiner Sicht, das ist das Tolle, aber auch das Bedrohliche irgendwie an DevOps, dadurch, dass es so viele verschiedene Aspekte zugleich berührt, die technische Automatisierungsebene über die Prozess- und Organisationsebene bis hin zur Kultur, hat das eine unglaubliche Wirkmacht.
Wir reden hier nicht bloß von 10% Verbesserung oder sowas, sondern wir reden im Zweifelsfall wirklich von Vervielfachungen, wenn ich mir den State-of-Devops-Report anschaue.
Aber das zeigt halt auch, wie tiefgreifend die Umwälzungen sind und wie bedrohlich sich das anfühlen mag, wenn man da unterwegs ist.
Ja, und dieses Bedrohliche, ich habe ja eben schon gesagt, es wäre ja schön, wenn wir ein fertiges Modell hätten, also so von wegen DevOps out of the box.
Wir drei können das nicht bieten, ich glaube, das wäre etwas zu viel verlangt, dann würden wir diesen Podcast nicht mehr machen wahrscheinlich, wenn wir da eine passende Antwort für hätten.
Aber auch, wenn ich mal so rumschaue beim Kunden und bei den Marktkunden.
Marktbegleiter, wie man es so schön nennt, dass ich da auch bei vielen Beratungs- und Systemintegrationsunternehmen auch da eigentlich sehr wenig sehe.
Das heißt, selbst die großen Beratungshäuser, selbst große Systemintegratoren, die da dafür prädestiniert sind, über DevOps vielleicht mehr zu machen, selbst die sind eigentlich nur in zwei Ecken unterwegs.
Entweder bieten sie Beratung an zu agilen Methoden, das heißt, sie helfen bei Einführung von Scrum oder Kanban, unterstützen die Unternehmen, unterstützen die Teams,
aber eben eher auf der Team-Ebene und nicht auf einer Unternehmensebene.
Oder sie kommen eben mit Tools daher, das heißt, sie zeigen auf, wie man eine tolle CI-CD-Pipeline gestalten kann und sagen dann, alles klar, wenn du das Tool hier eingeführt hast und die Teams agil sind, dann machst du DevOps.
Also auch da wieder kurz gesagt, glaube ich oder bemerke ich, dass eben am Markt auch große Beratungsfirmen, große Systemintegrationsunternehmen es nicht schaffen,
ein ganzes Konstrukt anzubieten.
Oder nur mit einzelnen Elementen kommen und dadurch auch die Unternehmen natürlich nicht animieren, da wirklich konsequent weiterzugehen.
Ja, aber das erscheint mir auch irgendwie logisch, weil letzten Endes, wenn man es zu Ende denkt, dann geht es halt ganz wesentlich um Kommunikation zwischen Leuten, die da stattfinden muss.
Und die Kommunikation muss sich danach richten, was für Bedürfnisse diese Leute haben.
Und das wiederum hängt natürlich ganz stark davon ab, was die für Produkte bauen, welche Beschaffenheit die Produkte haben, welche Struktur die Produkte haben.
Und somit natürlich auch, welche Wünsche die Kunden an diese Produkte richten.
Das heißt, es kann irgendwie, glaube ich, kein Schema F geben.
Das ist, ich glaube, das ist eine gute Nachricht, weil am Ende des Tages geht es dann da wieder um Menschen.
Und das ist etwas übrigens, was nicht nur ich mir irgendwie ausgedacht habe, sondern ich unterhalte mich sehr viel mit Technologie-Managern, CTOs, solchen Leuten.
Und interessanterweise haben die alle einen entsprechenden…
Werdegang, sage ich mal, von ihrer Philosophie im Laufe der Zeit gemacht, dass sie gesagt haben, naja, ich dachte immer, bei Technologie geht es um Technologie, bis ich irgendwann darauf gekommen bin, bei Technologie geht es ja um Leute.
Und die Art und Weisen, wie Leute zusammenarbeiten, ist wahrscheinlich so verschieden wie die Leute selber, ne?
Vielleicht als kleine Ergänzung noch, auch weil wir ja gerade dabei sind oder ich dabei auch gerade war, wo sehe ich auch Lücken?
Wo haben wir keine Antworten?
Also wir sehe ich jetzt mal die Berater, die Beraterzunft.
Die Trainerzunft.
Wir haben ja auch, wir reden darüber, was DevOps eine neue Art der Zusammenarbeit ist oder eine andere Art.
Und ich sage mal, so richtig gute Zusammenarbeitsmodelle in der Praxis können wir ja eigentlich auch gar nicht bieten.
Also wir können natürlich sagen, ja, wenn man Teams zusammenstellt, dass wir nicht die Menschen bereitstellen, sondern dass wir das Wissen transferieren müssen.
Alles okay, also da gibt es schon ein paar Antworten.
Aber ich habe auch an vielen Stellen in den Trainings…
In den Trainingsfragen, die ich einfach nicht wirklich konkret beantworten kann, vielleicht liegt es ja an mir, aber da darf sich gerne jemand melden, der dazu Antworten hat.
Aber zum Beispiel können wir, oder sehe ich hier in der Praxis, dass es eben schwierig ist, dass Auftraggeber DevOps gar nicht beauftragen können.
Also die Konstrukte in der Auftragsverteilung oder in der Auftragsvergabe, in der Auftragskontrolle, in der Durchführungskontrolle, das sind alles Dinge, die noch nicht so weit verbreitet sind.
Das heißt, Auftraggeber können meiner Meinung nach heute DevOps nur sehr, sehr schwer bei Leistungserbringern beauftragen.
Da kommt immer die Frage, wie wird das abgerechnet mit Stundenbasis und so weiter.
Also wahnsinnig viele praktische Herausforderungen.
Wenn ich eben gesagt habe, wie Stundenbasis abrechnen, also wie wird denn DevOps abgerechnet?
Und da sehe ich auf der anderen Seite ja auch den Punkt, wir haben ja auch Kunden, die aus der Softwareentwicklung kommen.
Also klassische Systementwicklung.
Also Entwicklungshäuser, die eben auch vermehrt, ich sag mal, dahin gebracht werden von ihren Kunden, das im Sinne von DevOps zu machen.
Also dass die Verantwortung für ein System nicht darin liegt, eine Diskette oder CD zu erstellen und die zum Download bereitzustellen,
sondern die Systemhäuser werden gezwungen, werden dahin gebracht, wirklich ein System as a Service bereitzustellen.
Auch die müssen ja über DevOps reden. Auch da ist es schwierig, Abrechnungsmodelle zu finden auf der Anbieterseite.
Wie kriege ich das hin, dauerhaft Teams zusammenzusetzen?
Wie kriege ich es hin, dauerhaft Teams zusammenzusetzen, die jetzt einfach gar nicht da sind?
Also es ist keine Seltenheit, dass da Mitarbeiter sind in den DevOps-Trainings, die sind in vier, fünf Projekten.
Wie soll ich denn einem Unternehmen oder wie soll ein Unternehmen es schaffen, diese Projektstruktur mit Experten, die immer in irgendwelchen Projekten arbeiten, in so eine dauerhafte Teamstruktur zu bekommen?
Also es gibt Ideen dazu, aber ich sehe noch keine wirklich heilsbringende Lösung, die in der Praxis auch funktioniert und die man einfach und erfolgreich implementieren oder umsetzen kann.
Ja, das ist eben die große Schwierigkeit, nicht wahr?
Dass es letzten Endes um Kommunikation zwischen den verschiedenen Mitarbeitern geht, innerhalb des Teams, zwischen Teams und so fort.
Und die muss sich ja auch wandeln können.
Also selbst wenn ich mir jetzt eine Teamstruktur…
Überlege und die sei jetzt perfekt, weil ich so unglaublich schlau bin, dann ist die in zwei Jahren vielleicht nicht mehr so ganz stimmig, sondern da bräuchte ich was anderes.
Also auch in diesem Sinne, DevOps ist eigentlich kein Endzustand, sondern DevOps ist ein Prozess des Hinarbeitens auf eine Struktur, die sich im Jetzt als hilfreich und günstig herausstellt, aber in der Zukunft ganz bestimmt nicht mehr ist.
Weil die Welt bleibt halt nicht stehen und Unternehmen bleiben auch nicht stehen.
Das ist übrigens ein anderer Punkt.
Wo ich gerade darauf komme, das ist ein ganz beliebter Fehler, finde ich, bei DevOps-Einführungen, dass man nur in Vorwärtsrichtung denkt.
Dass man denkt, ich baue jetzt…
Ich meine, selbst der Begriff Wertstrom drückt das ja schon aus.
Ich hätte viel lieber eine Wertschleife.
Ich würde viel lieber nicht nur in Vorwärtsrichtung, in Stromabrichtung denken, sondern auch dann die entsprechenden Rückkupplungen haben.
Und das ist etwas, was man, wie ich finde, ganz gezielt und ganz bewusst…
…von Anfang an einbinden muss.
Das wäre übrigens eine der Antworten, die man sozusagen allgemeingültig geben kann, Dirk, dass man sagt, wie mache ich denn ein DevOps?
Zum Beispiel, indem ich Rückkopplungsschleifen baue.
Und was das dann konkret heißt, hängt halt vom Einzelfall ab.
Da muss ich dann wieder in meinen Berater-Kommt-drauf-an ausweichen.
Ja, klar. Aber dann komme ich als Kunde und sage, diese Rückkopplung, die bezahle ich dir nicht.
Ich bezahle nur, dass da was rauskommt, was ich anfassen kann.
Ja, aber die Rückkopplung macht das, was rauskommt.
Ja, und dass das stabil rauskommt.
Und dass das, was rauskommt, auch wirklich anfassbar ist.
Und nicht nur die klassischen, zum Beispiel PowerPoints, die man dann sich schön angucken, aber nicht wirklich anfassen kann.
Also kein Produkt, keine Funktionalität, kein lebendiges, sich weiterentwickelndes System, das kontinuierlich neuen Wert für die Anwender schöpft.
Es ist mir auch ganz wichtig zu betonen, dass wir jetzt nicht über irgendwas reden, was sich irgendwie in den letzten zehn Jahren entwickelt hat.
Zum Beispiel Lockheed Skunkworks, die Forschungsabteilung des Flugzeugherstellers Lockheed.
Der Chef von denen hat gesagt, um Himmels Willen darf meine ganze Organisation nicht mehr als 150 Leute umfassen.
Einschließlich Putzfrau und Sekretärin.
Weil ich brauche es, dass wenn der Konstrukteur, der eine Turbine konstruiert, seinen Bleistift schmeißt, dann muss er den Dreher am Hirn treffen, der sie abdreht.
Wenn ich das nicht mehr habe, kann ich nicht mehr die Arbeit machen, die ich mache.
Und die haben Unglaubliches geleistet.
Vollkommen richtig.
Und jetzt spiele ich auch bei der Spielchen weiter, was wir von eben hatten.
Weil das, was du gerade sagst, Luca, da war der Chef, der stand dahinter.
Das Business, die Geldgeber standen dahinter.
Und ich sage jetzt mal so ein bisschen provozierend, ich will diese Rückkopplungsschleife nicht bezahlen.
Also ich bezahle euch für das, was ihr mir liefert als Kunde.
Dafür kriegt ihr eh schon viel zu viel Geld.
Und ich möchte, dass ihr, wenn ihr euch verbessert, das ist nicht mein Ding, das ist euer Ding.
Und das will ich auch nicht bezahlen.
So, jetzt wisst ihr es.
Du?
Du willst nicht, dass wir besser werden, Kunde.
Das können wir machen.
Dann kriegst du halt denselben Mist wie immer.
Kein Problem.
Ja.
Ey, ich will, dass ihr besser werdet.
Aber ich will das Ergebnis bezahlen.
Also ich will dafür bezahlen, dass ihr mir bessere Ergebnisse liefert.
Aber dieses ganze Verbessern und Zusammenarbeit und Rückkopplung und so weiter,
das könnt ihr mal schön ohne mich machen.
Kalkuliert mir einfach mal was Neues.
Ja, ist ja okay.
Dann kommt dann halt ein Pay-Per-Use-System bei raus.
Und du kannst dann kontinuieren.
Natürlich für den Wert, den du mit der Lösung, die entwickelt wird, schöpfst.
Einen gewissen Anteil kontinuierlich abgeben.
So ähnlich ist es ja an vielen Stellen geworden, dass man eben, keine Ahnung,
nicht mehr die CD oder die Kassette oder die Schallplatte als physisches Produkt kauft,
wo man eigentlich dann dauerhaft etwas von hat,
sondern dass man häufig auf den Service übergeht.
Zum Beispiel irgendein Streaming oder…
Oder anderen Anbieter, den man regelmäßig, dann halt in kleineren Paketen,
nicht in einem Schwung, großes Produkt, die CD oder die CD-Sammlung dann halt kauft und bezahlen lässt,
sondern halt die Nutzung.
Und das ist ja für mich auch völlig okay, weil im besten Fall hat man ein Produkt,
das mehrere Kunden, vielleicht sogar viele oder ein großer Markt nutzt,
wo dann jeder, der für diese Nutzung, an dieser Nutzung profitiert,
dann auch seinen Anteil kontinuierlich leistet.
So hat Spotify oder auch ein Adobe oder viele andere einen guten Weg gefunden,
um diese kontinuierliche Entwicklung und Weiterentwicklung, Verbesserung auch zu finanzieren.
So kommen wir dann halt auch in die Richtung Abrechnungsmodelle, Software as a Service,
die ganzen Cloud-Anbieter, die dann in Richtung Infrastructure oder andere Dinge as a Service,
dann auch ihre Abrechnungsmodelle gefunden haben.
Und an der Stelle gibt es dann DevOps.
Und an den Unternehmen, die das nicht denken, die so weit halt nicht sind,
die halt sagen, okay, ich möchte halt die Schallplatte haben,
dann müssen sie halt gucken, dass sie die Schallplatte bekommen.
Aber die verändert sich auch über die Zeit nicht.
Die wird dann halt nicht besser.
Das ist dann halt die Schallplatte mit der Musik von der Band, die dort halt draufgepresst wurde.
Naja, ich sehe es schon.
Wahrscheinlich müssen wir uns nochmal…
Wir müssen uns nochmal zusammensetzen und unsere Unterlagen ein bisschen aktualisieren,
dass ich auch was zu Abrechnungsmodellen sagen kann, ne, Falco?
Finde ich auch gern.
Okay, gut.
Gut, ein Punkt finde ich noch wichtig, den ich mir noch hier so vermerkt habe,
nämlich der Punkt, wie praxisrelevant das ist, was DevOps quasi beschreibt.
Und auch da, wenn ich mir schaue, die Idee von DevOps ist aus meiner Sicht,
dass wir quasi ein Produkt, ein Produktteam haben,
wir haben eine Produktorganisation, wir haben vielleicht wirklich erstmal ein kleines Team,
ein kleines Produkt, wir haben ein Startup.
Das beginnt klein und das wird dann organisch wachsen.
Also wir fangen ja nicht an, bei DevOps zu weiter Grundidee erstmal,
gleich so in einem Riesenkonstrukt von 100, 200 oder 400 Leuten zu arbeiten.
Das heißt also, der Grundgedanke von DevOps, auch so wie wir das erklären
und dann den Leuten näher bringen, passt eigentlich nicht zur Realität,
weil dort wir ja gerade durch die vielen Abhängigkeiten, die wir heute schon besprochen haben,
wir häufig darüber reden, dass wir größere Bereiche haben,
dass wir größere Produkte haben, die vielleicht im schlimmsten Fall auch total viele technische Abhängigkeiten haben,
die wir nicht einfach so trennen können.
Auch das haben wir schon oftmals behandelt, jetzt sagen wir mal zwischen Architektur und Organisation.
Also der Grundgedanke von DevOps passt vielleicht nicht immer sehr gut für die Unternehmen,
weil die in großen Kategorien denken müssen oder nur denken können.
Ja, also vielleicht hast du da auch etwas sehr Schönes gesagt,
gerade Dirk, insofern, als wir jetzt irgendwie auch ein sehr bedrohliches Bild,
ich komme nicht weg davon, DevOps kann sich auch sehr bedrohlich anhören,
dass wir ein sehr bedrohliches Bild gezeichnet haben, oh, es ist so schwer und es ist so viel
und man muss so viel und man muss und man darf und man, ne.
Aber andererseits ist es ja auch total okay, erstmal kleine Brötchen zu backen
und sich seine Erfahrungen zu sammeln und sich seine Rückkopplungsschleifen zu bauen, nicht wahr?
Und dann halt Schritt für Schritt, ihr wisst ja, wie ist man ein Elefanten, Gabel für Gabel,
sich so langsam aber sicher in seinen DevOps reinzuarbeiten.
Ich glaube, das ist auch das Wichtige, dass man da ein bisschen fair mit sich selber ist
und sagt, das ist ein weiter Weg und ich muss mich jetzt nicht irgendwie fertig machen
und mich grämen, dass ich nicht auf der Stelle die ganze Strecke schaffe,
nicht auf der Stelle einen Marathon-Weltrekord schaffe,
sondern ich kann ja erstmal mit einem 10-Kilometer-Lauf anfangen oder sogar nur mit einem 5-Kilometer-Lauf
oder überhaupt erstmal aus der Tür rausgehen und der Rest ergibt sich dann unterwegs.
Mhm.
Und dann, wenn du ein Jahr später mal schaust, wie weit du gekommen bist,
dann wirst du nämlich ziemlich erstaunt sein.
Dann sind wir nämlich bei der kontinuierlichen Verbesserung,
bei den Rückkopplungsschleifen, beim kontinuierlichen Lernen.
Und dann kommen wir halt von dem, was vielleicht bei Unternehmen schon angekommen ist.
Ich nehme mal so ein bisschen Gene Kim, die drei Wege gerade im Kopf.
An vielen Stellen ist der Gedanke des ersten Wegs, eine kontinuierliche Entwicklungspipeline
von Anfang bis Ende vielleicht schon angekommen, dass dann halt der nächste Schritt,
die Feedbackschleifen, das kontinuierliche Lernen.
Und das Ganze halt ins Unternehmen hereinzutragen, auch in Bereiche,
die eben größer als 150 Personen sein können, dass man an einer Ecke etwas lernt,
wovon man an der anderen Ecke profitieren kann, wäre natürlich dann der Punkt,
wo ich sage, okay, da ist halt noch Potenzial in vielen Unternehmen.
Genau. Wir haben uns ja auch in unseren Notizen aufgeschrieben als Frage,
was müssen Unternehmen noch tun? Wie geht es 2022 weiter? Wann ist DevOps fertig?
Und ich glaube, Falco hat gerade auf all diese Fragen die Antwort gegeben, oder?
Ich bin auch erfreut gewesen, dass wir das doch nicht ganz so düster sehen müssen.
Und es kommt doch ein ganz toller Spruch, auch der längste Weg beginnt mit dem ersten Schritt.
Der kommt nicht von mir, aber ich weiß die Quelle jetzt gerade nicht.
Das war bestimmt Konfuzius oder so.
Wahrscheinlich, klingt so.
Genau.
Genau.
Nee, aber ich glaube, Falco, du hast da wirklich die Antwort gegeben.
Genau.
Falco, du hast da wirklich den Nagel auf den Kopf getroffen.
Den ersten Weg, eine kontinuierliche Pipeline, das ist notwendig, aber es ist noch nicht hinreichend.
Sondern das Zweite ist dann, Rückkopplungsschreifen zu bauen.
Das Dritte ist, sich eine Kultur des kontinuierlichen Lernens zu verordnen.
Und dazu gehört natürlich auch vielleicht zuerst mal, dass man lernt, wie man eigentlich lernt.
Und dann ergibt es sich von selber.
Das ist vielleicht der Unterschied zwischen Unternehmen,
die erfolgreich mit DevOps arbeiten und solchen, die es nicht tun,
dass sie nicht nur den ersten, sondern dass sie alle drei Wege irgendwie zu ihrem Recht kommen lassen.
Naja, also insofern klingt ja schon fast wie so eine Art Schlusswort.
Ich bin zumindest beruhigt, dass wir nicht alle so schwarz gemalt haben,
dass wir auf ein paar Dinge hingewiesen haben und dass wir vielleicht wirklich eine Botschaft ebenso gemeinsam hier erarbeitet haben.
Die einfach heißt, anfangen, natürlich konzentriert und fokussiert anfangen
und auch nicht einfach sowas, irgendwas machen, sondern auch bewusst anfangen.
Aber das Wichtige ist einfach anzufangen und den ersten Schritt zu tun.
Oder zumindest den nächsten Schritt für alle die, die schon unterwegs sind.
Das heißt, sich zu überlegen, wo stehen wir gerade, sich vielleicht Hilfe zu suchen an den Stellen,
an denen man von alleine im Unternehmen nicht weiterkommt,
wo dann die Beratungsunternehmen oder auch die Toolhersteller vielleicht hilfreiche Ansprechpartner sind.
Und ansonsten reflektieren, selbst zu schauen, an welchen Stellen hakt es dann am ehesten?
Und dann für die Probleme Lösungen zu finden.
In kleinen Schritten voranzugehen und sich dem Ziel, dem Weg der kontinuierlichen Verbesserung zu öffnen
und auf dem weiterzugehen.
Regelmäßig zu reflektieren, regelmäßig zum Beispiel eine Wertstromanalyse zu machen,
zu schauen, welche Prozessschritte denn wirklich der Wertschöpfung einen Beitrag leisten,
an welchen Stellen es regelmäßig Nacharbeiten gibt,
wo man halt vielleicht mit Automatisierung oder mit anderen Hilfsmitteln Verbesserungen erreichen kann.
Und dann?
Eben nicht davon auszugehen, dass DevOps oder das Produkt oder das alles auf einmal fertig sein kann,
sondern dass das halt ein Weg ist, der nicht unbedingt an einem Ziel endet,
sondern der vielleicht auch das Ziel ist.
Genau, DevOps ist kein Ziel, DevOps ist ein Prozess.
Ja, und wie du auch sagtest, aus Fehlern auch lernen.
Da muss man bereit sein, Fehler zu machen.
Und sie am besten dann wirklich auch nur einmal zu machen,
um daraus eben Veränderungen abzuleiten.
Also ich glaube, Falco, das war ein schönes fachliches Schlusswort aus meiner Sicht.
Also ich glaube, wir können jetzt hier die Aufnahme beenden,
können allen weiterhin ein frohes neues Jahr wünschen.
Und ich habe schon zwei, drei Mal angedeutet,
wir haben im Februar vielleicht wirklich dann auch einen richtig tollen Praxisbericht,
der uns auch vielleicht zeigt, dass in dem Unternehmen, das wir im Februar haben,
dass da DevOps wirklich so schon sehr gut angekommen ist.
Bin mal gespannt, was wir dann mit den Kollegen dort besprechen werden.
Also ich danke euch beiden für das schöne Gespräch
und wir müssen noch einen Termin machen,
um die Schulungsunterlagen mit den Abrechnungsmodellen zu ergänzen.
Wunderbar, machen wir das.
Vielen Dank, hat mich auch gefreut.
Genau, das war ein toller Einklang, glaube ich, für das Jahr 2022.
Ich bin gespannt, was uns noch erwartet.
Ciao.
Tschüss.