In dieser Podcast-Episode erörtern Olaf Garves und Ralf Knobloch von T-Systems MMS ihre Erfahrungen mit der Implementierung von DevOps-Prinzipien in ihrem Unternehmen. Sie betonen die Bedeutung von Schnelligkeit und Qualität in der Softwareentwicklung, diskutieren Herausforderungen und Vorteile der Integration von Entwicklungs- und Betriebsteams und unterstreichen die Rolle von Automatisierung, Continuous Integration und Continuous Delivery. Besondere Aufmerksamkeit wird der Überwindung traditioneller Silos zwischen Entwicklung und Betrieb geschenkt, sowie der Notwendigkeit, Kultur- und Einstellungsänderungen im Unternehmen zu fördern, um die Effizienz zu steigern und auf zukünftige Trends wie Container-Technologie und künstliche Intelligenz vorbereitet zu sein.
Inhalt
- Einführung und Vorstellung der Gäste
- Grundlagen und Philosophie von DevOps
- Implementierung von DevOps bei T-Systems MMS
- Herausforderungen und Vorteile der Integration von Entwicklung und Betrieb
- Rolle der Automatisierung und Continuous Integration/Delivery
- Überwindung von Silos und Kulturwandel im Unternehmen
- Zukünftige Trends: Container-Technologie und KI in der Softwareentwicklung
- Diskussion über Sicherheit und Datenschutz in DevOps-Umgebungen
- Fallbeispiele und praktische Anwendungen von DevOps-Prinzipien
- Abschlussdiskussion und Ausblick
Shownotes
- DevOps-Manifesto – Ein zentrales Dokument, das die Philosophie von DevOps beschreibt. DevOps Manifesto (ähnlich dem Agile Manifesto, da kein spezifisches DevOps-Manifesto bekannt ist).
- T-Systems MMS – Ein Full-Service-Projekthaus. T-Systems MMS
- Phoenix Project von Jim Kim – Ein Buch, das die DevOps-Prinzipien veranschaulicht.
- Docker – Eine Plattform zur Containerisierung von Anwendungen. Docker Offizielle Website
- Amazon Web Services (AWS) – Ein wichtiger Cloud-Service-Anbieter, der auch DevOps-Praktiken anwendet.
Transkript (automatisiert, daher keine Gewähr 🙂 )
DevOps – auf die Ohren und ins Hirn
Ein Podcast rund um DevOps
Von Alex Lichtenberger und Dirk Söllner
Herzlich willkommen zur dritten Folge unseres Podcasts
DevOps – auf die Ohren und ins Hirn.
Mein Name ist Alex Lichtenberger und ich bestreite diesen Podcast zusammen mit Dirk Söllner.
Der wird sich dann auch gleich vorstellen.
Ja, das Thema des heutigen Podcasts
DevOps in der Praxis – von der Anforderung in die Produktion in einer Stunde.
Das tönt ja schon mal sehr vielversprechend.
Ich möchte dazu auch ganz herzlich unsere beiden Gäste
Olaf Garves und Ralf Knobloch von der T-Systems MMS begrüssen.
Sie werden uns heute vorstellen, wie DevOps bei Ihnen bei der T-Systems MMS umgesetzt wurde.
Sie begleiten aber auch Kunden auf diesem Weg.
Also sicher ein sehr spannendes Thema.
Ja, dann würde ich mal sagen, bevor ich an den Dirk übergebe,
Olaf, Ralf, stellt euch doch mal vor, gleich mal zu eurer Person,
wer ihr seid, was ihr macht und dann auch zur Firma, was die machen.
Ja, sehr gerne. Hallo, mein Name ist Olaf Garves.
Ich leite ein sogenanntes,
Service-Feld, wo wir halt seit drei Jahren DevOps machen.
Meine Vergangenheit ist allerdings ein bisschen bewegter.
Ich komme aus einem Umfeld, wo ich auch immer schon interdisziplinär gearbeitet habe.
War früher Projektleiter für Software-Entwicklung,
habe dann eine Software-Entwicklungseinheit geführt
und dann kam mir der Gedanke, dass das Support-Geschäft
eigentlich auch eine ziemlich coole Idee ist, halt langfristig auch Umsatz.
Und Services zu bieten, weil unsere Kunden das auch verlangt haben.
Und daraufhin halt auch eine betrieblich orientierte Einheit mit aufgebaut.
Die ist inzwischen auch gewachsen.
Da steht auch ein Team dahinter, das habe ich nicht alleine gemacht.
Und als das Thema DevOps so vor vier, drei Jahren auch in Deutschland so auftauchte,
habe ich mich auch daran erinnert, dass ich ja früher auch mal Software-Entwicklung gemacht habe
und dass eigentlich die Zusammenarbeit eigentlich immer ein erfolgskritischer Faktor war.
Und so bin ich halt auch in das Thema DevOps auch reingekommen.
Ja, dann möchte ich mich als Zweiter vorstellen.
Ralf Knobloch mein Name.
Ich bin seit circa zweieinhalb Jahren bei der T-Systems MMS
und ich arbeite als verantwortlicher Lead-Architekt für das interne DevOps at MMS Programm.
Das Ziel dieses Programmes ist es, die MMS, die ein Full-Service-Projekt
House ist mit 1.800 Mitarbeitern und einer hundertprozentigen Tochter der großen T-Systems,
dass wir die Dienstleistungserbringung in den Dingen Software-Entwicklung,
Consulting, Test, Betriebsüberführung und den IT-Betrieb selber
möglichst so weit miteinander verbinden und automatisieren,
dass wir unsere Marktfähigkeit und Wettbewerbsfähigkeit am Markt
und in der T-Systems MMS weiter ausbauen.
Ich habe auch ein Leben vor der MMS.
Dort habe ich ein Cloud-Startup mit aufgebaut, wo ich auf die grüne Wiese
eine hochverfügbare Cloud-Lösung Software S-Code aufgebaut habe
und diese DevOps-Prinzipien umgesetzt habe.
Und noch davor war ich bei einem DAX10-Konzern und habe mich seit 2008 beginnend mit dieser DevOps
Thematik, Zusammenwachsen von und Automatisierung von Software-Entwicklung,
Test-Betrieb im Großkonzern verbunden mit vielen, vielen Dienstleistern beschäftigt
und konnte dort auch aus Sicht eines Großkonzerns erste DevOps- und Cloud-Automatisierungserfahrungen sammeln.
Wie gesagt, seit 2009 bis 2010.
Dort zu diesem Zeitpunkt konnte man den Begriff DevOps,
noch gar nicht so recht definieren.
Ich habe mit meinen Mitarbeitern damals, wo ich eine erste DevOps-Plattform,
die nannte sich Lifecycle-Management-Plattform, aufgebaut habe,
auch versucht, in der deutschen Wikipedia den Begriff DevOps zu definieren und zu bringen.
Diejenigen, die dort in 2010 den Begriff DevOps dann freigeben sollten, haben gesagt,
das ist kein richtiges Wort und haben das nicht verstanden, was zu diesem Zeitpunkt
sein sollte.
Das heißt, ich habe also einen recht frühen Umgang mit dieser, mit DevOps gefunden und
geprägt und bin auch dann von der MMS genau zu diesem Zweck, das Internet-DevOps-at-MS-Programm
bei der Umsetzung architekturell, technisch mit zu unterstützen, geholt worden und arbeite
immer noch in dieser Aufgabe.
MARKUS TRANTOW Ja, sehr schön.
Dann glaube ich, dann kannst du ja, Ralf, als …
Ralf, als erstes auch aus deiner Historie mal versuchen, wie man DevOps definieren kann
oder wie würdest du DevOps definieren, wie würdest du DevOps beschreiben?
RALF SCHMIDT Ja, ich würde, also mein Credo ist dabei immer, dass ich das DevOps-Manifesto
zu Rate ziehe oder heranziehe.
DevOps ist aus meiner Sicht eine Philosophie, die sehr viel Leidenschaft beinhaltet.
Es ist eine kulturelle, professionelle Bewegung mit Haltung und Wunsch.
RALF SCHMIDT Ja.
RALF SCHMIDT Ja.
RALF SCHMIDT Verちょ бы certificate
der EU.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SPEN iTunes, ja.
RALF SCHMIDT Ja.
RALF SPEN iTunes, ja.
RALF SPEN iTunes, ja.
Duke indications.
GRAetics.
der Software-Defined-Everything-as-Code-Bereitstellung
erfolgt, wo Sales Services entstehen
in der Infrastruktur, aber auch für Corporate
Integration oder Continuous Integration und Continuous Delivery
Pipelines. Und es ist auch
für mich eine Definition,
dass hier Software entsteht, die eigentlich, wenn alles gut
und richtig gemacht wird und DevOps gut umgesetzt wird, keinen oder kaum
Support benötigt wird im laufenden Run oder im laufenden Betrieb,
dass Teams aus Entwicklung und Betrieb auch
testintegriert zusammenwachsen und dass
Service-Verantwortungen entstehen, die die heute vorhandene
Silo-Trennung zwischen Entwicklung, Test und Betrieb zum Teil
aufheben, beziehungsweise wo diese Aufgaben
verschwimmen, weil der eigentliche
Entwickler versteht immer besser die Herausforderungen des Betriebes
und der Betriebler, der ja immer sagt
Never touch a running system, versteht langsam, dass man seine Infrastruktur
auch ständig kodieren und ändern kann.
Und wir haben dort ein Zusammenwirken von
System, das ist der Ausgangspunkt, hin zu unserer eigenen Philosophie,
wie wir im Programm, im DevOps at MMS-Programm arbeiten.
Every time change a running system.
Und das ist also eine totale Brain-Änderung an dieser Stelle.
Und das bedeutet auch, dass im DevOps eine kontinuierliche
Rückkopplung zwischen Entwicklung, Test und Betrieb erfolgt.
Und jetzt mal gemappt auf unser Unternehmen.
Also DevOps ist die eigentliche interne Digitalisierung
unserer eigenen Firma, also unseres IT-Full-Service-Projekthauses.
Ja, ich würde nochmal auf das eingehen,
was du eben gesagt hast, bevor wir dann zu Olaf nochmal rüber wechseln,
wie er DevOps sieht. Ich denke, und da haben wir ja noch ein bisschen Zeit,
das zu besprechen, ich denke, dass manchen Betriebler jetzt die Ohren klingeln
bei dem, was du eben gesagt hast. Und da haben wir bestimmt noch ein bisschen
Gesprächsthema. Olaf, wie würdest du denn DevOps definieren
oder beschreiben?
Ich würde das folgendermaßen beschreiben, dass natürlich
im Fokus der Kunden und die Funktion, die er benötigt für den
Markt, halt möglichst schnell, aber bei hoher Qualität
erstellt und in die Produktion gebracht werden.
In der heutigen Markt, im dynamischen Markt geht es
wirklich sehr schnell.
Und ich denke, das ist ein sehr, sehr wichtiges Thema,
weil es ist eine digitale Transformation, die sämtliche
Arbeits- und Lebensräume durchdringt. Es wird halt alles digital, es gibt
digitale Services. Und wer das halt so kennt von
seinem Smartphone, wenn da irgendwie eine App nicht so richtig funktioniert,
dann ist die in einem Wisch halt mal weg. Und das ist wirklich auch die
Veränderung, die wir auch selber als Dienstleister ja selber
unterliegen. Dazu hat die erst ja auch dieses Programm mit aufgesetzt.
Auf der anderen Seite möchten wir ja unsere Kunden auch damit beliefern,
damit die halt auch in einem Markt erfolgreich sind.
Und DevOps ermöglicht es wirklich in einer engen Zusammenarbeit
mit der Entwicklung, mit einer externen Entwicklung, das ist nicht unbedingt immer eine
interne Entwicklung sein, dass man da wirklich interdisziplinär zusammenarbeitet,
dass man auch die die das Verständnis
hat, gegenseitig. Und dass man auf Augenhöhe sich begegnet mit dem Ziel, auch mit dem Business, mit den Fachbereichen zusammen, mit der Testabteilung, dann ein gemeinsames Ergebnis auch zu liefern. Denn auf das Ergebnis kommt es drauf an und nicht, wer sozusagen jenseits der Mauer nun recht hat oder vielleicht was falsch gemacht hat.
Und was Ralf schon sehr richtig sagte, diese Feedback-Schleifen sind extrem wichtig, dass man sich gegenseitig Feedback gibt, Retrospektiven auch gibt und dass man sozusagen die Kultur des jeweils anderen, die früher vielleicht mal getrennt war, respektiert, aber auch da absolut Vorteile gegenseitig nutzt.
Und wir werden sicherlich später im Gespräch mal auf Beispiele kommen, wie sich das dann auch tatsächlich dann halt auch ausdrückt in der täglichen Praxis.
Ihr habt euch ja schon sehr früh mit dem Thema DevOps angefangen zu beschäftigen und wir werden dann die Beispiele und wie ihr das auch umgesetzt habt oder zum Teil vielleicht Kunden auch geholfen habt, darüber sprechen.
Eine Frage, die ich aber vorher noch spannend finden würde, ist eigentlich dann das Warum. Was waren eigentlich für eine T-Systems, MMS, weil DevOps hat ja keinen Selbstzweck.
Wir machen jetzt Agile oder DevOps und da gibt es ganz bestimmte Treiber.
Oft sind das auch externe Markttreiber.
Was hat euch, die Frage, was hat euch bewogen, das Thema DevOps schlussendlich anzugehen für die T-Systems, MMS?
Na ja, starte ich mal mit einer Antwort.
Da gibt es viele Antworten drauf.
Es wurde festgestellt, dass wenn wir als Projekthaus einen Full-Service,
also das Erbringen zu einem Kunden, also Entwicklung, Test und Betrieb, alles in einer Hand für einen Kunden machen,
dass die Überführung aus der Entwicklung dann auf ganz andere, im Betrieb teilweise auf ganz andere Eingangsvoraussetzungen getroffen ist.
Und das hat dazu bewogen zu sagen, oder das war unter anderem ein Treiber, lasst uns doch mal eine Infrastruktur definieren und finden,
sodass schon bei Beginn.
In der Entwicklung der Zielbetriebs- oder die Zielbetriebsumgebung genutzt wird.
Und diese Zielbetriebsumgebung, die muss natürlich feststehen und die muss Plattformen, Plattformen, damit meine ich zum Beispiel Cloud oder Server-Backend,
überall gleich funktionieren, ja, also gleich funktionieren sein.
Also ist egal, welche Cloud, sage ich jetzt mal, man nutzt.
Das entwickelt vielleicht auf einem Lohn.
Also bei einem lokalen Laptop oder PC, bei einem Entwickler entwickelte Software-Stück sollte überall gleichartig funktionieren,
möglichst bei den Plattformen, die man als Dienstleister oder als Projekthaus bedient.
Das war unter anderem ein Treiber.
Und ich glaube auch natürlich, dass es Kundennachfrage gab.
Ich selbst war ja auch mal auf einer Kunden- oder auf Kundenseite.
Und Olaf, du erinnerst dich sicher, wo ich sehr früh schon mal bei deinem,
du erst hier vorgesprochen habe und die Anforderungen, die man dort gerne umgesetzt bekommen hatte, skizziert hat.
Also auch Kundenanfrage, Kundenausschreibung, glaube ich, sind zunehmend der Treiber,
diese DevOps-Thematik stärker zu liefern und umzusetzen.
Und wir haben dadurch auch, glaube ich, das Ziel, alles oder mehr aus einer Hand liefern zu können.
Weil wenn man mit seiner, mit automatisierten Prozessen,
einem Kunden überzeugt bei der Dienstleister-Erbringung,
so gelingt es durchaus mehr als vielleicht nur Entwicklung oder nur Test oder nur Betrieb
von dem Kunden beauftragt zu bekommen.
Hat da der Wettbewerbsdruck, die Konkurrenz hat auch eine Rolle gespielt?
Also weil oft ist ja dann plötzlich ab einem Mitbewerber oder sagen wir mal Marktbegleiter,
der eben schon, der macht DevOps, der kann sehr schnell und konsistent,
solche Service auf dem Markt bringen. War das auch ein Treiber?
Wenn ich jetzt aus meiner Perspektive antworten darf, weil ich antworte ja sozusagen mehr aus der Produktion sozusagen,
der, wir haben mehrere externe Kunden, da ist es natürlich auch ein Treiber von den Fachseiten,
mit denen wir zusammenarbeiten, die natürlich auf dem Markt, wie gesagt, Marktanteile verteidigen.
Müssen oder halt wirklich auch sehr schnell sein müssen, weil halt neue Trends entstehen,
die halt schnell bedient werden müssen oder eine Marketingkampagne, die schnell umgesetzt werden muss.
Und viele Softwareentwicklungsagenturen, die für unsere Kunden arbeiten oder halt auch vom Kunden selber kommen,
die arbeiten ja schon bereits agil und die müssen halt einfach auch sehr schnell sein.
Das nützt nichts, dann mit einer dritten guten App im Markt zu kommen, wenn es schon eine sehr,
sehr gute gibt und die sehr schnell eine Verbreiterung hat.
Und diesen Trend sozusagen, da unterstützen wir natürlich unseren Kunden, damit er sozusagen einfach diese Agilität hat.
Der kommt auch sehr viel mit unterschiedlichen Entwicklungseinheiten.
Natürlich wäre das Ziel für uns als MMS prima, wenn der Kunde jetzt alles aus einer Hand nehmen würde.
Das ist auch der Fall bei vielen Kunden.
Es gibt aber auch Kunden, die bewusst sagen, nee, ich möchte eine gewisse Unabhängigkeit haben.
Ich möchte sogar unterschiedliche Entwicklungsdienstleister haben.
Und die funktionieren halt von der Kultur manchmal auch total unterschiedlich und haben sozusagen auch ihre eigenen Entwicklungsprozesse unterschiedlich umgesetzt.
Und für einen Großkunde ist es natürlich wichtig, dass sie doch einheitlich irgendwo aufgegleist werden,
damit sozusagen hier nicht diese Energien verloren gehen, sondern, wie Ralf das schon sagte,
dann hinterher auf einer konformen Infrastruktur dann auch landen und auch möglichst dort,
stabil betrieben werden kann.
Also es ist auf jeden Fall ein externer Marktdruck.
Wenn man jetzt die Konkurrenz sieht in Deutschland, denke ich mal, ist das Thema auf jeden Fall zunehmend verbreiteter und bekannter.
Und da ist durchaus auch für die MMS selber der Anspruch da, aber auch weiter Vorreiter zu sein.
Ralf, ich würde nochmal auf das eingehen, was du eben gesagt hast.
Du hast bei der Definition von oder Beschreibung von DevOps gesagt, es geht darum auch,
ein gegenseitiges Verständnis zwischen Dev und Ops herzustellen.
Und deine Antwort eben auf die Frage von Alex war ja auch, dass ihr für diesen Fall damals eine gemeinsame Infrastruktur definiert habt.
Wie haben denn die Entwickler darauf reagiert, dass sie sich ja quasi jetzt in ihrer Freiheit,
in ihrer künstlerischen Freiheit vom Betrieb etwas vorschreiben lassen mussten?
Das.
Das ist ein Gefühl oder dass es dort eine Vorschreibung gab, die Entwickler, das ist die Rückmeldung, die wir bekommen, sind jetzt eigentlich zufrieden,
dass sie sich in ihrem Projekt nicht, ich sag mal, Tage, Wochen, manchmal vielleicht sogar Monate lang um den Aufbau und die Konfiguration der Infrastrukturelemente kümmern müssen,
sondern dass sie dadurch, dass es eine standardisierte Infrastrukturbereitstellung gibt, die man auch per Code-Definition, also Infrastruktur,
DrS-Code verändern kann, dass sie sich sofort und viel schneller anders entwickeln, eines Services oder einer Anwendung machen können.
Sie müssen sich also nicht selbst Tage, Wochen lang mit dem Infrastrukturdesign und dem Aufbau des Ganzen beschäftigen.
Und sie fühlen das schon als eine echte Entlastung.
Okay.
Dadurch, dass diese Infrastruktur, wenn sie automatisiert ist, bereitsteht.
Und man das alles im Source-Code hat.
Also wir tun Infrastruktur auch per Source-Code beschreiben, wie ein Anwendungsprogramm.
Dadurch kann man diese Infrastruktur auch schnell nachnutzen, weil automatisiert aufgebaut.
Und wenn man sie verändern muss, nehmen wir mal an, ich brauche jetzt für einen Cloud-Service eine gewisse Skalierbarkeit,
weil dieser Cloud-Service zum Beispiel an bestimmten Zeiten des Jahres,
viel mehr genutzt wird, als in den Ferienzeiten,
dann kann ich diese Cloud mit einer variablen Serveranzahl in der Software-Definition versehen
und bin dann ganz schnell auch in der Veränderung einer kundenspezifischen oder anwenderspezifischen Infrastruktureinstellung unterwegs.
Und muss nicht, ich sage jetzt mal, Monate oder Wochen lang auf die Beschaffung eines Hardware-Servers warten,
beziehungsweise auf die Konfiguration des selbigen.
Dadurch, dass wir eben auch auf Cloud- und Virtualisierungstechnologien, Containertechnologien zunehmend aufsetzen.
MARKUS TRANTOWSKI Ja, das, was du eben als Vorteil beschrieben hast, was die Entwickler jetzt sehen,
das haben sie ja vielleicht noch nicht zu Anfang gesehen.
Also wie habt ihr diesen, den von mir vorgestellten Widerstand gebrochen?
Oder wie habt ihr die Leute überzeugt, die Entwickler, diesen Weg mitzugehen?
Oder war da gar kein Widerstand?
War da gar keine Abneigung?
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
MARKUS TRANTOWSKI Ja.
Also, Widerstand war eigentlich aus meiner Sicht kaum welcher zu spüren. Es war wirklich teilweise ein Unverständnis, dass es einfach im Betrieb notwendigerweise eine aus Sicherheitsgründen Anforderung gibt, so wenig wie möglich Services oder Funktionalitäten in einem Serverbetriebssystem zu haben oder nur so wenig wie notwendig.
Der Entwickler hat gerne alles, was er irgendwo mal finden konnte, drauf konfiguriert und wollte das auch haben. Um, nehmen wir an, ein Debugging von einer Anwendung im laufenden Betrieb durchführen zu können und so weiter.
Und er hat auch dann nicht darauf geachtet, unter Umständen, dass man da mal ein bisschen ein paar Funktionalitäten runterschrauben muss, Ports zumachen muss, eigentlich nur aus Sicherheitsgründen.
Zum einen.
Zum anderen, die Entwickler haben eigentlich aber jetzt auch erkannt, das braucht natürlich ein bisschen Zeit, dadurch, dass sie die Infrastruktur auch als Code vorliegen haben.
Also sie speichern jetzt ihre infrastrukturelle Bereitstellungs auch mit dem Business Source Code zusammen ab, innerhalb eines Service oder eines Projektes oder für einen Kunden.
Und das kommt ihnen und ihrer Fähigkeit, alles zu jeder Zeit ändern, anpassen können oder zu wollen.
Entgegen.
Und natürlich der Betriebler oder die Betriebsleute, die haben dort ihre Gedanken oder ihre Forderungen nach Stabilität, nach Robustheit jetzt auch viel stärker eingebracht.
Und das ist ein Weg, den beide Seiten gehen können oder auch bei uns Stück für Stück gehen und wo dann auch Vertrauen entsteht.
Wir haben.
Aber auch um diese, dieses, dieses bessere Verständnis und das Wissen von einem anderen, also von Entwicklung oder DevOps zu übertragen, haben wir auch eigene Mittel innerhalb der MMS genutzt.
Zum Beispiel das Mittel einer Jobstation, wo in dieses DevOps Programm Entwickler, Tester oder auch Leute aus dem Betrieb in dieses DevOps Programm für eine gewisse Zeit rotiert sind.
Und dort mit ihren Spezialkenntnissen den anderen ihre Kenntnisse beigebracht oder auch überliefert haben und sich natürlich auch andere Kenntnisse angeeignet haben.
Wir haben auch Schulungen durchgeführt und vor allen Dingen, was aber das eine ist ja nicht nur technisches Wissen oder technische Fertigkeiten, sondern das gegenseitige Verständnis.
Und das ist das, wo ich auch sage, es ist eine Haltung, es ist eigentlich eine Philosophie, DevOps umsetzen zu wollen.
Und wir haben auch ständige Befragungen dieser Jobrotierer durchgeführt und die sind dann nach circa sechs Monaten, manche auch nach zwölf Monaten in ihr ursprüngliches Arbeitsgebiet zurück rotiert und haben natürlich dann das, was sie erlebt haben, ihre Ideen, auch ihre Haltung, die sie mittlerweile angenommen und verkörpert haben.
Es waren grundsätzlich sehr positive Rückmeldungen, die wir bekommen haben.
Die tragen das jetzt in die anderen Organisationsgruppen.
Mit zurück, dieses Wissen, was man mit DevOps alles machen kann, was geht und zu welchen, ich sage jetzt mal Beschleunigungen und auch schnelleren Lieferfähigkeiten das Ganze führen kann.
Ich würde es gerne mal ergänzen, was Ralf da gesagt hat, weil wir haben sozusagen auch dieses gegenseitige Verständnis auch ganz bewusst auch gefördert,
dass wir zum Beispiel in unserer Betriebsseite.
Das Team, was vorher für die Verantwortung für geschäftskritische Anwendungen, Application Management gemacht hat, Transitions durchgeführt hat, nach Heidel gearbeitet hat und in diesem Aspekt CICD Pipeline, also die Schnelligkeit der Software Delivery sicherzustellen, ist ein Software Architekt in das Team mit aufgenommen worden und man hat voneinander gelernt.
Und das ist auch das Wichtige daran, dass man da zusammenarbeitet.
Dass man ein gemeinsames Ziel hat, nämlich zum Beispiel diese CICD Pipeline aufzubauen für die Kunden Software und dieser Architekt beispielsweise, der ist dann natürlich mit dem Betriebswissen, was er zwangsweise mit aufnehmen konnte, dann halt in das nächste Projekt gegangen, also nächstes Kundenprojekt und halt auch umgekehrt die Betriebsmannschaft, die bei mir sitzt, hat halt auch eine neue Technologie.
Und dann hat man auch Aspekte der Softwareentwicklung mitbekommen.
Und so wachsen halt beide Bereiche wirklich tatsächlich mehr und mehr im Verständnis zusammen und erbringen halt sozusagen da dann auch einen ziemlich guten Job, weil das Ergebnis ist nach wie vor, es geht darum, hochqualitative Software in möglichst schneller Zeit in den Markt zu bringen.
Oder halt für interne Anwendungen, also ich rede jetzt, ich habe immer so die Brille auf, so nach draußen.
Das geht natürlich genauso darum, halt auch für interne Bereitstellung von IT-Services halt auch schnell zu sein und den Mitarbeitern halt auch entsprechende Software bereitzustellen.
Also gegenseitiges Verständnis, also der Jim Kim, der Autor des Phoenix Project, hat ja auch mal schön gesagt, eigentlich brauchen wir Entwickler, die eben denken können, wie auch wie Betriebsleute und Betriebsleute, die denken können wie ein Entwickler.
Also dieses gegenseitige Verständnis.
Und auch diese ursprüngliche Konfliktstabilität versus Flexibilität, um das aufbrechen zu können.
Also ich habe schon jetzt das Konzept, das ihr erklärt habt, auch mit der Team-Rotation, das da sehr hilft, um dieses gegenseitige Verständnis zu bekommen.
Das geht sogar auch an dieser Stelle in diesem DevOps-Programm, was wir intern in der MMS machen, soweit, dass wir erste leichte Organisationsänderungen probieren.
Wo eine Entwicklungsorganisationseinheit und eine Betriebsorganisationseinheit zusammen wirklich geschlossen werden und dann für Kunden gemeinsam arbeiten.
Also dort integrativ DevOps vertikal in einer vertikalen Entwicklungstest und hoffentlich dann auch Betriebsverantwortung zu erbringen.
Also das ist ein erster Organisationsprobe.
Und das ist ein erster Ballon, könnte man sagen.
Eventuell ist das ein Weg, wie sich Kunden, Erbringungsorganisationen wandeln könnten.
Und das kann man nicht pauschal, so jetzt wandeln wir mal das ganze Unternehmen, sondern das muss man mit kleinen Schritten, Organisationsschritten ausprobieren.
Was ist der richtige Weg?
Und wir sind ein 1800 Mann starkes Unternehmen.
Und da kann man nicht mal sagen, wir ändern jetzt mal die ganze Organisation.
Und wenn das nichts ist, dann probieren wir es nochmal.
Sondern es wird ganz bewusst auch getragen, committed von der Geschäftsführung, diese Organisationsprobierballon ausprobiert.
Also Ralf, ich finde, das ist für mich ein ganz wichtiger Punkt, weil ich, wenn ich jetzt unterwegs bin bei größeren Unternehmen, dann sind die häufig von jährlichen Reorganisationen geschädigt, die Mitarbeiter.
Jedes Jahr wird was Neues gemacht oder alle zwei Jahre.
Und das, was du eben gesagt hast, ist aus meiner Sicht immer ein ganz zentraler Punkt.
Ich habe nicht ein neues Framework, wo ich mich hinentwickeln muss, was ich sozusagen quasi umsetzen muss, wie ITIL oder Scrum, sondern ich muss schrittweise dahin kommen, diese Philosophie umzusetzen, dieses gegenseitige Verständnis hinzubekommen.
Und das eben schrittweise, mit kleinen Schritten und nicht mit einem Riesenprogramm, weil das geht in die Hose und dann gibt es das nächste Programm.
Und damit ist der Begriff DevOps.
Und das ist dann auch wieder verbrannt.
Kann ich bestätigen.
Ich hatte auch in einem Großkonzern, also auf der Kundenseite gearbeitet und im mittleren Management.
Und dort ist eine solche Umsetzung von oben dann, naja, ich sag mal durchgesetzt worden.
War auch erfolgreich, was Kosten und Schnelligkeit betrifft.
Aber das Mitnehmen der Leute ist dort nicht so gut erfolgt.
Also dort war der Erfolg da nicht so.
Mitnehmen der Leute bedeutet, dass sie sich also in einer veränderten Zuständigkeitssituation mit anderen Anforderungs- und Aufgabenbereichen schneller zurechtfinden.
Wir sind ja, oder die meisten Menschen sind ja so, dass sie Veränderungen nicht ganz so von sich aus wollen oder treiben.
Und das wurde dort mehr von oben dann verordnet und durchgesetzt.
Und so etwas, so eine Kulturänderung, die sollte nicht nur von oben vorgehen.
Und durchgesetzt werden, sondern das ist eine Kombination aus geführter Governance und dann auch wirklich Graswurzelbewegung,
die in einer gemeinsamen oder in einer mit wollenden Menschen umgesetzt werden sollte,
die willens sind, sich verändern zu wollen und die auch sehen,
dass eine solche Ausrichtung auf DevOps für alle Seiten auch etwas bringt.
Man wird schneller, wettbewerbsfähiger und lernt unheimlich ständig.
Immer.
Dazu.
So eigentlich ein Mix dann, wenn man über die Vorgehensweise, sprich für eine Transformation, so Top-Down, Bottom-Up.
Es ist klar, einerseits Management-Commitment ist wichtig, aber dann, ich glaube, das haben wir auch schon beim letzten Interview gehört.
Wir sehen auch hier in der Schweiz, wenn ich schaue, wie die Firmen DevOps umsetzen, es sind eben so kleine, kleine Schritte, jeweils Feedback holen.
Und auch die Leute dann, ich sage immer, die,
die Leute, die sind eigentlich offen gegenüber Veränderung, aber wenn es darum geht, dann sich selber zu verändern,
da kommt der Widerstand und der Trick ist dann irgendwie auch, dass man wie, wenn die Leute das Gefühl haben,
ah, das war ja meine Idee oder die auch dann, dann eben die Transformation selber agil zu machen,
dass die selber das vorantreiben, dass es dann auch getragen wird von den Leuten.
Also ich kann das nochmal bestätigen, das ist, wir sind Menschen, wir kommunizieren,
es gibt Missverständnisse, es ist halt auch Kultur, Bereichsdenken manchmal, Silo-Denken.
Und das ist sehr, eigentlich die Veränderung auf einer technischen Ebene herbeizuführen, ist eigentlich relativ einfach, in Anführungsstrichen,
weil da kann man, da kann jeder eigentlich gleich darüber sprechen, auch das Management, die verstehen das, die Mitarbeiter verstehen das,
aber so eine Kultur, das ist so ein wabbeliger Begriff, na, was ist denn das eigentlich?
Und ich finde es halt da extrem wichtig und das machen wir.
Das machen wir in der MS auch und das machen wir ja auch mit den Kunden, dass wir sagen, dass man frühzeitig alle Beteiligten an Bord holt,
dass man auch durch Community-Gründungen auch verschiedene Kanäle bereitstellt, wo wir darüber diskutiert werden können.
Das setzt natürlich eine offene und Kommunikationsbereitschaft Unternehmenskultur auch voraus
und die hat es dann halt letzten Endes dann auch leichter, solche Modelle sozusagen auch sukzessive schneller umzusetzen.
Als eine Unternehmenskultur, die vielleicht sehr stark hierarchisch geprägt ist.
Ich würde nochmal auf einen Punkt eingehen, auch vorhin noch ein bisschen aus der Einleitung, das, was ihr eben ja im Prinzip auch angedeutet habt.
Raif hatte gesagt, zur Definition, was ist DevOps? Das ist Leidenschaft, das ist Kultur.
Und dann noch weiter ausgeführt, es geht darum, Serviceverantwortung hinzubekommen und eben weg von,
von den Silos. Du hast es ja eben auch gesagt, Olaf, es geht um Kulturwandel.
Was mache ich denn oder welche Erfahrungen habt ihr denn mit Personen gehabt, mit Menschen gehabt?
Denn wir haben es ja mit Menschen zu tun, die eben nicht mit Leidenschaft zur Arbeit gehen,
die eben genau sich nicht verändern wollen, auch wenn sie vielleicht sogar einen Vorteil davon hätten.
Also habt ihr da so ein paar besondere Tricks entwickelt oder habt ihr etwas, wo ihr gemerkt habt, das hat bei euch funktioniert?
Also ich kann…
Ich habe ja nur eine Support-Abteilung verantwortet, die nach wie vor.
Und das sind durchaus auch als so zum ersten Mal die Themen wie DevOps angesprochen worden sind,
kamen da auch Bedenken, naja, da habe ich ja dann nichts mehr zu tun, wenn alles automatisiert ist
oder wenn halt einfach hier die normalen Betriebsaufgaben weniger werden durch die CICD-Pipeline.
Und ich glaube, da hat man als Führungskraft eine ziemliche Verantwortung.
Die sollte man auch wahrnehmen, man soll sich darüber auch klar werden.
Diese Veränderung kann nicht alleine von unten oder nur von oben passieren,
sondern die muss parallel geführt werden, so eine Diskussion.
Und ich habe tatsächlich mit meinen Mitarbeitern auch die Begeisterung wecken können.
Sagt, da gibt es neue Perspektiven, neue Chancen.
Denkt mal voraus, was das bedeutet.
Ihr könnt mehr Verantwortung übernehmen und man ist dann halt nicht mehr,
wie früher vielleicht so das Bild,
naja, man kriegt die Software über den Zaun geschmissen,
sondern nee, ihr seid auch bei diesem Prozess mit dabei, wie das passiert,
wie man halt zusammenarbeitet und dann halt auch am Ergebnis letzten Endes mit beteiligt.
Und dass das halt auch eine ganz andere Wertschöpfung ergibt,
eine viel höherwertige Wertschöpfung, als wenn man sozusagen einem nur sagt,
naja, mach das mal bitte jetzt hier, das ist eilig und das muss nachts installiert werden,
damit es morgen läuft und im Übrigen in der nächsten Nacht darfst du dann das nächste Release in Empfang nehmen.
Und das sind…
Ja, völlig von ab.
Und diese Begeisterung, die Ralf auch so schön erklärt hat,
das kommt dann insbesondere, wenn der Kunde dann wirklich auch sieht,
Mensch, ich habe die Software für meinen Fachbereich schneller deployen können.
Die Endkunden sind begeistert.
Und das wird dann halt als Feedback dann auch dem Team,
dem gemeinsamen Team auch wieder gespiegelt.
Und dann sind die auch richtig motiviert.
Okay, das heißt als Lerneffekt oder auch als Argument würdest du ansprechen,
abgesehen davon, dass es natürlich dann den Arbeitsplatz erstmal sichert,
weil wenn ihr es nicht gemacht hättet, hätten es andere gemacht,
dass es den Arbeitsplatz auch wertvoller macht, wertvoller auch für die eigene Tätigkeit.
Und das wären so quasi die beiden Argumente, die ich aus deinen Ausführungen, Olaf, mal rausziehen würde.
Also es geht wirklich darum, dass die Fähigkeiten des Mitarbeiters,
die müssen an dieser Stelle weiterentwickelt werden, weil aus betrieblicher Sicht und aus der Brille gucke ich,
ja hier auch hauptsächlich, müssen mehr Richtung Deployment,
mehr Richtung Entwicklungsverständnis gehen, weil ja auch die, wie Ralf das ja schon sagte,
die Infrastruktur, Cloud-Technologien, da wird es nicht mehr so sein,
dass man da den Server und sechs Wochen ist er da und dann muss er installiert werden,
sondern das ist tatsächlich auch auf Knopfdruck da.
Und der Systemingenieur von heute wird sich in einen DevOps-Ingenieur umwandeln,
der halt das Ganze orchestriert.
In dem Kontext hätte ich noch eine Frage, weil auch Dirk hat vorhin gefragt,
es gibt ja manchmal Leute, die wollen nicht, wie geht man die an?
Jetzt sprechen wir auch darüber, ja die Leute müssen sich weiterentwickeln,
aber manchmal können sie vielleicht nicht.
Also ein schönes Beispiel ist ja im Testing, also das manuelle Testing, das abnimmt
und jetzt mehr Richtung Testautomatisierung, Scripting, das braucht eine ganz neue Art von Skills,
aber vielleicht sind die Leute…
die dann gar nicht in der Lage, sich in die Richtung zu verändern, oder?
Habt ihr solche Fälle auch gehabt, wo ihr sagt, ja, das wird jetzt einfach schwierig, oder?
Also, der Ralf, ich hatte so etwas in dem Großkonzern natürlich auch in der ganz Frühzeit erlebt.
Man muss dann schon auch als Unternehmen ist man in der Verantwortung,
oder die Unternehmen sind eigentlich in der Verantwortung dort,
die Weiterbildung und der Mitarbeiter zu sorgen.
Natürlich gibt es auch eine gewisse Weiterbildungsresistenz unter Umständen,
die man feststellen, oder die ich auch erlebt habe.
Aber da helfen meiner Ansicht nach dann Überzeugungsgespräche und so weiter.
Der größte Hebel oder den besten Hebel, den ich immer gefunden habe, um dann bei Mitarbeitern,
Um dann bei Mitarbeitern, um dann bei Mitarbeitern,
Um dann bei Mitarbeitern, um dann bei Mitarbeitern,
wo das ein bisschen schwieriger war, die zu erzeugen,
war, dass sie durch die Übernahme neuer Skills ihren Marktwert eigentlich steigern konnten.
Und dass sie dadurch einen ganz anderen Selbstwert, ein Selbstwertgefühl kriegen und einen höheren Marktwert.
Denn wir wissen alle, dass Arbeitssituationen, dass man in einem Unternehmen anfängt und dort 40 Jahre bleibt,
dass das immer unwahrscheinlicher wird.
Und dass auch Arbeitgeberwechsel durchaus öfter stattfinden können, nicht müssen, aber können.
Und gerade wenn man mit dieser DevOps-Fähigkeit oder mit Fähigkeiten Entwickler-Test und Operations-Skills ausgestattet ist
und bei beiden immer oder bei allen drei Richtungen zunehmend die Softwareentwicklungsnotwendigkeit,
ob das Scripting oder Testautomatisierung oder Softwareentwicklung selber ist,
zunimmt, beziehungsweise dann das Wissen um solche neuen Technologien, die ja auch damit verbunden sind,
sei es jetzt Cloud, sei es Test, Driven Development oder was es da alles noch Neues gibt, Big Data-Technologien.
Also der Marktwert des Einzelnen erhöht sich.
Und das war aus meiner Erfahrung immer der größte Hebel, dass man dort ein bisschen Eigenmotivation schaffen konnte.
Okay.
Frage von mir noch mal zum Thema Sicherheit.
Das ganze Thema Sicherheit, Datenschutz und so weiter, das wird ja manchmal so dargestellt, dass das ein Showstopper ist für DevOps.
Oder dass es zumindestens die Schnelligkeit, von der ihr vorhin gesprochen habt, beeinflusst.
Seht ihr das auch so? Und wenn das bei euch auch ein Problem ist, wie geht ihr damit um?
Also da würde ich eine erste Antwort geben.
Dadurch, dass wir bei der…
Bei der Definition von den einzelnen Komponenten und Schritten in der Umsetzung dieses DevOps-Programmes,
von Beginn an die IT-Sicherheit als Design mit oder als Design-Abhängigkeit in den zehn…
Wir haben so eine Art zehn DevOps-Gebote uns gegeben.
Und Security by Design für alles das, was man dort an Automatisierung, an Standardisierung macht,
wenn man das von Beginn an berücksichtigt und auch die Sicherheitstests möglich macht,
wenn man das Testmöglichkeiten und Sicherheitsmonitoringmöglichkeiten automatisiert von Beginn an einbaut,
dann kann Sicherheit oder automatisierte Sicherheit auch zu einer Entwicklungsbeschleunigung führen.
Also ich kann das vielleicht auch nochmal von der anderen Seite beleuchten.
Ich sehe das nämlich ähnlich wie Ralf.
Es führt eigentlich zu mehr Sicherheit, weil nämlich durch die Automatisierung viele manuelle Schritte einfach entfallen.
Und da entstehen dann halt Fehler bei den manuellen Schritten.
Und dadurch, dass man sehr viel wiederholbar macht und halt automatisiert, wird eigentlich die Sicherheit da erhöht.
Dann ist es auch so, dass man in der CI-CD-Pipeline, also sozusagen technische Ausprägung von DevOps,
ja eine Reihe von Tests drin hat, die halt beginnen schon sehr früh im Code,
schon Code-Quality-Analysen zu machen bis hin zu Last- und Performance-Tests,
wo die Tests ja dann halt auch dazu führen sollen, bewusst dazu führen wollen,
die Software unter Druck zu setzen, damit halt Schwachstellen offengelegt werden können.
Und ein dritter Aspekt, den man vielleicht auch dazu sehen könnte,
die ganze CI-CD-Pipeline mit den ganzen unterschiedlichen Testverfahren, die da drin sind,
mit den Deployments, automatisierten Deployments von Stage-to-Stage,
das ist ja selber auch ein Qualitätssicherungssystem in der Gänze.
Es kann natürlich trotzdem vorkommen, das ist ja so, man macht die CI-CD-Pipeline ja auch so,
dass es halt schneller ist und nicht nur schneller, sondern natürlich auch mehr Deployments hat,
dass natürlich in der ersten Phase, so wie es bei jeder Software ist,
also auch die CI-CD-Pipeline ist natürlich auch Software,
dass dann natürlich Probleme schon entstehen können.
Und da ist halt aber auch wieder diese enge Zusammenarbeit, dieses enge Verständnis notwendig,
weil man dann ja auch sagt, es gibt eine gegenseitige Schuldzuweisung,
na, du hast ja hier irgendwie nicht aufgepasst, sondern es ist alles transparent,
man setzt sich schnell zusammen im interdisziplinären Modus und tut das halt dann auch lösen.
Okay.
Vielleicht noch auch ein Hinweis, also dadurch, dass man Dinge automatisiert und wenn ein Fehler auftritt
und diese automatisierten Tests, die man dann ja auch im Betrieb als Monitoring-Element einsetzen kann,
wodurch dann aus dem Betrieb immer wieder für einen neuen Software-Entwicklungszyklus
eine Rückwirkung da ist, dass man das Monitoring-Skript gleich auch wieder zum Testen in der Software-Entwicklung nehmen kann,
entsteht auch eine Über-die-Zeit-Situation.
Das heißt, man hat eine viel höhere Robustheit der Infrastruktur und des Applikations selber,
weil alle Tests, die ich einmal automatisiert habe, werden bei jedem Build oder Commit,
wie wir das nennen, wenn also eine Software eingecheckt wird, wird immer wieder durchlaufen.
Das heißt, die Testdurchlaufzahl, die Testabdeckung wird durch die Automatisierung auch wesentlich erhöht
und über die Zeit werden die Systeme immer robuster und damit auch immer sicherer, hoffentlich.
Also mit anderen Worten, weil im Titel des Podcasts steht ja auch von der Anforderung in den Betrieb in einer Stunde,
das könnte ja zur Schlussfolgerung verleiten, okay, dann geht die Qualität runter,
aber das ist ja nicht, also da, wie du jetzt gerade beschrieben hast,
die Robustheit und die ganze Testautomatisierung, dass sie dem entgegenwirkt.
Ein Beispiel, mal ganz konkret, das habe ich heute auch in einem internen Cloud-Tutorial gehalten.
Wir erstellen aus Software-Beschreibungen unsere Betriebssysteme.
Das nennt man ein Betriebssystem-Image.
Und dieses, bei dem Erstellungsprozess, der automatisch abläuft,
werden mehr als 400, 500 verschiedene automatisierte Infrastruktur-Tests für das Bauen aus einem Software-Repository,
wie Git oder Subversion, für das Bauen eines Betriebssystem-Images.
Genutzt und laufen ab.
Und dieses Bauen des Betriebssystems allein, die allein nur aus Software-Definition heraus erfolgt,
wird jede Nacht immer wieder für die unterschiedlichen Plattformen gemacht
und es tritt unter Umständen doch mal ein Fehler auf, da muss man danach suchen.
Und mit jeder weiteren Fehlerbehebung wird das Stück für Stück schon das Betriebssystem eines Servers,
auf dem Applikationen laufen, immer robuster.
Und ich sag mal,
damit auch hoffentlich immer performanter und vollständiger.
Wir wissen alle, Software ist nie fehlerfrei.
Wenn man sich die Lines of Code von der Software, die für eine Applikation gebraucht werden, mal aufaddiert,
das Betriebssystem, die Datenbank und so weiter, aus denen die alle bestehen,
da ist man sehr schnell für eine kleine einfache Anwendung,
da ist man sehr schnell dabei, dass man da mehrere Millionen Lines of Code hat
und die übereinandergelegt einen Riesenturm zu Babel an Lines of Code ergeben.
Und natürlich, wir wissen, dass die nicht fehlerfrei sind,
aber durch die ständige Automatisierung, durch das Härten und das Rausnehmen von Funktionen, die man nicht braucht,
das Abschalten von Funktionen, wird es sicherer, robuster, hoffentlich auch performanter über die Zeit.
Ich komme mal auf den Titel zurück.
Alex hatte da eben auch schon mal darauf hingewiesen.
Olaf, ich habe dich ja bei einem Vortrag mal gehört, wo du vor einer Zeit,
ich sage mal, versammelten IT-Service-Management-Mannschaft, vor ITIL-Freunden gesagt hast,
dass ihr wirklich von der Anforderung bis zur Produktivsetzung eine Stunde braucht.
Die haben ihren Mund nicht wieder zugekriegt und konnten sich nicht vorstellen,
wie man zum Beispiel in einer Stunde ein Change Advisory Board einberufen kann.
Also ist das so? Schafft ihr das? Schafft ihr das in einer Stunde Produktivsetzung?
Also Ralf hat es eben schon gesagt.
Also bei uns beginnt die Uhr zu ticken bei dem Commit.
In dem Moment, wo der Entwickler halt den frischen Code eincheckt, wird das erkannt aus dem System
und dann geht die Pipeline halt auch los und darauf bezog sich auch diese eine Stunde.
Und natürlich, wenn man jetzt sagt, die hohe Kunst ist es wirklich in einer Stunde zu machen oder auch schneller,
dann geht das. Wenn man aber jetzt sagt, man hat eine komplexere Anwendung, wo halt auch längere Lasttests stattfinden,
da muss man halt dann mehr Gehirnschmalz reintun, wie man die Tests parallelisieren kann,
beispielsweise um so eine Stunde dann auch zu erreichen.
Es gibt sicherlich auch Anwendungen, wo das auch schneller geht, wo einfach auch aufgrund der Vigna-Komplexität
dann halt auch einfach gewisse Stages auch wegfallen können.
Ich glaube, die besondere Herausforderung, die noch auf uns zukommen wird, ist das Thema Docker.
Ich tue das einfach mal voraussetzen, dass so ein gewisses Verständnis über Container-Technologie da ist.
Ich glaube, dass sich da auch nochmal ein Shift in der IT-Verständnis, in der Betriebsverantwortung tun wird,
die von so einer Layer-Verantwortung, da ist die Applikation und darunter ist der Betrieb
und der macht halt sozusagen die Systeme darunter, Datenbank, Infrastruktur,
dass sich das auch aus diesem Grunde auch nochmal ändert.
Das heißt, man wird in eine Betrachtung von Inside-Container und Outside-Container.
Und das Thema DevOps wird durch das Thema Docker noch sehr viel mehr beschleunigt.
Und ich glaube, da wird es noch eine ganze Menge an Gesprächsbedarf geben,
weil dann tatsächlich die Möglichkeit ist, Anwendungen überall zu deployen,
egal in welcher Cloud und in einer noch höheren Geschwindigkeit, wird natürlich dazu führen,
dass eine Unübersichtlichkeit auch entsteht.
Und ich glaube, deswegen ist das auch so richtig, diese Kulturaspekte noch zu betrachten,
dass man sagt, okay, man braucht über alles eigentlich immer eine gewisse Transparenz.
Wer macht denn da was? Wie ist die Qualität?
Ist dann Testdokument wirklich auch gemacht worden im Sinne einer Revisionssicherheit?
Also das wird alles, diese Governance darüber, die wird immer eine größere Rolle spielen.
Man wird auch immer mehr auf die Prozesse gucken.
Und das wird für mich sozusagen die zukünftige Herausforderung sein.
Also es wird nicht einfacher, glaube ich, sondern es wird eher noch komplizierter,
wo man dann halt auch wieder entsprechende Mitarbeiter braucht,
die auch mit dieser Komplexität umgehen können, das managen.
Die werden dann nicht mehr den Apache-Server neu starten,
sondern die werden sich mit solchen Themen auseinandersetzen.
Stimmt denn der gesamte Prozess? Wo hakt da was?
Ein weiteres Thema, was dazukommen wird,
auch was das Thema Robustheit auch angeht,
ist, glaube ich, die KI, also künstliche Intelligenz,
zu der Robustheit von Softwareentwicklung mit einzubeziehen.
Und ich glaube, das wird, wenn man so ein bisschen in die Zukunft guckt
und vielleicht trifft man sich ja in drei Jahren wieder im Podcast
und sagt, nee, das war alles Quatsch, was hier der Olaf erzählt hat,
KI ist noch lange nicht so weit.
Aber ich glaube, da fängt jetzt irgendwie so eine neue Generation an,
die wieder neue Herausforderungen angeht.
Und das ist dann, um diese Komplexität in den Griff zu kriegen,
wäre halt auch aus meiner Vision sozusagen KI auch ein Schlüssel dazu.
Weil allein in unserem Bereich betreiben wir knapp 50 ICT-Pipelines parallel.
Und das kann man auch nicht mehr alles manuell prüfen und checken.
Und wenn es dann halt um 100 Commits pro Tag geht,
dann potenziert sich das ja alles.
Man hat ja eine unglaubliche Masse von Durchläufen dann.
Und dazu brauchen wir halt auch Mechanismen,
auch Verständnis da, sozusagen den Überblick zu behalten
und halt nicht die Kontrolle zu verlieren, genau.
Ich möchte da nochmal auch einhaken auf die Frage
und kann das nur unterstützen, was Olaf sagte.
Die Frage war ja, was passiert mit dem Kasten,
mit dem Change Advisory Board?
Gewöhnlicherweise über die letzten Jahre haben sich Customer
oder Change Advisory Boards meistens in großen Firmen,
die in gewissen Outsourcing-Beziehungen standen
oder in großen Organisationen, auch wenn man ein Insourcing hatte,
der IT ausgebildet.
Durch die Beschleunigung von der Automatisierung
und dadurch, dass sich CI, CD-Pipelines,
die ständig übereinander automatisiert wirken und deployen,
und dadurch, dass ich Testalgorithmen habe,
die mit immer größeren Testabdeckungen dazu führen,
dass, wenn festgestellt wird durch Automaten,
das ist grün, das ist grün, das ist grün
und man dort eine gewisse Regel-Rollenauswertung,
KI-Intelligenz drüber legt,
dann können Rollout- und Freigabeentscheidungen,
die entweder durch ein Change Advisory Board
durch Menschen gemacht werden,
Stück für Stück auch ersetzt werden durch Automaten,
die, wenn sie dann sagen, alles ist grün,
rolle aus, mache eine nächste Stage
oder rolle es sogar in Produktion aus,
das mehr und mehr zu einer Reduzierung der Aufgabe
von menschlichen Entscheidungen im Change Advisory Board führt.
Und meine Messlatte, beziehungsweise unsere Messlatte,
auch für die MMS, ist eigentlich Amazon Web Services.
Amazon Web Services hat seinen Change Advisory Board Vorgang
von menschlichen Entscheidungen auf Roboterentscheidungen umgestellt.
Warum?
Weil die menschlichen Entscheidungen bei den ständigen Durchläufen,
die die Automatisierungs-Pipeline bei Amazon Web Services macht,
zu großen Fehlern geführt hat.
Das heißt, die KI- und Automaten, die CI-CD-Pipelines,
die mit hohen Testabdeckungen durchlaufen,
treffen größtenteils automatisch die Entscheidung,
rolle ich das jetzt aus, rolle ich das jetzt nicht aus?
Und dort werden wir mit KI- oder AI-Methoden im Betrieb
und auch in Change Advisory Board dazukommen,
Freigabeentscheidungen, die eigentlich ein Change Advisory Board trifft,
die Aufgaben eines menschlichen CABs weiter und weiter zu reduzieren.
Ich würde das nochmal aufnehmen, was Ralf gesagt hat.
Also das Ganze hört sich jetzt sozusagen so ein bisschen an,
als wenn das jetzt alles von alleine geht.
Ich glaube, es gibt ja auch mehrere Arten von Changes.
Und sicherlich kann ein Minor-Change oder halt ein Odd-Fix schneller durchlaufen
und da braucht man auch keinen Change Advisory Board.
Man kann gewisse Typen vordefinieren, wo es sozusagen so eine Art
Pre-Authorized-Change-Prozess gibt, wo das auch im Risiko auch bleiben kann.
Ich glaube, aktuell ist es so, ein Kunde, der wirklich eine wichtige Geschäftsanwendung hat,
der wird immer noch sagen, nee, ich brauche anderen Gewissen,
an einer gewissen Stelle brauche ich hier immer noch eine menschliche Freigabe.
Und das ist das, was wir unseren Kunden ja auch anbieten wollen,
dass sie sagen, okay, dass er natürlich immer die Hoheit darüber hat,
was er dann letzten Endes da auch im Markt auch deployt.
Wo ich Ralf aber absolut recht gebe, ist einfach in einem hochstandardisierten Umfeld,
da wird man ohne solche sehr starken Automatisierungen
und Selbstbestimmungen,
Selbstlernen-Systemen dann nicht mehr auskommen.
Bei einer großen individuellen Geschäftsanwendung,
da würde ich mal interpretieren, da wird es noch ein bisschen dauern.
Sehr schön. Also, ich gucke auf die Uhr.
Wir haben fast eine gute Stunde gefüllt und ich glaube,
da steckt ganz viel drin von dem, was ihr so berichtet habt.
Das muss man sich wahrscheinlich zwei- oder dreimal nochmal anhören,
weil ihr einfach sehr viel aus der Praxis berichtet habt.
Ich habe keine Fragen mehr.
Alex, wie sieht es bei dir aus?
Ich fand es unglaublich spannend.
Wir können natürlich lange weiter diskutieren,
aber vielleicht dann mal beim Folge-Podcast.
Keine weiteren Fragen.
Ja, recht vielen Dank.
Also, ich möchte mich auch bei euch bedanken,
dass ich hier bzw. dass wir hier teilnehmen durften
und unsere Meinung äußern konnten.
Sicherlich haben wir an der einen oder anderen Stelle
auch ein bisschen einen Ausblick in die Zukunft gegeben,
aber man muss sich weiterentwickeln.
Und nur dann, wenn wir wettbewerbsfähig bleiben,
dann hat unser Unternehmen auch gute Chancen auf Wachstum
bzw. weiterer Daseinsberechtigung.
Also, es bleibt spannend, definitiv.
Und DevOps ist ja eine Reise, nicht ein Ziel,
das man dann morgen erreicht hat.
Also, auch herzlichen Dank von meiner Seite.
Ja, ich danke auch.
Und ich sehe das genauso.
Eigentlich fängt das Spannende jetzt erst an.
Also, die IT ist jetzt sozusagen jetzt soweit,
wo man wirklich sagen kann,
jetzt beginnt auch eine aufregende Zukunft mit Chancen für alle.
Möchtest du vielleicht, Dirk, noch auf den,
wir haben ja noch einen nächsten Podcast geplant.
Jawohl, der nächste Podcast ist der,
den wir beim letzten Mal schon als nächsten angekündigt haben.
Also, wir sind gerade aktuell richtig agil in unserer Planung,
müssen uns immer auf veränderte Situationen einstellen.
Also, beim nächsten Mal hören wir dann,
was wirklich was zur MetroMap von der Direktgruppe.
Die wird ihre MetroMap vorstellen.
Und da werden wir auch wiederum zwei Gesprächspartner haben.
Wird bestimmt genauso interessant.
Wird dann vielleicht ein bisschen eher so in Beratung reingehen.
Aber trotzdem, wie gesagt, wird mit der MetroMap,
werden wir tolle Dinge besprechen.
Ich sage auch Dankeschön.
Und Alex, dann würde ich sagen, du mal das Schlusswort heute.
Ja, herzlichen Dank.
Ich denke, auch dieses Mal wird es super spannend.
Super spannender Beitrag.
Und auch, ich denke, aus der Praxis heraus,
die Herausforderung, die eine T-Systems MMS gesehen hat
und wie sie das dann effektiv umgesetzt hat.
Am Schluss ist auch, das Technische muss man natürlich auf die Reihe bringen,
aber dann der Faktor Mensch, der hat sich auch jetzt wieder gezeigt.
Also, die Leute, die begeistern, das Feuer wecken in den Leuten,
dass sie dann auch mitmachen.
Und ich fand irgendwie am Schluss dann die Diskussion Richtung,
ich meine da Artificial Intelligence,
das ist sicher so das nächste grosse Thema.
Da ist jetzt sehr viel mit Chatbots auch,
die jetzt eingesetzt werden.
Das wäre dann vielleicht auch mal ein spannendes Thema.
Aber in diesem Sinn, vielen Dank.
Vielen Dank.
Vielen Dank.