Erfolgreiche Unternehmen haben eines gemeinsam: Sie stellen das sogenannte \"Humankapital\" ins Zentrum ihrer Aktivitäten. DevOps-Veteran John Willis (Docker) erklärt im Interview, was DevOps-Unternehmen anders machen und weshalb Tools ohne die richtige Kultur nichts verändern. DevOps – eine Bestandsaufnahme.

Wie wird man ein DevOps-Unternehmen?

JAXenter: Hallo John. DevOps wird ja meist mit gewissen Techniken und Tools in Zusammenhang gebracht: Continuous Delivery, Container, Puppet, Chef, Jenkins, etc. Wenn du mit Leuten über DevOps redest, dann mündet das Gespräch aber schnell ins Thema Unternehmenskultur. Kannst du uns erklären, was „DevOps-Kultur“ wirklich bedeutet? Warum ist der kulturelle Aspekt so wichtig?

Im Kern steht das Problem, wie man Leute dazu bringt, zusammen zu arbeiten.

John Willis: Im letzten Jahr habe ich viel darüber nachgedacht, wie wir die Botschaft der DevOps-Bewegung in höhere Organisationsebenen tragen können. Und ich habe mich damit beschäftigt, wie man dem CEO eines großen Unternehmens DevOps beschreiben könnte. Das wurde dann irgendwie zu dem Thema, um das herum ich meine Talks auf Konferenzen erstellt habe.

Der Hintergrund ist der Folgende: Aus Umfragen mit hochperformanten Unternehmen haben wir gelernt, dass das, was wir DevOps nennen, ein wiederkehrendes Muster zu haben scheint: Das sogenannte „Humankapital“ wird dort sehr hoch priorisiert. Nun wird das Wort „Humankapital“ heute nicht mehr gerne genutzt, da es zu sehr nach „Human Resources“ klingt, ein Relikt aus der Vergangenheit. Aber das sind nur Worte. Am Ende des Tages kommt es in Organisationen immer noch darauf an, Humankapital in hochperformantes unternehmenrisches Kapital zu verwandeln. Und dabei muss unsere DevOps-Botschaft klar sein: Es geht in dieser Frage zentral darum, wie Menschen innerhalb einer Organisation zusammenarbeiten.

Natürlich ist es auch interessant und wichtig, die Tools zu betrachten, mit denen Unternehmensziele  erreicht werden können. Doch im Kern steht das Problem, wie man Leute dazu bringt, zusammenzuarbeiten.

Andrew Schaefer, ein guter Freund und DevOps-Speaker, hat einmal gesagt, dass es eigentlich keinen Fachkräftemangel in der IT gibt. Silicon Valley wird das nächste „große Talent“ schon produzieren. Und er sagt, dass das eigentliche Talent im zugehörigen Unternehmen liegt. Denn allzu oft wird vergessen, dass ein Unternehmen erst einmal lernen muss, eine Learning Organisation (dt. lernendes Unternehmen) zu sein. Das ist die Stelle, wo das Humankapital ins Spiel kommt, wo eins plus eins plötzlich fünf ergibt, wenn man herausfindet, wie Menschen zusammenarbeiten, einander vertrauen, wenn man eine sichtbare, transparente Umgebung schafft.

Die Tools, die man anschließend einsetzt, sind – wie erwähnt – zwar wichtig, aber nicht annähernd so wichtig wie das Wissen, wie man Menschen dazu bringt, gemeinsam in einer Vertrauensumgebung zusammenzuarbeiten. Durch dieses Wissen erreichen erfolgreiche Unternehmen die entscheidenden Durchbrüche, die sie von anders agierenden Unternehmen unterscheiden.

JAXenter: Die Frage lautet also, wie man sein Unternehmen soweit bekommt. Wie wird man ein DevOps-Unternehmen?

John Willis: Genau das ist der springende Punkt. In meiner Präsentation auf der DevOpsCon habe ich versucht, begreiflich zu machen, dass es um Humankapital geht. Es gibt Unternehmen, die das bereits verstanden haben.

Eine andere Sache ist, dass es in Großunternehmen bereits 50 Jahre Erfahrung mit gewissen Methoden gibt, die zwar nicht unmittelbar dem DevOps-Kontext entspringen, die aber isomorph auf DevOps-Szenarien abgebildet werden können und das, was wir DevOps nennen, untermauern. Beispielsweise die Erfahrungen aus dem Lean Management.

Von Lean kann man so viel lernen. Wenn man beispielsweise in einem Fertigungsunternehmen DevOps einführen möchte, dann besteht eine gute Chance, dass ein großer Teil der Mitarbeiter Lean und alle damit verbundenen Prinzipien bereits im Detail verstanden haben. Alles, was dann getan werden muss, ist der Führungsriege zu sagen: „Wir machen doch schon DevOps.“

Das zweite Thema ist die Learning Organisation. Ich behaupte, DevOps ist ein Stuhl mit drei Beinen: Lean, Learning Organisation und Vertrauenskultur. Zu Learning Organisations lässt sich sagen, dass sich viele Kollegen wahrscheinlich schon mit John Carter und Peter Senges „The Fifth Disciple“ auseinandergesetzt haben. Es ergeben sich also Anknüfungspunkte für Mitarbeiter, die sagen „Oh, das ist also DevOps? Oh, DevOps ist Lean? Oh, DevOps bedeutet Learning Organisation? Peter Senge, John Carter?”

Wer als IT-Coach tätig ist, hat vermutlich auch schon das dritte Stuhlbein kennengelernt: den menschlichen Faktor beim Bau von resilienten, sich selbst korrigierenden Systemen. Es gibt unglaublich reichhaltige Arbeiten über System Thinking, über vorwurfsfreie Unternehmenskulturen und Post-Mortem-Retrospektiven ohne Schuldzuweisungen.

Resilience-Experten wie Cindy Decker, Dr. Cook oder Dr. Wood werden im Normalfall erst hinzugezogen, wenn das Baby bereits in den Brunnen gefallen ist. Sie beschäftigen sich aber nicht mit der einen Ursache für einen Fehler, sondern mit den systemischen Faktoren, die zum Scheitern eines Projektes beigetragen haben.

Betrachten wir einmal ein Beispiel: Wenn etwa ein Kind im Krankenhaus stirbt, wird niemand gerne zugeben wollen, wer daran schuld ist. Die Krankenschwester wird nicht zugeben wollen, dass sie den Tisch umgeworfen hat und dadurch eine falsche Nadel benutzt wurde, nicht wahr? Die Aufgabe der Resilience-Engineering-Verantwortlichen ist es dann, mit den zugrundeliegenden Informationen sicherzustellen, dass sich solche Fehler nicht wiederholen. Der Schlüssel dazu liegt in einem psychologischen Sicherheitsgefühl, was im Prinzip bedeutet, eine Umgebung ohne Schuldzuweisungen zu schaffen.

Cindy Decker ist Autorin des Buchs „Just Culture“, wo sie über gängige Verurteilungsmuster wie „Du hast es kaputt gemacht, du gehst in den Knast“ spricht. Sie thematisiert das Ganze auf faszinierende Weise in Form einer Systemkritik. Auf der Metaebene bedeutet das für uns, dass wir unser Konstrukt zwar „DevOps“ nennen können und das toll ist. Aber das wirklich Wichtige ist, die entgegengebrachten Widerstände zu überwinden und zu sagen: „Ihr kennt das doch alles schon. Manche hier arbeiten Lean, manche sind eine Art ‚Resilience Engineer’ und manche beschäftigen sich mit Learning Organisations“.

DevOps-Transformation – wie startet man?

JAXenter: Wir sprechen hier ja über einen transformierenden Prozess. Wie geht man diese Transformation an? Handelt es sich bei DevOps um eine Graswurzelbewegung? Oder muss DevOps Top-down vom Management getrieben werden?

John Willis: Man braucht beides. Man braucht Garantien und Grassroots. DevOps kann als Graswurzelbewegung von unten funktionieren – man muss nur etwas tricksen und clever vorgehen. Das ist im Grunde genau der Hebel, an dem ich mit meinen Trick ansetze: „Hey, du arbeitest schon Lean. Lass mich dir zeigen, warum!“

Für DevOps braucht man bneides: Garantien und Grassroots.

Doch am Ende des Tages benötigt man, wie bei jeder Unternehmenstransformation, natürlich auch den Support der Führungsetage. Viele Führungskräfte und einige wirklich große Firmen, mit denen ich mich unterhalten habe und die in dem, was wir DevOps nennen, gute Fortschritte machen, geben ihren Mitarbeitern für diesen Fortschritt vor allem eines: viel Vertrauen.

Wenn ich also zu solchen Unternehmen gehe und die Mitarbeiter frage: „Was denken eure Führungskräfte über das, was ihr tut?“, dann sagen sie: „Weißt du was? Sie vertrauen uns. Sie lassen uns Lean arbeiten.“ Auf der anderen Seite fügen sie aber auch meist hinzu: „Wir sind allerdings noch nicht an dem Punkt, wo wir eine Toyota vs. General-Motors-Geschichte erzählen könnten.“

Ein Beispiel: Target, eine amerikanische  Großhandelsfirma, hat bisher vermutlich mehr in DevOps investiert als alle anderen Unternehmen, die ich bisher gesehen habe. Auf 15.000 Quadratmetern haben sie ein sogenanntes „DevOps Dojo“ in ihrem Hauptsitz eingerichtet, um die Umsetzung von DevOps weiter zu verfolgen und anderen Firmen die Möglichkeit zu geben, sich dort damit zu beschäftigen.

Ich habe mit vielen dieser Unternehmen gesprochen, aber die meisten haben noch nicht diesen Moment der Erkenntnis: „Aha, Target wächst besser, weil sie DevOps machen.“ Wir befinden uns bei DevOps also immer noch in einer Anfangsphase. Einige Glückliche haben den nötigen Support von Führungskräften, die sagen: „Ich glaube, dass das, was ihr vorhabt, richtig ist. Ich kann die schrittweise Veränderung sehen.“ Aber wir sind immer noch nicht weit gekommen, wenn es um den Zusammenhang zwischen DevOps und den harten Business-Zahlen geht. Diese Version unserer Geschichte müssen wir weiter erzählen. Es ist also ein verzwicktes Spiel.

DevOps Tools versus DevOps-Kultur

JAXenter: Wir haben uns nun viel über die Kultur unterhalten, aber es gibt natürlich auch die andere Seite:  technische Aspekte wie z.B. Microservices, Container-Technologien, Continuous Delivery Tools oder die neue Welt der Cloud-Plattformen. Glaubst du, dass es eine Verbindung zwischen diesen Technologien und den kulturellen Veränderungen gibt?

John Willis: Es gibt diesbezüglich eine interessante Konvergenz – aber wir reden hier über ein unterschiedliches Abstraktionslevel. Ich argumentiere, dass, wenn die kulturellen Aspekte einer Firma falsch konstituiert sind, der ganze Rest an irgendeinem Punkt fehlschlagen wird – außer man hat eine Menge Glück.

Am anderen Ende der Diskussion stehen die Tools – und ich denke, dass die Auswahl der richtigen Tools zweifelsohne wichtig ist. Manche sagen vermutlich: „Ich nutze am liebsten Chef“ oder „Ich liebe Docker“, „Ich benutze Jenkins und Git“ und so weiter. Aber der Knackpunkt ist, dass es meiner Meinung nach eine Balance zwischen den richtigen Ansätzen gibt. Die richtige Kultur und die besten Tools? – Perfekt! Aber sobald die Kultur schlecht ist, geht alles den Bach hinunter.

Mehr zum Thema: Continuous Delivery im Expertencheck: Softwarearchitektur und die richtige Tool-Auswahl

Darüber hinaus gibt es noch eine wirklich wichtige mittlere Ebene: Meta-Ideen wie Cloud Native oder Microservice-Architekturen, die als Mittel dienen können, um ein Unternehmen zu verändern. „Ich entwickle meine Software mittels Container-Technologie in einer Microservices-Infrastruktur oder als SOA-Version neu.“ Diese Ebene ist wichtig und vermutlich auch wichtiger als die Tools selbst, aber weniger wichtig als die Kultur.

Eine der schönsten Konvergenzen im Bereich der IT-Technologien dürfen wir gerade miterleben. In den letzten 10 Jahren haben wir einerseits die Entwicklung von Eric Evans‘ Domain-Driven Design, über SOA und Twelve Factor Apps, bis hin zu den Microservices miterlebt. Andererseits setzten sich zeitgleich Windows Container und Docker durch – auch für den Betrieb in Produktivsystemen. Und plötzlich, vermutlich um 2014, 2015, treffen sich diese beiden Konzepte: Beide sind Lean und ergänzen sich wunderbar. Oh mein Gott, Microservices und Container, das passt ja perfekt zusammen!

Als Industrie haben wir dabei noch mehr Glück gehabt: Es kam Cloud-Native als Methode zur Entkopplung und Art, um mit Network Computing umzugehen. Derzeit findet wirklich eine interessante Konvergenz zwischen Containern, Cloud-nativen Plattformen bzw. Frameworks und Microservice-Architekturen statt. Diese drei Technologien funktionieren außerordentlich gut zusammen. Aber auch hier gilt wieder: Ohne die richtige Kultur helfen auch diese technologischen Ansätze nicht viel weiter.

JAXenter: Vielen Dank für das Gespräch!

Das Interview live von der DevOpsCon

Mehr zum Thema:

Was ist eigentlich DevOps?

John Willis has worked in the IT management industry for more than 35 years. Currently he is an Evangelist at Docker Inc. Prior to Docker Willis was the VP of Solutions for Socketplane (sold to Docker) and Enstratius (sold to Dell). Prior to to Socketplane and Enstratius Willis was the VP of Training & Services at Opscode where he formalized the training, evangelism, and professional services functions at the firm. Willis also founded Gulf Breeze Software, an award winning IBM business partner, which specializes in deploying Tivoli technology for the enterprise. Willis has authored six IBM Redbooks for IBM on enterprise systems management and was the founder and chief architect at Chain Bridge Systems.