Folge 64: Peter Lange zu DevOps im Infrastruktur-Betrieb 2/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Zu Gast haben wir Peter Lange, Geschäftsfeldleiter und DevOps Coach bei der PROFI Engineering Systems AG.
Mit ihm sprechen wir über DevOps aus der Sicht des „Endes der Nahrungskette“: dem Infrastruktur-Betrieb.

In dieser Folge des Podcasts werden die verschiedenen Aspekte von DevOps im Kontext des Infrastrukturbetriebs vertieft. Der Gast Peter Lange teilt seine Einsichten über die Bedeutung von Visionen und sinnstiftenden Momenten in der DevOps-Transformation, die Herausforderungen in der Zusammenarbeit zwischen verschiedenen IT-Bereichen und die Notwendigkeit einer kulturellen Veränderung. Es wird die Rolle neuer Technologien wie Kubernetes und Cloud-Infrastrukturen diskutiert, wie sie die IT-Landschaft transformieren und den Weg für eine zukünftige Entwicklung ebnen, die einen stärkeren Fokus auf Automatisierung, Plattformdenken und Produktdenken legt.

Inhalt

  • Einführung und Vorstellung der Teilnehmer
  • DevOps im Infrastrukturbetrieb: Grundkonzepte und Bedeutung
  • Herausforderungen bei der Implementierung von DevOps in Unternehmen
  • Die Rolle von Vision und sinnstiftenden Momenten in DevOps-Projekten
  • Technologische Aspekte: Kubernetes, Cloud-Technologien und deren Einfluss
  • Kulturelle und organisatorische Veränderungen in der IT durch DevOps
  • Zukünftige Trends und Entwicklungen im Bereich DevOps
  • Abschlussdiskussion und Ausblick

Shownotes

Peter hat zwei Buchtipps für uns:
The Other Side of Innovation
Team Topologies

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk 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 letztes Mal haben wir uns mit so viel Spaß mit Peter Lange unterhalten
über verschiedenste kulturelle, organisatorische und technische Aspekte von DevOps im Infrastrukturbetrieb,
dass wir gesagt haben, wir machen einen zweiten Teil dieses Gesprächs daraus.
Und insofern ist auch heute wieder unser Gast Peter Lange. Willkommen zurück, Peter.
Hallo, auch willkommen. Vielen Dank für die erneute Einladung.
Sehr schön. Nachdem es uns ja etwas unsanft, das Netz uns etwas unsanft aus dem Gespräch des ersten Teiles gerissen hat.
Womit wachen wir denn weiter, Peter?
Mir ist im Nachgang, ist mir aufgefallen, auf deine Frage, wie das denn so abläuft.
Das war zwar richtig, aber ein bisschen inkomplett. Das würde ich gerne noch ein bisschen ergänzen.
Das letzte Mal haben wir davon, habe ich davon gesprochen, dass wir sinnvollerweise einen Sinnstifter finden,
wo die unterschiedlichen Teams sozusagen zusammenlaufen, der da auch eine Verantwortung hat.
Und dass es sehr wichtig und wirkungsvoll ist, wenn der die Vision für so ein DevOps-Projekt formuliert.
Damit ist es natürlich nicht zu Ende.
Also zum einen hat man dann natürlich die Herausforderung, einen Wertstrom auszuwählen.
Tatsächlich gibt es natürlich Produkte, die sind geeigneter, andere sind weniger geeignet.
Das ist wichtig. Dann ist es wichtig, ein Team zusammenzustellen, das man gegebenenfalls auch ergänzen kann.
Aber auch da, das Produkt, der Wertstrom und das Team müssen einfach sehr gut zusammenpassen.
Ja, nachdem man dann den Wertstrom schon mal hat und vielleicht auch ein erstes Mal visualisiert hat,
wenn es ihn schon gibt oder wenn es ihn noch nicht gibt, also ein Zollwertstrom,
dann geht es natürlich darum, über Architektur zu sprechen.
Eine Architektur zu definieren oder zu erarbeiten, was natürlich auch ein ganz wichtiger Part ist.
Zum einen ermöglicht es allen, mal über den Tellerrand hinwegzuschauen und das Gesamtgebilde zu verstehen
und ein gemeinsames Verständnis zu schaffen.
Ja, und dann geht es natürlich in Richtung, was wollen wir eigentlich für uns?
Welche Prinzipien brauchen wir? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Ja, das ist natürlich auch ein ganz wichtiger Part.
Und wo müssen wir eigentlich für uns? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Ja, und wo müssen wir eigentlich für uns? Welche Richtlinien brauchen wir für uns in diesem Projekt?
Und wo müssen wir Dinge vielleicht auch schon anders machen als bisher?
Genau, das sind so wichtige Anfangsbausteine, mit denen es typischerweise losgeht in einer Startphase von vier bis sechs Wochen.
Das wollte ich noch ergänzen.
Okay, also die Startphase ist aus deiner Sicht wirklich erstmal so ein bisschen eine Bestandsaufnahme, ein Klarstellen irgendwie?
Ja, das ist zu schaffen und tatsächlich auch zu schauen.
Dass das Produkt beziehungsweise der Wertstrom und das Team zusammenpasst.
Dass wir uns dann anschauen, was gibt es eigentlich für Architektur, Bausteine?
Vielleicht gibt es ja schon was.
Und auch den ganzen Kontext zu beleuchten.
Haben wir regulatorische Anforderungen?
Wie schaut eigentlich das Business aus?
Welche Akteure gibt es?
Eben nicht nur Menschen, vielleicht gibt es ja auch Computer als Akteure.
Welche APIs brauchen wir nach außen?
All dies in einer frühen…
In einer frühen Phase zu erarbeiten und auch für alle klarzumachen.
Das ist super hilfreich.
Und naja, ich plaudere mal so ein bisschen aus dem Nähkästchen.
Das Feedback der Teams ist, mein Gott, Peter, ist das trocken.
Und es ist zum Teil vielleicht auch schmerzhaft für die Leute.
Im Nachgang, manchmal Jahre danach, bekomme ich dennoch zu hören Mensch, Peter, es war zwar super trocken.
Und ich habe wirklich mit mir kämpfen müssen, aber es ist hilfreich bis heute.
Ja, es ist nervt, wenn man nicht endlich ins Machen kommen darf.
Jetzt reden sich alle irgendwie heiß über Kubernetes und was es so alles gibt und möchten gerne mal tüfteln.
Und dann kommst du und redest über, ich weiß auch nicht, Projektstrukturen oder so.
Ja, über Projekte, über Teamstrukturen, über regulatorische Anforderungen.
Softwarekomponenten, Hardwarekomponenten.
Alles, was man so…
In dem Werkzeugkasten, Togaf und andere Architektur-Frameworks halt hat.
Das kann bis runter zum Glossar, den wir in der letzten Folge angesprochen haben, gehen, wo man halt sagt,
okay, wie sieht denn jetzt wirklich unsere Sicht auf Begriffe wie Deployment oder Server oder was auch immer alles aus?
Und das kann natürlich echt trocken sein.
Ein bisschen interaktiver wird es, glaube ich, an den Stellen, wenn man dann in Richtung Wertstrom,
Wertstromanalyse, ist Wertstrom, wo können wir dann optimieren und so kommt.
Und ja, wenn man dann…
Wenn man dann echt in die Umsetzung geht, dann ist natürlich Bewegung drin.
Aber ohne das Fundament zu haben, ist es häufig nicht ratsam, gleich in die Umsetzung zu gehen, weil sonst macht man es halt drei- oder viermal.
Genau.
Und das ist halt auch einfach eine hervorragende Gelegenheit, für dieses gemeinsame Verständnis zu schaffen.
Also ich vergleiche das dann gern mit einem Architekten, der Häuser baut.
Es ist natürlich schon gut zu wissen, bauen wir ein Büro?
Ja.
Ein Haus oder ein Parkhaus oder ein Einfamilienhaus.
Und je früher man das gemeinsam festlegt, desto besser ist dann nachher auch das gemeinsame Verständnis.
Und desto besser kann man auch gemeinsam an dem Wert arbeiten.
Und dann kann man ja iterativ gut vorgehen, ne?
Ja, ganz genau.
Ja, ich finde, das ist eigentlich ein ganz tolles Bild.
So habe ich das noch gar nicht gesehen.
Aber es kommt nicht darauf an, wo die Steckdosen sind oder sowas.
Aber wir müssen uns wenigstens mal darüber im Klaren sein.
Brauchen wir einen Kuhstall oder brauchen wir keinen?
Wäre zumindest hilfreich, wenn man darüber ein gemeinsames Verständnis hat.
Und meine Erfahrung über die, ja jetzt ja schon Jahrzehnte ist, dass das manchmal in manchen Projekten, war das eben nicht klar.
Und dann gibt es Konfusion, babylonisches Sprachgewirr.
Und man wundert sich, warum Dinge nicht so funktionieren, wie sie eigentlich funktionieren sollen.
Weißt du, was ich glaube, Peter?
Ich glaube, es ist sogar genau umgekehrt, sondern es ist der Normalfall, dass diese Verwirrung besteht.
Und eigentlich ist es die bessere Situation, wenn das den Leuten wenigstens bewusst ist, dass sie dann auch keine gemeinsame Sprache haben.
Viel schlimmer ist es, wenn die Leute denselben Begriff für ganz verschiedene Sachen verwenden, so wie wir es im ersten Teil haben.
Was ist denn mit einem Server gemeint?
Ist das eine Softwarekomponente oder ist das ein Stück Blech im Keller?
Beides gleichermaßen legitim, aber wir müssen schon wissen, wovon wir eigentlich reden.
Da ist mir auch so wahnsinnig in Erinnerung.
Ich habe mal etwas, was ein Freund von mir mal erzählt hat, der, was war denn, ein CTO oder sowas von einem Hosting-Unternehmen.
Und der hat mal seine Teams gebeten, ihm ein Architektur-Diagramm zu malen von dem, was die da so machen.
Und kein Team konnte ein vollständiges und korrektes Architektur-Diagramm dessen malen, womit sie sich tagtäglich befassen.
Keiner von denen.
Interessanterweise die, die es am besten hingekriegt haben, waren zufällig die UXler.
Die wie?
User Experience.
Oder was heißt UX an deiner Stelle?
Genau.
Das ist, glaube ich, der Normalfall, dass es da ein gewisses Maß an Grundmissverständnis gibt.
Genau.
Und dann hilft es natürlich, da sind wir wieder bei Sprachaufhänden und Zusammenarbeit und Co.,
die Leute in ein Boot zu setzen, in einen Raum zu sperren und zu sagen, okay, jetzt mach das mal zusammen.
Dann können nämlich auch alle verschiedenen Sichten zusammenkommen.
Und nicht nur die Spezialisten im Diagrammezeichen, die UXler,
bringen ihren Anteil, sondern auch diejenigen, die letztendlich aus ihrer, keine Ahnung,
teilweise wahrscheinlich Silo-Sicht heraus auf das Gesamtprodukt schauen.
Das ist natürlich spannend.
Klar?
Absolut.
Und ich sage mal, so ein Kontext-Diagramm ist natürlich auch extrem hilfreich.
Wir haben das letzte Mal davon geredet, dass sich Teams auch verändern.
Es kommen neue Leute rein.
Da ist natürlich eine Architektur-Dokumentation, in der man beschrieben ist, um was geht es hier,
was ist der Kern, was ist außerhalb, was ist der Kontext, aus welchem Baustein besteht,
besteht das Ganze extrem hilfreich.
Und etwas, was ja typischerweise auch nicht jeden Tag angepasst werden muss
und damit auch vom Aufwand her überschaubar ist.
Du hast vorhin am Anfang des Podcasts, wie geht es dann so in so einem DevOps-Projekt los,
über einen Sinnstifter gesprochen.
Was kann ich mir da unter vorstellen?
Was ist so ein Sinnstifter?
Ja, das Thema Sinnstifter wird immer wieder nachgefragt.
Ich sage mal, wenn ich Menschen motivieren, zu einer Veränderung motivieren will,
dann ist der Sinn, also der Sinn der Veränderung extrem wichtig.
Also das haben wir auch, im Moment wird das auch allen halben kolportiert.
Wir brauchen einen Sinn, Purpose.
Das ist einfach nicht zu unterschätzen.
Und wer ist denn der gemeinsame Sinnstifter von Dev und Ops?
Irgendwo läuft es ja zusammen.
Wenn ich die Gräben nicht größer machen will, dann ist es tatsächlich hilfreich,
ich suche den, wo die Dinge zusammenlaufen und lasse den mal die Vision kommunizieren,
warum es jetzt hilfreich ist, anders zusammenarbeiten als zuvor.
Das ist dann aus Erfahrung jemand, der in einer Hierarchie im Unternehmen recht weit oben sitzt,
weil Entwicklung häufig aus anderen Budgettöpfen bedient wird
und in anderer Verantwortung liegt, als das beim Betrieb der Fall ist.
Kannst du das bestätigen oder hast du da andere Erfahrungen gemacht?
Oft ist es so, kommt auch auf den Kontext an, manchmal ist es auch ein Gesamtprojektleiter.
Ist ja auch möglich.
Also wenn es im Projektkontext ist, ist es manchmal auch ein Projektleiter.
Das ist sehr unterschiedlich.
Das kann auch ein Inhaber sein.
Im operativen Geschäft überhaupt nichts zu tun hat.
Den gilt es halt zu finden oder jemanden finden, der diese Rolle gut ausfüllen kann.
Und was sind so Beispiele für den Sinn einer DevOps-Transformation, DevOps-Projekt?
Beispiel, das mir noch einfällt, konkret war ein Projekt.
Da ging es eigentlich um ein Großprojekt, wo klar war,
dass die anfallenden Arbeiten auch infrastrukturseitig, manuell überhaupt nicht zu stemmen sind.
Und wir ein hohes Maß an Automatisierung brauchen, eigentlich diese 100%-Automatisierung.
Genau. Und dann war halt die Ansage, wir brauchen 100%-Automatisierung.
Wir haben sehr viele Entwickler, die müssen ad hoc Systeme,
ganze Applikationslandschaften bereitgestellt bekommen.
Und dafür brauchen wir die Infrastruktur.
Und eure Aufgabe ist 100%-Automatisierung und im besten Fall schon in einem Vierteljahr.
Wie lange hat es gedauert?
Deutlich länger. Nach einem Vierteljahr war es ausreichend gut.
Aber ich sage mal, wir reden hier über DevOps.
Das ist eine Reise, die hört nie auf.
Ich vergleiche das gerne mit Automobilherstellern.
Wann haben die angefangen?
Mit Toyota Production Systems?
Ich glaube, Ende der 40er des letzten Jahrhunderts.
Und die verbessern heute noch.
Nach 70 Jahren sind die immer noch dabei, Dinge besser zu machen.
Und so wird es auch dort sein.
Aber es ist natürlich wichtig.
Ja, der wichtigste Schritt auf dem Gipfel ist der erste, nicht der letzte.
Ja, die sind sehr weit gekommen.
Jetzt sind wir sehr, sehr weit gekommen und es geht kontinuierlich weiter.
Manchmal ist das sinnstiftende Moment, wir brauchen mehr Kundenzufriedenheit.
Wir wollen mehr Qualität.
Mhm.
Ja, das kann ja auch.
Das kann auch ein sinnstiftender Moment sein, all die Werte, die man mit DevOps erreichen
kann oder will.
Aber das klingt jetzt irgendwie, muss ich schon mal sagen, nach einem ganz schön dicken
Brett.
Und ich frage mich, Stolperfallen gibt es mit Sicherheit zuhauf, aber was sind denn
so die gemeinsten oder die verbreitetsten, wenn man sowas tatsächlich ernsthaft anfangen
möchte?
Ich denke mal, die wichtigste, die haben wir letztes Mal schon angesprochen, es ist
einfach die Manpower.
Ich glaube, der Betriebsaufwand, also das gemeinste ist eigentlich, dass der Betriebsaufwand
so hoch ist, dass ich mich um die Verbesserung von Arbeit nicht kümmern kann.
Ja, so dieses berühmte Beispiel von der stumpfen Säge, der keine Zeit hat, weil er Bäume fällen
muss oder derjenige, der ein Auto an der Tankstelle vorbeischiebt und keine Zeit zum Tanken hat.
Das hört sich blöd an, ja, ist aber so.
Und der Weg dort raus ist meiner Meinung nach, ja.
Ich muss natürlich temporär.
Ich muss da Zeit zur Verfügung stellen und dafür ist es halt hilfreich, auch mit extern
zu arbeiten oder so man sich dann bekommt, neue Leute einzustellen.
An der Stelle ist aber, finde ich, auch wichtig, also ich sage mal, Externe bringen halt nicht
nur, ich sage es jetzt mal, Ressourcen mit rein, sondern halt auch andere Sichtweisen.
Die Gefahr ist, und das ist, denke ich, auch ein wichtiger Aspekt, dass, wenn ich nur mit
intern arbeite, dass die mir das Gleiche nochmal in klein aufbauen, dass die wirklich,
dass die wirklich innovativen Dinge nicht passieren, dass nicht aus dem eigenen Kasten
herausgeschaut wird, ja, weil das haben wir schon immer so gemacht und dann sind die Ideen
vielleicht nur, nur halb so gut, wie wenn ich ein gerüttelt Maß externe Sichtweise
habe.
Das ist dann vielleicht auch eine Berechtigung für externe Berater oder Coaches.
Ja, also es kann schon echt hilfreich sein.
Ja, das stimmt, aus meiner eigenen Sicht als tatsächlich eben externer Berater ist es dann
auch einfach häufig so, gar nicht mal so sehr, dass man eine andere Sicht bringt, sondern
vielleicht auch einfach nur mal Mut machen muss und sagen muss, ja, ich habe das anderswo
schon gesehen und die haben das gekonnt und ihr könnt das auch.
Und dann hat man natürlich auch einen Kristallisationspunkt, wenn ein Externer da ist, dann auch zu sagen,
okay, der Externe.
Ich möchte jetzt mit jemandem aus einem Infrastruktur- oder Applikationsbetrieb sprechen, ich möchte
mit euch über Architektur reden, wir brauchen auch ein paar Entwickler am Tisch und dann
vielleicht auch die Karte, naja, das kostet ja sowieso Geld, ich bin ja jetzt nicht umsonst
hier, dann lasst mal alle, die eh da Kosten produzieren, mal ruhig mit mir zusammen an
einem Tisch sitzen.
Gibt es andere Wege, so eine positive, wohlwollende Atmosphäre zu schaffen, damit man auch in
Richtung Erfolg kommt?
Also was Luca schon angesprochen hat, ist auch einfach davon erzählen, wie es bei anderen
ist.
Also ich sag mal, das ist eigentlich der Klassiker, dass ich am Anfang gesagt bekomme, typischerweise
aus der Mannschaft heraus, manchmal aber auch aus dem Führungskreis heraus, ja, das mag
woanders funktionieren, aber bei uns funktioniert das nicht.
Ist ja so der Klassiker.
Und dann ist natürlich gut, wenn man vielleicht sogar aus der Branche kommt.
Ja.
Und dann kann man dann auch, wenn man im Führungsbereich noch Fragen hat, dann kann man halt auch da
nach dem Führungsprogramm, da kann man dann auch auf die Beispiele kommen, da kann man
mal sagen, ja, das wurde mir dort auch gesagt, und heute stehen wir aber an einer ganz anderen
Stelle.
Die sind nicht zu Ende mit der Reise, aber sie haben schon diese und jene Ziele erreicht.
Und ich kann euch sagen, wie wir da vorgegangen sind, wir können das auch hier mit dem oder
einem ähnlichen Weg versuchen.
Das bringt dann Vertrauen, das bringt dann ein bisschen Selbstsicherheit auch, um den,
ähm, den Wunsch zu erreichen.
Ja, klar.
Und das ist auch ein sehr guter Schritt.
Ja, klar.
Ja, klar.
Ich hoffe, das ist ein sehr guter Schritt.
Ja, klar.
den doch recht langen und häufig auch steinigen Weg der Transformation dann anzutreten.
Also den ersten Schritt, den du vorhin erwähnt hattest, auf dem Weg zum Gipfel auch wirklich zu gehen.
Ganz genau. Und ich sage mal, wenn wir jetzt schon bei der Metapher sind vom ersten Schritt,
hilfreich ist natürlich auch mal das Erreichen des ersten Basislagers sozusagen.
Also früh erste Erfolge zu zeitigen und die dann auch zu kommunizieren.
Und wenn denn erste Erfolge da sind, die kommuniziert sind und die dann auch angenommen werden,
dann wird es oft sogar ein Selbstläufer.
Übrigens auch nicht nur Erfolge, ich weiß nicht, zu kommunizieren, sondern überhaupt erst mal als Erfolge zu erkennen.
Das ist etwas, was ich ganz häufig habe, wenn es darum geht, zum Beispiel Testautomatisierung einzuführen.
Dann sagen die Leute, oh Mann, wir haben erst einen automatisierten Test.
Und dann sage ich, merkt ihr eigentlich, was ihr da geleistet habt?
Das war der schwerste.
Ihr habt eine Testinfrastruktur aufgesetzt, ihr habt euch Gedanken über Tests an sich gemacht.
Ihr wisst jetzt, wie man automatisierte Tests einerseits schreibt, andererseits ausführt.
Und wahrscheinlich sogar 90 Prozent des Weges sind geschafft.
Und die anderen 10 Prozent macht dann sowieso nebenbei, nämlich kontinuierlich den Testset aufbauen.
Klar kommt irgendwann nochmal so eine Phase, wo vielleicht nochmal ein Refactoring oder so notwendig ist,
wo man vielleicht nochmal die Regressionstests oder andere,
Testsets ein bisschen zusammenstutzt oder ähnliches.
Aber ja, das ist auf jeden Fall ein extrem wertvoller Punkt.
Und ich denke, Basislager 1 auf jeden Fall an der Stelle.
Ja, und das ist, denke ich, auch ein ganz wichtiger Punkt von zum Beispiel einem DevOps-Coach,
dass er in Retrospektiven das immer wieder hervorzieht, immer wieder die Leute darauf fokussiert,
was sie denn schon alles getan haben.
Genau.
Jetzt gibt es ein Architektur-Diagramm.
Wir brauchen jetzt einen neuen, der kann sich leichter einarbeiten.
Das sind ja alles auch echte Werte, die dort geschaffen werden.
Also sogar bevor es in die Umsetzung geht, werden ja Werte geschaffen.
Und das zu fokussieren und da immer wieder darauf hinzuweisen, ist, glaube ich, auch ein ganz wichtiger Erfolgsfaktor.
Ja, wir hatten ja zusammen in einem Projekt gearbeitet.
Und was mich so ein bisschen…
Was mich so ein bisschen überrascht hat, ist, dass häufig in den ersten Retros dieses
Wir haben uns zusammengesetzt und ausgetauscht über die Silo-Grenze hinweg.
Und wir haben ein besseres Verständnis geschaffen.
Wirklich die treibenden Erfolgserlebnisse der Teilnehmer waren, wo man sagt,
Okay, das ist ja jetzt eigentlich nicht wirklich ein Hexenwerk.
Also das macht doch mal ein Meeting und ladet mal jemanden aus Dev und Ops zusammen ein.
Ist häufig wirklich ein guter erster Schritt auf dem Weg zu
Wir haben einen gewissen Erfolg erreicht.
Und man wundert sich, aber miteinander reden hilft.
Ja, tatsächlich.
Also ich sage mal, am Anfang fängt man an, miteinander zu reden.
Und irgendwann arbeitet man sogar zusammen.
Das ist halt der erste Schritt.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Weil es ja offensichtlich im Alltag gar nicht so einfach ist, zusammenzuarbeiten.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Weil es ja offensichtlich im Alltag gar nicht so einfach ist, zusammenzuarbeiten.
Aber es ist ja auch schön, dass wir da an der Stelle immer wieder hilfreich sein können.
Okay, für uns warst du gerade kurz weg.
Aber nichtsdestotrotz, wir waren gerade bei dem erfolgreichen ersten Schritt.
Was sind denn die größten Herausforderungen auf dem Weg zum Basislager 1?
Oder vielleicht, wenn das zu kleine sind, die größten Herausforderungen auf dem Weg zum Gipfel?
Also was ich als eine große Herausforderung sehe, ist,
wir haben ja oft fragmentierte Organisationen, die sogenannten Silos,
wir haben ja oft fragmentierte Organisationen, die sogenannten Silos,
mit sehr unterschiedlichen Zielvorgaben und die Veränderung der Inzentivierung der Ziele.
Und das ist eine große Herausforderung, weil da brauche ich eben das Management.
Ich brauche das Management bei Ihnen, das erfordert auch Mut.
Ja, das ist eine der großen Herausforderungen.
Und dann die Entwicklung tatsächlich einer gemeinsamen Verantwortung.
Für die Beteiligten.
Auch ein großer Schritt, der halt aufgeteilt werden muss in viele kleine.
Und da ist es auch einfach sicherlich hilfreich, das auch mal transparent zu machen.
Also mal transparent zu machen, wo liegt Verantwortung, wo werden Entscheidungen getroffen
und an welcher Stelle ist es hilfreich, Entscheidungen abzugeben oder gemeinsam zu treffen.
Meiner Meinung nach auch ganz wichtige.
Ganz wichtige Aspekte, denn diese unterschiedlichen Ziele führen natürlich zu diesem Silo-Denken ganz stark.
Also mein Storage ist okay, der ist grün, also kümmert mich die Performance der Anwendung nicht.
Um es jetzt mal ganz platt zu sagen.
Ja gut, aber wenn man solche Messdaten, Messwerte erhebt, sind die natürlich dann, wie du sagst, Silo-bezogen.
Hilft das dann kundenfokussierte?
Kennzahlen zu erheben, also Kundenzufriedenheit wäre so ein Thema.
Oder andere, vielleicht auch unternehmensspezifische Richtung, keine Ahnung, Umsatz oder Gewinn oder Marge oder ähnliches?
Ja, natürlich. Das ist absolut hilfreich, ist aber gleichzeitig auch so ein Stück weit die Königsdisziplin.
Ich denke, da sollte man auf jeden Fall hinkommen.
Am Anfang steht, denke ich mal, die Silo-übergreifende, die cross-funktionale Sicht auf,
zum Beispiel Messdaten, aber mit Gipfeln sollte das natürlich in Business-relevanten Rundmeldungen, Feedbacks letztlich.
Weil am Ende sind es ja die wenigsten Firmen, die das Geschäftsfeld darin besteht, Storage zur Verfügung zu stellen, Server zur Verfügung zu stellen.
Die allermeisten Organisationen wollen etwas anderes.
Die Versicherung will Versicherung verkaufen.
Die Bank will Geld verwalten.
Der Maschinenbauer will Teile verkaufen.
teilen, produzieren.
Dann sind wir wieder bei dem, was du
einleitend als deine DevOps-Definition
genannt hast, diesen Wertfokus,
wie auch immer er sich dann konkret
darstellt.
Ja, natürlich, da muss es
hingehen und das ist schon auch,
weil ihr das vorher gefragt habt, ist schon
auch etwas, was nicht
von heute passiert, diese
Fokussierung der Leute
auf den eigentlichen Wert fürs
Unternehmen. Da kommen viele
Ideen und wenn du dann fragst,
okay, inwiefern
trägt das zu einem Mehrwert
bei? Das muss ja nicht
immer direkt ins Business gehen.
Manchmal ist es auch ein Mehrwert, wenn ich
regulatorische Anforderungen erfüllen kann.
Das kann durchaus
auch ein Mehrwert sein, aber
diese Fokussierung auf
Mehrwert, das ist
etwas, was nicht von
heute auf morgen geht und sicherlich
einer der spieglerischen
Komponenten
Tätigkeiten.
Und gleichzeitig
einer der wirkungsvollsten.
Vielleicht wollen wir ein bisschen die Richtung
ändern des Gespräches,
denn jetzt haben wir uns sehr viel auf
der kulturellen Ebene
aufgehalten, oder ich nenne es mal
pur kulturellen Ebene aufgehalten.
Solche Themen wie Wertfokus beispielsweise,
wie wertschöpfende
Kommunikation miteinander und so.
Und wir nennen es ja auch
DevOps im Infrastrukturbetrieb, das ist die
Überschrift über diese Folge.
Aber trotzdem frage ich mich,
wie kommen da jetzt eigentlich
neue Technologien, all das, was
auch viele Leute unter DevOps verstehen,
in diesem Thema
vor? Was ist denn mit
Kubernetes, sagen wir mal, oder mit
Docker oder mit Cloud
und all diesen Dingen? Wie hängt das
denn damit zusammen?
Das sind natürlich
viele der Dinge, die du
angesprochen hast, können
hilfreiche
Bausteine sein, ob sie es denn tatsächlich
sind, liegt natürlich,
liegt natürlich mal wieder
am Kontext. Also,
sag mal, sowas wie Containerisierung,
ja, ich weiß noch,
wie das damals mit, losging
mit der Hardware-Virtualisierung,
ja, also früher die
Emulation vom Betriebssystem,
wirklich Wine, etc.,
das war ja wirklich schmerzhaft.
Dann kam auf einmal Frau M. Währungs-Eck und hat
gesagt, wir machen alles anders und wir
virtualisieren die Hardware.
Auch da habe ich,
damals war ich sehr aktiv in diesem Bereich,
und habe sehr viele Widerstände.
So, jetzt haben
wir aktuell mit der
mit der Containerisierung,
legen wir die Abstraktion
wieder eins höher,
zu dem Anwendungsprozess,
und das ist natürlich
ein wichtiger und
hilfreicher Schritt.
Ich sag mal, ein Großteil,
ein großer, nicht zu unterschätzender Teil
der Betriebsaufwände liegt einfach
darin, Betriebssysteme
zu managen, zu patchen,
Sicherheitspatches, etc.
Leider Gottes auch
viel Produktionssysteme
anzupassen, ja, und dann zu hoffen,
dass es danach so gut funktioniert
wie zuvor. Also, insofern,
ja, diese Technologien sind
hilfreich, aber
nicht jede Technologie
passt in jeden Kontext,
und Technologie
allein schafft halt keine
Fähigkeiten.
Ich brauche die Prozesse dazu,
ich brauche die Menschen dazu,
mit den entsprechenden Skills,
wenn die Technologie allein
hilft halt nicht. Also, ich kenne
Situationen, da wurden Container,
Plattformen aufgebaut,
und die wurden halt einfach nicht angenommen.
Ja, und dann, also
der Mehrwert war praktisch null.
Ja, im Gegenteil.
Es wurde Geld ausgegeben,
ja, und
das war pure Verschwendung.
Ja, und da sind wir wieder
bei dem Teil,
wer ist eigentlich der Kunde?
Und dann können solche
Technologien natürlich total hilfreich sein.
An der Stelle, wir
haben September
2022, wir haben
ein Energiethema,
natürlich sind mit solchen
Technologien auch solche
Herausforderungen vielleicht besser zu stemmen.
Natürlich, wenn ich
Anwendungsinstanzen, die ich aktuell
nicht brauche, problemlos runterfahren kann
und problemlos wieder hochfahren kann,
dann kann ich natürlich auch
unglaublich viel Energie sparen.
Also, man glaubt ja nicht, wie viel
im Rechenzentrum im Kreis rumdreht
und Strom
in heiße Luft verwandelt,
ohne dass es benutzt wird.
Also, da sehr viel
Potenzial mit dem Hinweis,
die Technologie allein macht es nicht.
Und ob eine Ressource
bei mir im Rechenzentrum idelt oder
beim Cloud-Betreiber,
spielt an der Stelle
natürlich auch keine Rolle.
Ja, das stimmt. Ja, ich, ähm,
ich verwende da immer ganz gerne so ein Bild,
so wie,
wie wenn ich was anpflanze oder sowas.
Es geht mir nicht ums Substrat,
es geht mir nicht um die Erde, aber es ist halt nur mal notwendig,
dass die Tomaten wachsen können. Und ich glaube,
so ähnlich ist das auch mit all diesen
Plattform-Dingen, nicht wahr? Die sind
nicht hinreichend, aber durchaus notwendig,
damit ich die Früchte ernten kann, um die es mir
eigentlich geht.
Absolut. Absolut.
Mir fallen da andere Dinge ein, die vielleicht
noch notwendiger oder früher
notwendig sind, wie zum Beispiel
gemeinsames, gemeinsames Git.
So,
da,
da gäbe es schon, oder eine gemeinsame
Wissensplattform,
da gäbe es schon Dinge, die mir noch vorher
einfallen, ja, und die ich für
mindestens so, so wichtig
empfinde. Aber
du hast natürlich Recht, diese Plattformen
sind äußerst hilfreich
und in vielen Kontexten
auch das Mittel der Wahl.
Ich sag mal, Cloud wird da oft
insbesondere von den Anbietern als
Heilmittel dargestellt und
immer wieder werde ich
noch gefragt, ja, was ist denn jetzt eigentlich
Cloud und ist das denn immer Public
und da gibt es erschreckend
wenig Wissen eigentlich.
Ja, und
die Idee, dass es am Ende ein
Bereitstellungsmodell ist,
ist erstaunlich
wenig verbreitet. Ich ziehe dann oft
die Analogie zum Strom, also von der Erfindung
des Stroms bis zu dem
Zeitpunkt, zu dem er aus der Steckdose
kam. Ich glaube, das waren
20 Jahre, wenn überhaupt.
Beim Compute
hat es 100 Jahre gedauert.
Tatsächlich wird es
nach wie vor schlechter adaptiert.
Wer würde schon,
es gibt nur wenige,
die Strom produzieren, um ihn zu
nutzen. Tatsächlich
produzieren aber ganz viele
Compute, um es zu nutzen.
Aber es ist ein Bereitstellungsmodell und
das kann natürlich hilfreich sein,
muss es auch nicht und manchmal ist es so,
sogar gar nicht möglich aufgrund von
regulatorischen Vorgaben.
Das bedeutet ja nicht, dass ich
keine Cloud mache, sondern dass ich
vielleicht eine Cloud selber mache.
Das ist aber,
das ist etwas, das muss man sich halt
im Einzelfall anschauen,
aber es sind super hilfreiche,
super hilfreiche
Technologien oder im
Fall der Cloud Bereitstellungsmodelle
für solche Herausforderungen,
wie wir sie im DevOps-Umfeld erleben.
Mhm.
Dann ist das jetzt vielleicht ein guter
Zeitpunkt, um auch mal ein bisschen
aus der Vergangenheit oder der Gegenwart
sich zu lösen und mal ein bisschen in
Richtung Zukunft zu denken.
Wenn du jetzt mal so
extrapolierst die Reise, die du
und deine Kunden gemacht haben
über die vergangenen Jahre und Jahrzehnte,
was denkst du denn, wohin diese Reise
weiterhin gehen wird und wo siehst du denn
die aktuell größten Herausforderungen
oder die spannendsten Spielfelder?
Also
ich glaube, die Reise
geht gerade im Bereich
der Infrastruktur,
des Betriebs, noch
sehr viel mehr in Richtung
Plattform und Produktdenken.
Also die Zeiten,
in denen IT produziert
wird, wie in einer Manufaktur,
ich glaube, die werden
immer schwieriger.
Es wird mehr und mehr ein
Plattformdenken geben. Personen
werden sich auch umorientieren,
also nicht nur vom
reinen Denken, sondern auch von den
Skills. Die
Rechenzentren sind eher API
driven. Es wird immer weniger mit
der Maus am Arm
umgesetzt. Genau, das
ist einer der Dinge,
die ich sehe.
Die Art und Weise der Zusammenarbeit,
die wir heute
teilweise
schon sehen zwischen Entwicklern
und Anwendungsbetrieb,
das wird auch mehr und mehr
nach unten wandern in Richtung
Infrastruktur.
Die Methoden,
mit der wir arbeiten, die Werkzeuge,
mit denen gearbeitet wird,
das wird sich meiner Meinung nach
mehr und mehr angleichen.
Schon in vielen
Organisationen auf dem Weg,
aber mehr Unternehmen
noch nicht auf dem Weg und
das wird sicherlich ein
Teil des
Wandels.
Das ist dann das, was man
landläufig GitOps nennt, oder?
Ja, ich bin
gespannt, was nach GitOps kommt.
Was mich immer so ein bisschen fasziniert,
weil ich hätte irgendwie gedacht, dass das
schon immer gelebte Praxis war.
Ich möchte
wetten, dass zum Beispiel die Mainframe-Jungs
das vor 40 Jahren auch schon
von den Ansätzen her ganz ähnlich gelebt haben.
Vor 40 Jahren war ich
noch nicht in der IT, aber ich gebe dir natürlich
Recht.
Die haben das früher viel deutlicher
gelebt. Es gibt ja
neben dem Mainframe auch noch so
Midrange-Systeme, damals
hieß es AS400, heute glaube ich
i-Series. Dort waren
viele
Kompetenzen gebündelt.
Man hat sich eben nicht nur um die
Hardware gekümmert, sondern natürlich auch um den
damals Direct Attached Storage,
was wir heute teilweise auch wieder sehen,
über die Datenbank, die drauf ist,
bis zu den Anwendungen.
Das war alles in einem
Team. Und ja,
damals waren wir aus heutiger
Sicht weiter.
Lustig, oder? Ich finde,
das muss irgendwie so
sein in der IT. Das Pendel schwingt immer so ein bisschen
hin und her. Zuerst hatte man
Zentralisierung, dann hatte man Dezentralisierung,
jetzt hat man wieder Zentralisierung in Richtung
Cloud, jetzt kommt dann vielleicht wieder eine Dezentralisierung.
Und so ist es mit vielen anderen
Sachen auch, oder? Ja, mir fällt
dazu ein Geschäftsführer ein,
der tatsächlich einen IT-Hintergrund
hatte, neben seinem kaufmännischen Hintergrund.
Und der hat mir genau das
gesagt. Damals ging es
um Terminal Server,
und dann hat er gesagt so, ah, nee,
Herr Lange, ich beobachte
das jetzt schon seit langer Zeit,
seit 40 Jahren, das geht immer hin
und geht immer, und geht dann
wieder her. Und diesmal
setze ich einen Zyklus aus.
Kann man eben eigentlich nur
gratulieren zu dieser
Einsicht, wobei
was ich ganz klar sehe,
ist, dass DevOps
und DevOps
Vorgehen meiner Meinung nach
das IT-Produktions-
Modell der Zukunft darstellen. Davon
bin ich fest überzeugt.
Ja, es gibt ja auch nicht wenige, die sagen,
das ist die
Professionalisierung
letzten Endes endlich mal der IT,
dass man mehr
in Richtung nicht mehr Handarbeit
geht, wie du vorhin gesagt hast,
mit der Maus irgendwie in den Betriebssystemen
rumfuhrwerken, sondern in Richtung
einer Automatisierung,
einer Industrialisierung im weiteren Sinne,
dass das jetzt
die industrielle Revolution der IT ist irgendwie.
Ja, natürlich auch
der Digitalisierung. Mein Geschäftsfeld
heißt ja Digitalisierung und agile
Methoden, wie ich vorstehe und das ich
verantworte. DevOps ist natürlich
auch ein Stück weit die Digitalisierung
der IT-Produktion.
Und wenn wir uns
das anschauen… Was so lustig widersprüchlich
klingt, ne?
Ja, sollte man meinen. Und wenn man genau hinschaut,
dann ist es gar nicht so widersprüchlich.
Also, wenn wir uns anschauen,
die IT-Abteilungen dieser Welt
haben in der
Produktion, also die letzten
Jahrzehnte, den
produzierenden
Abteilungen enorm geholfen
weiterzukommen im Bereich der
Digitalisierung, im Bereich von
Lean-Production.
Diese ganzen Vorteile
und wenn man sich dann anschaut,
wie viel davon sie für sich selber
adaptiert haben, kann man ja
schon auch demütig werden.
Viele Erfahrungen, die
es in Organisationen gibt,
mit dem Thema, insbesondere
mit dem Thema Lean, kann man jetzt
natürlich auch für die
IT mitnutzen.
Wir fangen da ja nicht von…
Wir müssen das nicht
von Neuem erfinden.
Ja, und ich finde, das ist auch eine ganz gute
Nachricht, weil es
zeigt halt auch irgendwie, schlussendlich geht’s
ja um nichts Neues, um nichts anderes.
Wenn man ehrlich ist, zum Schluss geht’s
wahrscheinlich um Menschen, ne? Und Menschen
sind halt irgendwie immer Menschen.
Ja, das stimmt.
Wobei ich würde es ergänzen, es geht nicht
nur um Menschen, es geht natürlich auch um Prozesse,
es geht auch um Technologie,
neue Technologien zu adaptieren.
Aber der Mensch ist
natürlich ein ganz, ganz wichtiger
Player in dem Spiel.
Und der, der es
ermöglicht oder entmöglicht.
Genau.
Das klingt fast wie ein tolles Schlusswort für
eine Folge,
die sich ja nennt, DevOps im Infrastrukturbetrieb,
dass wir es auf diese Weise wieder
den Bogen zurückspannen.
Gibt’s noch was Wichtiges, was du loswerden
möchtest? Haben wir was vergessen?
Gibt’s was, was du noch genauer beleuchten
möchtest?
Ich weiß gar nicht, ob ich’s
ob ich was vergessen hab. Man kann
natürlich über DevOps, kann man ja reden,
Tage und Wochen lang.
Aber was ich schon nochmal
adressieren möchte, ist
die Veränderungen, wie sie
DevOps mit sich bringen, sind
ohne sinnstiftendes Moment
schwer umsetzbar.
Das ist wichtig.
Und ich hab’s schon
angesprochen, so eine Vision
und ein klares Commitment vom Sinnstifter
sind nicht zu unterschätzende,
äußerst kraftvolle Werkzeuge,
die Enormes
bewirken können und die man nutzen sollte.
Naja, und der Rest ist
harte Arbeit, Schweiß,
Tränen und sehr viel Lernen.
Und an der Stelle möchte ich auch
alle Zuhörer motivieren,
das ist es wert, weil
Arbeit wird dadurch eben nicht nur besser,
sondern auch schöner.
Ja, ich glaube, das hast du schön gesagt.
Das ist etwas, was ich auch als sehr wichtig empfinde.
Ich finde, Peter, das war ein tolles
Schlusswort und
wir haben ja jetzt auch schon wieder
mit Fug und Recht eine neue Folge
draus gemacht. Insofern danke
ich dir an dieser Stelle nochmal
vielmals dafür, dass du uns so viel von deiner
Zeit und von deinen Erfahrungen geschenkt hast.
Falls Leute noch Fragen haben,
dann können sie mit Sicherheit
einen Blick in die Shownotes werfen
und dort Wege finden, um mit dir
in Verbindung zu treten, um mit der profi AG in Verbindung
zu treten. Das Buch, das du erwähnt hast,
das packen wir natürlich auch in die Shownotes rein.
Und alles, was uns jetzt vielleicht auch im Nachgang
noch einfällt an Dingen, die wir als
Wichtige erachten für euch
liebe Hörerinnen und Hörer. Auch im Namen
von Falko, der jetzt irgendwie schon weghechten
musste, möchte ich mich
also nochmal ganz herzlich bei dir bedanken, Peter.
Und ich wünsche dir einen ganz tollen Tag.
Sehr gerne, gleichfalls. Vielen Dank
für die Einladung.
Vielen Dank.
Vielen Dank.
Vielen Dank.

Folge 63: Peter Lange zu DevOps im Infrastruktur-Betrieb 1/2

Klicken Sie auf den unteren Button, um den Inhalt von podcasters.spotify.com zu laden.

Inhalt laden

Zu Gast haben wir Peter Lange, Geschäftsfeldleiter und DevOps Coach bei der PROFI Engineering Systems AG.Mit ihm sprechen wir über DevOps aus der Sicht des „Endes der Nahrungskette“: dem Infrastruktur-Betrieb.

In dieser Podcast-Episode sprechen die Gastgeber mit Peter Lange über die Integration von DevOps in den Infrastrukturbetrieb. Sie erörtern die Notwendigkeit, Infrastrukturteams frühzeitig in Projekte einzubeziehen, um Probleme zu vermeiden und effizientere Arbeitsabläufe zu ermöglichen. Es wird diskutiert, wie traditionelle Betriebsmodelle und die Kultur in IT-Abteilungen durch DevOps-Prinzipien verändert werden können. Besonderer Fokus liegt auf der Bedeutung von Kommunikation, gemeinsamen Regeln und einem veränderten Mindset. Beispiele aus der Praxis und mögliche Lösungsansätze, wie die Automatisierung von Prozessen und die Bildung cross-funktionaler Teams, werden hervorgehoben.

Inhalt

  • DevOps im Infrastrukturbetrieb
    • Integration von DevOps-Prinzipien
    • Herausforderungen für Infrastrukturteams
    • Bedeutung frühzeitiger Einbindung in Projekte
  • Kommunikation und Zusammenarbeit
    • Entwicklung gemeinsamer Sprache und Regeln
    • Bedeutung von cross-funktionalen Teams
  • Kultureller und organisatorischer Wandel
    • Veränderung der Betriebsmodelle
    • Einfluss von DevOps auf die Unternehmenskultur
  • Praktische Ansätze und Lösungen
    • Automatisierung von Prozessen
    • Rolle von Architektur und Design
    • Sicherheitsaspekte in DevOps (DevSecOps)
  • Ausblick und zukünftige Themen

Shownotes

Peter hat zwei Buchtipps für uns:
The Other Side of Innovation
Team Topologies

Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)

Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und
ins Hirn, gestaltet und produziert von Luca Ingianni, Dierk Söllner, Falko Werner, ich
sozusagen. Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung. DevOps umfasst für
uns kulturelle, organisatorische und technische Aspekte. Wir freuen uns heute auf das Thema
DevOps im Infrastrukturbetrieb. Zu Gast haben wir Peter Lange, Geschäftsfeldleiter und DevOps-Coach
bei der Profi Engineering Systems AG. Er ist seit 1999 in der IT. Angefangen als Security-Admin,
dann BSI-Grundschutz, das was man heute unter ISO 27001 kennt, Virtualisierung, Storage,
Netzwerk, Data Center Design, ToeGraph-Architekt bis zum Thema Agile und DevOps, mit dem er sich
seit 2015 am liebsten und leidenschaftlichsten beschäftigt. In unterschiedlichen Organisationen
hat er einen starken Infrastruktur-Hintergrund und meint, DevOps-Kultur gehört auch dort mehr
etabliert. Lieber Peter, wir haben in diesem Podcast die Tradition, alle unsere Gäste nach
ihrer persönlichen Definition von DevOps zu fragen. Wie sieht es denn von deiner Seite aus aus?
Ja, hallo erstmal. Ja, DevOps- Definition, da gibt es so viele. Irgendwie sind alle richtig
und alle auch irgendwie inkomplett. Ich bin dazu übergegangen,
mehr darüber zu beschreiben, was DevOps eigentlich tut. Und meiner Meinung nach verbessert DevOps die
Produktion von IT-Produkten und IT-Services in Bezug auf die Durchlaufzeit, die Qualität und
ganz wichtig, den Betriebsaufwand, mit dem Ziel, die Bedarfe der Kunden optimal zu erfüllen.
Also so eine ganz klassische Wertperspektive eigentlich, ganz wunderbar.
Genau, also willkommen auch von mir, Peter. Schön, dass du da bist. Möchtest du denn noch
was hinzufügen?
Also, kann ich da noch was hinzufügen zu dieser Vorstellung, die wir, die wir da gerade haben,
zuteilwerden lassen? Oder ist alles richtig gesagt?
Alles Gesagte ist richtig. Vielleicht findet sich im Rahmen des Gesprächs noch Dinge, die wir
hinzufügen können. Für den Moment, glaube ich, passt es.
Wunderbar. So, ich bin neugierig. Du sagst, dass die Infrastruktur Teams oft irgendwie so
am Ende der Nahrungskette stehen und man weiß ja, den Letzten beißen die Hunde, die, sagen wir mal,
Sie sind vom Business sehr weit weg, von den Entwicklern womöglich.
Sag mal, muss das so sein, Peter?
Das ist leider Gottes so. Es sollte meiner Meinung nach nicht so sein.
Daraus ergeben sich natürlich Konsequenzen, Probleme, die es nicht gäbe, wenn Sie ein bisschen näher dran wären.
Sag mal, oft entstehen ja Projekte im Fachbereich oder durch Bedarfe von Kunden, interne, externe.
Diese Ideen werden dann gerne auch in Software gegossen, umgesetzt.
Die Entwickler sprechen vielleicht noch mit dem Anwendungsbetrieb und der Infrastrukturbetrieb bekommt dann ganz spät etwas mit.
Vielleicht ist er ganz am Anfang mal irgendwo in der Planung mit drin.
Ja, und dann bekommt das über die sprichwörtliche Wall of Confusion geworfen, gerade so wie auch Anwendungsbetrieb.
Und das führt natürlich zu Ungemach, zu Verzögerungen.
Und das muss tatsächlich nicht so sein.
Meine Erfahrung ist zumindest, dass überall dort, wo es gelungen ist, den frühzeitig einzubinden, es deutlich besser läuft.
Zumal ja die Infrastruktur auch noch so Herausforderungen hat, dass Beschaffungsprozesse oft Wochen oder sogar Monate dauern.
Oh Mann, da weiß ich jetzt schier nicht, wo ich anfangen soll.
Du hast jetzt ein paar Themen, in die ich gerne einsteigen würde.
Aber vielleicht fangen wir einfach mal bei dem letzten an, was du gesagt hast, nämlich frühzeitig einbinden.
Was heißt denn frühzeitig und was heißt denn einbinden?
Tatsächlich miteinander reden, Collaboration.
Ich hatte in einem eurer Podcasts mal gehört, DevOps lässt sich auch mit Zusammenarbeit übersetzen.
Und das finde ich eigentlich ein ganz schönes Bild dafür.
Tatsächlich früh einbinden, im möglichst frühen Status der anzugehenden Projekte und dann auch sehr umfassend,
sodass die Kompetenzen…
Die Kompetenzen aus dem Betrieb, auch aus der Infrastruktur, letztendlich auch zum Gelingen des Projekts beitragen können.
Ich weiß nicht, ob ihr das seht, oft passiert das sehr spät und dann sagt der Infrastrukturbetrieb so, halt, stopp mal.
Und das wird dann oft so als Widerstand wahrgenommen.
In Wirklichkeit sind das natürlich auch, kommen die Widerstände natürlich auch aus Kompetenzen heraus, die die Infrastruktur hat.
Und wo sie genau wissen.
Da lohnt es sich, früh drüber zu reden.
Und diese Kompetenzen verhindere ich natürlich, wenn ich sie nicht mit einbinde.
Ja, klar.
In der Hinsicht finde ich das übrigens auch interessant.
Wir hatten, das muss Episode 44 oder irgendetwas gewesen sein von diesem Podcast,
hatten wir mal einen Site-Reliability-Ingenieur von Google zu Gast, der lustigerweise exakt dasselbe gejammert hat.
Der hat gesagt, ja, meine Applikationsentwickler, die kommen dann irgendwann ums Eck.
Und schmeißen mir irgendwie einen neuen Container über den Zaun.
Und ich darf dann schauen, wie ich den auf meinem Fuhrpark am Laufen halte.
Also selbst in den schicken, funkelnden Unicorns ist offenbar in der Hinsicht nicht alles Gold, was glänzt.
Wie kann man es dann besser machen?
Wenn es selbst bei Unicorns oder bei, ich weiß ja nicht, was das für Unternehmen sind, von denen du redest, Peter.
Sind das auch Groß-IT-Getriebene oder sind das eher Unternehmen mit IT-Abteilungen,
die irgendwo außerhalb der Geschäftsprozesse irgendwelche IT-Wertströme betreiben?
Meiner Erfahrung nach lässt sich das nicht so klassifizieren.
Das findest du in allen Größen, tatsächlich auch in Organisationen, die sehr abhängig sind von der IT
und wo die Werte tatsächlich durch IT generiert werden.
Also das ist tatsächlich, durch die Bank findet man es.
Durch die Bank gibt es natürlich auch…
Ausnahmen.
Welche Zusammenarbeitsstrukturen funktionieren denn aus deiner Erfahrung heraus am besten,
wenn man versucht, das Thema DevOps-Zusammenarbeit möglichst frühes Einbinden
oder möglichst frühes Einbinden der betriebsverantwortlichen Teams
in die Projekt- oder Produktentwicklungsstrukturen zu ermöglichen?
Also wie funktioniert es am besten?
Meiner Erfahrung nach funktioniert es am besten, wenn gerade im Rahmen von Projekten,
vielleicht auch von größeren Projekten, dedizierte Teams geschaffen werden.
Denn der Betrieb ist ja auch im Bereich der Infrastruktur typischerweise so geschnitten,
dass er die alltäglich anfallenden Arbeiten sehr gut und kosteneffizient umsetzen kann.
Zusätzliche Arbeit ist schwierig.
Insbesondere, wenn es dann…
Wenn es dann…
Wenn es dann…
Innovationscharakter hat.
Das ist schwierig in der Bestandsorganisation des Infrastrukturbetriebs
oder überhaupt des Betriebs umzusetzen.
Und am erfolgreichsten ist meiner Meinung nach, wenn das über dedizierte Personen,
die dann tatsächlich auch die Zeit haben, sich um diese Themen zu kümmern
und die dann früh in das Gesamtprojekt mit einzubeziehen
und dort dann tatsächlich cross-funktional mitzuarbeiten.
Also dediziert klingt für mich immer so.
Dediziertes Netzwerkteam, dediziertes Security-Team,
das halt an einer Komponente im IT-Wertstrom dediziert arbeitet.
Du hast aber gerade auch cross-funktional gesagt.
Also ein cross-funktionales Team ist ja genau das Gegenteil von dem, was ich gerade zuerst gedacht habe.
Wenn wir von dediziert reden, ist das der Ansatz, Teams so zu schneiden,
dass sie einen Produktfokus haben mit dedizierten Teams,
mit Mitgliedern für bestimmte Aufgabenbereiche,
zum Beispiel Applikationsbetrieb hast du genannt,
zum Beispiel Infrastrukturbetrieb hast du genannt,
aber genauso auch Entwicklung oder wie sieht es mit dem Drummaster aus?
Vielleicht auch sowas, ne?
Gut, dass du es ansprichst.
Ich wollte so verstanden werden, dass die Personen dediziert diesem Projekt zugeordnet sind.
Keine zusätzlichen dedizierten Silos, bitte nicht.
Weniger davon, sondern natürlich mehr cross-funktionalität,
um dann dort auch bis runter,
in die Infrastruktur eine Sicht zu schaffen,
wo eigentlich das übergeordnete Ziel ist, um was geht es eigentlich?
Was ist eigentlich der Vorteil für den Fachbereich, für das Business, für den Kunden und wo sind die Herausforderungen?
Also sowas wie ein produktfokussiertes Team, das eine Ende-zu-Ende-Verantwortung hat,
sowohl mit Betriebsaufgaben als auch mit Entwicklungsaufgaben.
Genau.
Oft ist es ja so, dass sich im Rahmen solcher Projekte heraus,
dass wir eine Plattform brauchen,
dass dann sozusagen die Entwicklung oder auch der Anwendungsbetrieb sich an so einer Plattform bedient.
Und solche Dinge, dass wir natürlich wollen, dass ein Entwickler kurzfristig ad hoc eine Testumgebung bekommt,
sind natürlich so aus dem Standardbetrieb heraus sehr schlecht umsetzbar.
Und die Idee, ja auch wir in der Infrastruktur haben Kunden und reden direkt mit dem Kunden und fragen,
was er braucht, um das dann optimal umzusetzen, das ist natürlich äußerst hilfreich.
Plattform ist auch ein ganz interessantes Thema, interessanter Begriff.
Wie verstehst du denn Plattform?
Plattform in dem Kontext verstehe ich so, dass es eine Infrastrukturplattform gibt,
die eben die Anforderungen aus der Entwicklung und dem Anwendungsbetrieb optimal erfüllt.
Und manchmal ist es eine Plattform, die automatisiert virtuelle Maschinen zur Verfügung stellt.
Wir kennen alle das Thema Kubernetes und die ganzen Distributionen,
die auch so eine Plattform zur Verfügung stellen können.
Genau, aber die Ausprägung so einer Plattform hängt natürlich am konkreten Projekt.
Ist also auch unabhängig vom Hosting, ob es jetzt On-Premise gehostet ist
oder durch einen Public-Cloud-Anbieter zur Verfügung gestellt wird.
Das macht für dich keinen Unterschied?
Nein, das macht, also es macht in der Beschaffung natürlich auch, es macht schon Unterschiede.
Gerade der Beschaffungsprozess ist beim Public-Cloud-Anbieter,
der nochmal ganz anders skaliert, natürlich anders.
Sicherlich auch besser, dort haben wir dann mehr Herausforderungen in der Verrechnung.
Aber prinzipiell macht es keinen Unterschied.
Am Ende muss ich Anforderungen optimal erfüllen.
Und das ist natürlich ein Architekturthema, das tun lässt,
möglichst gut zu arbeiten.
Wenn es nicht früh adressiert wird und wenn es Architekten gibt und dann Architekten bohrt,
dann müssen die natürlich auch mit einbezogen werden.
Das löst so ein bisschen das Problem, dass Infrastrukturbetrieb ab und zu als Bremsschuh wahrgenommen wird.
Kann man das so sagen, dass man da eine Lösung hat,
indem man zum Beispiel Cloud-Anbieter an solcher Stelle mit einbindet?
Ja, Cloud-Anbieter mit einbeziehen kann natürlich eine Lösung sein.
Allerdings jetzt nur Ressourcen in den Cloud zu beziehen,
meiner Meinung nach ist das ein sehr teures Hosting 2.0.
Ich muss natürlich auch Betriebsmodelle anpassen.
Ohne Automatisierung wird es sicherlich nicht sehr viel mehr Spaß machen,
als wenn ich lokale Ressourcen zur Verfügung stelle.
Wie sieht es im Infrastrukturbetrieb dann aus?
Hat solche Anbieter, Technologie, Cloud und ähnliches auch einen Einfluss,
auf das Mindset, auf die Kultur in solchen, ich nenne es erstmal Abteilungen?
Ja, über kurz oder lang hat es natürlich Einfluss.
Zumindest wenn es erfolgreich sein soll, meiner Meinung nach.
Das ist ähnlich wie eine Containerplattform.
Die agiert oft als so ein Kristallationspunkt.
Es wirkt oft als Katalysator, um dann eben Arbeit zu verändern,
die Zusammenarbeit zu verändern.
Es wird sehr schnell klar, dass mit alten Betriebsmodellen
und der alten Art der Zusammenarbeit eben die Mehrwerte,
die man sich erhofft, gar nicht zu heben sind.
Insofern hat es natürlich Einfluss.
Das heißt, es verändert durch andere Beschaffungsprozesse
auch die Unternehmenskommunikation, die Kultur, das Verständnis der Arbeit.
Also an sich etwas, wo man nicht auf eine neue Generation an Mitarbeitern hat,
die andere vielleicht weniger historisch bedingte Einflüsse mitbringen,
sondern kann das auch in einem laufenden Unternehmen
mit bestehenden Mitarbeitern forcieren.
Gibt es außer Beschaffungsprozesse auch andere Mittel,
die eine Kultur beeinflussen?
Das ist witzig, dass du es ansprichst, Falco.
Mir wurde das tatsächlich so eins zu eins gesagt.
Ja, Herr Lange, das ist ja alles gut und schön,
was Sie uns hier vorschlagen.
Unsere Mannschaft geht das nicht.
Da müssen wir warten auf eine andere Generation.
Das ist natürlich schon auch ein Stück weit eine Bankrotterklärung,
meiner Meinung nach.
Kultur, ja, ein wichtiges Thema in DevOps.
Es gibt ja keine Nicht-Kultur.
Ich habe noch nie eine Organisation erlebt, in der es keine Kultur gibt.
Irgendeine gibt es immer und die ist ja irgendwie gewachsen.
Ich halte es für sehr wichtig,
dieses große, total schwammige Thema Kultur mal,
zu konkretisieren und ich bin Fan davon,
es auch erst mal stark zu reduzieren und zu sagen,
okay, lasst uns mal dafür sorgen,
dass wir eine gemeinsame Sprache entwickeln,
dass wir gemeinsame Regeln haben
und dass wir uns um die Arbeitsbeziehung kümmern.
Daraus lässt sich dann tatsächlich auch Kultur schaffen.
Also ich weiß nicht, wie es euch geht.
Ich hatte schon sehr oft das Erlebnis, dass ich,
gerade am Anfang, der Kunde meinte, ja, wir machen einen Workshop
mit den Entwicklern und einen Tag später machen wir einen mit dem Betrieb.
Und dann kommt man mit so wirren Ideen wie, nee, wir machen das gemeinsam,
wir setzen die an einen Tisch und im Nachgang ist dann das Feedback,
wow, dass wir mal miteinander reden konnten
und wir uns gegenseitig erklärt haben, was wir eigentlich meinen.
Das war so hilfreich.
Also gerade die Sprache.
Also meine Freunde, die nicht in der IT sind, die glauben ja, IT ist eins, so.
Und ja, vielleicht ist es ein eigener Planet,
aber auf dem gibt es doch sehr unterschiedliche Kontinente mit unterschiedlichen Sprachen.
Ja, also das zusammenzubekommen, dann tatsächlich die gemeinsamen Regeln,
der Fokus auf das übergeordnete Ziel, das sind Dinge, ja, die sind einfach so wirksam,
das ist…
…gar nicht stärker betonen kann.
Also für dich sind Sprache, Regeln und sind es Prozesse als drittes,
Zusammenarbeit, Arbeitsweisen, die Kernelemente, die eine Kultur ausmachen?
Zumindest ist es ein ausgezeichneter Anfang, das Thema Kultur konkret anzugehen,
konkret zu schauen, wo haben wir denn eine gemeinsame Sprache,
wo haben wir keine gemeinsame Sprache.
Das ist übrigens auch etwas, wo gerade am Anfang, wenn wir über Architektur reden,
die Architekten sicherlich einen guten Beitrag leisten können,
denn die Architektur, gerade mit ihrem übergeordneten und ganzheitlichen Blick im Idealfall,
natürlich für diese gemeinsame Sprache mitsorgen kann.
Wie stelle ich mir das am ehesten vor?
Der eine sagt Server, der andere sagt Server, ist die gleiche Sprache,
aber der eine redet trotzdem von was ganz anderem?
Ja, das ist doch genau schon so ein Punkt, oder?
Der eine denkt, wenn man Server redet, denkt er an Apache und der andere denkt an Blech im Keller.
Na klar. Also ein einfaches Beispiel, was ich immer wieder erlebe,
wenn der Entwickler von einem Deployment spricht, dann meint dann Maven einen Punkt
und jemand aus dem Betrieb sagt, Moment mal, wenn Software irgendwo auf der Platte liegt,
dann ist es nicht deployed.
Software muss sich im Kreis rumdrehen und Strom verbrauchen, dann ist es deployed.
Und der Fachbereich sagt.
Deployed ist das, wenn tatsächlich jemand darauf zugreifen kann und einen Mehrwert hat.
Wie kriegt man diese drei Sichten für ein Deployment übereinander?
Ja, indem man es einfach anspricht, zusammenbekommt und dann halt auch in der großen Runde mal fragt,
was ist denn das Ergebnis von einem Deployment-Entwickler?
Und dann erklärt er das und dann landen sich andere halt an die Stirn und sagen,
ja, Moment mal, und darüber findet man dann eine gemeinsame Sprache
oder zumindest eine gemeinsame Sprache.
Das ist zumindest ein Verständnis dafür, dass der gleiche Begriff woanders was anderes bedeutet.
Im Idealfall kann man ja daraus dann auch ein Glossar bauen, damit das für alle nachvollziehbar ist.
Ja, schönes Werkzeug auf jeden Fall für solche Zwecke.
Aber wenn das so einfach und so wirkungsvoll ist, wird das dann nicht eigentlich überall gemacht?
Den Eindruck habe ich nicht, dass es überall gemacht wird.
Ich glaube, es ist zumindest dort, wo ich gebeten werde, mitzuarbeiten,
gibt es natürlich schon Hindernisse.
Und eines der größten Hindernisse, die ich sehe, sind vor allen Dingen diese hohen Betriebsaufwände,
unter denen die Betriebsmannschaften stöhnen und die ihnen oft auch gar nicht die Zeit geben,
Dinge, Arbeit grundsätzlich zu verbessern.
Das ist tatsächlich einer der großen Punkte.
Und an der Stelle vielleicht auch mal ein Buchtipp.
The other side of innovation, solving the execution challenge,
von Govindarajan und Trimble, finde ich an der Stelle sehr lesenswert.
Die erklären, warum aus einer Bestandsorganisation heraus solche Dinge,
die reden tatsächlich von größeren Innovationen,
aber ich halte auch so DevOps-Projekte für ausreichend innovativen Charakter
und das aus der Bestandsorganisation nur schlecht heraus umsetzbar ist.
Ja, das ist auch interessant.
Da muss ich nochmal.
Als an diese Folge denken, die wir gemacht haben mit diesem Google SAE.
Der hat gesagt, wenn Sie mehr als 50% manuelle Arbeit haben im Wochenmittel,
dann befinden Sie sich per Definition im Notfallbetrieb.
Wow.
Er sagt, mindestens 50% seiner Aufwände sollen in tatsächliche Weiterentwicklung gehen,
in Autorobation, in Innovation und so weiter und so weiter.
Wenn er diese 50% nicht mehr halten kann, dann per Definition sind Sie im Notfallbetrieb.
Und dann greifen andere Regeln.
Dann werden zum Beispiel Lasten anders verteilt und sowas.
Das finde ich einen spannenden Ansatz.
Und ja, es ist bestimmt hilfreich.
Schön, dass Google dort eine Lösung gefunden hat.
Ob das so eins zu eins umsetzbar ist auf den klassischen Mittelständler, weiß ich nicht.
Google hat halt auch viel Geld, um es gegen so ein Problem zu schmeißen.
Genau, tatsächlich viel Geld.
Und sicherlich auch viel Personal, die da in der Lage ist, das anzugehen.
Aber diese 50% als Zielmarke, das ist, finde ich, sehr spannend und lohnenswert, sich anzuschauen.
Und selbst wenn es dann nur 30% sind, wäre ja sicherlich auch schon ein Schritt in die richtige Richtung.
Ja, irgendwo muss man anfangen.
Bis jetzt bei 50% hat, weiß man ja nicht, ob es dabei auch bleibt.
Aber es ist zumindest ein gutes Maß, um zumindest solche Themen wie Regeln, was du ja auch vorhin angesprochen hast,
dass für dich zur Kultur auch Regeln gehören, mal sichtbar zu machen, auch Transparenz zu schaffen.
Und dann zu sagen, okay, wir haben gerade offiziell mehr als 50% manueller Aufwand.
Folge, wir haben Notfallsituationen.
Folge, wir gehen anders mit unserer Arbeitszeit um.
Das ist natürlich eine interessante Regel.
Gibt es dann andere Regeln, die euch gerade einfallen, die Unternehmen in dem Umfeld definieren?
Ich meine, so klassisch, recht weit verbreitet ist ein Thema wie, wir arbeiten nach agilen Frameworks als Zusammenarbeitsmodell.
Wäre eine Form von Regel.
Eine andere habt ihr schon genannt.
Fällt euch noch was ein?
Also mir fällt vor allen Dingen ein, die Veränderung von bestehenden Regeln.
Typischerweise also solche Dinge wie Verantwortung und wer wofür verantwortlich ist.
Das verändert sich im Rahmen so eines DevOps-Prozesses einer Reise natürlich auch.
Und da muss natürlich drauf geschaut werden.
Wenn ich Möglichkeiten schaffe.
Ad hoc, vielleicht sogar als Self-Service, Ressourcen zu requestieren.
Wer ist denn eigentlich noch verantwortlich für das Ressourcenmanagement?
Kann ich das denn immer noch in der Infrastruktur verorten?
Haben die denn noch die Möglichkeiten?
Das ist, finde ich, einer der wichtigen Punkte.
Denn natürlich ernte ich Widerstand.
Wenn ich Verantwortung jemanden gebe, der sie letztendlich gar keine Möglichkeit hat,
hier die Verantwortung zu übernehmen.
Ja, das ist ein wichtiger Punkt, auf den ich auch zum Beispiel in Trainingsgesprächen immer wieder stoße.
Dass den Leuten Verantwortung aufgebürdet wird, ohne dass man ihnen die entsprechenden,
so wie du sagst, Möglichkeiten gibt, um dieser Verantwortung gerecht zu werden.
Entweder indem man sie fachlich befähigt oder indem man ihnen die Zeit einräumt
oder indem man ihnen die notwendige Autonomie gewährt, dieser Verantwortung gerecht zu werden.
Und wir wissen ja auch, Autonomie hat verschiedene Komponenten.
Hat eine, ich sag mal, kulturelle Komponente.
Darf ich was selber entscheiden?
Hat aber auch zum Beispiel vielleicht Architekturaspekte.
Kann ich überhaupt meinen Service so schneiden, wie ich das möchte?
Oder bin ich völlig eingeengt in bestehende architekturelle,
bestehende Vorschriften oder einfach nur faktische Gegebenheiten?
Genau, und das lässt sich, glaube ich, auch nicht für alle Organisationen über einen Kamm scheren.
Da muss man auch schauen, was gibt es für regulatorische Anforderungen etc.
Aber ich denke, der wichtige Punkt ist, wenn ich denn ein cross-funktionales Team habe,
dann muss ich mit dem Team gemeinsam diese Regeln sozusagen reviewen
und da, wo nötig, neu definieren.
Übrigens.
Übrigens.
Wenn ich da ganz kurz ein bisschen das Thema wechseln darf,
da gibt es etwas, was mich schon seit langem umtreibt
und ich bin wahnsinnig gespannt, ob du da eine gute Antwort für mich hast,
weil ich habe leider irgendwie nicht so richtig eine,
nämlich dieses ganze Thema von cross-funktionalen Teams.
Weil wir streben ja an, dass Teams auch ein langfristiges Gebilde sind,
dass da immer dieselben Leute zusammenarbeiten,
dass sich da Vertrauen einstellen kann,
dass sich da gemeinsame Arbeits- und Sichtweisen einschleifen usw.
Andererseits habe ich aber doch bestimmt über die Zeit
auch sich wandelnde Anforderungen an dieses Team.
Wenn ich jetzt mal sage,
ich fange jetzt auf der grünen Wiese mit einem neuen Service an,
da brauche ich in dem Sinne erstmal noch keinen Betrieb,
weil es gibt ja noch nichts zu betreiben.
Ja.
Und später kehrt es sich dann vielleicht um,
da brauche ich dann quasi keine Entwicklung mehr.
Da muss halt irgendwie einer noch so ein bisschen ab und zu mal ein paar Bugs fixen,
aber im Wesentlichen ist das Ding ausentwickelt
und es ist nur noch reiner Betrieb.
Wie geht das zusammen mit dem Wunsch nach stabilen Teams
mit einer mehr oder weniger konstanten Zusammensetzung?
Naja, eine der Möglichkeiten ist,
dass wir,
diese Liaison schaffen,
dass jemand eben nicht mehr in einem Team primär Mitglied ist,
sondern etwas, ich sage mal, etwas loser dem Team zugeordnet ist,
die Kompetenzen noch mit einbringt
und dann, wenn es noch notwendig ist, mitarbeitet.
Das wäre so das, was mir ad hoc einfällt,
weil natürlich verändert sich der Schwerpunkt eines IT-Produkts
im Laufe der Zeit.
Ich habe dazu auch ein paar Gedanken.
Und zwar, so ein IT-Produkt
entwickelt sich ja auch nicht von heute auf morgen.
Das heißt, es ist ja auch nicht wie so ein Projekt,
das vielleicht ein Jahr oder zwei geht, läuft,
sondern es sind ja teilweise sogar in die Jahrzehnte hinein.
Und da gibt es natürlich einerseits die Möglichkeit,
dass sich das Team von seinem Wissen her,
durch Schulung, durch Weiterbildung, durch Übungen,
tägliche Arbeit und Co. mit dem Produkt weiterentwickelt.
Und man hat natürlich auch solche Effekte wie Fluktuationen,
Mitarbeiter verlassen das Unternehmen,
neue kommen hinzu,
gegebenenfalls auch ältere Mitarbeiter gehen in Rente,
verlassen das Unternehmen dauerhaft und Ähnliches,
dass man diese, ich sage jetzt mal,
mehr oder weniger naturgegebenen Veränderungsprozesse
an der Stelle mitnutzt.
Einerseits durch Schulung, Weiterbildung,
andererseits durch Fluktuation
und dann natürlich auch solche Effekte dann zu sagen,
okay, man schaut vielleicht auch mal,
wie die Teams, die man im Unternehmen hat, zusammenarbeiten,
macht vielleicht sowas wie eine Analyse in Richtung Team-Topologien,
schaut vielleicht auch, ob man bewusst solche Zusammenarbeitsmodelle
zwischen Teams entsprechend anpasst, um bestimmte Ziele,
denkt da so ein bisschen an Architekturziele vielleicht auch,
abzubilden und eine Cross-Funktionalität herzustellen,
dass man vielleicht ein klassisches Entwicklungsteam,
ein klassisches Betriebsteam, die dann recht groß sind,
zusammenbringt und vielleicht anders schneidet,
dass dann daraus sowas wie ein Plattformen-
und ein Business- oder produktfokussiertes,
endkundenfokussiertes Team wird,
interne Kunden, externe Kundenschichten
und das lässt sich auch in überschaubaren Zeiträumen gut anpassen
und so funktioniert aus meiner Sicht das Thema Cross-Funktionale Teams
auch mit der Veränderung der Anforderungen
über einen Produktlebenszyklus hinweg.
Also wenn ich es richtig verstehe, dann sagst du einfach,
die Veränderungen sind so langsam,
dass ich einerseits den Charakter meine,
eines Teams ändern kann, aber gleichzeitig der Forderung
nach Stabilität weiterhin nachkommen kann,
weil die Änderung einfach langsam genug ist.
Wenn man das Produkt als jetzt längerfristig laufende Produkte sieht,
dann auf jeden Fall.
Wenn man jetzt natürlich ein kleines Unternehmen hat,
frisch gestartetes Startup mit einem Produkt,
das vielleicht regelmäßig, vielleicht auch einmal im Jahr
oder in kürzeren Abständen aufgrund von Kundenfeedback
einen Schwenk macht, klassischen Pivot,
dann ist es natürlich auch eine gute Situation,
dass man da andere Ansätze verfolgen muss,
dass man dann vielleicht auch wirklich sagt,
man löst das Team auf und baut neue auf,
entlässt gegebenenfalls sogar Mitarbeiter,
wenn das sinnvoll und hilfreich ist.
Da geht es natürlich dann so ein Stückchen
eher ans Eingemachte als bei Unternehmen,
die ein langlaufendes Produkt haben,
so ein Google mit einer Suchmaschine.
Ich glaube, die ist auch nicht letztes Jahr an den Start gegangen,
sondern halt auch schon so ein paar Jahrzehnte unterwegs.
Und auch bei solchen Produkten,
hat man ja regelmäßig Neuentwicklung,
wieder von vorne anfangen mit den Erfahrungen,
die man gemacht hat.
Und dann kann man natürlich an der Stelle
auch wieder mit einem neuen, frischen Team,
mit neuen Fähigkeiten wieder parallel entwickeln,
aufsetzen und dann das bestehende alte Produkt ablösen.
Weil viele Unternehmen gemacht,
nicht nur Google mit der Suche,
erst einen Monolithen bauen ist ein häufiger Ansatz,
danach dann halt was Service-orientiertes,
nächste Stufe,
wahrscheinlich was eher mit kleinen Services,
Microservice-Architekturen oder ähnliches einzusetzen,
ist ein häufiger Ansatz.
Und auch in diesen Rhythmen kann man natürlich entweder,
wie gesagt, bestehende Teams mit Weiterbildung fördern
und in die Richtung bringen
oder halt auch durch Neuzusammensetzung.
Ja, kann ich nur unterstreichen.
Aus meiner Erfahrung heraus gibt es natürlich immer wieder Punkte,
an denen man sich das Team anschauen muss.
Das Team und die Team-Zusammenstellung ist ja am Ende auch,
ich würde nicht sagen ein Tool,
aber hat schon diesen Charakter.
Und wenn ich merke, dass ein Team,
dass sich der Kontext geändert hat oder das Produkt
oder die Anforderungen geändert haben
und ich ein Team anpassen muss,
dann sollte ich es natürlich tun.
Und das ist ein ganz, ganz wichtiger Aspekt.
Und da kann man, glaube ich, nicht generell sagen,
mach es immer in diese Richtung.
Das ist tatsächlich kontextabhängig.
Genau, da kann man natürlich, wie du vorhin gesagt hast,
mit Teilzeit-Mitarbeitern, die vielleicht in dem Team
nur zeitweise mit unterstützen oder anderen Maßnahmen
genauso arbeiten wie halt die disruptiveren Themen,
wie komplette neue Teams aufsetzen.
Ja, und in der Hinsicht, glaube ich, ist auch tatsächlich
noch mal zu erwähnen die Gedanken,
die insbesondere zum Beispiel in diesem Buch
Team Topologies rauskamen.
Dass man eben eine Teamstruktur
und auch eine darunter liegende Architektur
nicht als etwas Statisches ansieht,
sondern als etwas, was sich ganz natürlich weiterentwickelt.
Und dass man dem einfach Rechnung trägt und einfach mal beobachtet,
welche Kommunikationsflüsse finden denn jetzt ganz real statt?
Welche Leute reden denn miteinander oder reden nicht miteinander?
Und ist das, was ich da wahrnehme, überhaupt das, was ich wünsche?
Das, was ich für erfolgversprechend halte?
Wie ist das denn dann eigentlich? Da bin ich neugierig.
Wenn jetzt zum Beispiel ein Peter in ein,
ich sag jetzt mal, klassisches Unternehmen geht,
die haben irgendwie eine eingespielte IT-Betriebsmannschaft
und jetzt kommt er irgendwie in die Geschäftsleistung
und sagt, hier, da ist der Peter und ihr bringt euch jetzt DevOps bei
und alles wird neu und besser. Läuft das so?
Ne, typischerweise läuft es nicht ganz so.
Das Thema alles wird neu und besser,
das muss man dann schon noch mal ein Stück tiefer legen.
Was natürlich enorm wichtig ist,
gerade wenn ich von ganz unterschiedlichen Menschen
in unterschiedlichen Bereichen,
wenn ich will, dass die zusammen etwas erreichen,
dann ist es meiner Meinung nach super, super wichtig,
dass ich den gemeinsamen Sinnstifter finde.
Also das ist dann vielleicht sogar der CIO
oder ein Abteilungsleiter, wo mehrere Teams drunter sind
und er auch eine klare Vision vermittelt.
Er klar sagt, warum brauchen wir das eigentlich?
Damit erstmal ein Bewusstsein da ist,
wozu soll denn diese Veränderung führen?
Und dann die Menschen mitzunehmen,
dass sie selber auch den Wunsch verspüren für diese Veränderung,
auch merken, was ist da für mich mit drin?
Und dann fangen wir an, Wissen zu vermitteln
und Dinge zu verändern.
Das ist der typische Weg.
Und tatsächlich einer der wichtigsten initialen Schritte,
initialen Punkte ist eben diese Vision
und das Buy-in vom gemeinsamen Sinnstifter.
Denn so eine Veränderung, so groß wie sie denn auch sein mag,
ist natürlich auch mit viel Unsicherheit behaftet.
Und dort hilft natürlich eine klare Vision.
Das ist meiner Meinung nach
einer der wirkmächtigsten Instrumente,
um so eine Veränderung ins Rollen zu bekommen.
Ja, zumal,
um da mal eine Lanze für altgediente Betriebler zu brechen,
es mir auch in DevOps-Trainings dann oft so gegangen ist,
dass die dann gesagt haben,
naja, das machen wir eigentlich schon lange so.
Oder wir haben es jedenfalls so gemacht,
bis sie es uns verboten haben.
Und jetzt dürfen wir endlich wieder so,
wie wir schon lange wollen und können.
Ja, auch so in der Zwischenzeit
sind Organisationsgrenzen dazwischengezogen worden.
Irgendwas ist outgesourced worden.
In, keine Ahnung, Osteuropa, Indien und Co.
sind ja da meist Kandidaten, wo man dann so was findet,
Betriebsteams oder Supportteams
oder gegebenenfalls sogar ganz andere Bereiche.
Selbst die Entwicklung wird da teilweise outgesourced
und dann halt in Tochterunternehmen
oder Unterauftragnehmer und ähnliches gepackt.
Da hat man natürlich dann einen höheren Aufwand,
das wieder zurückzurollen,
um wirklich cross-funktionales Miteinander hinzubekommen.
Ja, richtig.
Diese Fragmentierung ist natürlich ein großes Problem,
insbesondere, wenn da ja die Ziele oft sehr unterschiedlich sind.
Die Entwickler werden für Veränderungen bezahlt,
und die Betriebsmannschaft wird für Stabilität und Sicherheit bezahlt.
Das widerspricht sich natürlich.
Und dementsprechend muss ich natürlich agieren.
Das ist dann wieder das Thema gemeinsame Regeln.
Das, was du, Luca, ansprichst, erlebe ich verhältnismäßig häufig.
Also gerade die, die sich mit dem Mainframe, den Hosts beschäftigen,
die kommen ganz oft mit dem Thema und sagen,
ja, vor 40 Jahren hatten wir das schon mal.
Jetzt kommt ihr damit wieder ums Eck.
Verrückterweise sind das aber auch oft die,
die als die Dinosaurier gesehen werden
und die, die anscheinend in den Widerstand gehen.
Tatsächlich, wenn man jemandem mit denen arbeiten würde
oder ihnen wirklich zuhören würde, würde er feststellen,
dass die, was Automatisierung angeht, unglaublich weit sind.
Natürlich, die gesamte Dunkelverarbeitung passiert vollautomatisiert.
Also tatsächlich könnte man sich dort auch die Kompetenzen zunutze machen
und von ihnen lernen.
Also ich breche auch gern, wie ihr merkt,
gerne eine Lanze für den Betrieb und auch für die Infrastruktur.
Zumal sie viele Dinge auch verantworten.
Sie verantworten typischerweise auch so Themen wie Netzwerk und Security.
Und wir kennen das. Es gibt ein Problem.
Na ja, dann als erstes sagt man, das ist das Netzwerk.
Das ist einfach.
Das ist intransparent.
Man weiß nicht genau, was da passiert.
Also wird schon das Netzwerk sein.
Und das macht natürlich was mit den Teams.
Ich war selber am Anfang meiner IT Firewall-Administrator,
Content Scanner, solche Dinge.
Und nie ruft jemand an und sagt, hey, die Firewall funktioniert heute wieder ganz toll.
Und sie blockt auch alles ganz toll.
Vielen Dank für deine Arbeit.
Man wird nur angerufen, wenn etwas nicht funktioniert.
Und das macht natürlich was mit einem.
Man hat den Eindruck, da draußen funktioniert nie etwas.
Und ganz oft bin es ich und meine Firewall.
Und das ist eben auch ein Thema von gegenseitigem Verständnis.
Einfach mal in alle Köpfe reinzubekommen.
Die Firewall soll Dinge blocken.
Und wenn sie das tut, ist das genau richtig.
Einfach mal Danke sagen.
Zum einen Danke sagen und zum anderen frühzeitig Bescheid geben,
wenn man eine neue Anwendung hat.
Und neue Firewall-Regeln braucht.
Zumal ja diejenigen, denn auch diejenigen sind, die geprüft werden,
ob die Policies alle so passen, ob alles dokumentiert ist.
All das ist ja in diesem Umfeld, in dem wir eigentlich sehr schnelle Durchlaufzeiten haben wollen,
ein wichtiger Aspekt.
Wie kann ich das denn erreichen und trotzdem die regulatorischen Anforderungen noch umsetzen?
Und da hilft miteinander reden und gemeinsam Lösungen finden.
Ja, genau.
Zum Beispiel auch nicht den armen Betrieb dann erstens mal immer die Rolle des Kontrolleurs aufs Auge drücken
und auch die Rolle des irgendwie undankbaren Neinsagers.
Sondern das vielleicht einfach schon weiter nach links schieben und sagen,
das gehört in unsere Definition of Done mit rein.
Wenn wir Firewall-Regeländerungen brauchen,
dann müssen wir erstmal für uns geschaut haben, ob das Hand und Fuß hat.
Und vielleicht holen wir uns halt auch zum Beispiel einen Firewall-Menschen mit ins Boot,
dass der bei Zeiten schon mal drüber schaut und direkt sagt, oh Jungs, so wird das nichts.
Genau.
Entweder das, zeitweise vielleicht sogar jemanden mit dem Team mitlaufen lassen,
punktuell zu Workshops mit dazu holen.
Gegebenenfalls aber auch die Chance nutzen, in Richtung Automatisierung zu denken.
Und zwar zu überlegen, vielleicht ist das ja nicht nur einmalig,
sondern macht man halt regelmäßig.
Und dann entsprechend zu schauen, was kann man tun, damit man eben,
wenn, keine Ahnung, eine neue virtuelle Maschine ist,
die ins Netzwerk kommt, da nicht jedes Mal jemand aus dem Netzwerk
oder Security-Team hinzugezogen werden muss,
sondern dass man halt Regeln schafft,
sind wir wieder bei Regeln, schöner Hinweis,
Regeln schafft, die man auch als Grundlage für eine Automatisierung nutzen kann,
um eben das zu verkürzen.
Auch da dann sich wiederholende Tätigkeiten so weit weg zu automatisieren,
dass es entspannt und rund läuft.
Wie sagt man so schön?
Anders, was man mehr als zweimal tut, sind gute Kandidaten für Automatisierung.
Genau, automate everything you can.
Na klar, warum ist eigentlich die Anforderung für ein neues Objekt
in der Regelbasis nicht im Git mit drin?
Damit habe ich eine Versionskontrolle,
ich kann vielleicht auch den Prüfer zufriedenstellen damit.
Das ist aber auch ein heißes Eisen.
Also ich kenne auch so Situationen, da kommt dann jemand und sagt,
hey du Firewall-Administrator, ich will die Firewall automatisieren.
Damit erreicht man manchmal auch nur mit Mühe und Not die Ausgangstür.
Natürlich muss, wenn der Firewall-Administrator die Verantwortung hat,
dann muss er natürlich auch die Hoheit über die Regeln haben.
Aber wie du schon angesprochen hast,
vielleicht gibt es ja Regeln und ich muss nur Objekte hinzufügen.
Und das muss in der Zusammenarbeit mit den Firewall-Administratoren gelöst werden,
weil die haben letztendlich auch die,
auch die Verantwortung und sind auch rechenschaftspflichtig.
Tatsächlich ist meine Erfahrung, wenn man aufeinander zugeht,
wenn man miteinander redet, dann gibt es typischerweise Lösungen,
sodass wir dann nicht in einer Situation sind,
dass man ein Deployment von Wochen auf Minuten herunterbekommen hat
und dann braucht man halt nochmal eine Woche für eine Firewall-Regel.
Und bloß um das nochmal zu sagen, bloß weil jemand die Hoheit hat,
heißt das ja nicht, dass er erst am Schluss drauf schauen darf.
Oder bloß weil jemand die Verantwortung hat,
sondern wäre es nicht toll, wenn man ihn direkt von vornherein einladen würde,
so wie es der Falco vorhin schon gesagt hat,
dass wenn das Ding fertig ist, alle schon wissen, das wird auch funktionieren.
Genau so ist es.
Also ein anderes gutes Beispiel im Security-Kontext ist das Thema Betriebssystem-Hardening.
Wie schaffe ich eigentlich ein Hardening?
Und wie schaffe ich auch notwendige für Applikationen, notwendige Ausnahmen eines Hardenings zu automatisieren?
Und auch in Reports zu gießen, um den Prüfer zufriedenzustellen?
Auch das ist tatsächlich machbar und bedarf halt der Zusammenarbeit der unterschiedlichen Spezialisten.
Das sind doch einige DevSecOps-Themen, die wir jetzt gerade so am Wickel haben.
Finde ich gut, dass man das Thema auch bei uns im Podcast im Fokus mitbekommt,
weil es ist ja ein recht verbreiteter Punkt.
Den man an vielen Stellen wiederfindet, sei es im Scaled Agile Framework,
dass da Security auch einen höheren Wert bekommt und mit im Fokus steht
oder an vielen anderen Stellen genauso.
Wenn man das miteinander in der Zusammenarbeit mit unterbringen kann, umso besser.
Also für mich war das nie verstehbar, warum das Thema Security,
manche sagen ja DevSecOps und BuzzDevSecOps,
warum das extra betont werden muss.
Ich meine mal ganz ehrlich, heutzutage das Thema Security nicht mit zu fokussieren,
ist absolut sträflich.
Und egal wie eine IT-Produktion läuft, ob super klassisch oder mit DevOps-Methoden,
Security muss ein ganz starker Fokus sein und mit berücksichtigt werden,
voll umfänglich umgesetzt werden.
Das steht doch außer Frage.
Was ist an spannenden Dingen,
mit Peter zu reden gibt,
dass er sich großzügigerweise bereit erklärt hat,
mit uns noch einen zweiten Teil aufzunehmen.
Insofern betrachtet das mal als die erste Folge eines zweiteiligen Gesprächs mit Peter Lange.
Wir haben ja vorhin gesagt, alles was man öfter als zweimal macht, sollte man wegautomatisieren,
aber wir belassen es bei zweimal.
Insofern ist es glaube ich okay, wenn wir uns unterhalten.
Insofern Peter, bis hierhin ganz vielen Dank für die interessanten Sachen,
die du uns erzählt hast und über die wir gesprochen haben.
Und ich freue mich schon auf den zweiten Teil.
Genau. Bis dann. Ciao.
Na dann, bis zum nächsten Mal.
Auch von meiner Seite herzlichen Dank für die Einladung.
Hat mich gefreut.
Ich freue mich auch auf den nächsten Teil.
Tschüss.