DevOps in der Praxis: Wie wird DevOps bei einem der größten Rückversicherer der Welt umgesetzt? Wir haben Tobias Weinmann zu Gast im Podcast.
Inhalt
- Vorstellung von Tobias Weinmann und seiner Rolle bei Swiss Re
- Definition und Bedeutung von DevOps-Transformation
- Die „Three Ways“ im DevOps-Kontext: Flow, Feedback, und kontinuierliches Lernen
- Einsatz und Herausforderungen von Cloud-Technologien bei Swiss Re
- Der Ansatz von Swiss Re zur DevOps-Transformation, inklusive Bottom-Up und Top-Down Strategien
- Konkrete Beispiele für DevOps-Initiativen: Value Stream Mapping, Lean Change Management, Minimal Viable Processes
- Diskussion über die Rolle von Technologie und Kultur in der DevOps-Transformation
- Der Umgang mit Legacy-Systemen und neuen Applikationen im Kontext von DevOps
- Die Rolle der Cloud im DevOps-Ansatz von Swiss Re
- DevOps als Balance zwischen IT-Service-Management, Lean-Management und agilem Vorgehen
- Gesamtbild der DevOps-Reise bei Swiss Re
Shownotes
- DevOps-Transformation bei Swiss Re
- „The Phoenix Project“ Buch (https://itrevolution.com/book/the-phoenix-project/)
- „DevOps Handbook“ Buch (https://itrevolution.com/book/the-devops-handbook/)
- Swiss Re Unternehmen (https://www.swissre.com/)
- Definition und Prinzipien von DevOps
- Agile Methoden und Scrum
- Cloud-Technologien in der Versicherungsbranche
- IT-Service-Management
- Lean-Management
- Minimal Viable Architecture und Prozesse
- Datenbankmanagement und Automatisierung
- Continuous Integration und Continuous Deployment (CI/CD)
- Value Stream Mapping
- Lean Change Management
Transkript (automatisiert, daher keine Gewähr 🙂 )
DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Hallo und herzlich willkommen zum DevOps-Podcast auf die Ohren und ins Hirn.
Ich begrüße Sie. Mein Name ist Dirk Söllner.
Wir haben hier heute zu Gast den Tobias, der von der Swiss Re sich gleich vorstellen wird,
wenn ich sage, wir ist das Alex Lichtenberger, mit dem ich gemeinsam diesen Podcast erstelle.
Also insofern würde ich sagen, Tobias, stell dich doch einfach mal bitte kurz vor.
Ja, hallo. Mein Name ist Tobias Weinmann.
Wie Dirk schon gesagt hat, ich arbeite für einen der größten Rückversicherer weltweit bei der Swiss Re.
Und ich habe dort die ehrenvolle Aufgabe, mich Vollzeit dem Thema DevOps zu widmen,
was ich seit ein bisschen mehr als einem Jahr jetzt mache und befinde mich dort auf einer sehr spannenden Reise.
Oder wir als Unternehmen befinden uns dort auf einer sehr spannenden Reise.
Ein bisschen zu meinem Hintergrund.
Ich bin schon sehr lange bei der Swiss Re, habe einige Sachen gesehen.
Ich habe in der Entwicklung, Softwareentwicklung angefangen und hatte dann,
von diversen Verantwortlichkeiten auch im betrieblichen Umfeld,
war unter anderem verantwortlich für die ganzen Entwicklungsplattformen, Versionskontrollsysteme, CICD-Systeme und so weiter.
Und ja, bin jetzt, wie gesagt, dort gelandet, DevOps Transformation Lead in einer vergleichsweise großen IT-Organisation.
Und vielen Dank, Tobias. Herzlich willkommen auch von meiner Seite.
Mein Name ist Alex Lichtenberger.
Vorstellen muss ich mich, glaube ich, nicht mehr.
Heute haben wir ja das Thema DevOps Transformation bei der Swiss Re.
Das heisst, ein Praxisbeispiel aus der Unternehmenswelt.
Und ja, bevor wir da reingehen, wir haben ja immer zu diesem Running Gag oder die Standardfrage an unsere Gäste,
dieses Mal auch an dich, Tobias.
Was verstehst du unter DevOps Transformation?
Unter DevOps, kann man das überhaupt definieren, oder wie würdest du das definieren?
Ich versuche es mal mit nur zwei Worten.
Nachhaltige Geschwindigkeit.
Also nicht Geschwindigkeit oder Schnelligkeit um jeden Preis, sondern,
und auch nicht sicher und stabil, egal wie lange es dauert, sondern eben beides zusammen.
Also für mich ist DevOps eigentlich ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oftmals für mich ist es ein Optimieren für die Geschwindigkeit.
Oft Janeiro.
Wird es auch mit der Idee assoziiert, Optimierungen für Kosten?
Wird es auch mit der Idee assoziiert, Optimierungen für Kosten?
Sehe ich aber nicht so.
Ich sehe wirklich Optimierungen für der Geschwindigkeit.
Aber halt nicht um den Preis von Qualität, Sicherheit und Compliance.
Und wenn ich noch ein bisschen weiter ausholen darf.
Also ich sehe, also den Startpunkt, wie muss auch so in der Lektüre viel sieht wirklich auf diesem Cor.
Country Konflikt.
Also wenn man mal die Top-Prioritäten aus IT-Executive-Sicht anschaut,
es ist natürlich Rapid Change, also wir wollen eigentlich schnelle Veränderung,
aber gleichzeitig wollen wir Stabilität, Zuverlässigkeit, Sicherheit und so weiter.
Also so die funktionalen und nicht-funktionalen Aspekte.
Und jetzt ist es aber typischerweise so, dass halt die Leute, also Teile der Organisation,
sich eher in diese Richtung Rapid Change orientieren
und andere Teile in der Organisation Richtung Stabilität, Zuverlässigkeit und Sicherheit.
Und wenn halt nicht da alle wirklich an einem Strang ziehen,
findet man sich möglicherweise dann halt in so einer Abwärtsspirale,
die ja auch oft beschrieben wird in einem DevOps-Kontext.
Also man macht dann tatsächlich die schnelle Veränderung,
aber die Systeme werden eben nicht stabiler und zuverlässiger und sicherer,
sondern das Gegenteil ist der Fall.
Und dann werden oft die Kontrollen hochgefahren
und im Endeffekt wird man eigentlich langsamer und nicht schneller,
wenn man nicht die Sachen wirklich konsequent gemeinsam adressiert.
Und wenn man auf die Three Ways schaut, für all die,
die das Phoenix Project oder das DevOps Handbook gelesen haben,
das sind für mich auch sehr zentrale Themen.
Also der erste Weg.
Die Principles of Flow oder auch anders gesagt,
die systemische Sicht, Systems Thinking.
Da geht es natürlich um Sachen wie Limit, Work in Progress oder Release Cadence.
Aber für mich ist da wirklich ein zentrales Thema,
auch mit Silos zu brechen und wirklich zu schauen,
dass sich halt alle an einem schnellen Fluss orientieren.
Also dass man wirklich auch sagt,
Sicherheit oder Compliance sind wichtige Themen,
aber nicht zu jedem Preis.
Also nicht Hauptsache sicher, egal wie lang es geht,
sondern der Fluss muss wirklich gewährleistet sein.
Und der zweite Weg, Principles of Feedback.
Da geht es ja darum, dass man möglichst schnell eigentlich Feedback gibt,
bei allem, was man tut, dass möglichst früh die Rückmeldung passiert.
Also Negativbeispiel.
Man merkt erst, dass ein Produktionssystem nicht mehr funktioniert,
wenn der User halt anruft und sagt, da tut was nicht.
Also das möglichst früh bekommendes Feedback.
Und darunter liegt für mich eigentlich die Idee,
dass man ein möglichst sicheres Environment schafft.
Also ein Environment, wo man schnell Änderungen machen kann,
ohne Angst zu haben, dass irgendwas zerbricht
und nachher nicht mehr funktioniert.
Und der dritte Weg, Third Way,
Continued Learning and Experimentation,
ist für mich wahrscheinlich der zentralste Punkt,
bei DevOps, weil ich glaube, dass wir uns in einem Environment bewegen,
das zunehmend komplex wird, wo wir uns immer schneller bewegen
und wo es eine gewisse Unsicherheit gibt.
Was meine ich damit?
Cloud ist ein Riesenthema bei uns, bei der Swiss Re,
aber auch, würde ich sagen, überall in der Industrie.
Und Cloud bietet viele Möglichkeiten, aber es macht gleichzeitig die Systeme
auch komplexer, weil sie halt verteilter werden.
Wenn wir uns Microservices-Architekturen zum Beispiel anschauen,
da gibt es viele Möglichkeiten, aber es gibt auch viele neue Herausforderungen.
Und die Unsicherheit, die ich erwähnt habe,
die bezieht sich sowohl auf das technologische Umfeld
als auch auf das Business-Umfeld.
Dort muss man auch eben flexibler sein.
Man muss sich möglichst schnell den neuen Gegebenheiten anschauen.
Man muss sich ganz schnell anpassen können.
Jetzt habe ich ein bisschen weit ausgeholt.
Um noch einfach zu sagen, wie wir DevOps interpretieren,
da ist ganz wichtig, dass wir es halt als ganzheitliches Konzept sehen.
Also wir versuchen uns immer entlang den Dimensionen
Culture, People, Process und Technology zu bewegen.
Da gibt es auch ein paar interessante Sichtweisen.
Oftmals ist es halt so, dass man es ein bisschen zu einseitig betrachtet.
Dass man sich zu sehr auf die Technologie konzentriert
oder vielleicht zu sehr nur auf den kulturellen Aspekt.
Man sollte wirklich versuchen,
es ist unsere oder meine Meinung,
halt wirklich entlang all dieser vier Dimensionen zu gehen.
Danke, das fand ich eine sehr spannende Beschreibung.
Also was ich herausgehört habe,
also Ziel nachhaltiger Geschwindigkeit,
dann die Umsetzung über die Three Ways
und dann eben, dass ihr auch,
weil viele sehen ja DevOps nur als Tool-Angelegenheit,
dass du eigentlich sagst,
schlussendlich müssen alle Bereiche stimmen,
People, Process, Technology.
Und was jetzt auch,
ein bisschen hast du es schon angetönt,
das Warum, du hast es ein bisschen erwähnt,
Cloud ist wichtig bei euch
und dass sich die Änderung,
also immer mehr Änderungswünsche.
Und die Frage wäre jetzt,
wenn wir so den Link noch mehr zur Swiss Re machen,
was waren dann für euch schlussendlich
die Treiber, oder dass eine IT der Swiss Re gesagt hat,
okay, wir möchten jetzt uns Richtung DevOps bewegen.
Tobias.
Also ein Treiber ist sicherlich die Agilität,
also sich möglichst schnell verändernden Voraussetzungen
anpassen zu können.
Und in dem Zuge halt auch neue Ideen auszuprobieren,
möglichst schnell,
und die dann auch möglichst schnell wieder verwerfen,
so sie sich dann als falsch,
oder als nicht richtiger Pfad rausstellen.
Und dann haben wir,
also wir sind wie gesagt im Rückversicherungsgeschäft tätig.
Wir haben nicht jetzt,
wir haben zwar auch Consumer Exposure,
aber das ist nicht so wesentlich.
Wir arbeiten eigentlich mehr im B2B Umfeld.
Aber unsere Kunden,
also zum Beispiel Erstversicherer,
oder größere Unternehmen,
die sind natürlich viel stärker,
oder sind auch sehr stark,
oder noch stärker als wir,
in dieser digitalen Transformation.
Dort ist der Druck viel größer,
und die Veränderung findet statt.
Und wir müssen da mitgehen.
Also wir wollen eigentlich dann stetig dort am Ball bleiben.
Und gleichzeitig eben auch neue Ideen direkt an den Markt bringen.
Also vielleicht auch dann direkt wirklich im B2C Business
noch mehr Fuß fassen.
Das ist bei uns im Moment noch eher kleiner.
Und was halt bei uns intern,
um den Weg gehen zu können,
organisieren wir uns auch neu innerhalb der IT
und auch über die IT hinaus.
Also das IT wächst eigentlich näher ans Business ran.
Wir gehen weg von Shared-Funktionen.
Also wir hatten eine sehr dicke Shared-Infrastruktur-Organisation,
die jetzt eigentlich,
wo wir uns immer mehr zu einem föderierten Ansatz entwickeln,
weil ich die, wir sagen den Business-Domain ITs,
also die IT-Organisationen,
die den entsprechenden Business-Domains zugeordnet sind,
wo die wirklich End-to-End-Verantwortung
für den Betrieb von den IT-Lösungen übernehmen.
Und um das zu ermöglichen,
müssen wir eigentlich DevOps-Prinzipien umsetzen im Unternehmen.
Okay, du hast eben davon gesprochen,
Transformation Lead,
auf dem Weg digitaler Transformation.
Habt ihr ein Ziel?
Wie weit seid ihr?
Seid ihr schon fertig?
Kannst du da mal ein bisschen was zu sagen?
Also fertig sind wir sicher noch nicht.
Und ich persönlich bin halt auch immer,
ich sage, die Leute,
die schon mutmaßlich ein ziemlich komplettes Bild von dem Ganzen haben,
die challenge ich eigentlich immer.
Weil ich sage, wir können das noch gar nicht so genau sagen,
wie das denn in einem Zeithorizont von ein bis zwei, drei Jahren aussieht.
Oder?
Weil das alles in Bewegung ist
und wir auch noch sehr viel lernen müssen, oder?
Also wir können, die Zeit ist einfach nicht die,
dass wir jetzt sagen können, es ist alles schon klar.
Wir müssen nur das und das und das machen
und dann sind wir genau dort, wo wir hinwollen.
Also von dem her, um deine Frage zu beantworten,
wir sind mittendrin und wir wissen,
dass es noch eine geraume Zeit so weitergehen wird
und dass auch eben diese hohe Geschwindigkeit an Veränderungen,
die wird mehr zum Alltag.
Also wir werden uns mehr in diesen Schnellwechselmodus gewöhnen,
als dass wir dann irgendwann sagen, jetzt sind wir fertig mit dem,
wann kommt die nächste große Transformation?
Wie reagiert denn das Business da drauf?
Weil ich häufig, wenn ich in Scrum-Trainings bin
und auch in den Projekten drin bin,
man ja der IT vorwirft, dass sie nicht liefert,
dass sie keinen Ziegel hat
und letzten Endes ist ja das genau,
was ich bei dir raushöre,
aktuell der Fall.
Zumindestens könnte man euch vorwerfen,
ihr wisst gar nicht, wann ihr fertig seid.
Insofern wieder mal planlos.
Naja, das kommt dann auch drauf an,
auf was man das jetzt anwendet, diese Aussage.
Also digitale Transformation, glaube ich,
sind wir uns einig, das geht ja durch das ganze Unternehmen.
Das ist ja nicht nur ein IT-Thema.
Und ich gebe dir schon recht,
also es ist nicht so jetzt unbedingt,
dass das Business jetzt sagt,
jetzt lass uns hier das zusammen machen
und jetzt wissen wir schon genau, wo es hingeht,
sondern ich habe da oft das Beispiel mit dem,
wenn es darum geht, jetzt gerade wieder in einem DevOps-Kontext zu sagen,
hey, lass uns doch mal die Release-Cadence erhöhen.
Lass uns doch mal nicht Quarterly-Releases machen,
sondern jeden Monat oder alle zwei Wochen
oder wenn es geht, noch öfters.
Und oft ist halt eine Reaktion auf der Business-Seite dann,
ja, eigentlich wollen wir eher weniger Releases,
weil Release bedeutet für uns eigentlich Aufwand.
Also wir müssen dann irgendwie,
werden dann zum User-Acceptance-Test eingeladen,
müssen vielleicht noch eine Ausbildung machen
und dann, wenn es übers Wochenende,
dann braucht es ein ganzes Wochenende,
um das Deployment zu machen
und am Montagmorgen gibt es dann wieder Probleme.
Also Bottom-Line-Release wird assoziiert mit Arbeit, Aufwand und Problemen.
Und da, das ist auch ein Teil meiner Aufwand,
meine Aufgabe halt auch zu erklären,
dass mittelfristig eigentlich eine höhere Release-Cadence bedeutet,
dass die Releases kleiner werden, weniger spürbar,
weniger Risiko mit sich bringen
und dann eben sich nicht so anfühlen,
wie sich jetzt so ein Quarterly-Release anfühlt,
wo man dann das Gefühl hat,
hey, ich möchte es eigentlich eher weniger als mehr machen,
sondern dass es sich eher so anfühlt,
es wäre dann ein Zielbild,
wie ich eigentlich Releases auf einem Mobile-Device wahrnehme, oder?
Ich nehme da immer mich als Beispiel.
Am Anfang auch gesagt,
ja, hm, das verschiebe ich mal lieber,
bevor ich da irgendwie das Knöpfchen drücke
auf meinem Mobile-Device,
um das Upgrade machen,
aber mittlerweile ist das ja was,
wo man quasi automatisch macht
und wirklich im laufenden Betrieb,
weil man weiß,
die Applikation verändert sich nicht fundamental
von einem Release zum anderen.
Also jetzt nur eine Anekdote,
ein Beispiel,
aber das ist eben auch das,
wo zustimmen,
ja, das Business und die IT
muss da noch mehr zusammenwachsen,
aber das ist eben auch ein Teil,
ein Bereich, wo DevOps helfen kann.
Aber zeigt auch,
dass ein Teil deiner Arbeit ist ja auch,
dann mit den Leuten sprechen,
mit den Stakeholdern sprechen
und aufzeigen, was DevOps bedeutet
und das bei ihnen zu bekommen.
Genau.
Ja, und wenn wir jetzt
über die DevOps-Transformation
bei der Swiss Re sprechen,
also wie,
also du hast erklärt, schön,
die Treiber auch.
Warum ist das überhaupt ein Thema
bei einer Swiss Re?
Bei euch ist es natürlich anders
wie jetzt bei anderen Unternehmen,
weil es ist ein Business-to-Business-Umfeld
und ihr habt aber auch,
sagen wir, die interne IT-Perspektive,
sagen wir mal,
ein bisschen weg von,
sagen wir, dem Shared Service,
sondern mehr im federalistischen Ansatz.
Und jetzt von der Transformation her,
wie seid ihr da vorgegangen?
Oder wie,
deine Aufgabe ist ja,
die Transformation vorwärts zu treiben
innerhalb der IT.
Wie geht ihr das an?
Also angefangen haben wir eigentlich,
und es hat immer noch den Charakter
eher mit einem Bottom-up-Ansatz,
also dass wir wirklich an der Basis anfangen,
auch anhand von kleinen Beispielen
und das dann wirklich Bottom-up
in die Organisation versuchen reinzutragen.
Und jetzt, als ich angefangen habe
vor einem Jahr,
da hat eigentlich,
hat man, sage ich mal,
auf Executive-Ebene noch nicht so prominent
über DevOps geredet.
Das wird auch heute noch nicht so jetzt
ganz riesengroß geschrieben im Sinne von,
wir haben jetzt eine riesen DevOps-Strategie,
obgleich jeder Einzelne im Executive-Team
natürlich weiß, was DevOps ist
und das auch unterstützt und weiterbringen möchte.
Ich sage da oft,
wir haben so eine Art Sandwich-Situation eigentlich.
Also wir bringen das von unten nach oben
anhand von wirklich konkreten Beispielen.
Und es hat aber auch den Executive-Bein und Support.
Also ihr bringt, sagen wir,
von unten nach oben mit konkreten Beispielen,
aber gleichzeitig auch so mit Top-Down
oder das Management-Commitment zu bekommen.
Wenn wir jetzt so von unten nach oben,
also da, was habt ihr da konkret?
Gibt es da ein paar Beispiele,
was ihr so gemacht habt?
Ja, also da kann ich gerne ein paar Beispiele bringen.
Also wir haben ganz am Anfang haben wir,
und das machen wir auch bis jetzt noch,
wir haben mit Value-Stream-Mappings angefangen,
wo wir wirklich Leute aus der Infrastruktur,
Shared-Infrastruktur, aus dem Bereich IT-Audit,
Governance-Compliance und natürlich
aus der Applikationsseite zusammengebracht haben
und dann wirklich mal den Technology-Value-Stream
also Change-Inception, also von der Idee bis hin zu Change
wirklich verfügbar in Produktion,
den ganzen Ablauf angeschaut und analysiert haben
und daraus dann abgeleitet wirklich kleinere Verbesserungsansätze.
Das kann oftmals sein,
dass einzelne Schritte einfach weggestrichen werden,
weil man sieht, wenn man dann auf das Ganze mal schaut,
ja, die braucht es eigentlich gar nicht.
Oder halt auch Verbesserungen im Sinne von Automatisierung,
im Sinne von Automation oder APIs zu den Infrastruktur-Plattformen,
dass man wirklich dann die Automation in einem Pipeline,
CICD-Pipeline-Kontext umsetzen kann.
Typischerweise und so auch bei uns ist das halt oft
so eine zusammengestöpselte Toolchain aus verschiedenen Systemen,
wo dann oftmals halt auch Portale oder User-Interfaces involviert sind,
wo es halt schwierig ist,
so einen ganzen End-to-End-Ablauf wirklich zu automatisieren.
Also wir haben das gemacht mit verschiedenen Business Domain ITs
und das Schöne war, dass sich dann wie ein gemeinsamer Backlog entwickelt hat,
wo wir uns halt, wo wir jetzt uns durcharbeiten sukzessive.
Was wir auch gemacht haben, ist dann, wir haben das Flash Builds genannt,
weil wir so ein bisschen, sag ich mal, an vielen Orten,
auch speziell ein bisschen in der Infrastruktur,
dort plant man traditionell ein bisschen in größeren Zyklen, oder?
Weil dort halt auch viele Investments gemacht werden,
wenn man neue Hardware kaufen muss,
obgleich wir auch unsere Datacenters runterfahren.
Aber dass wir wirklich ein bisschen mit dieser langen oder, ja,
Monate- bis Halbjahresplanung brechen konnten,
haben wir dann Flash Builds gemacht.
Also wirklich so, was können wir erreichen innerhalb von einer Woche,
um wirklich ein bisschen auch aus dieser, ja, dadurch, dass wir,
ich habe dem Analysis Paralysis gesagt, oder?
Weil wir dadurch, dass halt oftmals die Investments so groß sind
in technische Lösungen, in Enterprise-technische Lösungen,
dass man sich dann wirklich ewig lang hin und her überlegt
und mit allem, mit jedem redet und schaut,
was könnte denn jetzt die beste Lösung sein,
weil man natürlich nicht ein großes Investment machen möchte,
ohne sich ganz sicher zu sein.
Mit dem zu brechen und mal was wirklich Kleines anzufangen.
Und wir haben das dann Minimal Viable Architecture genannt.
Also wir haben da in dem Fall jetzt wirklich mit einem ganz einfachen
Cloud-Native-Muster angefangen.
Wir haben eigentlich ein Open-Source-API-Gateway genommen,
haben dann mit eine Microservices-Architektur implementiert,
auf Basis von Docker.
Und das war es eigentlich, wo wir dann wirklich die Leute drum herum
konzentriert haben und so einen gemeinsamen Arbeits-Context
geschaffen haben.
Und auf Basis von dem, was dabei rausgekommen ist,
haben wir dann wirklich weitergearbeitet.
Also mittlerweile sind die Technologie-Bausteine,
die da entstanden sind, in einem höheren Reifegrad.
Also wir arbeiten uns da jetzt sukzessive vor.
Und ein anderes Beispiel, mehr so aus der Prozess-Ecke,
läuft bei mir so unter dem Überbegriff Lean-Change-Management.
Ist ja sehr interessant für Leute mit einem IT-Service-Management-Programm,
die Service-Management-Background.
Also dort haben wir halt den Prozess für Change-Release-Deployment
angeschaut.
Der ist bei uns im Wesentlichen über ServiceNow implementiert.
Und haben dann festgestellt, wenig überraschend, dass das halt
mit so einer hohen Release-Cadence, mit CI-CD und so weiter,
nicht kompatibel ist.
Und haben dann uns auch zusammengesetzt mit den Haupt-Stakeholders,
also mit den Applikationsleuten, mit Leuten von IT-Audit
und mit den Prozess-Ownern von den jeweiligen Prozessen
und haben dann einen Minimal Viable Process definiert.
Und das war eigentlich ganz interessant, weil was wir da gesehen haben ist,
und ich habe das Delegation of Concern genannt,
das ist nicht zu verwechseln mit dem schönen Software-Design-Pattern,
Segregation of Concern, sondern was ich gesehen habe,
ist so, es gibt einen Prozess-Owner für den Change-Release-Deployment-Prozess.
Der redet mit den Leuten auf der Applikationsseite.
Die deponieren ihre Requirements.
Und er redet aber gleichermaßen auch mit den Leuten auf der Governance,
auf der IT-Audit-Seite.
Also es ist wie so eine Art Proxy.
Aber gleichzeitig, jetzt komme ich zu dem Punkt Delegation of Concerns,
die Leute auf der Governance-Compliance-Seite schmeißen so ihre Requirements,
da zum Process-Owner und auf der Applikationsseite genauso.
Und er steht dann so in der Mitte und muss da irgendwie eine Lösung finden.
Und der Schlüssel bei uns, was dann auch zu diesem Minimal Viable Process geführt hat,
war auch ein Value-Stream-Mapping, wo wir wirklich alle Leute an einen Tisch gebracht haben.
Und dadurch, dass eben auch die Leute auf der Applikationsseite direkt mit den Leuten
auf der IT-Audit-Seite geredet haben, hat sich wie ein neuer Solution-Space,
wo sich zusätzliche Optionen ergeben, die man sonst vielleicht gar nicht so einfach gesehen hätte.
Und ganz konkret, was wir gemacht haben dort ist,
wir haben zum Beispiel das eigentliche Change-Management angeschaut
und sind dann zu einem Schluss gekommen, dass nur weil es nicht in ServiceNow stattfindet,
heißt es nicht, dass es nicht stattfindet.
Es findet einfach in anderen Tools statt, bei uns mehrheitlich in Jira zum Beispiel.
Und wir haben uns dann darauf geeinigt, dass wenn der Product-Backlog und das Sprint-Planning,
also wenn wirklich vernünftig mit Jira gearbeitet wird, dass das ein implizites Change-Management ist
und das dann nicht mehr noch in einem separaten Tool nachgeführt werden muss.
Und das ist aber jetzt wohlgemerkt auch nur der Anfang, aber wir haben jetzt wirklich
eigentlich einen wesentlichen Schritt dahin gemacht, dass wir den Prozess wirklich entschlacken.
Und den Prozess mehr um die Continuous-Deployment-Pipeline oder Delivery-Pipeline orchestrieren und nicht umgekehrt.
Das waren ja ein paar schöne Beispiele, insbesondere dieses Minimal-Viable-Process-Architecture.
Finde ich ja eine ganz gute Übertragung dieser Prinzipien.
Und als du das eben so erzählt hast, habe ich mir gedacht, da ist mir die Frage hochgepoppt, wie würdest du das sehen?
Also ich sage immer, DevOps ist im Prinzip eine vernünftige Mischung zwischen IT-Service-Management, Lean-Management und agilem Vorgehen.
Wenn du das auch so siehst, meinst du, dass man da auch aus deiner Erfahrung heraus quasi so gewisse Prozentsätze verteilen kann?
Also im ersten Moment klang es bei dir sehr stark nach Lean, dann kam aber schon wieder auch Scrum mit dazu.
Also die Frage ist, kann man das irgendwie aufteilen und wie siehst du, wie sich DevOps aus klassischen, bisher bekannten Disziplinen zusammenfasst?
Also da, ich würde sicher da nicht mit irgendwelchen Prozentzahlen, würde ich mich sicher nicht festlegen.
Also da spielt alles ein bisschen mit rein und ich sage halt immer, das Wichtigste ist eigentlich der gesunde Menschenverstand.
Also man darf sich da nicht zu sehr auf die eine oder andere Weisheit oder Methodologie verlassen.
Ich glaube, man muss es immer individuell anschauen und dann entscheiden.
Das höre ich gerne.
Gesunder Menschenverstand hilft.
Das war jetzt schon ein bisschen eine sehr schweizerische Antwort.
Aber das mit dem gesunden Menschenverstand ist international, das muss man schon sagen.
Und du bist ja schon ein Weilchen in der Schweiz.
Genau, ja.
Und du hast jetzt schön, also es sind so drei Bereiche, so Value Stream, dann das mit dem Flash Build und dann Lean Change Management.
Aber immer was die drei Bereiche gemeinsam haben.
Also am Anfang gesagt, so statt Analysis, Paralysis, also statt zu Tode argumentieren, auch mal, einfach mal klein anfangen.
Aus dem, also so auch das Bein der Leute bekommen, aus dem raus wachsen, verbessern.
Und das ist ja auch so ein typischer Ansatz aus dem Lean.
Also man macht einen Value Stream, mal End-to-End verstehen von der, du hast auch schön gesagt, von der Inception bis zum Rollout.
Man hat auch schön den Three Ways.
Man hat ja, die Leute haben ein gemeinsames Verständnis, wie arbeiten wir zusammen.
Aus dem verbessert man dann Schritt für Schritt.
Und das ist ja so stark, auch im Moment ist es noch ein Bottom-Up Ansatz.
Ist aber auch etwas, wenn wir zum Beispiel schauen in der Vergangenheit bei vielen Firmen, wie agile Transformationen stattgefunden haben.
Da haben ja einfach mal Teams angefangen mit Scrum zu arbeiten.
Das war recht erfolgreich.
Und die anderen Teams haben das dann automatisch adaptiert.
Aber irgendwo muss ja dann immer der Punkt kommen, wo dann auch das Management sagt, ja okay, da wollen wir jetzt.
Das ist auch, sagen wir, Teil unserer Strategie, dass wir den Weg gehen wollen.
Und wo steht ihr in Bezug auf das, also das jetzt, sagen wir, das Management bei Ihnen, dass es auch jetzt von oben bewusst gesteuert wird?
Oder ist das etwas, das ihr jetzt dieses Jahr angehen wollt?
Jetzt, wir haben vereinzelt Business Domain ITs, die wirklich das auch in ihrer Strategie manifestiert haben.
Also explizit auch eines von den Top-Level-Punkten und andere, wo das mehr so implizit ist.
Also wo dann schon DevOps auftaucht als Element der IT-Strategie, aber nicht ganz so explizit.
Und das hängt auch ein bisschen damit zusammen, dass die,
die Strategien, wir haben natürlich eine Gruppen-IT-Strategie, aber die Business Domains an sich sind unterschiedlich
und entsprechend sind auch teilweise die IT-Teile unterschiedlich ausgerichtet und haben da unterschiedliche Schwerpunkte drauf.
Und um den anderen Teil der Frage zu beantworten, also wir sind schon noch jetzt an einem Punkt, wo wir halt mit Referenz-Applikationen,
wir sagen dem auch DevOps Co-Owner,
also das sind wirklich so DevOps Advocates in den Business Domain ITs, mit denen ich eng zusammenarbeite,
die für gewisse Applikationen oder Portfolios zuständig sind, wo wir wirklich so die Referenz nicht unbedingt,
ja doch Implementation kann man schon sagen, jeweils machen.
Und auf Basis von dem wollen wir es dann eigentlich später auch ausdehnen und erweitern.
Und vielleicht ist es auch noch, also wir haben die Applikationen, mit denen wir zusammenarbeiten,
sind tendenziell halt eher in diesem, werden neu gebaut oder sind also keine Bestands-Applikationen oder Legacy-Applikationen
und das ist dann noch ein Feld, wo es für uns sehr spannend wird oder wenn wir wirklich dann mal mehr traditionelle Applikationen anpacken
und uns die noch weiter modernisieren im Sinne von DevOps-Prinzipien.
Habe ich das richtig verstanden, dass ihr im Prinzip diese DevOps-Ansätze wirklich nur bei neuen Applikationen anwendet?
Das heißt, ihr habt es noch nicht übertragen auf Bestands-Applikationen und insofern auch noch nicht unbedingt auf eine großartige Organisationsveränderung?
Ja, also sagen wir mal, die Referenz-Implementationen sind jetzt eher mit neueren Applikationen.
Das hängt aber auch damit zusammen, dass halt viele ältere Applikationen sind halt im Run-Modus.
Also da werden nicht massiv neue Features implementiert, sondern die werden halt am Laufen gehalten, sage ich mal.
Und dort will man halt noch nicht jetzt so die großen Investments machen.
Aber man muss auch sagen, also die Applikationen, wo wir jetzt wirklich entlang von DevOps-Prinzipien arbeiten,
das sind nicht nur Cutting-Edge-Applikationen aus Technologiesicht.
Also wir haben eine, die ist schon eine Microservices-Architektur, wo auf unserer Private Cloud läuft,
wo aber WebSphere, also so Sachen sind da mit dabei.
Das ist noch die modernste in Anführungszeichen.
Aber wir haben auch welche, wo wirklich Batch-Verarbeitung, ETL, Data Warehouse, auch Enterprise-Datenbank-Lösungen.
Sind zwar neue Applikationen, aber nicht jetzt auf irgendeinem Cutting-Edge-Public-Cloud-Technologie-Stack.
Und solche haben wir dann aber wiederum auch, oder? Also welche, die wirklich schon auf einem hochmodernen Tech-Stack sind.
Aber wie gesagt, eher Applikationen, die noch im Build-Modus sind, nicht Applikationen, die im Run-Modus sind.
Weil dort halt die Schwelle zu investieren, ist halt dort höher, oder?
Du hast ja auch erwähnt, Cloud ist bei euch ein Thema. Ihr habt, glaube ich, auch eine Cloud-Initiative am Laufen.
Wie siehst du da den Kontext jetzt Cloud und DevOps, respektive bei euch konkret jetzt?
Ja, also das eine, also es spielt wie ineinander und gehört zusammen.
Es gibt ja wie so zwei Ansätze, die wir da, oder zwei Sichtweisen.
Also man kann ja einerseits sagen, DevOps entfaltet die Wirkung und erst richtig, wenn man Cloud als Betriebsmittel hat.
Also wenn man die Cloud-Möglichkeiten ausschöpfen kann.
Zum Beispiel Immutable Infrastructure und so weiter, Infrastructure as Code.
Das kommt erst so richtig zum Tragen, wenn man Cloud-Mittel nutzen kann.
Oder man sieht es umgekehrt.
Also man kann wirklich Cloud nur nutzen, wenn man DevOps-Prinzipien und Methoden anwendet.
Wir sehen es mehr so, wir haben eine sehr starke Cloud-Ausrichtung in unserer IT-Strategie.
Also das wird da sehr groß geschrieben.
Entsprechend wird DevOps mehr so als Mittel und Ansatz gesehen, um wirklich diese Cloud-Strategie zu implementieren.
Also einer der Gründe, um Cloud zu machen, ist eigentlich auch,
DevOps und dann Cloud als Enabler für DevOps. Richtig?
Genau.
Und wenn ich jetzt die Sicht, also viele Software-Entwickler, für die ist ja so ihre Vision, also sie wollen,
wenn sie Code einchecken, also sie können eh virtuell ganz schnell, sie bekommen eine Umgebung und da werden automatisiert Tests ausgeführt.
Alles eigentlich darunterliegen ist alles Infrastructure as Code.
Und für die ist eigentlich dann ein bisschen eine Blackbox.
Oder ob das dann aus dem eigenen Datacenter kommt oder ob das so diese Tendenz von Know-Obs.
Der Software-Entwickler würde am liebsten dann alles aus der Public Cloud beziehen, Azure, Amazon.
Aber das ist ja bei euch, also ich sage das ja nicht, wenn wir noch die Branche besser verstehen.
Also Rückversicherung ist ja auch sehr stark reguliert. Also welchen Weg geht ihr da?
Mehr Public Cloud oder ist das dann Private Cloud?
Ja, im Moment, also ein Großteil der Applikationen wird sich jetzt erstmal in eine Private Cloud bewegen.
Eben aus den erwähnten Gründen. Aber die Strategie sieht eigentlich vor, wo immer möglich, gehen wir eigentlich in die Public Cloud.
Wo das nicht möglich ist, in die Private Cloud.
Und von dem Last Resort, dass irgendwas ordentlich passiert,
was On-Premise bleibt, redet man eigentlich gar nicht, oder?
Also eigentlich ist Public Cloud first und dann als zweite Möglichkeit halt Private Cloud.
Und wie es sich jetzt manifestiert, ist halt wirklich so, dass ein Großteil jetzt in die Private Cloud geht.
Eben wegen den erwähnten Regulatorien, die halt sehr stark sind im Financial Services Sektor und speziell im Versicherungssektor.
Alex hat eben nochmal ein Stichwort eingebracht, Know-Obs.
Und so wie du es auch ausgeführt hast, Alex, klang es für mich so ein bisschen,
als ob die Entwickler sich eigentlich gar nicht um Obstthemen kümmern wollen. Nicht unbedingt.
Gab es denn bei euch Erfahrungen, oder wie sind eure Erfahrungen, wenn die Entwickler, die eben neue Features bauen wollen, auf IT-Betrieb treffen?
Also wenn sie auch den Betrieb sicherstellen müssen. Was sind da so eure Erfahrungen mit den Entwicklern?
Aus dem, was ich jetzt erfahren habe aus vielen Gesprächen, ist eigentlich, dass ein Applikationsentwickler
möchte eigentlich Applikationsentwicklung machen, oder?
Also die sind im Regelfall schon eher an den funktionalen Aspekten von der Applikation entwickelt.
Also ich persönlich sehe wieder ein bisschen ein neues Profil.
Das ist jemand, also so ein Ops-Engineer, wo er sich eher an der Applikation orientiert,
wo er sich aber auf die nicht-funktionalen Aspekte konzentriert.
Die verschiedenen Entwicklertypen arbeiten dann zusammen in einem Team.
Das ist so das, wo ich so ein bisschen vermute, wo die Reise hingeht.
Aber es ist noch ein bisschen schwierig zu sagen.
Um die Frage zu beantworten, wie Applikationsentwickler reagieren.
Also das kommt dann, nachdem so wir dürfen jetzt alles und machen alles selber,
kommt irgendwann oft ein Punkt, wo so ein bisschen auch nicht Ernüchterung,
aber wo die Leute dann sehen, was das denn alles bedeutet.
Also diese, ich glaube, diese No-Ops-Idee.
Irgendwann kommt dann da die Ernüchterung, oder?
Wo man dann sagt, okay, aber ganz das alles wollen wir dann doch auch nicht machen, oder?
Und ich rede von dem klassischen Applikationsentwickler.
Ich glaube an Teams, an Applikationsteams, wo es halt Entwickler gibt.
Alles sind Entwickler, aber halt welche, die sich auf die funktionalen Aspekte konzentrieren
und andere auf die nicht-funktionalen.
Das bedeutet Monitoring, Automation, CI-CD-Pipeline und so weiter.
Okay, das heißt, die Entwickler,
von denen du gesprochen hast, die lernen dann durch DevOps,
dass Ops doch nicht ganz so einfach ist und ja,
manchmal auch ein bisschen langweilig wahrscheinlich,
aber trotzdem schon eine Herausforderung und wollen es dann wahrscheinlich doch eher auch abgeben
oder einfach im Team auch vielleicht so ein bisschen hin und her schieben.
Ja, so könnte man das zusammenfassen, ja.
Und es ist halt, es ist alles auch noch ein Lernprozess, oder?
Weil das verändert sich halt doch sehr stark.
Also das muss sich alles setzen und man muss gute Setups am Ende vom Tag finden, oder?
Wie man das nachher betreiben kann.
Ja, ist schlussendlich, also DevOps-Transformation ist ja eine Reise.
Das ist ja, auch wenn man so liest oder hört, was andere im Bereich Enterprise IT,
DevOps-Transformation machen, ist ja nicht so, dass man von Anfang an Ziel bildet, sondern es ist eine Reise.
Und jetzt auch anknüpfen, was wir vorher diskutiert haben halt,
dass sich auch Operation ein bisschen neu finden muss, neu definieren und eben sicher nicht No Ops,
weil das ist sicher nicht die richtige Lösung, sondern eher würde ich sagen so New Ops,
was auch immer das konkret heisst, ja.
Und was ich jetzt vielleicht noch spannend finden will, wir haben ja darüber gesprochen,
was habt ihr da konkret gemacht, eben so Value Stream Mapping, Flash Build,
dann das Lean Change Management, wenn wir vielleicht ein bisschen tiefer gehen.
Also ich persönlich bin Fan noch von diesem Value Stream Mapping,
weil es ist auch etwas, wo man relativ schnell dann auch Verbesserungen erzielen kann,
dann einen gewissen Drive reinbringen kann, weil die Leute sehen das und wollen dann weitermachen.
Kannst du, Tobias, vielleicht ein Beispiel von so einem Value, also du musst es ja nicht beim Namen nennen,
aber in welchem Bereich habt ihr denn das Value Stream Mapping gemacht, welche Art von Applikation?
Also was ist dann konkret so aus solchen Value Stream Workshops,
was ist da dann herausgekommen an konkreten Verbesserungen?
Also eins ist sicherlich das gewesen mit dem Lean Change Release Deployment Management.
Das war ein Finding, das wir dann konkret halt jetzt in diesem Minimal Viable Process Beispiel umgesetzt haben.
Dann haben wir auf der Datenbankseite angefangen,
und dort wirklich das auch mehr aus einer, also wir haben einen gewissen Automationsgrad,
was das Ausführen von Datenbankskripten oder das Verwalten von Datenbanken anbelangt, haben wir schon,
aber eben nicht in einem End-to-End Automationskontext oder in einem Pipeline-Kontext.
Und das war eigentlich in so gut wie allen Value Stream Mappings, die wir gemacht haben, ein großes Thema.
Dort haben wir jetzt wirklich auch schon konkret erste Schritte gemacht,
wo Applikationen dann wirklich aus der Pipeline kommen,
aus der Pipeline raus im Prinzip ihre Datenbank Changes deployen können.
Und dann gibt es eben, ein anderes Beispiel wäre noch Monitoring,
dass man wirklich das Monitoring, das Produktionsmonitoring eben auch aus der Pipeline quasi abschalten kann,
dann Veränderungen vornehmen kann automatisiert und zum Schluss das Monitoring wieder anstellen.
Und ja, ab dergleichen gibt es noch mehrere kleine Beispiele, würde ich sagen.
Aber das ist auf der Prozessseite mit dem Change Management und auf der Datenbank
Seite, das sind wohl die grösseren Blöcke bisher, würde ich sagen.
Ja, aber das sind doch konkrete Verbesserungen.
Und ihr seid ja, habe ich verstanden, auch so vorgegangen, dass ihr mich halt dann als Team zusammengesetzt habt,
vielleicht Leute, die vorher noch nicht so miteinander gesprochen haben, also verschiedene Departments.
Man hat gefragt ja, der End-to-End Stream, wer ist da involviert?
Und zuerst mal ein Bild bekommen, wie läuft es jetzt und dann aus dem heraus Verbesserungen identifiziert.
Wie habt ihr das gemacht?
Also das Interessante war für mich, ich habe auch fast bei allen Value Stream Mappings eigentlich gesehen,
dass jeder, also dass zum Beispiel Leute, die in einem grösseren Applikationsteam zusammenarbeiten,
auch jeweils untereinander was voneinander gelernt haben.
Also eigentlich nicht mal nur Leute, die jetzt da normalerweise nichts miteinander zu tun haben,
sondern alle haben irgendwie was gesehen oder Einsichten bekommen in das,
was der andere macht.
Und was mir so hängen geblieben ist, ist das Beispiel mit dem, das war eine Batch-orientierte Applikation,
wo die Testzyklen sehr, sehr teuer sind.
Also konkret ein voller Testzyklus hat, glaube ich, acht Stunden oder so gebraucht.
Also zeitmäßig sehr teuer und entsprechend konnte der nicht so oft durchlaufen.
Wir haben dann herausgefunden, dass eben pro Release dreimal dieser Testzyklus durchlaufen wird
und dass in dem ersten Testlauf hunderte von Fehlern entdeckt werden.
Und dann werden die Fehler behoben, dann hat man vielleicht noch 50% oder 30% von den Fehlern im zweiten Testlauf
und im dritten läuft dann alles durch.
Und dann haben wir wirklich in einer Gruppe eigentlich geschaut, ja, was machen wir denn damit?
Und haben dann gesehen, eigentlich wäre es doch gut,
wenn man wirklich möglichst viel von dem Testing nach links verschieben kann,
dass das nicht alles nur an diesen teuren Testläufen hängt, oder?
Weil man hat gesehen, das war halt für sie die einzige Möglichkeit, das zu testen, aus ihrer Sicht,
und das war sehr teuer, also hat man alles dort reingesteckt.
Und die Schlussfolgerung war eigentlich, dass wir dann wirklich versucht,
möglichst viele Tests schon vor diesen teuren Testzyklen zu machen,
dass dann der erste teure Testzyklus halt zum Beispiel nur noch,
50% der Fehler finden muss, dass man vielleicht am Ende vom Tag mit zwei teuren Testzyklen statt mit drei laufen kann.
Und natürlich ist das dann in der Theorie sehr einleuchtend und naheliegend
und in der Umsetzung halt etwas schwieriger, aber schon allein die Einsicht hätte man glaube ich nicht gehabt,
ohne dieses Value Stream Mapping, wo dann wirklich alle, die in diesem Value Stream mitarbeiten,
das an einem Tisch sitzen und das anschauen.
Das klingt doch gut. Das finde ich auch einen sehr schönen Lerneffekt,
auch aus dem Phoenix Project Buch, aus dem Roman, dass man wirklich den Value Stream,
den Wertstrom sich anschaut und daraufhin eben entwickelt.
Und damit ja letzten Endes auch über die Silo-Grenzen hinaus das Ganze mal betrachtet.
Ja, jetzt gucke ich mal auf die Uhr, Alex. Sonst ist das immer dein Job, auf die Uhr zu gucken.
Jetzt gucke ich mal auf die Uhr. Ich habe keine Fragen.
Das war ein super tolles Gespräch und wenn du keine Fragen hast, Alex, dann können wir ja auch langsam beenden.
Also ich habe auch keine Fragen mehr. Ich fand das super spannend.
Das sind auch die wertvollsten Beiträge, die wirklich aus der Praxis kommen.
Also was machen die Unternehmen effektiv, wenn es um DevOps geht?
Also von dem her vielen Dank von meiner Seite, vor allem von Tobias.
Sehr gern.
Dann auch von mir vielen Dank. Ich habe mitgenommen eine sehr tolle Definition von DevOps.
Nachhaltige Geschwindigkeit oder Geschwindigkeitssteigerung. Finde ich sehr, sehr interessant.
Werde ich bestimmt übernehmen in Vorträgen oder in Schulungen oder in Erläuterungen.
Und was ich interessant fand, war die Erkenntnis, dass das viele kleinere Verbesserungen sind.
Also das ist ein Weg, den man gehen muss, wo man viele kleinere Verbesserungen hat,
wo man viele Schritte hat, wo man Erfahrungen hat und dass das kein so riesen Programm ist, was man aufsetzt.
Das fand ich sehr, sehr interessant. Und davon von mir auch herzlichen Dank an dich, Tobias.
Sehr gern. Danke euch.
Und dann noch ein Ausblick auf den nächsten Podcast. Dirk, willst du das machen?
Respektive haben wir da noch mehrere Optionen im Moment, oder?
Ja, das hast du geschickt gemacht. Das muss ich wieder sagen.
Wir wollen kein neues Thema haben. Also wir haben die Option, jawoll.
Und wie es immer so ist, so am Jahresanfang, jetzt wo wir heute diesen Podcast aufnehmen, das startet so langsam.
Also insofern, der nächste Podcast kommt bestimmt wieder zur Mitte des Monats, wieder dann Mitte Februar.
Aber das Thema ist noch nicht ganz klar.
Ja, das stimmt.