DevOps ist nicht das, was Ihre Firma braucht, es sei denn Sie betreiben Lean Startup, eine Social-Website, ein Musik-Streaming-Dienst oder ähnliches. Was Sie stattdessen brauchen, sind die Ergebnisse, die damit erzielt werden können.
Begrenzen wir das Thema auf rund 80% der Fälle, denen ich in meiner Arbeit als Agile Coach begegne.
Zum Teil verdankt DevOps seinen Erfolg dem Bestseller The Phoenix Project. Das Buch beschreibt die Art von IT-Katastrophe, an der viele „normale“ Firmen leiden. Es spricht Leser an, die den Schmerz schlechter Qualität in der IT nachempfinden können. Im Buch rettet DevOps eine Firma vor der Pleite. Ein Happy End also.
Wenn Sie keine praktische Erfahrung mit Agile und Lean in der IT haben, dann kann DevOps schon verwirrend sein. Es herrschen viele verschiedene Ansichten über DevOps, die, je nach Kontext und wen man fragt, variieren. Sie werden also keine einheitliche Definition dafür finden. Und wenn Sie der Meinung sind, doch eine gefunden zu haben, wird sie von den DevOps-Leuten bestritten, da die Definition von DevOps noch nicht ausgereift ist.
Es kann also schwierig sein anzukündigen, dass die IT in Ihrer Organisation DevOps „machen“ wird. Wie kann das implementiert werden, wenn Ihre Mitarbeiter sich nicht auf ein gemeinsames Verständnis des Konzeptes einigen können?
Umgehen wir das Problem indem wir eine andere Frage stellen: „Was ist das gewünschte Ergebnis von DevOps?“ oder: „Was ist der Geschäftswert von DevOps?“
Eine Firma, die mit DevOps erfolgreich arbeitet, kann von sich behaupten: „Wir können jederzeit ein fehlerfreies Rollout jeder Software, die wir – oder unsere Kunden – brauchen, starten“.
Dies zu bewerkstelligen verlangt viel Automation, Feedback und Testen. Im Buch ist es dargestellt als „first and second Way“.
Zur obigen Beschreibung des Geschäftswertes könnte man hinzufügen: „Das Ziel erreichen und in Zukunft beibehalten“, das könnte „the third Way“ sein.
Es ist mir schon bewusst, dass die Autoren dieses hervorragenden Buches womöglich beleidigt sein könnten. Meine Beschreibung von DevOps ist eine fürchterliche Übervereinfachung des Umgangs mit IT-Problemen, die über Jahre gewachsen sind und deren Lösung sich äußerst schwierig gestaltet. Im Grunde möchte ich sagen: DevOps handelt vom „Machen“.
Vor allem für bestehende Organisationen aber ist die Durchführung von DevOps keineswegs schnell und einfach durchzusetzen. Der Grund dafür ist die technische Altlast innerhalb der IT, woran jede Organisation leidet. Eine fiktive Geschichte lässt sich leichter schreiben, als sich Taten in der realen Welt verwirklichen lassen. Lesen Sie dazu meinen ersten Beitrag unter demselben Titel.
Mein Vorschlag für ein Unternehmen mit einem durchschnittlichen Technologiestand ist: Konzentrieren Sie sich auf den Geschäftswert. So bleibt alles leicht verständlich.
Aufgrund meiner Überlegungen rate ich davon ab, eine einheitliche Definition von DevOps anzustreben. Stattdessen möchten Sie vielleicht eine einzige Userstory erarbeiten. Nehmen wir als Beispiel den großen Chemiekonzern, für den ich gerade tätig bin. Eine solche Story könnte lauten: „Als ‚Business‘ möchte ich eine neue Version eines Softwareproduktes auswählen und ausrollen, ohne dass IT-Mitarbeiter per Hand eingreifen müssen“.
DevOps folgt dann ganz natürlich, sobald diese einfache Userstory aufgestellt wird. Wenn sie einmal besteht, dann wird jeder in Ihrer Firma wissen, was DevOps bedeutet.