Im SAP® Lifecycle ist es immer wieder erforderlich ein Projekt- oder Sandboxsystem aufzubauen. Dies kann notwendig sein für Performance-, Update-, Validierungstests. Aber auch für andere Anforderungen wie einen Systemumzug. Sei es auf eine neuere Hardware, in ein anderes Servercenter oder in die Cloud.
Nicht immer sind die vorhandenen nicht-produktiven Staging-Systeme wie Quality Assurance- (QA-), Test-, Trainings- und Development-Systeme der regulären Linien dafür geeignet oder gedacht, für größere Änderungen, wie umfassende Projekte oder komplexe Software-Upgrades, genutzt zu werden. In diesen Fällen greifen Organisationen gerne auf Sandbox-Systeme zurück, die beliebig verändert und im Zweifelsfalle auch logisch zerstört werden können, ohne dass dies Auswirkungen auf die reguläre Linie hat.
Der Nutzen dieser Projekt- und Sandboxsysteme steigt mit ihrer auch kurzfristigen Verfügbarkeit, sowie ihrer Fähigkeit, die logischen Eigenschaften der regulären Linie abzubilden. Mit Fokus auf den letztgenannten Punkt werden für die Bereitstellung dieser Systeme normalerweise nicht leere Standardsysteme, sondern Systemklone, also vollständige Abbilder, der Systeme der regulären Linien aufgebaut.
Je nach Architektur, Komplexität und Größe der SAP-Landschaft kann dies eine sehr umfangreiche Aufgabe werden, üblicherweise umfasst diese Prozedur eine große Zahl manueller Aktivitäten, die sich über Stunden bis hin zu Tagen ziehen können. Handelt es sich dazu noch um Umgebungen mehrerer verbundener Systeme, addieren sich diese Zeiten im Rahmen eines Landschaftsklones auch gerne zu einer wirklichen Arbeitsbelastung der ausführenden Organisationseinheiten, für die es nie „den richtigen“ Zeitpunkt gibt. System- und Landschaftsklone blockieren wichtige und nicht zuletzt auch teure Ressourcen: interne oder externe SAP-Basis Professionals.
Es kommt ganz darauf an. Dies ist sehr abhängig von den Anforderungen. Geht es darum ein möglichst standardisiertes System aufzubauen, dann wird hier wohl die Entscheidung auf die Neu-Installation from-the-scratch fallen.
Da die SAP® Systeme aber im täglichen Gebrauch angepasst werden und damit immer weiter vom Standard abweichen ist dies nicht immer passend. Diese Abweichungen oder „Schmutz“ können für andere Test-Anforderungen gerade relevant sein. Ein Performance-Test auf einem „sauberen“ frisch aufgesetzten System kann nicht vergleichbar sein mit einem genutzten System mit all seinen Unmengen an Daten und genau der Verteilung bzw. Struktur der Daten.
Genauso verhält es sich auch mit Update- oder Validierungstests. Gerade die im Gebrauch angepassten Parameter oder eingespielten Programme können ein einfaches Update verhindern und darum genau geht es ja bei solch einem Update-Test. Einen sauberen Update-Ablauf zu finden, um genau dieses bestehende System mit möglichst kurzer Downtime auf einen neuen SW-Stand zu bringen.
Auch die Aufwände für den Aufbau der Systeme spielen bei der Überlegung eine Rolle.
Mit einer Automatisierung können hier die Durchführenden enorm entlastet werden und durch den Automatismus ist der Aufbau auch einfach wiederholbar.
Die Installationen lassen sich meist über mitgegebene Parameterfiles automatisieren. Dennoch muss hier die Installation durchlaufen werden und das ist meist zeitaufwendiger als ein bestehendes System zu duplizieren, also zu klonen. Was gibt es dabei zu beachten?
Für den Aufbau von Testsystemen:
Hierbei muss aber als Teil des Klonings bzw. anschließend beachtet werden, dass das System ggfs. nicht einfach 1-zu-1 übernommen werden kann. Dies sind offensichtliche Dinge wie der Rechnername. Aber auch Informationen im System sind hier zu berücksichtigen. Sprich infrastrukturelle Informationen wie Drucker oder Verbindungen und Schnittstellen zu anderen Systemen sowie Jobs, die im SAP System laufen.
Es gilt aber noch weitere Punkte zu bedenken. Sollen die Tester die „wahren Daten“ sehen dürfen? Hiermit sind Sicherheitsanforderungen zu beachten, so z. B. die DSGVO. Nun gilt es also die Daten so zu verfremden, dass hier keine relevanten Informationen ausgelesen werden können, aber nach der Verfremdung muss die Verteilung bzw. Struktur der Daten noch dem Original entsprechen, weil sonst beispielsweise für Performance-Tests die Testergebnisse wieder nicht belastbar sind.
Hier ist vor allem wichtig, dass das duplizierte System möglichst weitestgehend dem Quellsystem entspricht sowie die Downtime, die für den Aufbau des duplizierten Systems entsteht, möglichst geringgehalten wird.
Es zeigt sich, dass im Vorfeld einige Fragen zu klären sind und aufgrund der Anforderungen dann der Weg für die optimale Umsetzung basierend darauf definiert werden muss.
Die Libelle IT Group kann Sie hier als Experte mit 27 Jahren Erfahrungen unterstützen. Als auch Ihnen Tools an die Hand zu geben, um diese möglichst optimale Umsetzung realisieren zu können. Libelle SystemClone - hilft Ihnen die oben genannten Herausforderungen automatisiert zu meistern. Informieren Sie sich jetzt und sichern Sie sich Ihr kostenloses Whitepaper.