DevOps@Work (Teil 1)

Digitalisierung, Agilität und DevOps

Digitalisierung wird immer mehr zum Schlagwort für die zukünftige Ausrichtung von großen IT-Organisationen der führenden Branchen – etwa für Banken, Versicherungen oder Organisationen im Gesundheitswesen. Die Aufnahme des Schlagwortes „Digitalisierung“ in die IT-Strategie eines Unternehmens gibt aber nur Auskunft über die zukünftig geänderte Ausrichtung. Die Fokussierung muss allerdings noch konkreter definiert und festgelegt werden. Oft wird im gleichen Atemzug der Begriff „Agilität“ genannt und unter der Annahme, dass Agilität eines der Kernelemente für Digitalisierung ist, beginnt nun die Suche nach unterstützenden Technologien.

Genau zu diesem Zeitpunkt wird dann häufig die Einführung von DevOps gefordert. In der Tat ist „DevOps“ die meist favorisierte Antwort auf die Frage nach einer Technologie zur Umsetzung von Agilität innerhalb der IT-Organisation. Was in der Regel geschieht, ist der Start eines Infrastrukturprojektes zur Einführung von notwendigen Technologien eines zukünftigen DevOps-Technologiestacks. Diese Projekte benötigen jedoch andere Rahmenbedingungen, wenn sie erfolgreich abgewickelt werden sollen, ansonsten besteht die Gefahr, dass Potenziale nur bedingt oder gegebenenfalls gar nicht genutzt werden. Neben der Technologie benötigen erfolgreiche Projekte in diesem Kontext nämlich auch geänderte Aufbau- und Ablauforganisationen, denn die meisten IT-Organisationen sind nicht für diese Philosophie ausgerichtet. Das bedeutet: Damit ein Fundament gelegt werden kann, muss ein entsprechender DevOps-Technologiestack ausgewählt und implementiert werden. Erst dann können Prozess- und Organisationsaspekte fokussiert werden.

DevOps-Definition aus der Praxis

Aber was sind DevOps denn nun genau? Wir erklären es euch. Wir verstehen unter dem Begriff folgendes:

Das Ziel von DevOps besteht darin, die Veränderung einer Software schnellstmöglich in Umgebungen zu überführen. Dazu können produktionsferne und -nahe Systeme gleichermaßen gehören. Die Art und Weise, wie diese Überführung der Software geschieht, muss individuell zwischen Betrieb und Entwicklung für das jeweilige Unternehmen definiert werden – das heißt organisatorisch, prozessual oder technisch.

Spannungsverhältnis zwischen Entwicklung (Dev) und Betrieb (Ops)

Die Tatsache, warum Dev und Ops so schwierig zu vereinen sind, hängt im Kern mit den unterschiedlichen Zielen dieser Funktionsbereiche zusammen. Wie ihr auf der Abbildung seht, existiert ein Zielkonflikt im Verantwortungsübergang zwischen Dev („innovativ und agil“) und Ops („standardisiert und stabil“).

Der DevOps-Technologiestack

Inzwischen existieren am Markt viele ausgereifte Lösungen zum Aufbau eines adäquaten DevOps-Technologiestacks. Die Bandbreite der angebotenen Tools geht von Open Source bis hin zu kommerziellen Lösungen und Mischformen.

Das wesentliche Ziel sollte allerdings erst einmal darin bestehen, im Vorfeld ein Setup zu ermitteln, das sich am Support der Unternehmensanforderungen orientiert. Dieser Schritt ist notwendig, damit Unternehmensanwendungen für Kerngeschäfts-, Management- sowie Unterstützungsprozesse zukünftig erstellt und betrieben werden können.

Der Kosmos an potenziellen Werkzeugen über alle Technologieebenen und Funktionsbereiche ist dabei sehr umfangreich geworden. Welche Werkzeuge für euch in Frage kommen, hängt im Wesentlichen von den folgenden Kriterien ab:

• Welche Anforderungen bestehen im Unternehmen auf Basis der abgeleiteten IT-Strategien?
• Welche abgeleiteten Anforderungen für Dev und Ops existieren im Unternehmen?
• Gibt es Vorgaben aus Governance, Risk und Compliance (GRC)?
• Wie sieht der vorhandene Technologiestack im Unternehmen aus?
• Über welches Skillset verfügen die Mitarbeitenden (intern und extern)?
• Wie hoch ist das Projektbudget?

Warum scheitern DevOps-Projekte?

Ob Planungsprozesse, Unternehmenskultur oder Skills von Mitarbeitenden – die Gründe, wieso ein DevOps-Projekt scheitert oder zumindest nicht sein volles Potenzial entfalten kann, sind vielfältig:

Unternehmenskultur: Die Unternehmenskultur beschreibt letztlich ein Ordnungsmuster für die Art und Weise der Zusammenarbeit. Sofern neu eingeführte Technologien und Kooperationsmodelle nicht auf Akzeptanz oder zumindest Toleranz stoßen, führt dies zur Verlangsamung oder schlimmstenfalls zur völligen Blockierung der notwendigen Veränderungen.

Integration von Altanwendungen: Durch die Auswahl von Anwendungen, die unzureichend dokumentiert oder zu komplex sind, entstehen oft kosten- und zeitintensive Migrationsprojekte. Dadurch können im Betrieb die Vorteile des DevOps-Ansatzes kaum umgesetzt werden.

Planungsprozesse: In vielen Unternehmen wird bereits agil entwickelt, aber weiterhin nach klassischen Vorgehensweisen geplant, Budget zugewiesen und überwacht. Das funktioniert nicht in agilen Softwareprojekten und bei Technologiemigrationen.

Anwendungskomplexität: Eine Anwendung, die aufgrund der Anzahl und Qualität ihrer Schnittstellen und IT-Systeme zu komplex ist, führt im ersten Anlauf hochgradig zu einem Scheitern des Vorhabens.

Skillset der Mitarbeitenden: Die Bewertung von Mitarbeiter-Skills fällt oft sowohl in der Tiefe als auch Breite der vorhandenen Fähigkeiten zu positiv aus. Der Aufwand, um fehlende Skills aufzubauen und anschließend produktiv einzusetzen, wird oft unterschätzt. Direkte Abhängigkeiten zum eingesetzten Kooperationsmodell und zur verwendeten Technologie werden nicht beachtet oder sind nicht bekannt.

Auswahl der Werkzeuge: Eine falsche oder inadäquate Zusammenstellung im Kontext der DevOps-Philosophie passt nicht zu den notwendigen Anforderungen, Abläufen oder der Infrastruktur im Unternehmen.

Management-Unterstützung: Ohne durchgängige, verbindliche und transparente Unterstützung durch das Management scheitert ein Projekt. Das gilt insbesondere für die Einführung von DevOps im Unternehmen. In manchen Fällen wird hier eine Einführungsentscheidung getroffen, aber keine Unterstützung im Verlauf des Projektes sichergestellt.

Testautomatisierung: Oft ist kein durchgängiges Verständnis des Prozesses oder der Anwendung bei der Testkonzeption vorhanden. Somit kann nicht sichergestellt werden, dass die automatischen Tests den gewünschten Beitrag zur Qualitätssicherung leisten. Die Folge davon ist eine unzureichende Testabdeckung der Anwendung, womit ein Showstopper für den Einsatz von Deployment Pipelines (CI/CD) einhergeht.

Vorgehensmodell zur Einführung des DevOps-Technologiestacks

Während im Dev-Bereich schon viele erprobte agile Vorgehen - etwa SCRUM, Kanban, XP oder BDD - existieren, gibt es für DevOps kein allgemeingültiges und reproduzierbares Vorgehen. Ein bereits erfolgreiches DevOps-Vorgehen in Firma A kann nicht immer eins zu eins auf Firma B übertragen werden. Schließlich kann es vorkommen, dass dort existierende Ordnungsmuster möglicherweise mit anderen Werten, Prinzipien und Technologien arbeiten.

Im zweiten Teil unseres Blog-Beitrags werden wir näher auf die einzelnen Projektphasen eingehen. Ihr erfahrt, wie ihr die entsprechenden Rahmenbedingungen schafft, das Projekt plant, durchführt und erfolgreich zum Abschluss bringt.

Ihr möchtet mehr zu spannenden und interessanten IT-Themen erfahren? Dann werft auch einen Blick auf unsere bisher erschienenen Blog-Beiträge.

Dieser Beitrag ist auch im Java Magazin (Ausgabe 3/2019) erschienen.