Kein Grund länger mit der HANA Migration zu warten

Seit mehr als 25 Jahren unterstütze ich Unternehmen bei der Implementierung und Modernisierung von SAP.

Zurzeit stehen viele Unternehmen, die SAP einsetzen vor der Entscheidung, wann der beste Zeitpunkt ist, um mit der Migration nach HANA eine Modernisierung ihrer Infrastruktur anzugehen. Aus guten Gründen haben viele IT-Verantwortliche gezögert, die damals revolutionäre In-Memory-Technologie gleich bei ihrer Markt-Einführung zu implementieren. In den vergangenen Jahren ist HANA aber zu einer stabilen Datenbank gereift, zu der mit jedem Service Pack neue Features dazukommen.
Damit sind auch HANA-Migrationen immer mehr zur Routine ohne jedes technische Risiko geworden. Ich war von Anfang an dabei und habe jedes Jahr eine Verdoppelung der HANA-Installationen gesehen. In Anbetracht der riesigen „Installed Base“ haben trotzdem 60-80% der SAP-Kunden diesen Schritt noch vor sich.

Warten wird zum Risiko

Darauf zu hoffen, dass SAP in letzter Minute die „HANA-only“ Strategie wieder ändert, ist ein hohes Risiko – denn SAP hat ihrerseits zum Jahr 2025 die Wartungsverträge mit Oracle, Microsoft und IBM abgekündigt. Damit bleiben die ehemaligen Sybase-Produkte ASE und IQ als einzige Alternativen, aber ohne den Vorteil einer hybriden OLTP/OLAP Architektur bei HANA, die wiederum die Basis für S/4HANA als Nachfolger von ECC bildet.
Denn Berater, SAP Basis und Datenbank-Admins mit SAP Erfahrung sind jetzt schon schwer zu bekommen und wenn in den nächsten 5 Jahren 55.000 produktive NetWeaver-Systeme migriert werden müssen, beißen bei der zu erwartenden Tor-Schluss-Panik in Bezug auf die Stundensätze den letzten die Hunde.

Aus technischer Sicht ist eine HANA-Migration kein Problem, da sie auf seit Jahrzehnten bewährten Verfahren beruht (Export auf Flatfile und Import auf HANA). Mit einem erfahrenen OS/DB Migration Experten und ausreichenden Tests lassen sich auch sehr große Systeme ohne Risiko bequem an einem Wochenende migrieren.

Trotzdem zögern viele Verantwortliche immer noch aus einer verständlichen Angst vor unkalkulierbaren Kosten. Zum einen geht es um die notwendige Hardware. Durch die hohen Vorgaben der SAP an die Hardwarehersteller für die Zertifizierung sind die Kosten einer HANA Appliance sehr viel höher als die einer im Vergleich sehr viel genügsameren traditionellen Datenbank. Zudem muss man den Hauptspeicherbedarf über die Abschreibungsperiode der Hardware abschätzen. Da dieser bei HANA nicht nur von der absoluten Größe der Datenbank abhängt, sondern auch von deren Komprimierbarkeit und der Komplexität der Abfragen eine mehr als anspruchsvolle Aufgabe.

Die größte Unsicherheit bei der Planung des Finanz- und Zeitbudgets für die Migration ist jedoch die Frage, wie lange es dauert unter Umständen zehntausende von Z-ABAPs anzupassen, die sich über die vergangenen Jahrzehnte angesammelt haben.
Spätestens mit S/4 wird ein Teil dieser Kundenanpassungen nicht mehr funktionieren, vor allem wenn sie versuchen in die Datenbank zu schreiben. Denn SAP hat mit S/4 zur Simplifizierung tausende Tabellen mit Metadaten aus der Datenbankstruktur entfernt.
Auch wenn man erst einmal bei ECC bleibt und „nur“ auf HANA migriert, sollte man die Überarbeitung der Z-ABAPs nicht noch länger aufschieben, denn was schon auf der alten Datenbank lahm war, wird auf HANA nicht schneller. Auch für in-memory gilt das „garbage-in, garbage-out“ Prinzip. Nur mit für HANA optimiertem Code laufen auch die Transaktionen schneller.

Glücklicherweise gibt es für beide Fragestellungen erprobte Antworten von Rackspace. Als Mitglied der „SAP Migration Factory“ mit mehr als 20 Jahren Erfahrung in Hosting und Cloud nutzen wir die durch „Tailored Datacenter Integration“ (TDI) geschaffene Möglichkeit HANA zu virtualisieren und dadurch die Größe maßzuschneidern sowie an den sich ändernden Bedarf anzupassen. In der Cloud können darüber hinaus HANA-Systeme bei Nichtgebrauch „schlafen gelegt“ werden, was ebenfalls Kosten spart. Dies gilt besonders bei vielen Entwicklungs-, Test- und Trainingssystemen – denn auch wenn diese viel kleiner sind als Produktionssysteme gilt für sie „Kleinvieh macht auch Mist“.

Das Problem der Kosten und Zeit für die Code Conversion lösen wir dadurch, dass der Code nicht wie üblich offshore manuell umgeschrieben wird. Stattdessen erfolgt dies in Kooperation mit Partnern mittels Werkzeugen, die in der Lage sind pro Stunde zehntausende von Code-Zeilen vollautomatisch zu analysieren und daraus neuen, optimierten Code zu generieren. Damit dauert die ganze Konvertierung gerade mal 2 Wochen.
Dabei zeigt sich, dass die Qualität des automatisch konvertierten Codes wesentlich höher ist als bei manuell geschriebenem, wodurch sich der Aufwand für die Regressionstests durch die Fachabteilungen signifikant reduziert.

Deshalb gibt es keinen Grund mehr noch weiter zu warten, um die Hausaufgaben in Bezug auf die Z-ABAPs zu machen und in den Genuss der durchaus vorhandenen Vorteile von HANA zu kommen.

Ein meiner Meinung zu Unrecht unterschätztes Feature von HANA ist die Möglichkeit Reports ad-hoc zu generieren. Damit entfällt die Notwendigkeit, bei jeder Änderung der Organisationsstruktur oder der Marktbedingungen tage- und wochenlang neue Info-Cubes zu schreiben, bis das Management endlich wieder aktuelle Zahlen bekommt.

Warum Rackspace für SAP

Rackspace hat als ein führender Multi-Cloud-Anbieter die Expertise, unvoreingenommen die richtige Kombination von Cloud Services für die individuellen Bedürfnisse jedes einzelnen Unternehmens zu empfehlen.
Wenn Ihr Unternehmen seine SAP-Zukunft plant, sollten Sie eine Zusammenarbeit mit Rackspace in Betracht ziehen.

Erfahren Sie, wie Rackspace Sie bei Ihren SAP-Anwendungen unterstützen kann – mit konformen Managed Services für Infrastruktur, Anwendungen, Daten und Sicherheit. Melden Sie sich einfach bei uns!

LEAVE A REPLY

Please enter your comment!
Please enter your name here