Lean management et automatisation

Wie in der E-3 Ausgabe Februar 2019 auf Seite 66 gezeigt wurde, hat die DevOps-Idee zahlreiche Vorläufer und Vorbilder, die vor allem das C (Culture), M (Measurement) und S (Sharing) im Calms-Konzept beeinflussten. Doch mindestens ebenso wichtig sind die Aspekte Lean Management (L) und vor allem Automatisierung (A).

Während bereits ab den 1990er-Jahren neue Ansätze aufkamen, wie sich Software schneller und flexibler entwickeln ließ, dauerte es noch bis 2009, bis alle Calms-Elemente in einem Konzept auf den Begriff gebracht wurden.

Ziel des Ansatzes ist es, die Zusammenarbeit zwischen Entwicklung und IT-Betrieb genauso agil und flexibel werden zu lassen wie die Entwicklung selbst: Seit den ersten DevOps-Days in Gent werden die Erfahrungen aus der Entwicklung und anderen Unternehmensbereichen im DevOps-Konzept gebündelt, wie sie etwa im DevOps-Handbuch dargelegt sind.

Kulturänderung auf allen Ebenen

Die Implementierung von DevOps verlangt den Beteiligten sehr viel ab. Alle müssen ihre Einstellungen, Erwartungen und Arbeitsweisen ändern. So ist in DevOps-Zeiten die Ära prestigeträchtiger Großprojekte vorbei.

Dafür rückt die betriebswirtschaft­liche Steuerung eines Entwicklungsvorhabens in den Vordergrund. Die Grundsatzfrage wird umgedreht: Statt zu fragen, was das Projekt kosten wird, gilt es zu definieren, welche neuen oder verbesserten Softwarefunktionalitäten für ein bestimmtes, überschaubares Budget realisiert werden können.

Liegt die Antwort vor, muss das Management sich damit zufriedengeben und den Projektbeteiligten vertrauen, dass es sich hier um realistische Ziele handelt. Gleichzeitig ist auf Detailkontrolle von oben zu verzichten.

„Was aus Managementsicht zählt, ist nur das Ergebnis im Vergleich zum Plan, nicht das Controlling der Einzelschritte. Das ist es, was im DevOps-Konzept mit Lean gemeint ist. Diesem Perspektivenwechsel müssen sich sowohl die Top-Manager als auch die Leiter der Fachabteilungen, die in besonderem Maße auf ihre Kollegen in der IT angewiesen sind, unterwerfen“

empfiehlt James Roberts, CTO bei Basis Technologies.

Auch für die Release Manager bedeutet das eine große Umstellung. Sie beziehen ihre Reputation nicht mehr aus dem Präsentieren und Leiten von Großbaustellen, sondern daraus, dass sie viele kleine Projekte, jeweils nur für ausgewählte Anwendergruppen in den Fachabteilungen, erfolgreich zum Abschluss bringen.

Weil die einzelnen Vorhaben überschaubar sind, muss sich ihr Rollenverständnis vom Leiter zum Coach, Motivator und Trainer wandeln. Außerdem müssen sie dafür sorgen, dass die Zusammensetzung des Teams auf Dauer stabil bleibt.

Teamgeist entsteht nicht nur aus der Ausrichtung an einem gemeinsamen Ziel, sondern auch durch verlässliche und vertrauensvolle Beziehungen der Teammitglieder untereinander. Da strategische Großprojekte in der DevOps-Welt in viele kleine, iterativ angelegte Detailprojekte unterteilt werden, ist dies strukturell möglich.

Die Teammitglieder wiederum müssen bereit sein, ein Stück weit von ihrem Spezialistentum abzurücken und ihr Wissen mit allen Teammitgliedern zu teilen. Nur so kann Verständnis für die Herausforderungen des jeweils anderen wachsen.

Erst durch den Austausch im Team lernen Entwickler, vor welche Probleme ihre Artefakte die Server-, Storage- und sonstigen Administratoren stellen, sowohl bei der Bereitstellung der passenden Testumgebung als auch bei der Übergabe der Änderungen in die Produktionsumgebung.

Dieses institutionalisierte „Sharing“ (S) jenseits von Silo-Denken und -Grenzen ist der Aspekt, der Vertrauen mittels Verständnisses schafft und die Grundlage für Standardisierung legt: Standardisierung der Vorgehensweise, aber auch der Tools, mit denen gearbeitet wird.

Indem Entwickler verstehen, wie eine Testumgebung genau funktioniert und warum die Kollegen aus dem Betrieb sich für diese und keine andere entschieden haben, lassen sich viele Reparaturen und Risiken beim späteren Produktivbetrieb von vornherein vermeiden.

Das entspricht exakt einer der zentralen Ideen der agilen Entwicklungsmethode Scrum, wonach interdisziplinäre Teams besser und schneller in der Lage sind, Neues und qualitativ Hochwertiges hervorzubringen.

Diese zweifache Standardisierung ist die Voraussetzung für den essenziellen Dev­Ops-Baustein der Automatisierung (A). Denn erst eine standardisierte Umgebung für Monitoring, Tests und Qualitätssicherung lässt sich als Selfservice bereitstellen, mit dem die Entwickler selbstständig arbeiten können.

Wollen sie bei einer Code-Änderung testen, ob diese die gewünschte neue Funktion tatsächlich bietet und welche Auswirkungen sie auf das Gesamtsystem hat, müssen sie nicht mehr auf das Betriebsteam warten, sondern können unmittelbar zur Tat schreiten.

Der IT-Betrieb wiederum kann sich voll und ganz auf die Qualitätssicherung der zu einem Release zusammengefügten Änderungen und deren Implementierung in der Produktion konzentrieren.

Damit das Zusammenspiel zwischen Entwicklung und Betrieb kontinuierlich verbessert wird, muss schließlich auch das Messen (M) von Kenngrößen automatisiert werden.

Dazu zählen etwa Auswertungen zu Geschwindigkeit und Pünktlichkeit oder Angaben zur Qualität wie die Zahl der gefundenen Fehler und deren Entwicklung im Zeitverlauf.

Accelerated to SAFe SAP

Es ist der Kulturwandel, der den Strukturwandel nach sich zieht, nicht umgekehrt. Dabei muss die Änderung anfangs gar nicht von oben gekommen sein, im Gegenteil: In der Regel sind es Initiativen von den betroffenen Entwicklern und ihren Kollegen im Betrieb, die nach Art von Graswurzelbewegungen für die DevOps-Revolution sorgen.

Das zeigen Untersuchungen immer wieder, wie zum Beispiel der 2018 State of DevOps Report. Diese Pioniere sind umso erfolgreicher, je überschaubarer sich die Aufgabe darstellt, die sie sich vornehmen, und je dringlicher diese aus der Sicht des Unternehmens oder einer wichtigen Fachabteilung ist.

SAP-Bestandskunden können in diesem Stadium auf das Konzept Accelerated SAP zurückgreifen, das bereits agiles Arbeiten à la Scrum beschreibt. Haben sie die neue Kultur und ihre Überlegenheit vorexerziert, können und müssen sie das Management auf verschiedenen Ebenen involvieren und zu Sponsoren der DevOps-Revolution machen.

Diese Unterstützung von oben ist dabei erfolgsentscheidend. Denn DevOps-Teams können nicht in zwei Welten gleichzeitig leben, nicht einerseits nach dem Wasserfallmodell und andererseits nach agilen Methoden arbeiten, zu groß wären die Reibungsverluste.

Das bedeutet insbesondere, dass das Management die Mitglieder der zu bildenden DevOps-Teams von ihren bisherigen Aufgaben freistellt. Sie müssen sich ganz auf die neuen Prozesse und eventuell neue Tools konzentrieren können.

So lassen sich Stück für Stück immer mehr IT-Bereiche auf DevOps umstellen. Eine Beschreibung ihrer neuen Rolle finden die Manager in dem Rahmenwerk Scaled Agile for Enterprises oder SAFe von Scaled Agile, das nicht nur die einzelnen Teams, sondern auch alle Managementebenen darüber in Richtung DevOps anleitet.

Vertrauen und Zutrauen sind insbesondere im SAP-Umfeld der Schlüssel, da hier das Misstrauen gegenüber DevOps wegen der Komplexität und der internen wie externen Abhängigkeiten der verschiedenen Komponenten von SAP-Umgebungen vielleicht am größten ist.

SAP-Entwickler und -Administratoren sind dabei wie kaum eine andere Gruppe in der Unternehmens-IT nicht nur auf persönliche Beziehungen, sondern auch auf Tools angewiesen, mit deren Hilfe sich dieses Vertrauen aufbauen lässt.

Sie brauchen Werkzeuge, die alle Abhängigkeiten zuverlässig abbilden und neue Releases inklusive ihrer Auswirkungen auf die Produktivumgebungen auf Herz und Nieren prüfen können.

Zu diesen Werkzeugen gehören insbesondere Tools für automatisierte Regressionstest. Geeignete Tools decken dabei praktisch die gesamte Produktivumgebung ab und liefern daher Ergebnisse, die so realitätsnah sind, dass positiv getesteter Code mit einem stark reduzierten Risiko implementiert werden kann.

Das ist die Voraussetzung dafür, Releases in kurzen Abständen in produktive SAP-Umgebungen auszuliefern. Im Dev­Ops-Jargon heißt diese Auslieferungskette Continuous Delivery Pipeline oder – im SAFe-­Framework – Agile Release Train mit den Einzelschritten Exploration, Integra­tion und Deployment.

Sollten dennoch Probleme auftreten wie spürbare Perfor­manceeinbußen oder Funktionsfehler, müssen solche Automatisierungswerkzeuge zusätzlich die Möglichkeit bieten, das Release unterbrechungsfrei zurückzunehmen – so wie es die Anwender aus der Cloud gewohnt sind.

Automatisation

Fehlt das Vertrauen in die Automatisierung der Ops-Seite, ist und bleibt der Betrieb der Flaschenhals, der die Einführung von DevOps in der SAP-Landschaft eines Unternehmens verhindert.

Ist es ein Wunder, dass viele SAP-Bestandskunden Dev­Ops heute schon in ihrer IT anwenden, nur nicht in der eigenen SAP-Landschaft, sondern bei Drittlösungen?

In SAP-Umgebungen spielen Automatisierungswerkzeuge definitiv eine größere Rolle als in anderen Bereichen. Mehr noch: Auch wenn am Anfang von DevOps die Kultur steht, ist die Automatisierung in SAP-Umgebungen genauso wichtig wie diese.