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.