SAP-Releasemanagement und die Agilität

In der dynamischen IT-Welt hören wir oft von unseren Kunden, dass durch die Agilität das Releasemanagement obsolet geworden sei. Der Trend zur sofortigen Produktivsetzung abgeschlossener Features scheint diesen Glauben zu bestärken. Doch ist das wirklich der Fall? Oder handelt es sich hierbei um eine Rückkehr zu alten Gewohnheiten? Alte Hasen werden sich erinnern, wie man früher Änderungen einfach auf Zuruf in die Produktion (unkoordiniert) übertragen hatte. Waren die Anfänge also nicht hyper-agil und warum sollten sie es heute nicht mehr sein?

Continuous Delivery im Kontext von SAP

Parallel zur Agilität hat sich das Konzept der kontinuierlichen Lieferung, auch bekannt als Continuous Delivery oder Feature Delivery, etabliert. Dieses Modell zielt darauf ab, in regelmäßigen Abständen, beispielsweise alle zwei Wochen, neue Features oder Updates produktiv zu setzen. Aber wie passt Continuous Delivery in das SAP-Releasemanagement?

In der SAP-Welt, die oft durch komplexe und integrierte Systeme gekennzeichnet ist, könnte man annehmen, dass Continuous Delivery eine Herausforderung darstellt. Aber mit den richtigen Werkzeugen und Prozessen kann es durchaus implementiert werden:

1. Automatisierte Tests: Ein Schlüsselaspekt von Continuous Delivery ist die Fähigkeit, schnell und zuverlässig zu liefern. Dies erfordert eine starke Betonung von automatisierten Tests, um sicherzustellen, dass neue Features oder Änderungen keine bestehenden Funktionen beeinträchtigen. Warum automatisiertes Testing unabdingbar sein sollte, haben wir bereits in diesem Artikel beschrieben Testautomatisierung für SAP-Kunden: Warum sie unabdingbar sein sollte › blue.works

2. Feedback-Schleifen: Kurze Feedback-Schleifen zwischen Entwicklungs-, Test- und Betriebsteams sind entscheidend. Dies stellt sicher, dass Probleme schnell erkannt und behoben werden können, bevor sie in die Produktion gelangen (vgl. DevOps).

3. Flexibles Deployment: Während einige Features für eine schnelle Auslieferung geeignet sein könnten, erfordern andere, insbesondere in einem SAP-Kontext, möglicherweise längere Test- und Validierungsphasen. Ein orchestriertes Deployment, das sowohl Continuous Delivery als auch traditionelle Release-Zyklen unterstützt, ist daher unerlässlich und genau hier, spielt das Releasemanagement ein tragende Rolle – nämlich bei der Orchestrierung von Änderungen aus verschiedenen Projekten und Erweiterungen mit unterschiedlichen Change-Geschwindigkeiten. Dies kommt vor allem auch zum Tragen, wenn es darum geht, ein schnelles Continuous Delivery auf neuen Mikroservice-Architekturen, z.B. der SAP BTP, mit einem Unternehmenskern (z.B. einem integrierten ERP-System) mit langsameren Change-Geschwindigkeiten zu kombinieren.

Warum SAP S/4HANA kein Mikroservicesystem ist und zahlreiche Abhängigkeiten aufweist

SAP S/4HANA und auch der Vorgänger SAP ERP sind, wie die Abkürzung schon verrät, ein integriertes Enterprise Resource Planning-System, das dazu entwickelt wurde, Geschäftsprozesse in Unternehmen zu unterstützen und zu optimieren. Es ist kein Mikroservicesystem, sondern ein umfangreiches und komplexes System, das viele verschiedene Geschäftsfunktionen abdeckt. Anbei einige Gründe, warum es kein Mirkoservice-System:

• SAP ERP/SAP S/4HANA wurde entwickelt, um eine Vielzahl von Geschäftsprozessen zu unterstützen, von Finanzen und Controlling über Beschaffung und Produktion bis hin zu Vertrieb und Service. Diese Prozesse sind oft miteinander verknüpft und erfordern eine enge Integration, um effizient zu funktionieren.

• Da S/4HANA ein integriertes System ist, müssen Daten konsistent und in Echtzeit über verschiedene Module hinweg verfügbar sein. Dies erfordert eine enge Verknüpfung und Abhängigkeit zwischen den verschiedenen Modulen.

• Zudem hat SAP hat mit Fiori eine einheitliche Benutzeroberfläche für S/4HANA entwickelt. Dies erfordert eine enge Integration zwischen den verschiedenen Modulen, um eine konsistente Benutzererfahrung zu gewährleisten.

• Viele Unternehmen passen S/4HANA an ihre spezifischen Geschäftsanforderungen an. Diese Anpassungen können zu zusätzlichen Abhängigkeiten zwischen den Modulen führen.

• Viele Unternehmen integrieren S/4HANA mit anderen Systemen, sei es innerhalb des SAP-Ökosystems (wie SAP Ariba, SAP SuccessFactors usw.) oder mit Drittanbietersystemen. Diese Integrationen erzeugen zusätzliche Abhängigkeiten.

Es lässt sich also sagen, dass die Komplexität und der integrierte Charakter von S/4HANA zu vielen Abhängigkeiten zwischen den verschiedenen Modulen und Funktionen führen. Dies ist sowohl eine Stärke als auch eine Herausforderung des Systems, da es Unternehmen ermöglicht, ihre Geschäftsprozesse umfassend zu optimieren, aber auch eine sorgfältige Planung und Implementierung erfordert.

Bündelung von Änderungen macht das Change- und Testmanagement effizienter

Aus dem o.g. Gründen sollte Änderungen orchestriert und gebündelt werden. Damit reduziert man den Overhead bei Tests und Deployments erheblich. Eine organisierte und strukturierte Bündelung von Änderungen für den effizienten Betrieb von solch integrierten Systemen ist unerlässlich. So können Test-Szenarien einmal erstellt und für mehrere Änderungen gleichzeitig verwendet werden. Dadurch wird der Testumfang viel grösser als bei Einzeländerungen, und die Wahrscheinlichkeit, dass Fehler und unerwünschte Seiteneffekte in Regressionstest unentdeckt bleiben, verringert sich stark.

Man kann also sagen, dass prinzipiell jede Änderung die Produktion stresst und durch die Bündelung der Änderungen dieser Stress vermindert wird.
 

Releasekalender mit verschiedenen Takten zum flexiblen Deployment – aber geplant!

Ein vorhersehbarer Release-Zyklus stellt sicher, dass alle Teams im Unternehmen synchron arbeiten. Dies ist insbesondere in großen Organisationen wichtig, in denen Projekte oft interdependente Elemente aufweisen. Ein fester Kalender ermöglicht es den Teams, ihre Ressourcen effektiv zu allokieren und sicherzustellen, dass ihre Arbeit nicht durch externe Faktoren beeinträchtigt wird. Haben die Takte der Releases einen festen Rhythmus, so können sich die Anwender aus dem Business besser darauf einstellen.

SAP Best Practice ist es, zwischen drei verschiedenen Changes Paces zu unterscheiden.

1. Innovation Pace – für die grossen Projekte
    Der «Innovation Pace» ist für die grossen Projekte gedacht. Änderungen aus diesen Projekten haben signifikaten Prozessimpact. D.h. solche Projekte werden sorgfältig geplant, können in mehrere Schritten (Waves) produktiv gesetzt werden oder in einem grossen Schritt.
   
2. Enhance Pace – für flexiblere Deployments (und Continuous Delivery)
   Der «Enhance Pace» ist dagegen dafür da, kleinen Erweiterungen und Verbesserungen ins System zu bringen. Der Prozessimpact sollte minimal sein und jede jede sollte innerhalb eines Changeboard-Komites analysiert und genehmigt werden.
   Hier kommt jedem Betrieb ein gutes Anforderungsmanagement zu Gute: Der Fachbereich darf all seine Wünsche und Anforderungen aufnehmen. Diese werden bewertet und analysiert. Das spannende ist nun, dass aus einer Anforderung – je nach Analyseergebnis – entweder nur ein Enhance Change entsteht, oder aber gar ein ganzes Projekt. Oder man erkennt, dass viele Anforderungen thematisch geclustert werden könnten und innerhalb eines Erweiterungsprojektes umgesetzt werden.
   Schafft man es nun, viele dieser Arbeiten transparent zu koordinieren und Schritte für das Testing- und Deployment zu automatisieren (vgl. Piplines), ist man wohl schon beim Continuous Delivery angekommen.
   
3. (Bug)fixing Pace: Ja, der Produktivstillstand darf direkt behoben werden
   Es gibt Zeiten, in denen sofortiges Handeln erforderlich ist, insbesondere bei kritischen Produktionsfehlern. Der «Fix Pace» bietet genau diese Flexibilität. Besteht ein Fehler in der Produktion, soll dieser so schnell wie möglich behoben werden – ohne lange auf das nächste Deploymentfenster warten zu müssen.
   

Macht meine Mikroservicesarchitektur nun dann ein Releasemanagement obsolet

Gekapselte Mikroservices würden in der Tat eine höhere Flexibilität bieten und es Organisationen erlauben, schneller und häufiger zu deployen. Dies ist einer der Hauptvorteile des Mikroservice-Designs. Dennoch bedeutet das Vorhandensein von Mikroservices nicht zwangsläufig, dass das traditionelle Releasemanagement vollständig überflüssig wird. Hier sind einige Überlegungen dazu:

• Komplexität: Trotz der Vorteile der Unabhängigkeit können Mikroservices komplex sein, insbesondere in einem Ökosystem und im Zusammenspiel mit SAP S/4HANA mit vielen miteinander interagierenden Diensten. Ein effektives Releasemanagement kann also noch immer helfen, diese Komplexität zu steuern und sicherzustellen, dass es bei der Einführung neuer Funktionen oder Änderungen zu keinen unbeabsichtigten Nebenwirkungen kommt.

• Abhängigkeiten: Selbst wenn Mikroservices gut gekapselt sind, können dennoch Abhängigkeiten zwischen ihnen bestehen. Änderungen in einem Service könnten Auswirkungen auf andere haben, insbesondere wenn sie gemeinsam genutzte APIs oder Datenbanken verwenden. Zum Beispiel: Fällt ein Mikroservices für die Authentifizierung aus, können alle anderen Mikroservices davon betroffen sein – auch eine kleine Änderung (wie z.B. der Austausch der Zertifikatskette bzw. der Trusted CA) die gekapselt funktionert, kann grosse negative Seiteneffekte für alle anderen Webserivces haben.

• Qualitätssicherung: Unabhängig von der Architektur ist eine gründliche Qualitätssicherung unerlässlich. Bei häufigen Deployments kann die Qualitätssicherung eine Herausforderung darstellen, insbesondere wenn keine ausreichenden automatisierten Tests vorhanden sind.

• Stakeholder-Kommunikation: Bei großen Organisationen kann es sinnvoll sein, ein Releasemanagement beizubehalten, um sicherzustellen, dass alle relevanten Stakeholder über bevorstehende Änderungen informiert sind und um Feedback zu sammeln.

Letztendlich bringen Mikroservices tatsächlich die Möglichkeit, Features häufiger und unabhängig voneinander zu deployen (Continuous Delivery). Es bleibt aber wichtig, Deployments zu orchestrieren, zu überwachen und sicherzustellen, dass sie den Erwartungen der Stakeholder und den Qualitätsstandards des Unternehmens entsprechen und vor allem: Änderungen mit allfälligen langsameren Change-Pace Systemen abzustimmen.

Eine gesamthafte Vorausplanung macht das Deployment sogar schneller

Jeder, der in einem großen Unternehmen gearbeitet hat, kennt die Herausforderungen, die mit der Koordination verschiedener Abteilungen einhergehen. Hier bietet das Releasemanagement einen sehr guten Koordinationspunkt. Wenn beispielsweise die Finanzabteilung eine Jahresendverarbeitung plant, kann das IT-Team sicherstellen, dass dies im Releasekalender berücksichtigt wird, um potenzielle Konflikte zu vermeiden.

Weiterhin nehmen Cyber-Bedrohungen ständig zu und Sicherheitspatches sind unerlässlich. Mit einem festen Releasemanagement werden Zeitslots für Securityupdates bereits im Voraus definiert. Das bedeutet, dass der zeitraubende Prozess, diese Slots mit Stakeholdern abzustimmen, entfällt. Dies fördert nicht nur die Effizienz, sondern stellt auch sicher, dass kritische Sicherheitsupdates nicht aufgrund von Planungskonflikten verzögert werden.

Die Notwendigkeit, schnell und agil zu sein, steht ausser Frage. Doch in komplexen IT-Umgebungen, insbesondere in solchen, die von integrierten SAP-Systemen unterstützt werden, ist ein ausgewogenes Releasemanagement (derzeit noch) unerlässlich. Es lässt sich sagen, dass, während Agilität und Continuous Delivery ihre eigenen Vorteile bieten, das traditionelle Releasemanagement, insbesondere in komplexen Systemen wie SAP, immer noch seinen Platz hat. Es geht darum, das Beste aus beiden Welten zu kombinieren, um sowohl schnell als auch sicher zu liefern.

Fragen Sie uns doch einfach, wie Sie die Vorteile der Agilität als auch des strukturierten Releasemanagements nutzen und technisch abbilden können.