Mai 2017

Mit SAP S/4HANA zieht mehr denn je das Gedankengut ein &bdquo;Keeping the Core Clean“. Dahinter verbirgt sich kurz gesagt die Idee, dass Eigenentwicklungen und Drittanbieter-Addons (3rd Party Tools) nur noch durch externe Systeme bereitgestellt werden. Das heißt es wird beispielsweise On-Premise oder in der Cloud ein eigener NetWeaver Application Server ABAP betrieben. Auf diesem Sidecar-System werden nun ABAP-Programme, Strukturen, HANA Calculation Views, Fiori Apps und sonstige SAPUI5-Anwendungen etc. entwickelt. Das Coding holt sich die Quelldaten aus dem S/4HANA Core über Schnittstellen-Technologien wie RFC, REST, OData Services sowie das Application Interface Management Framework (AIF) oder durch Middleware-Produkte wie das PI/PO, SLT, SAP ESP u. Ä. und verarbeitet diese in den vom Kunden eigens entwickelten Codings. Was versteht man unter &bdquo;Keeping the Core Clean“? Nach diesem Dogma wird also jedwede vom Anwender erdachte Anwendungslogik auf ein externes Systems ausgelagert. Die Logik bedient sich über gängiger Schnittstellen der Daten aus dem System und schreibt mitunter das Ergebnis in ein Zielsystem. Die Technologie zum Enablement dieses Gedankengangs wäre grundsätzlich da, verfügen wir doch aktuell über breitbandige Netzwerkanbindungen und zahlreiche Schnittstellen, mit denen SAP-Objekte und -Rohdaten übermittelt werden können. Der Vorteil dies Vorgehens ist der saubere Kern der Anwendung, denn das S/4HANA System enthält dann bestenfalls keine Objekte im Kundennamensraum mehr, enthält also nur noch SAP-Standard. Dies bringt beispielsweise Vorteile beim Upgrade auf einen neuen Release, da kundeneigene Entwicklungen keine Kompatibilitätsprobleme im Upgradepfad mehr darstellen, die Entwicklungen jedoch immer noch auf der Codebasis des externen Application Servers weiterhin ausgeführt werden können. CDS-Views sorgen dafür, dass ältere Kundenanwendungen und Drittanbieter-Addons auch nach einer S/4HANA System Conversion noch funktionieren, da SAP mittels CDS-Views eine Abwärtskompatibilität mit dem Datenschema der Business Suite gewährleistet. So können mit alten Eigenentwicklungen noch Tabellen angesprochen werden, die de fakto unter S/4 gar nicht mehr vorhanden sind. Warum sollte man diesem Ansatz folgen? Mit diesem Ansatz sollen S/4HANA-Kunden in Zukunft noch schneller Upgrades auf neue FPS-Komponenten durchführen können, um noch schneller Gebrauch vom aktuellen Feature Set machen zu können. Business Suite Kunden haben in der Vergangenheit Upgrades auf ein neues EHP häufig gescheut, weil sie besorgt um die Funktionalität ihrer Eigenentwicklungen und zugekaufter Drittanbieter-Addons waren. Sofern das Datenschema auf Tabellenebene auch auf dem neuen S/4HANA FPS gleich bleibt, können Legacy-Anwendungen weiterhin auf dem Sidecar NW AS ABAP betrieben werden. Während dessen kann das eigentliche S/4HANA System ohne Probleme im Release angehoben werden kann. Was sind die Probleme in der Praxis? Doch gibt es in der Praxis bei diesem Ansatz häufig Probleme. Keeping the Core Clean bedeutet zwangsläufig, dass selbst einfachste Eigenentwicklungen wie das Anfügen eines Appends an eine Standard-Tabelle bestenfalls unterlassen werden sollten. Der Mehraufwand, statt des Appends die Daten in ein externes System zu spiegeln, dort die Daten mit dem angehängten Feld einer zweiten Tabelle anzureichern und dann das Ergebnis anzuzeigen, ist enorm. Der Aufwand zur Entwicklung eigens erdachter Lösungen sowie die Last auf den Middleware-Komponenten der Systemlandschaft wird hierdurch immens. Häufig vergessen wird außerdem die in der Vergangenheit unabstreitbare Notwendigkeit zur kurzfristigen Implementierung von OSS Notes im System. Hierbei müssen häufig vom Kunden zuvorderst Z-Objekte angelegt sowie Standardobjekte bearbeitet werden, bevor diese beim Einspielen des nächsten Support Packages überschrieben werden können. Wird der Ansatz des &bdquo;Keeping the Core Clean“ kompromisslos verfolgt, zwingt er den Kunden jedoch dazu, anstelle des Einspielens der Note auf den Release des nächsten Support Packages zu warten bzw. dieses einzuspielen. Desweiteren müssen die Anbieter von Drittanbieter-Addons berücksichtigt werden, welche Ihre Produkte für S/4HANA optimieren. Es ist nicht davon auszugehen, dass die Entwickler von Addons Ihre Produkte auf ein Sidecar-Szenario optimieren werden, solange SAP als Hersteller dies nicht durch entsprechende Zertifizierungskriterien erzwingt. Sofern Sie darüber nachdenken, den Sidecar Approach zu fahren, um Ihren S/4HANA Core sauber zu halten, müssen Sie diesen Gedanken also in die Bewertung zur Kaufentscheidung von Drittanbieter-Software also mit einbeziehen. Die größten Herausforderungen im Keeping The Core Clean sind also: Komplexität und Agilität von Eigenentwicklungen steigen. Dies setzt außerdem hohe Erwartungen an das Management von Eigenentwicklungen. Die Anbindung zwischen S/4HANA und Sidecar System muss agil, stabil, sicher und zuverlässig sein. Drittanbieter-Software muss explizit auf diesen Sidecar-Approach zugeschnitten sein. DaFRK Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement. www.andreas-loibl.eu Unterstützt mich bei der Übersetzung von SAP BegriffenOptimierung der Conversion / Migration PerformanceSAP Software Update Manager Approaches im ÜberblickSet your Author Custom HTML Tab Content on your Profile page

Monatsarchiv: Mai 2017

SAP S/4HANA Keeping the Core Clean Philosophie kurz erklärt

Neueste Beiträge

Neueste Kommentare

Archive

Kategorien

Meta