Das Konzept DevOps, sprich die Verschmelzung von IT-Entwicklung und -Betrieb, hält in immer mehr Unternehmen Einzug. Sie versprechen sich damit, die Leistung der IT-Abteilungen zu steigern und für bessere Software bei gleichzeitig schnelleren Prozessen zu sorgen. Doch ist das wirklich so einfach? Sollte man sich nicht zunächst mit der Ist-Situation im Unternehmen befassen, mit dem, was das DevOps-Konzept zur Automatisierung und Verschlankung von Prozessen beitragen kann?
Foto: dani3315 - shutterstock.com
Höchste Zeit Licht ins Dunkel vieler IT-Abteilungen zu bringen: Grundsätzlich geht es bei DevOps darum, dass Entwicklung und Betrieb besser integriert sind, reibungsloser zusammenarbeiten – mancher Experte spricht vom "Einreißen der Mauer" zwischen den Teams, um mit weniger Manpower schneller zu neuen Produkten zu gelangen. Es geht also primär um mehr Effizienz.
So viel zur Theorie. Konkret müssen IT-Entscheider Strukturen und Verantwortungen an die immer kürzeren Entwicklungszyklen anpassen, um sich auf dem Markt zu behaupten. Agile Methoden in der IT und Standards zwischen Software-Entwicklung und IT-Betrieb halten damit Einzug. Ein Schlüssel zum Erfolg liegt in der langfristigen Einbindung von Mitarbeitern, die bei möglichst vielen Entscheidungsprozessen involviert sind. Hier kann das DevOps-Konzept mittel- und langfristig zum Erfolg führen. Das bedeutet aber nicht, alte Systeme und Strukturen von heute auf morgen auszumustern. DevOps gewinnt erst mit der Zeit an Effizienz.
NoOps - der radikale Schritt
Die NoOps-Strategie ist auf dem Weg zu mehr Effizienz weit radikaler. Im Extremfall verfolgt diese Idee einen kompletten Verzicht auf das für den Betrieb zuständige Team und strebt eine Vereinigung von Development und Operations an. Man schafft damit ein Umfeld, in dem Software durchweg schnell und automatisiert arbeitet und Eingriffe durch den Menschen nur noch in Ausnahmefällen nötig sind. Dadurch kann man nicht nur auf IT-Mitarbeiter verzichten und gleichzeitig Prozesse schneller vorantreiben, sondern auch Kosten einsparen, lautet das Versprechen. Das fertige Produkt kommt also noch flotter auf die Straße, da das Management quasi komplett wegfällt und die Bereitstellung vollständig auf IaaS und PaaS basiert.
Die Vorzüge von NoOps liegen damit doch auf der Hand – so könnte man vermuten. Leider ist es in der Praxis nicht ganz so einfach. Denn wichtig ist auch die Sichtweise auf den IT-Betrieb im Unternehmen. Dabei gilt es zu klären, zu welchem Automatisierungsgrad Entscheider die Abläufe überhaupt in die Hände von Robotern und künstlicher Intelligenz geben möchten. Es gilt auch über ganz grundlegende Fragen zu entscheiden. Liegt die Einführung von NoOps eigentlich im Interesse meiner Unternehmenskultur und den Werten, die ich an meine Mitarbeiter weitertragen möchte?
Eine Klasse überspringen
Für Unternehmen, die sich im Zuge der stetig voranschreitenden Digitalisierung gerade im Findungsprozess befinden, stellt sich somit durchaus die Frage, ob sich IT-Entscheider überhaupt mit DevOps auseinandersetzen sollen. Generell ist zu bedenken, welche Elemente für Continuous Delivery Software wesentlich sind und welche nützliche Optimierungen notwendig sind.
Geht man vom Optimalfall aus, dann wäre der direkte Sprung auf NoOps durchaus die logische Konsequenz. Doch die Ist-Perspektive entscheidet. Glücklicherweise stellt sich die Situation in den meisten IT-Organisationen nicht ganz so schlecht dar, wie man vermuten könnte. Teams, Prozesse und Bereitstellungssoftware sind meist vorhanden, arbeiten häufig jedoch nicht auf dem gleichen Level von Effizienz und Skalierbarkeit als agiles Entwicklungsteam zusammen.
Lesen Sie mehr zum Thema DevOps und NoOps:
Im Hinterkopf sollte man deshalb behalten, dass DevOps die Lücke von Entwicklung zum produktiven Betrieb effizient und zuverlässig schließt. Wie sinnvoll es ist, die DevOps Entwicklung voranzutreiben, oder ob es erstrebenswert scheint, den direkten Sprung auf NoOps zu wagen, hängt von der jeweiligen Situation ab. Beim radikaleren Schritt zu NoOps ist die Kompatibilität zu bestehenden Anwendungen wohl das größte Hindernis, da dieser Ansatz auf bestehende PaaS-Lösungen passen muss.
Pragmatismus ist gefragt
Die Lösung ist ganz pragmatischer Natur. Viele Unternehmen verwenden noch alte zusammenhängende Software, die nie für NoOps konzipiert wurde. Diese müsste in den meisten Fällen komplett überarbeitet und neugeschrieben werden, um für NoOps zu funktionieren. Zudem wird auch zukünftig das Problem bestehen, dass der Großteil neuer Software und Technologien nicht zwangsläufig auch mit NoOps kompatibel sein werden. Mit NoOps befindet man sich also in einem Expressaufzug, der aber nicht jedes Stockwerk ansteuern kann.
Der Vorteil von NoOps besteht in der Verzahnung zu Platform-as-a-Service- (PaaS-)Architekturen – eine von drei serviceorientierten Formen, die zwischen Infrastructure und Software as a Service (IaaS und SaaS) liegt. Bei PaaS liegt der Schlüssel zum Erfolg in der horizontalen Implementierung der Cloud und nicht, wie so häufig, in einer vertikalen Vernetzung. Der Einzug von Cloud Computing hat in den vergangenen Jahren diese Entwicklung enorm vorangetrieben. Denn Platform as a Service teilt die Aufgaben von Development und Operations zwischen dem Bereitsteller der Cloud und dem Kunden auf. Diese Administration ist nur mit NoOps im Sinne einer automatisierten Softwarelösung möglich. In dieser Konstellation wird eine Operations Unit überflüssig.
DevOps - Entscheider und Fachbereiche mit einbeziehen
Auch für den DevOps-Kosmos beginnt eine erfolgreiche Umstellung mit einem Assessment der Ist-Situation. Eine der Herausforderungen, die es zu meistern gilt, ist die Einbeziehung von betrieblichen Entscheidern und allen notwendigen Fachbereichen. Mit der Zusammenarbeit wird sichergestellt, dass die gleiche Sprache gesprochen wird und ein aussagekräftiger Soll-Zustand definiert wird. Darauf aufbauend lässt sich die initiale Organisation inklusive Prozesse, Werkzeuge, Rollen und Governance definieren. Hierbei geht es zunächst um die minimal tragfähige Ausprägung der vollständigen Lieferkette und den Aufbau des Optimierungs-Backlogs.
Im nächsten Schritt müssen Change-Management-Aktivitäten festgelegt werden. Zudem gilt es, Messgrößen und entsprechende Erhebungsformen einzuführen, um die datengetriebene Steuerbarkeit des Einführungsvorhabens zu gewährleisten. Dies lässt sich mit dem Aufbrechen bestehender Businesskulturen gleichsetzen, um eine einheitliche produktorientiere Organisation zu leben.
Foto: Accenture
Nach der Initiierungs- und Definierungsphase folgt die Pilotierung der DevOps-Organisation, um erste Praxis-Erfahrung und damit ein besseres Verständnis zu erlangen. Dazu lässt man kleinere Piloten als eine Art Testballons steigen, um diese im nächsten Schritt an bestehenden Infrastrukturen zu testen. Die Einführung eines mindestens funktionsfähigen Sets von Prozessen zur Unterstützung hilft dabei. Fehler können dadurch frühzeitig erkannt und ausgebessert werden.
Fehler müssen akzeptiert werden
Natürlich bedeuten diese zusätzlichen Prozesse die Akzeptanz einer mühseligen Fehlerkultur. Diese dient aber am Ende einzig und allein der Produktqualität und beschleunigt eine Implementierung in späteren Schritten. Denn diese Erfahrung lässt sich dazu nutzen, um das Optimierungs-Backlog zu priorisieren und den Skalierungsplan inklusive Change-Management anzupassen. Bei der Umsetzung des Skalierungsplans wird sichergestellt, dass die DevOps-Organisation aus sich selbst heraus das Optimierungs-Backlog umsetzt und entsprechende Effekte mit Datenbelegen aufzeigt. Somit ergibt sich am Ende ein Automatisierungseffekt bei gleichzeitiger Festigung von Kernkapazitäten in der gesamten Unternehmensorganisation.
Allzu oft lösen Veränderungen in Organisationen bei IT-Entscheidern Sorgen aus. Denn das Zusammenrücken von "Dev" und "Ops" bewirkt, dass zentrale Themen und Problemstellungen "der anderen Seite" plötzlich von gemeinschaftlicher Relevanz sind. Entsprechend müssen die einzelnen Fachkräfte ihren Kompetenzhorizont gegenseitig erweitern. Oftmals bedarf dies eines individuellen Coachings, damit Change Prozesse besser kommuniziert und auf beiden Seiten verstanden werden.
Eine gezielte Optimierung der Lieferkette für die Bereitstellung der geschäftsrelevanten Anwendungen setzt eine detaillierte Erfassung des Zusammenspiels der beteiligten Komponenten voraus. Oftmals sind entsprechende Daten nicht oder nur unvollständig vorhanden. Es muss eine positive Kultur des Sichtbarmachens und der Transparenz etabliert und gepflegt werden, in der die DevOps-Organisation Optimierungspotentiale identifizieren und entsprechende Maßnahmen mit messbarem Erfolgsindikator umsetzen kann und will. Die notwendige Unterstützung durch erfahrene Coaches wird hier oft unterschätzt, ist jedoch Schlüssel zum Erfolg.
Speziell bei der Interaktion mit dem Business als Quelle von Änderungswünschen ergeben sich Herausforderungen. Gemeinsame Bestimmung der Größe und eventuelle Teilung von Anforderungen sowie deren Priorisierung stellt eine junge, noch unerfahrene DevOps-Organisation oft vor Probleme. Insbesondere die Artikulation des jeweilig zugeordneten Wertbeitrags und dessen Messbarkeit führt zu Diskussionen, die besser geführt werden können, wenn ein erfahrender Coach unterstützt.
Vollkommene Automatisierung durch Integration in SAP
Wir erinnern uns: Der optimale Fall und das Ziel jeder DevOps-Implementierung ist das zusammenrücken von "Dev" und "Ops". Um eine weitestgehende Automatisierung sowie Integration zu erreichen, muss zunächst die Frage beantwortet werden, welche Systeme Teil der DevOps-Pipeline sein sollen. Es gibt Organisationen, die eine heterogene Systemlandschaft haben, welche sich aus SAP und Non-SAP Systemen zusammensetzt. Andere hingegen haben eine stärkere Ausrichtung in Richtung SAP.
Wurde SAP vollumfänglichen implementiert, bietet es die Möglichkeit, mithilfe eines Solution Manager Addon "Focused Build" Software Entwicklung in agile Methodik umzusetzen. Auch für die Integration in Testautomatisierung (CBTA, Worksoft, Tricentis) und Requirements Engineering wie zum Beispiel JIRA sind Vorbereitungen zu treffen. Bei der Verwendung von Focused Build ist der Entwicklungsprozess stärker durch SAP vorgegeben und kann nur eingeschränkt automatisiert werden.
Foto: Accenture
Eine Alternative bei starkem Fokus auf SAP ist die Lösung "ActiveControl" von Basis Technologies. ActiveControl bildet den gesamten SAP Software Development Prozess ab und bietet im Standard mehr als 60 sogenannte Shift-Left Checks, womit die Qualität der Softwareentwicklung automatisiert geprüft werden kann. Außerdem bietet ActiveControl Features an, die im SAP Standard nicht verfügbar sind, wie zum Beispiel "Deep Impact Analysis". Damit können vor einem Deployment auf ein nächst höheres System fehlende Objekte identifiziert werden. Oder "Backout", womit nach einem Deployment veränderte Objekte wieder auf die ursprüngliche Version zurückgesetzt werden können.
Bei einer weit heterogeneren Systemlandschaft, in der non-SAP sowie SAP Systeme gleichermaßen in die DevOps-Pipeline integriert werden sollen, bietet sich beispielsweise eine Lösung wie die DevOps-Plattform "ADOP" an. Hier wurde für SAP eine vollumfängliche Integration mittels Jenkins dargestellt. Durch diese Integrationsform eröffnen sich Möglichkeiten, neue Tools zu integrieren, die im Rahmen von Software Development verwendet werden.
Fazit
Welchen Ansatz gilt es also zu befolgen? Es bedarf zunächst ein Assessment der Ist-Situation, um ein genaueres Bild über die Systemlandschaft, Prozesse und Tools zu erhalten. Abhängig von dem Assessment Ergebnis, empfiehlt sich die Umsetzung eines Piloten/PoC, bei dem entweder Focussed Build von SAP, Active Control von Basis Technologies oder ADOP zum Einsatz kommen. Nach erfolgreichem PoC muss der gesamte Scale-Out der DevOps-Pipeline im Unternehmen unter Einbezug der notwendigen Change-Management Maßnahmen umgesetzt werden. Vor diesem Schritt lohnt es sich, einen Coach ins Boot zu holen, um etwaige Unklarheiten zwischen Dev und Ops aus der Welt zu schaffen, Integrationsrisiken zu mildern und die beste Lösung für den jeweiligen Unternehmens- und Organisationkontext umzusetzen.