Sie streben einfache Upgrades bei geringem Risiko an? Versuchen Sie es mit dem zweigleisigen „Dual-Track“-Ansatz.

Ach ja… SAP Upgrades, diese spannende Arbeit, die wir so herbeisehnen wie die ersten Sonnenstrahlen im Frühling. Aufregende Nächte, ein paar fröhliche Wochenenddienste und dieses gespannte Warten wie bei der Fußballweltmeisterschaft. Gibt es etwas Schöneres, als seine Lebenszeit so zu verbringen?!

SAP Upgrades müssen jedoch nicht zwangsläufig qualvolle Überstunden bedeuten – wenn Sie beispielsweise die Vorteile anderer Techniken wie den DevOps-Ansatz nutzen. Die Sorgen und Risiken, die mit SAP Upgrades verbunden sind, werden so reduziert. Zudem können Sie diese Upgrades auch flexibel und ohne große Auswirkungen auf den Geschäftsbetrieb ausführen.

Ein eisiger Wind weht durch die Produktionslandschaft.

Ich habe in einem anderen Beitrag bereits dargestellt, was für ein frostiges Gefühl einen beim Gedanken an Produktionsausfällen überkommt. Es ging in dem Artikel um die Verhinderung von Innovation durch geplanten Stillstand. Dies führt uns direkt zu einem Grundsatzproblem bei Upgrades: In vielen SAP Umgebungen ist es nicht möglich, ein Upgrade durchführen und es gleichzeitig zu testen, während die alltägliche Produktion ganz normal weiterläuft. Man könnte es versuchen; jedoch wären danach die Projekt- und Produktionsumgebungen nicht mehr synchron. Viele Teams frieren daher Änderungen an der Produktionsumgebung für die Dauer eines Upgrades oder einer Bereitstellung ein.

Das kann bei relativ kleinen Upgrades gut funktionieren. Doch je umfangreicher und komplizierter ein Upgrade-Projekt ist, desto eher wird es erforderlich, das Produktionssystem für notwendige Änderungen wieder live gehen zu lassen – was natürlich Störungen und andere Risiken zur Folge haben kann. Eingefrorene Projekte bedeuten in der Regel auch einen größeren manuellen Arbeitsaufwand, da der Cutover üblicherweise während eines Wochenendes, innerhalb eines Batch-Fensters oder anderer geplanter Ausfallzeiten abgeschlossen sein muss, um den Geschäftsbetrieb nicht lahmzulegen. Schließlich ist niemand gern an einem Samstag im Büro.

Umfangreiche Änderungen und Geschäftskontinuität

Wegen eines Upgrades die Produktion zu stoppen, ist für die meisten Unternehmen keine geeignete Option. Bei einem Rund-um-die-Uhr-Service stellt jede Änderung eine beträchtliche Herausforderung dar. Doch auch Unternehmen, die die Zeit für geplante Ausfälle aufbringen können, finden umfangreiche oder komplexe Upgrade-Projekte zumeist nicht praktikabel. Ich nenne Ihnen ein Beispiel dafür: Die allermeisten SAP Anwender halten die S/4-Migration für unvermeidlich. Doch es ist sehr unwahrscheinlich, dass ein Unternehmen einen dauerhaften Produktionsstopp bis zum Abschluss einer Brownfield- oder Hybrid-S/4-Migration überleben würde, da diese Projekte mitunter Jahre dauern.

Es gibt für dieses Problem einen Standardansatz für SAP, bekannt als Project Landscape, Parallel Track, Dual Track oder N+1. Dieser Ansatz sieht vor, eine Systemkopie zu erstellen, typischerweise ohne Produktion, in welcher das Upgrade und die Migration durchgeführt werden, während die bestehende Produktionsumgebung nicht angerührt wird und weiter für den normalen Betrieb zur Verfügung steht.

Die Vorteile dieses Ansatzes sind so zahlreich wie offensichtlich: Projekt- und Geschäftsbetrieb laufen nebeneinander, ohne sich gegenseitig zu stören. Es ist völlig unerheblich, wie viel Zeit das Projekt in Anspruch nimmt, weil Produktionsänderungen und Verfügbarkeit nicht beeinträchtigt werden. Auf diese Weise werden in der Mehrzahl der Fälle geplante Ausfälle und Übergangszeiten vermieden, da die neue Umgebung vor dem Go-Live vollständig bereitgestellt und getestet werden kann. Dies ist mit einem Freeze-Ansatz kaum möglich.

Inspiration von außen

Bei einer Unterhaltung in Java oder C# würden wir bei diesem Thema von „Branch“, „Tip“ oder „Version“ sprechen, um klarzumachen, wo im Konfigurationsmanagement (Versionskontrolle) wir aktuell stehen, während bestehende Versionen der Software unberührt blieben. So können wir nicht nur alle Änderungen ohne Produktionsunterbrechung ausführen, sondern bei Bedarf eine Änderung auch ganz einfach zurücknehmen – alle früheren Systemversionen sind ja weiterhin im Konfigurationsmanagement verfügbar.

Bei der Einführung des zweigleisigen Ansatzes kam schnell das Problem auf, dass Änderungen zwischen Produktions- und Projektlandschaft synchronisiert werden mussten. Es kursieren unter SAP Entwicklern wahre Horrorgeschichten über ellenlange Excel-Tabellen. Mittlerweile haben an diesem Punkt moderne Automatisierungstools angesetzt und, neben vielen weiteren Vorteilen, das klassische Problem der Verwaltung paralleler Systeme weitgehend beseitigt.

Nehmen wir einmal den DevOps-Ansatz mit seiner Grundidee einer kontinuierlichen Integration. Anstatt Änderungen im Projekt- und Produktionssystem regelmäßig zu synchronisieren, können Sie dies auch auf kontinuierliche Weise erreichen, bevor Konflikte auftreten. Wenn zwei Änderungen zueinander in Konflikt stehen, dann ist es nicht immer nötig, Systeme zu sperren und eine Änderung zu blockieren. Nutzen Sie die Vorteile der Konfigurationsmanagement-Tools anderer Plattformen. Sie können die beteiligten Entwickler auf den Konflikt hinweisen und eine zusammengeführte Version anfordern, die die Funktionalitäten beider Änderungen enthält.

Automatisierte Transportmanagementsysteme übernehmen diesen Part und haben den Excel-Alpträumen ein Ende gesetzt. Und wenn alle Änderungen in beiden Landschaften bekannt sind, besteht auch kein Risiko mehr, dass beim Cutover versehentlich eine Regression eingeführt wird. Sollte dennoch eine Änderung eine nicht geplante Auswirkung auf die Produktion haben, können die zuletzt bereitgestellten Transporte auf die vorherige Konfiguration zurückgesetzt werden – so einfach, wie in Java oder C# ein vorher bestehender Zweig wieder erstellt werden kann.

Die Reise zu SAP S/4HANA

S/4 stellt ein besonders herausforderndes Upgrade-Projekt dar, welches in der Regel viele Monate oder Jahre umfasst. Viele Kunden mit einem hohen Individualisierungsbedarf wollen nicht auf ihre Spezialisierungen des ECC-Systems verzichten. Brownfield- oder Hybrid-Migrationen können solche Anpassungen des Altsystems übertragen, auch wenn dabei einige Operationen und Geschäftsprozesse durch weniger spezifische Funktionen der neuen Plattform ersetzt werden.

Bei einer Bewertung von Automatisierungslösungen für S/4-Upgrades muss darauf geachtet werden, dass individuell angepasster Code auch störungsfrei vom ECC zu S/4 übertragen werden kann, ohne dass Funktionalitäten verloren gehen und ohne dass bei der Synchronisierung der Systeme während des Upgrade-Projekts Regressionsprobleme auftreten. Diese Möglichkeit, Änderungen zwischen dem bestehenden ECC-System und der zukünftigen S/4-Plattform automatisch zu synchronisieren, macht den Start von S/4 für alle Beteiligten deutlich einfacher.

Entspannt ankommen

Wenn Ihnen die Vorstellung einfacher und risikoarmer Upgrades zusagt, werfen Sie einen Blick auf moderne DevOps-Tools für SAP, zum Beispiel auf unsere branchenführende Lösung ActiveControl. Mit dem richtigen Ansatz sind vollautomatisches Release- und Transportmanagement, Retrofit und Deployment auch für SAP schon jetzt möglich.