DevOps – Mauern einreißen

DevOps steht für den Zusammenschluss von Softwareentwicklung und IT-Betrieb und beschreibt mehr eine Philosophie der Zusammenarbeit denn eine klar definierte Methodik. Woraus setzt sich DevOps allgemein zusammen?

Jörg Landwehr: Es gibt keine klaren Regeln, die sich auf DevOps anwenden ließen. Es gibt nicht das eine DevOps-Manifest, das definiert, was Teams zu tun oder zu lassen haben.

Bei DevOps handelt es sich vielmehr um einen flexiblen Arbeitsansatz, der den Bedürfnissen, Prozessen und Ressourcen jedes Unternehmens angepasst werden kann.

Mir wurde mal gesagt, dass DevOps die Prinzipien industrieller Herstellprozesse auf die Auslieferung von Code überträgt. Dennoch gibt es einige grundlegende Bausteine, die die Umstellung auf DevOps ungeachtet der Ausgangssituation unterstützen, nämlich eine agile Softwareentwicklung (Prozess), eine Kultur der Zusammenarbeit (Menschen) und die passenden Automatisierungstools (Technologie).

DevOps einzuführen ist schwer, wenn nicht wenigstens kleine Fortschritte auf all diesen Gebieten erreicht werden. Doch 100 Prozent sind zu Anfang gar nicht erforderlich. Wenn nur auf einem dieser Felder Verbesserungen erzielt werden, kann das enorme Verbesserungen herbeiführen oder sogar die gesamte DevOps-Umstellung bewirken.

DevOps wird häufig mit kontinuierlicher Auslieferung assoziiert. Was ist der Unterschied?

Landwehr: Viele verwenden die Begriffe DevOps und kontinuierliche Auslieferung nahezu synonym. Damit liegt man nicht komplett falsch, doch es gibt einige Unterschiede.

Jez Humble, Experte und Autor zum Thema „kontinuierliche Auslieferung“ sagt, dass sie die Fähigkeit sei, Änderungen aller Art in die Produktion zu übernehmen und somit in die Hände des Benutzers zu geben – und zwar sicher, schnell und nachhaltig. Das erreichen wir, indem wir sicherstellen, dass unser Code immer „nutzbar“ ist.

DevOps kann man als eher businessorientierten Ansatz sehen, denn er umfasst weitaus mehr Menschen und Prozesse. Von einer klaren ­Abgrenzung kann man jedoch nicht sprechen, thematisch überschneidet sich sehr viel.

Bei SAP hat man den Eindruck, dass die kontinuierliche Auslieferung ein Ergebnis von DevOps ist. Doch ich denke, sie ist eher ein Ergebnis der Zielsetzung, nachdem DevOps integriert wurde.

Was sind die Hauptvorteile von DevOps im Vergleich zu klassischen Methoden?

Landwehr: Ein Schlüsselvorteil von Dev­Ops ist, dass aktuelle Unternehmensbedürfnisse im Fokus stehen. Das bedeutet, dass ein IT-Unternehmen in der Lage sein muss, auf Änderungen von Anforderungen, z. B. durch Kundenwünsche oder einen disruptiven neuen Wettbewerber, zu reagieren.

Im Allgemeinen sind die Kosten und Risiken mit DevOps geringer und die Produkteinführungszeiten bedeutend kürzer, was dazu führt, dass die Produkte besser und die Kunden deutlich zufriedener werden.

Teams, die auf klassische Ansätze wie Wasserfallentwicklung setzen, sind nicht in der Lage, sich so schnell neuen Gegebenheiten anzupassen. Probleme werden meist später gefunden, sind schwerer zu diagnostizieren und teurer zu beheben.

DevOps bringt zudem wichtige Verbesserungen wie Sicherheit und Stabilität von Anwendungen und ganz nebenbei auch einen Anstieg an Mitarbeiter­zufriedenheit und -bindung.

Welche Herausforderungen muss ein Unternehmen bei der Implementierung von DevOps bewältigen? Wie können größtmögliche Widerstände überwunden und eine neue Kultur der Zusammenarbeit etabliert werden?

Landwehr: Wenn wir mit Kunden über DevOps sprechen, merken wir, dass die Einstellung zu Arbeitsansätzen und die Art und Weise, wie die Teams zusammenarbeiten, das größte Problem sind und nicht wie sie „offiziell“ zusammengestellt werden.

Jeder, der an einem Projekt des Unternehmens beteiligt ist, muss zum Beispiel Inhaber von Produkten und Prozessen werden. Der Übergang von Silos hin zu interdisziplinären Teams mit vielfältigen Fähigkeiten ist hier der Schlüssel.

Das bedeutet jedoch nicht, dass die gesamte Organisation auf den Kopf gestellt werden muss. Schon eine Änderung in der Einstellung zur Arbeitsweise und ein entsprechender neuer Ansatz können ausreichend sein.

Die Frage der Organisation kann hier jedoch tatsächlich eine Herausforderung darstellen, und zwar wenn wichtige Teile der Verwaltung eines SAP-Systems an externe Partner ausgelagert wurden.

Die beteiligten Teams befinden sich unter Umständen nicht im selben Land und haben zudem nicht denselben Anbieter. Dies kann zu einer komplizierten Situation führen, die jedoch mit genügend konzentrierter Arbeit und Kommunikation überwunden werden kann.

Welchen Einfluss hat DevOps auf die Fehlerrate in SAP-Projekten?

Landwehr: Die Vorteile, die entwickelte DevOps-Prozesse in einer SAP-Landschaft mit sich bringen, können enorm sein. Jedoch ist stets zu bedenken, dass viele Vorteile bereits zu Beginn deutlich werden, wenn langfristig entwickelte Prozesse noch schwer absehbar sind.

Wir haben Kunden, die die Fehlerquote in der Produktion einfach nur durch die Nutzung guter Tools und mehr Automatisierung um 60 bis 70 Prozent gesenkt haben. Und das, bevor sie sich ernsthaft der agilen Softwareentwicklung und DevOps gewidmet haben.

In welchem Ausmaß wurde DevOps in den SAP-Communitys bereits implementiert?

Landwehr: Wenn wir ehrlich sind, müssen wir sagen, dass sich DevOps für SAP immer noch in den Kinderschuhen befinden, wenn man den Markt als Ganzes betrachtet.

Agile Softwareentwicklung hat sich bisher größerer Attraktivität erfreut. Immer mehr Teams stellen fest, dass die agile Entwicklung in SAP funktioniert, und ich habe den Eindruck, dass dieser Umstand bei den Beteiligten auch die Augen für Dev­Ops öffnet.

Ganz egal, was der Grund ist, DevOps wächst in jedem Fall rasant. In den letzten zwölf Monaten haben wir einen Zuwachs an Organisationen festgestellt, die zu uns kommen und fragen, wie wir helfen können, DevOps für SAP einzuführen.

Einige von ihnen sind technisch schon sehr weit, andere jedoch würde man eher als festgefahren bezeichnen. Interessanterweise denken selbst einige der traditionellen SAP-Benutzer jetzt über die Vorteile nach, die DevOps ihrem Unternehmen bringen kann.

Doch bevor Dev­Ops zur Normalität in SAP-Umgebungen wird, muss noch einige Zeit verstreichen. Zweifellos wird der Ansatz in den nächsten Jahren an Bedeutung gewinnen. Die Unternehmen müssen einfach sicherstellen, dass sie die richtigen Tools und Prozesse einsetzen, die dafür notwendig sind.

Was sind die Unterschiede zwischen KMU und größeren Unternehmen?

Landwehr: DevOps ist für alle Unternehmensgrößen geeignet. Und wie bei allen Dingen muss man sich auch hier fragen, ob die Ergebnisse den Aufwand wert sind. Je größer das Unternehmen, desto wahrscheinlicher ist es, dass es über eine große und komplexe SAP-Landschaft verfügt, in der sehr viele Änderungen ausgeliefert werden müssen.

Jeder kann sich vorstellen, dass große Organisationen dank Dev­Ops beträchtliche Vorteile erreichen können. Bei KMUs mit schlanken IT-Teams ist die Agilität für Rollenänderungen und neue Prozesse viel leichter gegeben und führt so schneller zu Erfolg.

DevOps- und Automatisierungs-Tools, wie wir sie unseren Kunden anbieten, können auch für kleine Teams sehr hilfreich sein, denn so können sich die Fachleute auf die wirklich wichtige Arbeit konzentrieren.

Mit der Hana Cloud Platform konnte SAP Mikroservices innerhalb des S/4-Kerns entwickeln. Eignet sich das neue SAP-Paradigma für die Umstellung auf DevOps?

Landwehr: DevOps ist sehr weit verbreitet und deckt viele verschiedene Gebiete der IT-Welt ab. Einschneidende Verbesserungen können demnach nicht auf eine spezifische Technologie oder ein Konzept zurückgeführt werden.

Jedoch ermöglichen die Dienste, die von HCP zum Konsum von Anwendungen bereitgestellt werden, einen größeren Fokus auf Entwicklungen zu Unternehmenszwecken statt auf technische Nacharbeiten, was auf alle Fälle im Einklang mit der Dev­Ops-Philosophie steht.

Ganz gleich, welche spezifische Technologie benötigt wird: Wir sehen, dass S/4 Hana, HCP usw. als Vorreiter für viele Unternehmen dienen, um neu zu beurteilen, wie sie ihre SAP-Systeme verwalten.

Diese neuen Optionen bieten Möglichkeiten für eine viel weiter gefasste Überlegung zum Einsatz vorhandener Methodiken, der Zusammenstellung von Teams, Tools usw.

Ein sehr großer multinationaler Kunde nahm die Umstellung auf S/4 Hana zum Anlass, seine gesamte SAP-Tool-Chain auf den Prüfstand zu stellen, um eine moderne Best Practice anzunehmen, was dazu führte, dass unser DevOps-Toolset ausgewählt wurde, das den Umstellungsprozess unterstützt.

Mit dem DevOps-Toolset geben Sie Unternehmen ein Werkzeug in die Hand, das die Umstellung vereinfacht. Wie wichtig sind diese Tools für DevOps für SAP?

Landwehr: Die Bedeutung der Tools kann gar nicht genug herausgestellt werden, hauptsächlich, weil Automatisierung ein absolut wichtiger Bestandteil im Dev­Ops-Konzept ist.

Letzten Endes ist es die Automatisierung, die die Sicherheit und die ­Geschwindigkeit bietet, durch die sich Dev­Ops auszeichnet. Für einige Organisationen stellt dies in gewissem Maße eine Herausforderung dar.

Wenn DevOps bereits außerhalb von SAP implementiert wurde, sind höchstwahrscheinlich bereits Tools (wie Jenkins, Chef oder Puppet) im Einsatz. Die Annahme geht meist dahin, dass diese Tools und die damit ausgeführten Prozesse einfach auf SAP angewandt werden können.

Tatsächlich ist es jedoch so, dass die spezifische Natur von SAP besondere Tools wie unser DevOps-Toolset erfordert. Damit erhalten Nutzer die notwendige SAP-spezifische Automatisierung wie Transportsequenzierung, Prüfungen auf Beziehungswissen, Freigaben, Bereitstellungen und Zusammenführungen über verschiedene Systeme hinweg.

Außerdem ist es wichtig, dass sich SAP-spezifische Tools in die weiter gefasste DevOps-Toolkette integrieren lassen. Unser DevOps-Toolset macht genau das und bietet dazu die Integration in Remedy, ServiceNow, Jira und weitere.

Wir unterstützen darüber hinaus auch die eher personenorientierten Aspekte von Dev­Ops wie zum Beispiel ein zentrales Dashboard, das von allen Benutzern verwendet werden kann. Einer unserer Kunden beschrieb dies neulich als „das Einreißen der Mauern“ zwischen den SAP-Teams, die in verschiedenen Ländern arbeiten.

Was ist Ihrer Meinung nach das nächste heiße Thema in Verbindung von SAP und DevOps?

Landwehr: Für uns ist aktuell das Testing das heißeste Thema. Selbst in Organisationen, die bereits erfolgreich DevOps für SAP eingeführt haben, können Regressionstests eine echte Herausforderung darstellen.

Üblicherweise ist keine Zeit da, einen umfassenden Regressionstest- Durchlauf für jeden SAP-Release durchzuführen, weil die Systeme viel zu komplex sind und Änderungen in einem zu hohen Rhythmus erfolgen.

Wir haben lange Zeit darüber nachgedacht, wie wir das Problem angehen, um Regressionstests praktischer zu gestalten, vor allem, wenn SAP-Releases sehr häufig ausgeliefert werden.

Dafür haben wir nun ein Produkt auf den Markt gebracht, das genau dazu in der Lage ist. Es heißt Testimony und nutzt einen völlig neuen Ansatz, der die vielen Mühen und Kosten traditioneller Lösungen beseitigt.

Es ist auch nicht nur an DevOps-Umgebungen gebunden und somit ein regelrechtes Wunderwerk für Großprojekte wie der Umzug von Plattformen in die Cloud und hat auf alle Fälle das Potenzial, einen höheren Rhythmus bei regelmäßigen Änderungen zu unterstützen. Dieses Tool macht unseren Alltag derzeit enorm spannend.