Öltanker mit der Agilität eines Schnellboots DevOps für mehr Sicherheit und Qualität im Konzern

Autor / Redakteur: Sven Euteneuer * / Stephan Augsten

Der digitale Wandel erfordert von Unternehmen mehr Agilität. Manche Konzerne und größere Unternehmen wirken aber behäbig wie Öltanker. DevOps-Strategien können hier für schnellere Reaktionen und bessere Steuerung sorgen.

Firmen zum Thema

Mit DevOps-Strategien lassen sich auch die Prozesse eines Großkonzerns agiler gestalten.
Mit DevOps-Strategien lassen sich auch die Prozesse eines Großkonzerns agiler gestalten.
(Bild: The Photographer - Wikimedia.org / CC0 )

Der Wettbewerb am Markt für Software-basierte Systeme wird immer härter. Gerade jene Unternehmen, die technologisch und prozessual nicht „auf der grünen Wiese“ starten können, verlieren im Kampf um Kunden gegen Startups und kleinere, wendige Firmen. Unabhängig von Standort und Größe entsteht eine direkte Konkurrenz

Neue oder verbesserte Produkte müssen immer schneller eingeführt werden. Trotzdem muss die Qualität der Produkte stimmen. Denn Mängel werden über soziale Medien und App-Stores diskutiert und können nicht verheimlicht werden. Und beispielsweise in der Automobilindustrie oder auch bei der Bahn können Schwächen in der Qualität lebensgefährliche Folgen haben.

Den Herausforderungen mit modernen Ansätzen begegnen

Die Situation ändert sich dabei in zweierlei Hinsicht: In der Dynamik der Anpassung und – bedingt dadurch – beim Einsatz neuer Entwicklungs- und Testmethoden. Die Entwicklung muss sich auf kurze Feedback-Schleifen einstellen, um schnell auf neue Kundenanforderungen oder gefundene Mängel reagieren zu können. Häufige Anpassungen erfordern auch mehr Testaktivitäten, speziell bei Regressionstests.

Gleichzeitig wird durch den Wechsel mit nur kleinen Änderungen auch der Einsatz neuer Testmethoden ermöglicht. Zum Beispiel, dass die Kunden selbst gezielt als Testpersonen eingebunden werden – üblicherweise ein gezielt ausgewählter Teil der Kundschaft, so dass für den überwiegenden Teil der Nutzer kein Unterschied sichtbar wird.

Für den IT-Betrieb bedeutet dieser Prozess, dass häufiger und flexibler neue Software verteilt werden muss (Software Deployment). Zudem müssen die Systeme skalierbar sein, das heißt, die Leistungsfähigkeit der Produktionsumgebung muss sehr flexibel steigenden Bedarfsfällen, zum Beispiel durch höhere Nutzerzahlen, oder dem parallelen Betrieb unterschiedlicher Versionsstände zum Live-Test, genügen können. Andernfalls besteht die Gefahr, den Geschäftserfolg durch Performance-Probleme oder verfrüht global ausgerollte Änderungen aufs Spiel zu setzen.

DevOps-Ansätze unterstützen all diese Anforderungen auf den folgenden drei Ebenen von Software-Entwicklung, Test und Betrieb:

  • 1. Entwicklung und Betrieb arbeiten sehr eng zusammen; und zwar so eng, dass zwischen beiden Gruppen nicht länger unterschieden wird. Stattdessen werden zum Beispiel gemeinsame Feature-Teams gebildet, die sich um eine bestimmte Funktionalität der Anwendung kümmern, diese gemeinsam entwickeln und zugleich deren Betrieb realisieren.
  • 2. Die interne Struktur einer Anwendung wird nach Funktionalität gegliedert, nicht länger nach technischen Ebenen oder Komponenten. Das wirkt sich natürlich auf die Architektur einer Anwendung aus: Über Microservices (ein Architekturmuster) wird die Unabhängigkeit von Entwicklung und Deployment ermöglicht. Auf diese Weise unterstützt die Software-Architektur den Einsatz innovativer Aspekte in Organisation (Feature-Teams), Betrieb (Skalierbarkeit) oder Testmethodik (A/B-Testing).
  • 3. Schließlich erfordern schnelle Marktzyklen, kurze Feedbackschleifen und häufige (Regressions-)Tests eine weitreichende Automatisierung von Tätigkeiten, nicht nur im Hinblick auf Testautomatisierung – auch die Erzeugung, Betankung und Bereitstellung von Test- und Produktionsumgebungen gehören dazu.

Agile Arbeitsweisen setzen sich nicht nur auf der Anbieterseite durch. Viele Kunden fordern die Umstellung traditioneller Prozesse und Software-Architekturen auf DevOps ein. Wie ein Unternehmen DevOps in die eigenen Prozesse integriert, hängt dabei von der Ausgangslage ab. Manchmal ist es möglich, ein Entwicklungsprojekt „auf der grünen Wiese” aufzusetzen.

Meist bewegt sich ein Projekt jedoch innerhalb komplexer organisatorischer, prozessualer und technologischer Rahmen, die im Unternehmen vorgegeben oder nur langsam und mit hohem Aufwand zu ändern sind. Besonders in größeren Unternehmen sind solche Prozesse oft relativ starr; denn die etablierten Strukturen widersetzen sich prinzipbedingt dem erforderlichen Wandel. Große Unternehmen wirken hier wie Öltanker, die plötzlich wie Segelboote im digitalen Wind wendig sein sollen.

DevOps einzuführen, ist ein Weg mit (tausend) Schritten

Viele Unternehmen setzen in DevOps ganz gezielte Erwartungen – manche von ihnen sind realistischer, andere realitätsferner. Da sich auch die Ausgangssituationen erheblich unterscheiden, ist jeder Weg in Richtung DevOps individuell. Um dies berücksichtigen zu können, sind mehrere Schritte mit diversen Feedbackschleifen notwendig.

Zuerst muss geklärt werden, was Ausgangslage und was Ziel ist. Das findet man mit einer Reihe von Workshops heraus. Sie betreffen die Organisation selbst, aber auch Prozesse, Methoden und Tools – wie etwa Continuous Deployment Pipelines.

Ergebnis eines jeden Workshops ist die Gegenüberstellung der aktuellen Situation mit der für die Organisation richtigen DevOps-Zielsituation. In Abhängigkeit dieser Ergebnisse werden im Abschluss der Workshops dann die eigentlichen Maßnahmen für notwendige Veränderungen festgelegt.

Anschließend werden Maßnahmen in einer Umsetzungsiteration im Unternehmen eingeführt. So ist sichergestellt, dass nicht zu viele Änderungen auf ein Mal versucht werden und dass bereits beschlossene Maßnahmen erfolgreich umgesetzt sind, bevor weitere, gegebenenfalls darauf aufbauende Maßnahmen angegangen werden.

Organisation und Prozesse

Im ersten Bereich werden Prozesse, Organisation und die Schnittstellen zwischen den einzelnen Teams unter die Lupe genommen. Keine dieser Schnittstellen darf bei der Einführung von DevOps übergangen werden. Möglich ist, dass die eine oder andere Schnittstelle in der neuen Organisationsstruktur überflüssig wird oder sich als kontraproduktiv erweist.

Genau diese Schnittstellen müssen im eigentlichen Veränderungsprozess angepasst werden und benötigen besondere Aufmerksamkeit. Tatsächlich mag es zwischen Teams auch unternehmensspezifische Schnittstellen geben, die sich mit der Einführung von DevOps nicht ändern können. Diese Altbestände müssen dann beibehalten werden und werden möglicherweise im Veränderungsprozess nicht angepasst.

Methoden und Tools

Häufig werden DevOps-Ansätze stark Tool-orientiert gesehen. Betrachtet man allerdings ausschließlich die Einführung neuer Tools, scheitert der Versuch eines DevOps-Umstiegs oft an der mangelnden Gesamtsicht auch auf organisatorische Aspekte. Konzentriert man sich umgekehrt nur auf die oberste Ebene im Veränderungsprozess, das heißt eine Veränderung von Kultur und Aufbauorganisation, wird häufig die Einführung geeigneter Methoden und Tools vergessen.

Die Umstellung auf DevOps sollte von der vorgegebenen Situation im Unternehmen ausgehen. Für die Entwicklungsphase wird die Toolkette von der integrierten Entwicklungsumgebung (IDE) über Entwickler-Tests, technische Qualität, funktionale und nicht-funktionale Tests bis zur Testautomatisierung betrachtet.

Bei vielen Tools bieten sich durchaus Möglichkeiten, ihren Einsatz auf die Bedarfe von DevOps zu optimieren. Das gilt auch für die im Betrieb verwendete Toolkette (Umgebungsmanagement mit Fokus auf Bereitstellung und Virtualisierung, Daten-Management, Monitoring und allgemeiner Betrieb) sowie für das Konfigurations-Management der unterschiedlichen Software-Artefakte und das Anforderungsmanagement.

Jeder agile Ansatz lebt von der Idee transparenter Prozesse. Aus diesem Grund basieren alle Entscheidungen innerhalb der in Entwicklung und Betrieb genutzten Prozesse auf gut begründeten Kontrollmechanismen. Die Einführung von Dashboards spielt daher eine Schlüsselrolle im DevOps-Veränderungsprozess.

Es wird auch die Zielarchitektur für die CD-Pipeline (Continuous Deployment) festgelegt. Dabei muss die Integration unveränderlicher Schnittstellen zu den Altbeständen an Tools und Systemstrukturen berücksichtigt werden. Im Anschluss werden dann die Architektur und die zunächst nur grob festgelegten Tools weiter verfeinert und pilotiert, bevor sie im Zuge des Veränderungsprozesses tatsächlich schrittweise implementiert werden.

Kultureller Wandel und Veränderungsprozess

Beim Begriff DevOps wird häufig nur an die Tools der Continuous-Delivery-Pipeline gedacht. Doch die volle Kraft des DevOps-Ansatzes entfaltet sich nur, wenn auch der damit einhergehende Kulturwandel berücksichtigt wird. Kunden sollten daher das Drei-Wege-Modell (Three Ways) von DevOps1 verstanden haben:

  • „The Principles of Flow“
  • „The Principles of Feedback“
  • „The Principles of Continual Learning and Experimentation”

Es bringt daher nur einen geringen Nutzen, DevOps als Rundumschlag einführen zu wollen, oder nur die Toolkette zu implementieren und zu glauben, existierenden Prozesse von Software-Entwicklung und IT-Betrieb damit optimieren und besser verzahnen zu können. Stattdessen bedarf es eines langen Atems und der schrittweisen Einführung des Drei-Wege-Modells innerhalb des Veränderungsprozesses. Der Workshop ist dazu da, genau dieses neue Denken zu verdeutlichen und innerhalb der Organisation zu festigen.

Vorteile eines ganzheitlichen Ansatzes

Viele Unternehmen spüren in Zeiten des digitalen Wandels den Druck zu mehr Agilität und sehen in der Implementierung von DevOps einen vielversprechenden Weg zu diesem Ziel. Jedoch wird der daraus einhergehende, massive Wandel oft nicht wirklich verstanden. Die oben beschriebene Vorgehensweise unterstützt Unternehmen dabei zu erkennen, was für sie Sinn ergibt und wie für sie entsprechend Maßnahmen implementiert werden können.

Sven Euteneuer
Sven Euteneuer
(Bild: SQS Software Quality Systems)

Allerdings ist es noch viel entscheidender, dass es sich hierbei um den ersten Schritt auf einem iterativen Weg handelt, um diese Veränderung tatsächlich umzusetzen. Ein solch schrittweiser Ansatz ist der einzige, mithilfe dessen derart massive Veränderungen erfolgreich eingeführt werden können.

* Sven Euteneuer arbeitet als Practice Lead Technical Quality bei SQS.

1Kim G., Humble J., Debois, P. &, Willis J. (2016): The DevOps-Handbook. IT Revolution Press, Portland

(ID:45339106)