DevOps: Wo beginnt das Kontinuum?
DevOps ist kein Spleen irgendwelcher Freaks. DevOps ist vielmehr Konzept und Methode in einem. Konzept, weil es nach einer anderen Unternehmenskultur verlangt, weg von übermäßiger Arbeitsteilung hin zu interdisziplinärer Teamarbeit.
Methode, weil der Ansatz klar definierten und erprobten Prinzipien und Verfahren folgt, die speziell im SAP-Umfeld von einer integrierten Tool-Chain inklusive automatisierten Testverfahren unterstützt werden müssen.
Bei DevOps geht es um Funktionalität, die das Geschäft voranbringt. Und deren Entwicklung sich strikt an die Budgetvorgaben hält, ohne Detailkontrollen durch die Vorgesetzten. Womit wir direkt beim Thema Lean Management sind: Zu- und Vertrauen statt maximale Dokumentationspflichten, überschaubare und zielführende Projekte statt Großbaustellen, die viel Prestige einbringen, dafür doppelt so teuer sind wie geplant.
Doch auch IT-Teams selbst müssen „lean“ und agil sein, denselben Prinzipien für schlanke Verfahren folgen wie das Management. Aber was heißt das eigentlich? Das Lean Enterprise Institute gibt Antwort:
Kein DevOps ohne agile Prinzipien
Oberstes Prinzip ist die Kundenorientierung, der Nutzen einer neuen Funktionalität für die Anwender. Haben die Verantwortlichen deren Wert ermittelt, sollten sie als Nächstes die Abläufe dahingehend prüfen, ob diese einen positiven Wertbeitrag erbringen. Diejenigen, die das nicht tun, sollten entfernt werden.
Drittens sollten die Prozesse so (um)gestaltet werden, dass die durchschnittliche Dauer eines Zyklus von der Entwicklung bis zur Übernahme in den Produktivbetrieb (Sprint) verkürzt wird.
Dadurch lassen sich Funktionalitäten kontinuierlich ausliefern – und somit deren Qualität und Wertbeitrag genauer prüfen und messen. Dabei sollte viertens das Business bestimmen, welchen Wertbeitrag die IT leisten soll, und nicht umgekehrt.
Man muss sich diese vier Prinzipien wie die Perlen einer Kette vorstellen, deren fünfte den Kreis schließt: „Continuous Improvement“ erlaubt dank Wiederholungsschleifen Erkenntnisse, mit deren Hilfe sich der Gesamtprozess mit jedem Sprint optimieren lässt.
Doch Verbesserungen sind nur als solche erkennbar, wenn sie sich messen lassen. Das DevOps-Konzept empfiehlt sogar, kontinuierlich zu messen, das heißt an vielen verschiedenen Stellen im Entwicklungsprozess Kennzahlen zu erheben.
SAP-Bestandskunden sollten zum Beispiel die Transporte und Änderungen zählen, die an ein SAP-System in bestimmten Zeiträumen ausgeliefert werden.
Wie lange dauert es, bis Anforderungen in neuen Softwarecode gegossen werden? Wie viele Korrekturen gibt es pro Sprint? Nimmt diese Zahl zu oder ab? Werden die geforderten neuen Funktionen pünktlich ausgeliefert?
All das sind relevante Kennzahlen, die sich kontinuierlich verbessern lassen, wenn die DevOps-Teams ihre Arbeit regelmäßig reflektieren, diskutieren und optimieren.
SAP-Bestandskunden, die DevOps einführen wollen, sollten sich an den genannten Lean-Prinzipien orientieren. Welches davon lässt sich am einfachsten verwirklichen oder ist bereits Realität?
Ausgangspunkt könnte etwa der Wertstrom Requirement-to-Deploy sein. Legen Sie Kennzahlen an und messen Sie, wo das größte Verbesserungspotenzial in diesem Wertstrom schlummert.
Sind es Umfang und Größe der Projekte und Teams? Verkleinern Sie sie und erhöhen Sie gleichzeitig deren Zahl! Bringen Sie Entwickler, Administratoren und Qualitätsmanager an einen Tisch und schon sind Sie in der DevOps-Welt. Kleine, aber schlagkräftige, weil abteilungsübergreifend und autonom arbeitende Teams erbringen in Summe einen höheren Wertbeitrag.
Konkreter Anlass für die DevOps-Einführung wird in den kommenden Jahren der Umstieg auf S/4 sein. Für ein Projekt dieser Größenordnung und Relevanz braucht es neue Methoden.
Dem trägt auch SAP mit seiner Einführungsmethode SAP Activate Rechnung (siehe auch Seite 62), die agilen Prinzipien folgt. In unserer nächsten Kolumne diskutieren wir Ansätze zur Migration auf S/4 Hana und die Rolle, die Automatisierung dabei spielt.
