COVERSTORY

58

Hana-Busters

E-3 APRIL 2016

M it den Geschäftsführern von Q-Partners, Guido Hoepfner und Matthias Kneissl, sprach

E-3 Chefredakteur Peter Färbinger. Was sind die Herausforderungen für einen Ein-satz von Hana und S/4? Was ändert sich beim SolMan, Abap und UI5? Und warum braucht die SAP-Community dringend dis-ruptive Hana-Busters? Die Ghostbusters sind allgemein bekannt. In Österreich gab

es lange Zeit eine wissenschaftliche Kaba-retttruppe mit dem Namen Science Busters. Die SAP-Community hat mit Guido Hoepf-ner und Matthias Kneissl die Hanabusters, weil kaum jemand die Technologie besser beherrscht und eine SolMan-, Abap- und S/4-Roadmap für die SAP-Bestandskunden hat. Meisterhaft ist das agieren von Q-Part-ners aufgrund des ganzheitlichen Ansatzes: Beginnend bei der Hana-Architektur bis hin

zur App-Entwicklung und Verwaltung durch den neuen SolMan – das Team von Q-Part-ners kennt alle Tipps und Tricks.

„Q-Partners war eine der ersten SAP-Re-ferenzen im Mittelstand für ERP on Hana“, erklärt Matthias Kneissl nicht ohne Stolz. „Wir setzen SAP für unsere eigenen inter-nen Prozesse in der Business Suite auf Basis von Hana ein und waren 2013 im Ramp-up. Darüber hinaus sind wir SAP Recognized Expertise im Bereich In-memory Computing und SAP-Datenbanken.“ Und Guido Hoepf-ner ergänzt im Gespräch mit Chefredakteur Peter Färbinger: „Wir investieren sehr stark in unsere Mitarbeiter und in Ausbildung. Unsere SAP-Basisberater sind mehrfach zertifiziert - sowohl als Technologen als auch im Bereich OS/DB-Migration und SAP Hana. Im Applikationsumfeld ist dies ähn-lich, bei allen unseren Mitarbeitern streben wir neben dem fachlichen Know-how in den Modulen auch immer eine Zertifizierung als Hana-Consultant an.“ Viel Aufwand und Engagement für die neue SAP-Plattform, aber der Markt und die Analysten geben den beiden Geschäftsführern Recht.

Die Analysten der Experton Group haben Ende vergangenes Jahr recherchiert, dass die Umstellung auf oder Neueinführung von Hana ein breites Spektrum an Lösungen erfordert, angefangen bei der Distribution (Lizenzierungsmodelle) und den Techno-logien (Hardware, Software, Infrastruktur) über die Services (Strategien, Analysen, Business Case Betrachtungen) bis hin zur eigentlichen Transformation (Implementie-rung, Migration, Integration). Speziell der Bereich Services mit der Entwicklung kun-deneigener Hana-Strategien und der Dar-legung des individuellen Nutzens für den Kunden auf Basis von belastbaren Business Case Betrachtungen stellt viele Dienstleister vor eine Herausforderung.

Q-Partners kann alles und bietet des der Community an, auch wenn momen-tan die Personaldecke sehr dünn ist. „Die Anzahl der Hana-Spezialisten ist sicherlich aktuell noch etwas dünn gesät“, bestätigt

HanaMeisterhaft hat Professor Hasso Plattner die In-memory-Computing-Technologie belebt undrevolutioniert. Die Hana-Datenbank war ein disruptives Ereignis. Die erste Generation derHana-Busters kam aus Walldorf. Die zweite Generation kommt aus der SAP-Partner-Community.

Die 1. Generation der SAP-Hana-Busters: Ex-Vorstand Jim Hagemann Snabe (oben), Ex-CTO Vishal Sikka (grün), Vorstand Gerd Oswald, SAP-Chef Bill McDermott, Ex-Vorstand Lars Dalgaard (v.l.n.r.).

COVERSTORY

59

Hana-Busters

E-3 APRIL 2016

Matthias Kneissl. „Das liegt aber sicherlich auch daran, dass die Technologie nun erst im Markt ankommt. Wir haben uns schon frühzeitig für das Thema spezialisiert und neben den klassischen Technologie- und Applikationsthemen sind unsere Berater für die Hana-Themen ausgebildet. Die größ-te Herausforderung ist es, dieses Wissen aufgrund der Innovationsgeschwindigkeit aktuell zu halten.“

„Die Historie der SAP-Landschaften bei Endanwendern könnte vielfältiger nicht sein, eine standardisierte Ausgangsbasis existiert nicht. Hier ist es für Anbieter wichtig, den Kunden abzuholen und seine individuelle Situation nicht nur zu erkennen, sondern in der Lage zu sein, darauf zu reagieren“, wissen die Analysten der Experton Group. Der Einsatz von Hana ist mehr als nur ein technisches Upgrade. Die richtige Strategie, die passende Technologieplattform sowie ein klarer Business Case für die Geschäfts-prozesse können über Erfolg und Kosten eines Hana-Projektes entscheiden. „So-wohl im Betrieb als auch im Customizing ist Hana eine andere Technologie und damit komplexer“, erklärt auch Guido Hoepfner. „Im Betrieb müssen neue Betriebsformen definiert und implementiert werden. Soll die Anwendung tatsächlich von Hana profitie-ren, so sind auch die kundeneigenen Pro-gramme zu berücksichtigen und auf Hana auszurichten. Dies erfordert Umdenken bei den Entwicklern bzw. auch Anpassung der bestehenden Programme.“

Dazu kommt, dass Anwender neben Hana sich auch mit den neuen begleiten-den Technologien SAP UI5 und Fiori ausei-nandersetzen sollen. Auch diese Themen bescheren natürlich neue Komplexität. Eine Umstellung auf Hana in welches Szenario auch immer, ist kein reines IT-Projekt. Um den Mehrwert wirklich ausschöpfen zu kön-nen, ist ein Zusammenspiel von Business und IT dringend erforderlich. Gefragt sind Anbieter, die beides abdecken können, Bu-siness- und Strategieberatung gleicherma-ßen wie technische Umsetzung. Aber auch

Anbieter, die sich auf einzelne Bereiche fo-kussieren und hier gezielt eine tief gehende Expertise aufbauen, können in Kombination mit anderen Anbietern eine wesentliche Rol-le am Markt einnehmen.

„Bei Q-Partners bieten wir den kom-pletten Hana- Lebenszyklus von Konzep-tion über Implementierung bis hin zum Betrieb an“, kennt Matthias Kneissl sein Angebot, dass genau auf die SAP-Com-

munity abgestimmt ist. Meist beginnt das mit einem Lösungsdesign und Architek-turkonzept. Hier gilt es die Frage nach der Tailored Datacenter Integration (TDI) oder Appliance, Intel Xeon oder IBM Power zu betrachten. Auch diverse Storage-Systeme und Backup-Lösungen müssen verglichen werden. Das Betriebskonzept muss erstellt werden. „Hier ist oft vom Kunden ein Ver-gleich Insourcing gegenüber Outsourcing

Busters

Die 2. Generation der Hana-Busters: Gründer und Geschäftsführer von Q-Partners, Matthias„SolMan“ Kneissl (li.) und Guido Hoepfner (re.) weithin bekannt in der SAP-Community.

COVERSTORY

60

Hana-Busters

E-3 APRIL 2016

gewünscht“, erklärt Guido Hoepfner und ergänzt: „Als unabhängiges Beratungshaus ohne einen integrierten Hardwarevertrieb können wir hier den Kunden im Rahmen von Workshops individuell und lösungsorientiert beraten. Im Rahmen von Total Cost-of-Ow-nership-Kalkulationen – hier Betrachten wir meist einen Zeitraum von drei Jahren – können wir die beste Kombination aus Plattform- und Betriebsform ermitteln. Die Ermittlung findet statt auf Basis von Preis/Leistung anhand der kundenspezifischen Service Level Agreements.“

Business & IT

Mittlerweile ist es den meisten Dienstleis-tern als auch Anwenderunternehmen klar geworden, dass Hana keine Modeerschei-nung, sondern ein ernst zu nehmender Schritt in die Zukunft ist. Die Ergebnisse des vorliegenden Experton-Benchmarks zeigen deutlich, wie Anbieter im Hana Markt auf-gestellt sind und wohin die Reise geht. Vor allem aber zeigen die ersten abgeschlosse-nen Projekte, welchen Mehrwert Endkunden tatsächlich erwarten können.

Die Herausforderung für Anbieter liegt vor allem darin, die Brücke zwischen IT und Business zu schlagen. Hana Projekte sind keine reinen IT-Projekte und schon gar kei-ne technischen Releasewechsel. „Nur wer den Spagat schafft, IT-Know-how mit Pro-zess- und Businessdenken zu verknüpfen, wird langfristig erfolgreich am Hana-Markt sein“, so Frank Schmeiler, Projektleiter des Benchmarks und Research Direktor bei der Experton Group. Matthias Kneissl hat daruf eine Antwort: „Sind die Konzeptionsfragen geklärt, unterstützen wir den Kunden bei der Installation bzw. Implementierung inklusi-ve Solution Assurance für TDI. Wir bieten Migrationen auf Hana für alle SAP-Kom-ponenten an und weisen danach entweder den Kunden in den Betrieb ein oder können einen vollen Managed Service anbieten. Da-mit decken wir den gesamte Produktlebens-zyklus durch mehrfach zertifizierte und sehr erfahrenen Beratern ab. Meist wünschen sich Kunden hier ein Komplettpaket, das wir natürlich gerne offerieren.“

„Hana bzw. In-memory-Technologie birgt zweifellos diverse Vorteile“, ist Guido Hoepf-ner überzeugt. „Massiv gestiegene Perfor-mance – nicht nur im OLAP Bereich – mit merklicher Reduktion der Datenbestände. Durch diese Kombination ergibt sich eine Vielzahl neuer funktionaler Möglichkeiten, bestehende Geschäftsprozesse zu optimie-ren oder neue zu Geschäftsmodelle zu abzu-bilden.“ Und Matthias Kneissl ergänzt: „Auf technischer Ebene bringt die Technologie auch eine Vielzahl von Vorteilen, die darauf

bezogen zu einer besseren Total Cost of Ow-nership führen als konventionelle Datenban-ken: die Storage-Belegung wird verringert und damit auch die Backup-Umlaufzeiten. Die Hana-Architektur kann auf verschiede-ne Arten hochverfügbar ausgelegt werden: synchron, asynchron, preload, preload oder per Failover.“ In Summe hat Hana eine sehr gute Stabilität, weiß man bei Q-Partner, aber ist im Vergleich zu traditionellen und lang erprobten Plattformen immer noch recht neu. „Dies bedeutet, dass ausgiebige Tests in der kundeneigenen Landschaft erforder-lich sind“, betont Kneissl.

Wartung & Reifegrad

„Hana ist sehr ausgereift für eine vergleichs-weise neue Technologie im Releasestand 1.x“, lobt Matthias Kneissl. „Dennoch spre-chen wir hier von kürzeren Release- und Wartungszyklen und damit verbunden auch mit erhöhten Wartungs- und Testaufwän-den – hier sehen wir im Mittel nur neun Monaten anstatt bei konventionellen Da-tenbanken 12 bis 18 Monaten. Im Vergleich zur von SAP genannten AnyDB haben wir hier einen wesentlich höheren Innovati-onsgrad. Die Aufwände zur Integration der neuen Funktionen und Features darf natürlich nicht vernachlässigt werden. Ne-ben der reinen Umsetzung muss auch der notwendige Test in der Kundenumgebung berücksichtigt werden.“ Interessant in die-sem Zusammenhang eine Erkenntnis von PAC-Analyst Frank Niemann: „Doch was an Aufwand sowie an Kosten für Hana-Projekte auf sie zukommt, können die Firmen heute oftmals noch gar nicht beziffern. Zudem müssen Unternehmen das neue Produkt so-wie unter Umständen auch neue Hardware anschaffen. Es braucht gute Argumente und überzeugende Business Cases, um diese Investitionen zu rechtfertigen angesichts bereits bestehender SAP-Landschaften in den Unternehmen und der damit anfallen-den laufenden Kosten.“

Hana-Busters & S/4

Q-Partner hat im Hana-Umfeld schon diver-se Projekte umgesetzt. „Wir haben sowohl, BW on Hana, als auch Solution Manager on Hana sowie S/4 Hana implementiert und unterstützen dies auch im Betrieb“, erklärt Guido Hoepfner. „Bei der Hana Enterprise Cloud und Hana Cloud Platform sind unsere Kunden noch sehr zögerlich. Generell set-zen Cloud-Lösungen ein großes Vertrauen des Kunden in Hinblick auf Datenschutz und Datensicherheit voraus. Genau dieses Vertrauen ist in Deutschland bei wenigen Kunden gegeben.“ Und Matthias Kneissl er-

gänzt: „Ganz klar sprechen wir hier meist mit Kunden über Hana on-premise. Sicher-lich gibt es Lösungen, in denen der Kun-de die Systeme im Outsourcing betreiben lässt. Dies ist ja dann aber noch keine echte Cloud-Lösung, sondern eine Betriebsform, die es schon mehr als zehn Jahre gibt. Lö-sungen wie Microsoft Azure können auf-grund des Pay-per-Use-Konzepts große Vorteile in der betriebswirtschaftlichen Kal-kulation bieten. Dennoch stellt gerade das Thema Datenschutz und Datensicherheit hier immer die größte Hürde dar.“

Insgesamt betrachten die Bestandskun-den S/4 Hana heute eher als einen Weg zu besseren SAP-Anwendungen. Das mögliche Innovationspotenzial in Richtung neuer Pro-zesse und Geschäftsmodelle ist ihnen dabei nicht präsent, hat Analyst Frank Niemann recherchiert. Und noch eine Analyse zum S/4-Hana-Markt gibt es von PAC: Während viele Firmen überzeugt sind, der SAP-Pro-duktstrategie früher oder später folgen zu müssen, sehen andere bereits klare Vorteile und Innovationspotenziale, die sich ihnen mit S/4 Hana bieten. Sie erhoffen sich, eini-ge der heutigen Herausforderungen im Zu-sammenhang mit SAP-Umgebungen besser bewältigen zu können. Weniger häufig wird der Einsatz von S/4 Hana getrieben von dem Willen, Geschäftsprozesse zu transformie-ren sowie neue Geschäftsmodelle rund um Big Data, Internet of Things bzw. Industrie 4.0 zu entwerfen.

Ressourcen & Deadline

In der Vergangenheit gab es in der SAP-Com-munity einen Stau beim Releasewechsel von R/3 auf ECC 6.0 – unter anderem weil es zu wenig Berater und Ressourcen der SAP-Partner gab. Kann sich ähnliche für S/4 wiederholen und ist die Deadline 2025 zu schaffen? „Die Deadline ist sicherlich eine große Herausforderung für SAP Kunden“, meint Guido Hoepfner. „Insbesondere vor dem Hintergrund, dass sich technologisch in Richtung Hana sehr viel ändert. Hier ist auf eine gute Planung der Infrastruktur zu achten sowie auf ein sicher herausforde-rungsvolles SAP-Basisprojekt. Im Applika-tionsumfeld liegen die Herausforderungen sicherlich noch eine Messlatte höher. Die Technologie und Programmierumgebung ist das, was man einen Disruptive Change wohl nennen dürfte. Wir schwenken auf eine objektorientierte Sichtweise, HTML5, ein serviceorientiertes Programmiermo-dell sowie neue Datenstrukturen. Alleine die Tatsache, dass sich die Oberfläche än-dert in Richtung HTML5 und Fiori und auch die Datenstrukturen ändern, ist für die IT Abteilungen und auch gestandene ABAP

COVERSTORY

61E-3 APRIL 2016

Programmierer vieles neu zu erlernen und zu erfahren.“ Und Analyst Frank Niemann bestätigt in seiner Hana-S/4-Studie: „Somit muss es den Firmen gelingen, die Bewälti-gung der bestehenden Herausforderungen, die Optimierung der SAP-Umgebungen sowie Innovationen rund um ihre digitale Agenda unter einen Hut zu bringen – alles andere als eine leichte Aufgabe.“

Fazit & Zukunft

Die Hana-Busters haben ein ganzheitliches Konzept, das SolMan, Abap, S/4 und eben Hana umfasst. „Der Upgrade des SAP So-lution Managers von 7.1 auf 7.2 ist ja schon durch das Wartungsende am 31. Dezember 2017 für IT-Verantwortliche als Hausaufgabe zu erledigen“, erklärt Matthias Kneissl – un-ter anderem der monatliche SolMan-Kolum-nist des E-3 Magazins. Wie bei S/4 kommt auch schon beim neuen Solution Manager konsequenterweise SAP UI5 als Oberflä-chentechnologie zum Einsatz. „Kunden, die bislang den Solution Manager nur zum Herunterladen der Wartungsvorgänge nut-zen haben natürlich keine größeren Hürden zu überwinden und können gegebenenfalls sogar eine Neuinstallation durchführen. Für Kunden, die diverse Szenarien im Einsatz haben – siehe meine Kolumne –, ist das natürlich eine größere Herausforderung“, warnt Kneissl. „Hier müssen die Szenarien im neuen Release getestet, gegebenenfalls neu customized und an die Endanwender transportiert werden. Durch die neue Ober-flächentechnologie sind auch sicherlich Schulungen relevant. Alleine aus diesem Grund ist der Upgrade durchaus ernst zu nehmen und zu planen.“ Sein Kollege, Gui-do Hoepfner, ergänzt den Ausblick in die Zukunft: „Jeder Kunde, der sich mit dem Gedanken trägt, die Infrastruktur neu zu beschaffen, sollte auch das Hana-Thema berücksichtigen. Alleine schon durch S/4 ist Hana der konsequente und richtige Weg. Eine gute und abgestimmte Planung ist hierbei jedoch relevant.“ Weiters meint man naturgemäß bei Q-Partner, dass eine Beschäftigung mit den neuen Themen (SAP UI5, HTML bzw. Fiori) ebenfalls frühzeitig erfolgen sollte. Schließlich gilt es einiges an Know-how aufzubauen. Darüber hinaus sollten insbesondere größere und neue Entwicklungsvorhaben gegen die neuen Technologien SAP NetWeaver Gateway bzw. SAP UI5 abgeglichen werden, um technolo-gisch auf das richtige Pferd zu setzen. „Die Planung einer Infrastruktur für HANA ist nicht zu unterschätzen und sollte auch rechtzeitig angegangen werden“, betonen beide „Hana-Busters“-Geschäftsführer zum Abschluss des E-3 Gesprächs-

Hana-Busters

Guido Hoepfner und Matthias Kneissl sehen viele Vorteile in Hana on IBM Power.

Ist die neue IT-Infrastruktur mit Intel Xeon und Linux angekommen und akzeptiert in der SAP-Community?Matthias Kneissl: Ja, Intel und Linux wer-den SAP-Welt nicht mehr in Frage gestellt! Die erforderliche Unterstützung zieht sich üblicherweise durch alle Phasen, von der Konzeption bis hin zur Umsetzung und Betrieb. Meist beginnt es beim Sitzing der Architektur.

Welche Bedeutung hat Hana on IBM Power?Kneissl: Aktuell ist die Bedeutung im Markt leider noch sehr gering. Das Konzept bietet jedoch vielfältige Vorteile. Wenn der An-schaffungspreis der Hardware vergleichbar zur Intel ist sprechen wir über eine sehr vali-de Alternative. Hier zeigen sich die Vorteile insbesondere für CRM und ERP im Scale Up Verfahren. Eine TDI kann durch den besse-ren Zuschnitt der LPARs optimiert werden.

Gibt es bei Q-Partners bereits HoP-Projekte? Guido Hoepfner: Ja, in verschiedenen Pha-sen. Wir haben Projekte als Proof-of-Con-cept im Labor für Demo und Testzwecke, sind aber auch in der Implementierungspha-se von ersten Projekten. Diese sind jedoch noch nicht live. Die Anwender haben alle immer schon Power Architekturen betrieben – AIX oder iSeries beziehungsweise AS/400 – und schätzen die Flexibilität und Perfor-mance der großen Power Maschinen, die bedarfsgerecht durch LPARs zugeschnitten werden können. Darüber hinaus zeichnet sich die Power Architektur ja schon immer durch die hohe Verfügbarkeit aus.

Man sieht wenig innovative Graph- und Neuronale-Netz-Lösungen auf Basis von Hana Predictive Analysis Library, PAL: Kann die Hana-Plattform mehr als die ERP- und IT-Szene braucht?Hoepfner: Sicher sind neuronale Netze oder Bibliotheken für Support Vektor Ma-chines interessant, aber nicht unbedingt für den klassischen ERP-Anwender. Das ist insbesondere dann spannend, wenn Hana als Plattform zur Implementierung von Lö-sungen außerhalb der ERP Szene genutzt wird. Dies dürften dann vornehmlich Cloud Lösungen sein.

Was darf der SAP-Bestandskunde vom neu-en SolMan 7.2 erwarten?Kneissl: Der SolMan unterstützt den Kun-den in allen Disziplinen des Lifecycles. Die neue Lösungsdokumentation kommt ge-rade richtig zu S/4. Wenn der Kunde den Releasewechsel vernünftig durchführen will, hat er endlich ein Werkzeug, in dem er vor dem Wechsel seine Prozesse dokumentie-ren kann und darauf eine sinnvolle Testdo-kumentation und einen Testplan aufbauen kann. Dafür ist natürlich Vorarbeit notwen-dig, aber die sollte genau jetzt mit dem 7.2 angegangen werden. Ist es fünf vor zwölf und der Releasewechsel muss durchgeführt werden, sind alle auf einmal ob der Dring-lichkeit überrascht und niemand hat Zeit, für S/4 noch Prozesse zu dokumentieren.

Ein detailliertes Interview mit Matthias „SolMan“ Kneissl zum SAP Solution Manager 7.2 lesen sie in der E-3 Ausgabe Mai 2016.

Ein Kurzinterview mit den Hana-Busters Guido Hoepfner und Matthias Kneissl von Q-Partners.

Was die Hana/SolMan- Community diskutiert ...

COVERSTORY

62

Hana-Busters

E-3 APRIL 2016

N eben den Implementierungsan-satz der Appliance (Black Box) und der kundenspezifischen TDI

(tailored datacenter integration) gibt es verschiedene Formen der Verfügbarkeits-auslegung einer Hana-Landschaft. Diese werden wiederum direkt die Architektur selbst beeinflusst. Dabei unterscheidet man grundsätzlich zwischen der asyn-chronen oder Storage basierten High Availability (HA) zu den synchronen HA-Mechanismen, die die Hana DB von Hause aus mitbringt. Neben dem Mo-dus „asynchron“ gibt es noch innerhalb der synchronen HA drei verschiedene Auslegungen: Sync, Sync-MEM und Full Sync. Während der Standard Sync Modus mit einer Fire-and-Forget-Methode zur Schatteninstanz verglichen werden kann, warten die anderen beiden Mechanismen darauf, dass die Spiegelseite die Daten-bankbefehle entweder im Memory, oder im Full-Modus, sogar bis in den Storage weggeschrieben haben. Die daraus resul-tierenden erhöhten Sicherheitsstufen der Synchronität werden mit einer ebenfalls erhöhten Abhängigkeit und höheren Per-formanceanforderungen auf der Spiegel-seite erkauft. So kann es im schlechtesten Fall beim Full-Sync dazu kommen, dass eine Spiegelseite die Produktivseite aus-bremsen oder komplett lahm legen kann. Je nach gewünschter HA- Stufe muss die Spiegelseite entsprechend performant zur Produktivseite aufgebaut werden. Zudem gibt es in Scale-out-Umgebungen die Option des Failover, um einem Ser-verausfall vorzubeugen. Darüber hinaus gibt es aktuell zwei Cluster Varianten auf Betriebssystemebene, als Ergänzung zu den Sync-Methoden der Hana selbst. Ma-nuell (händisch bzw. skriptbasiert) oder vollautomatisch mit einem Cluster Fra-mework (Red Hat Enterprise Linux High Availability Add-on bzw. Suse-Extension). Demzufolge kommt schon in der Archi-tektur- und Designphase die Frage auf:

Wer führt den Takeover durch (geplant oder ungeplant)? Der DB-Admin auf Ha-na-Ebene oder doch der Linux-Admin im Cluster Ressource Manager (Pacema-ker). Spätestens für das Einstellen des DBSL Suspend Features wird zudem der SAP-Basis-Admin benötigt.

Insgesamt kann man festhalten, dass die meisten SAP-Kunden heute eine TDI-Umgebung klar einer Appliance vor-ziehen, zum einem um bestehende In-vestitionen weiterzuverwenden und zum anderen, um die Gesamtarchitektur ro-bust und gemäß ihren Anforderungen an-zupassen. Bzgl. der HA-Architektur sind die Sichten so unterschiedlich wie die Bedarfe. Meistens werden Failover-Sze-

narien mit dem Standard-Sync-Mechanis-mus ergänzt, um auf HW- und SW-Ebene Vorsorge zu tragen.

Hana Lifecycle und Folgen

Durch die rasante Entwicklung der Ha-na-Technologie sieht der Wartungszyklus der SAP für ein SPS effektiv nur neun Mo-nate Support vor. In Anbetracht dessen, dass man nur DSPs (DataCenterServ-ciePoints) in Produktionsumgebungen einsetzen sollte (deren Freigabe ist etwa alle sechs Monate), werden die Wartungs-fenster zeitlich sehr knapp. Besonders, wenn man noch eine Testphase von 1-2 Monaten abzieht. Möchte man zudem

Projekterfahrungen

Robuste Hana-Umgebungen bauenJeder SAP-Kunde, der neu auf die Hana-Plattform schwenkt, stellt sich Fragen nach Architekturkonzept, Hochverfügbarkeit, Backup, Wartungs- & Lebenszyklen und Know-how-Aufbau.

Von Guido Hoepfner und Jens Gleichmann, Q-Parnters

Guido Hoepfner sieht Hana in einer steilen und dynamischen Entwicklung.

COVERSTORY

63

Hana-Busters

E-3 APRIL 2016

Hana eigenständig installieren und be-treiben, benötigt man mindestens zwei Hana-Zertifizierungen. Neu ist allerdings, dass diese Zertifizierungen nur noch drei SPS, also ca. 3x6 Monate, gültig sind. Ak-tuell ist noch unklar (Rückfrage liegt direkt bei der SAP), ab wann die Zertifizierungen gültig ist, sprich zum Zertifizierungs- oder zum Releasezeitpunkt. Unabhängig davon resultiert aktuell ein Re-Zertifizierungsbe-darf der Mitarbeiter von spätestens allen 1,5 Jahren bzgl. Hana. Bei allen anderen von SAP zugelassenen DBs (anyDB) war dies nie der Fall. Stellt sich die Frage, ob das ein notwendiges Muss oder doch nur eine zu-sätzliche Einnahmequelle der SAP darstellt.

Wer ist zuständig?

Wie schon zuvor angesprochen, stellen sich aufgrund der Hana kundenindividuel-len TDI-Architekturen die Zuständigkeits-fragen bzgl. des Betriebes, des Monitoring und der Wartung. Welcher Fachbereich ist wofür in der Hana TDI zuständig? Insour-cing, Outsourcing/Cloud oder Managed Services? Bei vielen Kunden wird dies über die Hana Einführung neu definiert. Hier empfiehlt sich, über einen Hana SLA eine RACI Matrix zu legen, welche Aufgaben vom Linux-, HDB- oder SAP Basis-Admin um-gesetzt und verantwortet werden. Anhand dessen kann man auch mit wenig Aufwand seine Sourcing- und Ausbildungsbedarfe ermitteln. Zudem sein erwähnt, dass ein vernünftiges und in die Hana integriertes Meldewesen (Alerting) aktuell nur über den Solution Manager erreichbar ist. Ein weiterer wichtiger Punkt ist das Hana Housekeeping. Der Backup Katalog enthält alle wichtigen data- und log-Sicherungen und wird bei jedem Backup mitgesichert. Dieser sollte zyklisch bereinigt werden, da es dafür keine automatisierte Funktion in der Hana gibt.

Fazit

Aus technologischer Sicht lässt sich fest-halten, dass sich Hana nach wie vor in einer steilen und dynamischen Entwick-lungskurve befindet. Es empfiehlt sich, sich sowohl architektonisch sowie organi-satorisch nachhaltig aufzustellen, um von den Neuerungen profitieren zu können, als auch um die Hana-Technologie als Kern-kompetenz im eigenen Unternehmen zu etablieren. Darunter fällt auch weitsichtig das Prüfen und Scannen der bestehenden ERP Komponenten in Richtung S/4 Hana mittels des Reports R_S4_PRE_TRANSI-TION_CHECKS (Hinweis 2182725), der ca. ein Jahr ihre bestehenden SAP Systeme in Richtung S/4 Hana Readyness prüfen sollte.

„Es dürfte vergleichsweise schwer hierfür werden“, meint Matthias Kneissl. „Klar stellt SAP mit dem Hana-Stack auch eine Lösung zur Verfügung, die durchaus mit einem JBoss mehr als konkurrieren kann. Allerdings gibt es darüber hinaus sicherlich auch das Thema hin-sichtlich Preise und Lizenzierung. Darüber hinaus sind klassische Java Enterprise Entwickler ihre jeweiligen Stacks gewohnt, so dass es schwierig werden dürfte, hier einen Takeout der bekannten Kandidaten JBoss oder WebSphere durchzuführen. Damit ein Kunde den Stack tauscht - im J2EE Umfeld ja deutlich komplizierter als in der SAP Welt – wo eine OS/DB Migration mit Standard-Tools mög-lich ist – muss er ja deutliche Vorteile daraus ziehen. Sicherlich sind die Bibliotheken für Textsuche und Fuzzy Logik toll, diese werden aber unserer Sicht nach von SAP noch nicht stark genug in der Community vermarktet. Darüber hinaus ist SAP auch in der Java Community ein neuer, bislang weitestgehend unbekannter Play-er.“ Guido Hoepfner ergänzt dazu, dass die Innovation bei den Q-Part-ner-Kunden einerseits im Bereich Mobiler Lösungen, Nutzung der Fiori Apps sowie Entwicklung eigener Applikationen auf Basis SAPUI5 statt-findet. „Im Bereich Technologie ist es tatsächlich so, dass sich eine Vielzahl

unserer Kunden für das Thema SAP Hana interessieren und wir aktuell diverse Umstellungen bestehender Lösungen auf Hana durchführen“, berichtet er aus einer beruflichen Pra-xis. „Wenn dieses Fundament gelegt ist, sind die Voraussetzungen für In-novationen auf Seiten der Applikation möglich. Dies ist eine Entwicklung, die wir kommen sehen. Logischer und erster Schritt ist die SAP-basis-technische Umstellung auf die neue Plattform.“ Die Herausforderungen liegen insbesondere darin, die neuen Programmiermodelle, Technologien und Architekturen zu integrieren. Aus der Historie heraus kann in Abap sowohl objektorientiert als auch his-torisch nicht-objektorientiert struk-turell programmiert werden. „Dies ist ja heute noch in Reports üblich und bisweilen auch sinnvoll“, betont Kneissl. Mit der neuen Technologie in Richtung Hana, SAPUI5 und NetWea-ver Gateway muss man sich deutlich stärker in Richtung Objektorientie-rung bewegen. „Dies ist insbeson-dere wichtig, damit Anwender die neuen Technologien sinnvoll nutzen können und auch von den Vorteilen profitieren. Dies ist natürlich schon ein deutlicher Change, den ein An-wender nicht von heute auf morgen realisiert. Im Bereich der Technolo-gie verhält es sich ähnlich“, ergänzt Hoepfner.

Hana & Non-ERP

Die Hana-Busters: Matthias Kneissl (li.) und Guido Hoepfner (re.), Q-Partners

COVERSTORY

64

Hana-Busters

E-3 APRIL 2016

E s ist doch erfrischend zu erfahren, dass man inzwischen bei der Tech-nologieplattform eine Wahlfreiheit

besitzt. Seit letztem Jahr haben Hana-An-wender die Möglichkeit zwischen Intel und IBM Technologie zu wählen.

Die neuen Power-8-Prozessoren von IBM sind ein wahrer Segen für die SAP Lösungen, die wir in Zukunft einsetzen sollen. Simplify your Business hören wir auf allen Kanälen. Dazu passen die Vor-teile einer IBM Power Plattform wie der sprichwörtliche Deckel auf den Kochtopf.

Wichtig für den Mittelstand ist und war die notwendige Verfügbarkeit der gängi-gen SAP-Komponenten. Mittlerweile sind folgende SAP Lösungen für Hana on Pow-er (HoP) freigegeben, wie man in einschlä-gigen SAP Hinweisen nachlesen kann:

○ SAP EHP1 for SAP NetWeaver Business Warehouse 7.3○ SAP Business Warehouse 7.4○ SAP ERP 6.0 EHP7○ SAP CRM 7.0 EHP3○ SAP SRM 7.0 EHP3○ SAP BusinessObjects Business Intelligence Platform 4.1 SP03○ SAP Business Planning and Consolida- tion 10.1 (kontrollierte Verfügbarkeit)

Vorteile

Kommen wir nun zu den angesproche-nen Vorteilen einer Hana-Implementie-rung auf IBM-Power-Technologie. Es gibt eine ganze Reihe von Anwendern, die bis heute die Vorzüge von SAP auf AIX oder SAP auf IBM i (früher AS/400) genießen. Diese werden früher oder später eben-falls auf Hana umsteigen. Je nach Größe des Unternehmens kann das längerfris-tige Projekte für die IT und das Business nach sich ziehen. Wie gut, wenn man sich dann auf das SAP-Projekt konzentrieren

kann, ohne sich grundsätzliche Gedanken über die Hardware machen zu müssen. Oftmals wird es in den nächsten Jahren hybride SAP-Landschaften (Hana und anyDB) geben, die Dank der LPAR-Tech-nologie auf einem einzigen physischen System abbildbar sind.

Ein Schwerpunkt der SAP-In-memo-ry-Technologie ist logischerweise die Hauptspeicherverarbeitung. Die Band-breiten von und zum Hauptspeicher hin sind bei Power aktuell nicht zu schlagen, was besonders für Big-Data-Szenarien eine wahre Freude ist.

Technikbegeisterte achten auf die Leistungsfähigkeit von Prozessorker-nen. Daran ist SAP mit Ihren Vorgaben nicht ganz unschuldig. Der Intel-Pro-zessor ist ein sehr guter, universeller Re-chenknecht. Der Power-Prozessor wurde für Big-Data-Anwendungen optimiert. Da-durch gibt es mehr Leistung mit weniger Prozessorkernen.

Das produktive SAP-Systeme am Mon-tag hochgefahren und am Freitag runter-gefahren werden, gehören schon lange der Vergangenheit an. Es bleibt immer weniger Spielraum für IT-Abteilungen um SAP-Systeme zu warten. Der SLA be-stimmt den Lebenszyklus von IT-Syste-men. Hier greifen jetzt bestimmte Aspek-te für einen Einsatz der Power Architektur im Hana Umfeld. Durch verschiedene RAS (Reliability, Availability und Service-ability) Features steigt die Verfügbarkeit der Komponenten drastisch. Hier ein klei-ner Vorgeschmack:

○ Enterprise Memory mit Chipkill / Advan- ced ECC Memory○ Vermeidung von Soft Errors: eDRAM für L4 Cache○ L2 Cache Column Repair ○ Active Memory Mirroring für den Hypervisor

○ redundante Hardware (Stromversor- gung, Lüfter, Service Prozessor, Clocking)

Wer mehr Details zur Hana-Roadmap wissen will, sollte sich den SAP-Hinweis 2227464 zur Gemüte führen.

Arbeitsgruppe Hana on Power

Um den Wissensbedarf der wachsenden Hana Community zu stillen, gibt es seit 2015 eine spezielle Arbeitsgruppe Hana on Power (HoP), die sich in regelmäßigen Abständen trifft, um aktuelle Informatio-nen und Erfahrungswerte auszutauschen. Dort treffen sich unter der Schirmherr-schaft von Common, GSE und DSAG be-stehende SAP-on-Power-Kunden, Berater und technische Mentoren der Hersteller SAP, IBM und SUSE. Dieser Zusammen-schluss ist wohl einmalig in Deutschland. Der digitale Spiegel dieser Arbeitsgruppe findet man unter der Adresse: hanaon-power.com

Wer sich in gemäßigten Schritten dem Thema Hana nähern möchte, dem bietet die Q-Partners eine Zwischenlösung an: Ein Proof of Concept (PoC) von kundenei-genen SAP Systemen auf der Hana-on-Po-wer-Plattform. Der PoC wird während der Projektlaufzeit von erfahrenen Beratern begleitet und extern gehostet, um die eigene IT zu entlasten.

Die nächsten Jahre werden sich durch komplexe und spannende SAP-Migrati-onsprojekte auszeichnen. Es kommt also viel Arbeit auf die Unternehmens-IT zu. Bei all der Begeisterung sollte man aller-dings den alten Werbespruch der AS/400 nicht vergessen: Run your business, not your computer!

Unschlagbare Bandbreiten

Power für HanaSAP-Anwender haben es ja nicht einfach. Jahrelang konnten sie zwischen verschiedenen Datenbanken wählen und taten dies auch. Nun führen mit der Softwaregeneration S/4 alle Wege zu einer einzigen Datenbank, nämlich Hana – zumindest wenn es nach dem Willen der Walldorfer geht.

Von Peter Althapp und Jens Gleichmann, Q-Parnters

www.hanaonpower.com

COVERSTORY

65

Hana-Busters

E-3 APRIL 2016

M it Hana und insbesondere S/4 ändert sich auch einiges in der klassischen Abap-Entwicklung.

Zu beachten ist im ersten Schritt insbeson-dere, über welche Betriebsform man spricht. Zu unterscheiden ist hier zwischen der klas-sischen on-premise und der Cloud-Lösung. Beide Betriebsformen können miteinander kombiniert werden. Während in der on-pre-mise Lösung noch die klassische Abap-Welt für den SAP-Anwender zugänglich ist, gibt es in der Cloud-Umgebung durchaus eini-ge Restriktionen. So gut wie jeder SAP-An-wender hat diverse Modifkationen in sein SAP-System eingebaut, mit denen er sei-ne Prozesse individualisiert und sich vom Wettbewerb abhebt. Ob alle diese Modifi-kationen wirklich notwendig waren, sei mal dahingestellt. Dennoch sind einige sicher valide, nicht umsonst wäre sonst darin in Form von Zeit und Geld investiert worden.

In der Cloud-Umgebung ändern sich die Voraussetzungen. Klassische Modifikatio-nen und Änderungen am Code sind mit S/4 ausschließlich noch in der on-premise-Lö-sung möglich. Es ist zu vermuten, dass mit künftigen Releases auch die Form und Weise wie wir heute modifizieren restriktiert wird. In der Cloud-Umgebung sind keinerlei Modifikationen möglich. Dies bedeutet also, dass der heute bestehende Funktionsum-fang entweder in den Standard zurückge-führt oder anders realisiert werden muss, bevor ein Anwender seine SAP-Systeme in der Cloud betreiben kann.

SAP unterscheidet hier zwischen einer Key-User Erweiterung und einer Managed Erweiterung. Die Key-User Erweiterung ermöglicht kleinere Anpassungen am Ge-schäftsprozess in Form von kundenspe-zifischen Feldern und kleineren Code-An-passungen. Diese Erweiterungen sind nicht mit der heutigen Abap-Workbench zu ver-gleichen, sondern vielmehr mit einem sehr eingeschränkten Werkzeug. Vergleichen kann man das in etwa mit den CRM- oder

Solution-Manager-Oberflächen, in denen über Konfiguration ja auch neue Feldinhalte geschaffen werden können. Die große Frei-heit, die der SAP-Anwender kennt, ist dies natürlich nicht.

Für Anpassungen, die damit technisch nicht implementiert werden können, steht die „Managed extensibility“ zur Verfügung. SAP stellt hierfür in der Cloud für Anwender ein in der Cloud gehostetes Entwicklungs-system zur Verfügung. Auf diesem System können dann Erweiterungen implementiert werden. Auch diese vermeintliche Freiheit ist jedoch restriktiert. Hier muss sicherge-stellt werden, dass die Implementierung nicht die Cloud-Betriebsform verletzen. SAP stellt dies dadurch sicher, dass Modi-fikationen nicht erlaubt sind. Auch Zugriffe auf SAP-Objekte dürfen nicht über ein de-finiertes Interface erfolgen. Zu vergleichen ist dies mit den heute freigegebenen BAPIs. Eine Kombination einer on-premise- Lösung mit einer Cloud-Lösung, auf der bestimmte Erweiterungen ablaufen, ist denkbar, erfor-dert aber einiges an Know-how. So ist es si-cherlich denkbar, dass Fiori-Applikationen in der Cloud betrieben werden und damit ska-lierbar und hochverfügbar sind. Gleichzeitig erfordern diese Applikationen jedoch auch Gateway Services im ERP-Backendsystem. SAP empfiehlt hierfür die Entwicklung einer Gateway Services. Diese Architektur kann natürlich nur in einem hybriden Szenario umgesetzt werden. In der Liste der kun-denspezifischen Objekte stehen ja bekannt-lich Formulare immer an allererster Stelle. SAP löst dies in der Cloud mit einem klaren Committment in Richtung Adobe Lifecycle Designer. Alle Formulare oder E-Mail-Vorla-gen werden also auf Basis von Adobe Forms implementiert. Anders als in der klassischen Welt, werden keine Druckprogramme zur Datenaufbereitung genutzt, sondern Net-weaver Gateway. Grundlage von Formula-raufbereitungen sind also OData Services, mit deren Hilfe die relevanten Informatio-

nen abgerufen und aufbereitet werden.Es zeigt sich also, dass sich einiges mit S/4 grundlegend ändern wird. Eine Migration eines ERP- oder CRM-Systems von einer any-Datenbank auf Hana ändert das Pro-grammiermodell noch nicht. Dennoch – um von der Geschwindigkeit zu profitieren – sind die kundenindividuellen Programme zu prüfen und gegebenenfalls anzupassen. Mit der Umstellung auf S/4 wird sich am Programmiermodell deutlich mehr ändern. OData Services (Netweaver Gateway), Fi-ori und SAPUI5 sowie objektorientierte Entwicklungen sind die relevanten Techni-ken. Auch das oftmals noch auf SAPScript oder Smartforms basierende Formularwe-sen ist damit endgültig ein Oldtimer. Für einen Übergang in Richtung Hana sollten IT-Verantwortliche schon frühzeitig damit beginnen, Modifikationen zu analysieren, eine Standardisierung herbeiführen und die neuen Technologien sinnvoll einzusetzen.

Was ändert sich bei der Abap-Entwicklung

Modify your S/4Mit Hana und S/4 kommt ein neues Programmiermodell in die Abap-Welt. SAP-Anwender, die Überle-gungen zur Cloud anstrengen, sollten kundenspezifischen Entwicklungen rechtzeitig überarbeiten.

Von Matthias Kneissl, Q-Partners

Matthias Kneissl rät für den Hana-Umstieg frühzeitig Modifikationen zu analysieren und zu standardisieren.

COVERSTORY

66

Hana-Busters

E-3 APRIL 2016

F ür den Solution Manager 7.1 hat das letzte Stündlein geschlagen – Ende 2017 endet die Mainstream Main-

tenance. SAP-Anwender, die mehr als nur den Maintenance Optimizer und die Ge-nerierung von Early Watch Alerts nutzen, sollten frühzeitig den Umstieg planen.Nach dem Upgrade ist der wohl augenfälligste Unterschied die neue Oberfläche – alles im Fiori-Style. In Summe ist der Solution Manager viel ganzheitlicher geworden. Die neuen Funktionen greifen alle viel nahtloser und sinnvoller ineinander. Eines der ersten und wichtigsten Einsatzszenarien ist das Monitoring. Es gibt kein anderes Monito-ring-Tool, das dem SolMan in der Überwa-chung von SAP-Landschaften überlegen ist. Mit einer Hana-Einführung müssen ohne-hin Betriebsprozesse und Verantwortlich-keiten neu geklärt werden. In diesem Zu-sammenhang ist es sinnvoll, auch die Ser-vice Level Agreements zu überarbeiten und festzulegen. Diese bilden üblicherweise die Grundlage für ein Monitoringkonzept. Da der Betrieb einer Hana-Umgebung sicher-lich anfangs etwas komplizierter und unge-wohnter ist, als der klassische SAP-Basis-betrieb, sind auch tägliche Checklisten im Solution Manager sinnvoll untergebracht.

Der SolMan bleibt auch in hybriden Ansätzen, also dem gemischten Betrieb von on-premise und Cloud seinem Ansatz „single source of truth“ treu. Zwar wird in einem Cloud-Szenario ein Solution Mana-ger von SAP betrieben, dennoch werden relevante Daten in den Solution Manager des SAP-Kunden übertragen und stehen dort zur Nutzung weiterer Szenarien bereit.

Management von Changes

Ein weiteres, relevantes Szenario ist das Management von Changes. Die Kompo-nente des Change Request Managements

gewinnt zusammen mit der Geschäfts-prozessdokumentation massiv an Bedeu-tung. Ein Übergang zu S/4 wird erfordert einiges an Prozessanpassungen, da sich auch in der Technik sehr viel ändert. Je früher ein Anwender sich seiner Prozesse bewusst ist und diese dokumentiert hat, umso mehr Zeit bleibt für sinnvolle An-passungen und Reengineering. Die neue Lösungsdokumentation unterscheidet sich von der bekannten, drei-stufigen Hierarchie deutlich und ist massiv im Lösungsumfang gewachsen. Enterprise Support Kunden können nun auch sinn-voll grafisch ihre Prozesse modellieren und damit auch dokumentieren. Auch Integrationslösungen zu Aris und Signa-vio existieren, wobei letztere sicherlich relevanter und praxisnäher ist.

Releasemanagement

Viele SAP-Anwender sind heute oft in ei-nem „Continous Development“ gefangen – Anforderungen werden von der Fachab-teilung „bestellt“, von der IT umgesetzt und zu einem beliebigen Zeitpunkt getes-tet bzw. produktiv gesetzt. Eine Bünde-lung von Änderungen zu Releases findet oftmals nicht statt, da Anwender dies als zu starr empfinden.

Mit der Änderung in Richtung S/4 und spätestens einem hybriden Betriebsansatz ist es nahezu unmöglich, auf Transportauf-tragsebene Änderungen zu managen. Hier dürften einige Anwender ohne ein Release-management überfordert sein. Komplizier-ter wird das Transportwesen auch dadurch, dass mit den neuen Hana-Objekten das Handling in der STMS bleibt, die Objekte aber dennoch ihre spezifischen Eigenheiten besitzen. Dadurch ist das Transportverhal-ten (ähnlich wie beim Thema Java) anders als eine klassische Abap Entwicklung.

Das Custom Code Management, das oftmals heute noch ein Dasein als Mau-erblümchen fristet wird, sollte auch näher betrachtet werden. SAP -nwender, die ei-nen Übergang in Richtung Cloud planen, können damit schon frühzeitig ihre Modi-fikationen managen, konsolidieren und in den Standard zurückbauen. Das Custom Code Management kann darüber hinaus auch Code Duplikate identifizieren, also Kopien von SAP Standardroutinen. Auch diese sind in einer Cloud Lösung passé und müssen frühzeitig zurückgebaut werden.

Investieren lohnt sich

Auch wenn Anwender für den Übergang nach S/4 gefühlt noch Zeit haben, so lohnt es sich frühzeitig in die Themen Dokumentation, Change Management und Testmanagement zu investieren. Gerade diese Prozesse sind nicht eben von heute auf morgen aufgebaut und in einer Organisation verankert. Um hier nicht wie beim Übergang von R/3 4.6C nach ERP 6.0 rechts-außen überholt zu werden, sollten diese Themen schon jetzt angegangen und vorbereitet werden. Der Solution Manager 7.2 ist ein hervorragen-des Werkzeug, das SAP-Anwender beim Betrieb von Hana-Landschaften unter-stützen kann. Ein Selbstläufer ist es je-doch nicht, organisatorische Änderungen sowie eine gute Disziplin sind dringend vonnöten.

Der neue SAP Solution Manager Version 7.2ist ein Paradigmenwechsel für alle Bestandskunden

Der Solution Manager in der Version 7.2 bietet einiges an neuen Funktionen, um Hana-Umgebungen effizient zu betreiben. Neben den technischen Umstellungen sind jedoch auch organisatorische Anpassungen erforderlich.

Von Mattias „SolMan“ Kneissl, Q-Partners

Bitte beachten Sie auch den Community-Info-Eintrag ab Seite 99

SolMan 7.2 für Hana

7.1

Deadline: 31. Dezember 2017