Romano Roth ist Chief of DevOps bei Zühlke. Im Interview erklärt er, warum DevOps kein Bullshit ist, wie die Transformation im Unternehmen gelingt und was IT-Studenten wirklich lernen sollten.
Ein Interview von Daniel Ziegener veröffentlicht am 7. Januar 2023, 11:14 Uhr auf https://www.golem.de/news/devops-wenn-wir-ueber-devops-reden-muessen-wir-ueber-menschen-reden-2301-170592.html
Für die einen ist DevOps eine Methodensammlung zur Produktentwicklung, für andere schlichtweg Bullshit. Im Golem.de-Newsletter Chefs von Devs erklärte Romano Roth, der Chief of DevOps bei Zühlke, warum DevOps kein Bullshit ist - und es manche dennoch dafür halten. Denn Entwickler, "die sagen, dass DevOps Bullshit ist, sind häufig in einer Rolle irgendwo zwischen Dev und Ops gefangen", sagt er.
Golem.de: Herr Roth, was ist DevOps für Sie - und warum ist es kein Bullshit?
Romano Roth: DevOps ist kein Bullshit, denn es hilft bei einem wichtigen Problem: Wir schmeißen immer wieder Dinge über die Walls of Confusion. Das Business hat viele gute Ideen. Diese Ideen schreiben sie als Anforderungen in Word-Dokumenten oder Jira-Tickers nieder und schmeißen sie dann über die Wall of Confusion zu den Entwicklern. Die schauen sich das an und sagen sich: Wenn ihr das so haben wollt, entwickeln wir das für euch.
Nach der Entwicklung geht es in die Build-Pipeline, wo das Testing-Team merkt, dass das Ergebnis nicht mit den Anforderungen übereinstimmt. Sie testen trotzdem irgendwas, irgendwie ist es dann grün und geht weiter. Der Betrieb fragt sich, wie das überhaupt betrieben werden soll, aber sie kriegen es irgendwie hin. Dann geht es zurück und das Business sagt: Das haben wir gar nicht bestellt! Auf der einen Seite haben wir das Problem der Organisationssilos, auf der anderen Seite das Problem, dass wir immer noch in Projekten arbeiten, aber Produkte entwickeln. Bei einem Projekt fokussieren wir uns auf den Output: Anzahl der Features, Stories, Code und so weiter. Bei einem Produkt fokussieren wir uns auf das Outcome. Wir wollen das Problem des Kunden lösen, sein Verhalten ändern. Es kann sein, dass wir das mit einem einzigen Feature hinbekommen.
Ein Produkt hat auch kein Start- oder Enddatum, sondern wird kontinuierlich entwickelt. Daher müssen wir uns entlang dieses kontinuierlichen Wertstroms organisieren - statt monatelang zu spezifizieren, dann monatelang zu implementieren und monatelang zu testen. Das muss inkrementell und kontinuierlich passieren. Und da hilft DevOps.
Golem.de: Wie kann ein konkreter Begriff wie DevOps denn den gesamten Wertstrom abbilden?
Roth: Wenn wir über DevOps reden, müssen wir auch über Menschen reden. DevOps ist ein schlecht gewählter Begriff, denn es heißt genau genommen "Development and Operation". Nun versuchen manche Leute das zu beheben, indem sie Security mit reinnehmen. Dann haben wir Devsecops. Wieder andere sagen: "Aber das Business ist noch wichtiger" - und wir bekommen BizDevOps . Aber auch dieser Begriff ist zu kurz gegriffen. Denn es geht um alle Personen, die am Wertstrom arbeiten.
Eigentlich bräuchten wir einen Begriff wie Devsecbizarccomqaops. Und ich bin sicher, ich habe da auch noch jemanden vergessen. Wir könnten es auch Dev*Ops oder DevXops nennen. Aber nennen wir es doch einfach DevOps. Denn bei DevOps geht es darum, alle Personen, Technologien und Prozesse zusammenzubringen, um kontinuierlich Wert zu schaffen. Das ist der Kern von Devops.
Golem.de: Geht es bei der "Bullshit-Debatte" also vor allem um Missverständnisse und Begrifflichkeiten?
Roth: Ich bin der Meinung: ja. Die Personen, die sagen, dass DevOps Bullshit sei, sind häufig in einer Rolle irgendwo zwischen Dev und Ops gefangen. Sie sehen nur einen kleinen Teil des gesamten Wertstroms - und können ihn auch nicht optimieren. Das führt zu Friktionen und Frust. In den Artikeln, die DevOps Bullshit nennen, geht es meistens darum, dass ein Entwickler überlastet oder überfordert ist, weil er so viele Hüte aufhaben soll, aber das System nicht ändern kann.
Wenn das Management denkt, sie können Ops eliminieren und die Devs übernehmen das, führt das genau zu solchen Problemen. Aber es ist gar nicht Sinn und Zweck von DevOps, eine Person oder ihr Skillset zu eliminieren, sondern Leute zusammenzubringen, damit sie kontinuierlich Wert schaffen können.
Gut gemeint - schlecht umgesetzt
Golem.de: DevOps ist also gut gemeint, aber schlecht umgesetzt.
Roth: Oh ja. Wenn wir uns entlang des Wertstroms organisieren wollen, heißt das, dass wir die Organisation verändern müssen. Bei der Veränderung einer Organisation kommt es immer zu einem Machtverlust.
Entscheidungen werden neu von einem Team getroffen und du als Manager hast plötzlich weniger Entscheidungsspielraum. Das führt ganz oft zu Problemen, weil sich mit der Organisation auch die Führung ändern muss. Der klassische Manager muss sich nun zum Leader oder Coach wandeln. Diesen Schritt gehen die meisten Unternehmen aber leider nicht. Ich habe schon erlebt, dass das ganz konkret torpediert wird, da Karrieren auf dem Spiel stehen.
Ich habe schon mit Leuten in Unternehmen geredet, in denen wir eine Transformation durchgeführt haben, die mir sagten: "Ich weiß nicht mehr, was ich machen soll, ich habe jetzt zehn Jahre auf diese Position hingearbeitet und jetzt gibt es diesen ganzen Karrierepfad nicht mehr." Die waren Abteilungsleiter, aber wenn man Silos auflöst und Teams befähigt, braucht es diesen Posten nicht mehr. Diesen Frust kann ich verstehen. Allerdings muss das so gemacht werden, wenn sich wirklich etwas ändern soll: Entweder man verändert die Ablauforganisation, oder - noch besser - die Aufbauorganisation. Aber vor Letzterem scheuen sich die meisten Unternehmen.
Golem.de: Zühlke ist jetzt kein junges Unternehmen mehr. Wie wurde der Strukturwandel bei Zühlke umgesetzt?
Roth: Wir hatten genau die gleichen Probleme und es dauerte eine Weile, bis das verstanden wurde. Auch bei uns war es so, dass manche Personen Macht abgeben mussten. Früher mussten wir immer bei der Geschäftsführung pitchen, wenn wir eine neue Idee, für die wir Zeit und Geld brauchten, umsetzen wollten. Manchmal hat die Geschäftsführung die Idee verstanden, manchmal haben wir Budget bekommen, manchmal auch nicht.
Wir haben eine angepasste Form der Helix-Organisation eingeführt und uns damit entlang des Wertstroms organisiert. Auf der Horizontalen haben wir die Markt-Units, die sich auf unsere Kernmärkte konzentrieren. Auf der Vertikalen haben wir unsere Practices, die die Kompetenzen bereitstellen. Jede Markt-Unit und Practice hat ihr eigenes Budget und setzt es ein, wie sie es für richtig hält. Das hat zu mehr Autonomie und unternehmerischem Denken geführt. Wir haben jetzt weniger Manager und einige von ihnen mussten sich auch mit neuen Rollen zufriedengeben.
Golem.de: Was sind aus Ihrer Sicht gute Wege, um DevOps einzuführen - vielleicht auch in einem Unternehmen, das nicht dieses Ingenieursverständnis hat?
Roth: Es ist wie mit allem: Starte klein. Versuch ein Team mit geeigneten Personen auszuwählen, die einen gewissen Leuchtturmcharakter haben und gut im Unternehmen vernetzt sind. Zeig dem Unternehmen so, dass es funktioniert. Und von da aus änderst du das nächste Produkt und das nächste und so weiter. Mach das rollierend, versuche es nicht überall gleichzeitig einzuführen.
Solche Change-Prozesse können Unternehmen auch lähmen. Wenn du Change zu groß einführst, wird dein Unternehmen nur mit diesem Change beschäftigt sein. Wenn du ihn kontinuierlich einführst, hast du die Chance, dass das Unternehmen den Change besser verdauen und kontinuierlich lernen kann. Aber es dauert auch länger.
Zu wenig Geduld bei der Transformation
Das Blöde für den CEO ist, dass so ein Ansatz mehrere Jahre dauert. Ganz oft wollen sie schnelle Ergebnisse. Vor allem bei börsennotierten Unternehmen ist es so, dass man den großen Wurf machen und die Transformation dann abschließen will. Das Ding ist nur: So eine Transformation endet nie. Das ist ein kontinuierlicher Prozess.
Golem.de: Jetzt haben wir darüber gesprochen, wie die Unternehmen ihre Prozesse transformieren. Aber wie sind Sie denn zu der Einschätzung gekommen, dass DevOps der beste Weg ist, so einen Wertstrom zu organisieren?
Roth: Im Prinzip durch Faulheit (lacht). Als ich nach der Universität, im Jahre 2002, bei Zühlke als Programmierer angefangen habe, hat mich genervt, dass ich immer wieder die gleichen Tests bei meinen Applikationen durchführen musste. Du machst eine Änderung und musst schon wieder die gleichen Tests manuell durchführen. Weil mir das zu blöd war, habe ich angefangen zu automatisieren, immerhin bin ich ja Programmierer!
Die Tests wurden mit der Zeit immer größer, ausgefeilter, aber auch wartungsintensiver. Aber sie wurden immer lokal durchgeführt. Dann kam der Team-Foundation-Server. Ein Continuous Integration System, das war mein erster zarter Berührungspunkt mit "DevOps".
Golem.de: Also haben Sie den Grundstein für Ihre jetzige Position schon vor 20 Jahren gelegt.
Roth: Im Prinzip schon. Es ist eine Journey, in der man Fehler macht, lernt und so kontinuierlich das Mindset aufbaut. Aber ich glaube, den größten Impact hatten die Bücher The Phoenix Project, DevOps Handbook, Accelerate. Vor diesen Büchern hatte ich verschiedene Lösungsansätze für Herausforderungen. Nach dem Lesen dieser Bücher hatte ich wirklich verstanden, warum diese Lösungsansätze funktionieren.
Gute Ausbildung und Start-up-Förderung in der Schweiz
Golem.de: Zühlke hat seinen Sitz in der Schweiz. Wie steht es um die Technologiebranche dort?
Roth: Man sieht viele Start-ups, die kommen, aber auch gehen. Da sind pure Software-Start-ups wie Doodle dabei. Viel interessanter sind Start-ups wie Cellsius, die das batteriebetriebene Flugzeug E-Sling entwickeln. Oder Curtiss, die am Laufmeter künstliche Haut herstellen, die bei Verbrennungsopfern eingesetzt werden kann.
Wenn ich die Start-up-Szene in der Schweiz anschaue, erkenne ich einen Trend in Richtung von cyberphysikalischen Systemen - also einer Kombination von Hardware und Software. Aktuell sieht man viele Finanz-Start-ups, die Probleme haben und wieder verschwinden.
Golem.de: Warum sind diese Produkte in der Schweiz verbreiteter als reine Softwareanwendungen?
Roth: Ich sehe da einen interessanten Punkt: DevOps kommt von Agile, Agile kommt von Lean und Lean kommt vom Toyota Production System - also aus Fabriken. Zurzeit sehe ich, dass dieser Ansatz auch immer stärker bei der hardwarenahen Entwicklung in der Schweiz ankommt.
Golem.de: Beeinflusst so ein Workflow, so eine Philosophie, also direkt die Art von Produkten, die damit entstehen?
Roth: Ich glaube, der Einfluss ist sehr groß. Du hast einen iterativen Ansatz, mit dem du kleine Experimente wagen, Feedback einholen und dann dein Produkt so bauen kannst, dass es das Problem des Kunden löst. Die Start-ups in der Schweiz haben das geschnallt.
Golem.de: Hat die Schweiz ihre Start-up-Szene der guten Ausbildung zu verdanken?
Roth: Eine gute Ausbildung ist sehr wichtig und die ETH hat wirklich eine sensationell gute Ausbildung. Ich würde es aber nicht nur darauf zurückführen, die Firmengründung wird nämlich auch gefördert. Start-up-Förderung ist der Key, aber wenn unsere Studenten nicht so gut ausgebildet wären, würden sie gar nicht erst so weit kommen.
Ent-to-End-Entwicklung "sträflich vernachlässigt"
Was ich auch in der Schweiz immer wieder bemängele, ist, dass man zwar die Technik lernt, also zu programmieren oder ein Kubernetes-Cluster aufzusetzen. Aber End-to-End-Entwickeln von Produkten wird meiner Meinung nach noch sträflich vernachlässigt. Dabei spart man viel Geld und Zeit, wenn man das Richtige richtig entwickelt - so dass es auch testbar und betreibbar ist.
Golem.de: Sollten die Studenten also schon mehr über die Prozesse in einem Unternehmen lernen?
Roth: Meiner Meinung nach ja. Studenten sollten nicht in Projekten, sondern in Produkten denken, die einen konkreten Nutzen haben, testbar und betreibbar sind.
Golem.de: Wie oft sehen Sie selbst noch Code?
Roth: Es gibt Dinge, die du großartig mit Code lösen kannst, aber irgendwann kommst du an den Punkt, wo du merkst, dass es Herausforderungen gibt, die du nicht mit Code lösen kannst. Du erkennst dann auch, dass das Lösen dieser Herausforderungen viele Probleme der Programmierer löst - ja, dass es sogar dazu führt, dass Code nicht geschrieben werden muss oder eben der richtige Code richtig geschrieben werden kann. Nichtsdestotrotz versuche ich, immer fit zu bleiben beim Coden.
Ich mache bei den Open Hacks bei Zühlke mit, dort machen wir meistens Pair Programming. Ich bin natürlich nicht mehr so fit wie meine Kollegen, aber ich versuche dranzubleiben. In der Produktentwicklung bin ich meistens weg vom Code, aber durch mein breites technisches Know-how kann ich sehr viele Dinge in die richtige Richtung treiben.
Golem.de: Und was ist die richtige Richtung?
Roth: Mit der Geschwindigkeit neuer technologischer Möglichkeiten müssen Unternehmen sich umorganisieren, damit sie die Digitalisierung nicht verpassen. Das heißt, sie müssen sich entlang des Wertstroms organisieren.
Produktteams liefern mittels digitaler Förderbänder (CI/CD Pipelines) kontinuierlich Wert für die Kunden. Diese digitalen Förderbänder sind wiederum das Produkt des Plattform Engineering Teams, das sicherstellt, dass die Produktteams so effizient und unabhängig wie möglich Wert liefern können. Das ist die Industrialisierung der Softwareentwicklung, die digitale Fabrik der Zukunft.