Was in der Welt der SAP-R3-Systeme notwendig, aber unbeliebt war, wird unter S/4 HANA nicht unbedingt beliebter. Ich spreche hier nicht von teuren SAP-Beratern, sondern vielmehr von der Datenauslagerung in einen Archiv-Storage. Allein die richtige Formulierung im vorangegangenen Satz zu finden, zeigt die Problematik. Es gibt nämlich verschiedene Gründe, seine Daten aus dem führenden SAP-System auszulagern. Und es gibt unterschiedliche Schnittstellen, die genutzt werden können. Jede hat ihre eigene Geschichte und ihre eigenen Stärken und Schwächen. Um es gleich vorwegzunehmen: Wie so oft gibt es nicht den einen besten Weg, der in allen Fällen zu präferieren ist. Es kommt selbst bei SAP immer darauf an, worum es inhaltlich geht und in welcher IT-Infrastruktur man sich bewegt oder bewegen will. Und leider ist seitens des Herstellers keine klare Strategie zu erkennen, die einem Nutzer diesbezüglich eindeutige Leitlinien an die Hand geben würde.

S/4 HANA – wurde die Archivierung vergessen?
Was ich mich schon seit Langem frage, mir bisher aber noch niemand plausibel erklären konnte, ist Folgendes: Hat SAP bei seiner HANA-Strategie die Datenarchivierung vergessen? Oder war es eine bewusste Entscheidung in der Annahme, jeder Kunde würde bei HANA alle seine Daten für immer im Onlinespeicher halten? Vielleicht gab es auch noch eine andere Überlegung, die sich mir bisher nicht erschloss. Bis heute konnte mir noch niemand eine nachvollziehbare Antwort auf diese Frage geben und so wird es wohl vorerst ein Geheimnis bleiben. Dass die uneingeschränkte Datenhaltung im HANA nicht unbedingt die preiswerteste Storage-Lösung ist, wurde jedoch schnell klar. Vor allem dann nicht, wenn es um die GoBD*-relevante Aufbewahrung von Daten innerhalb eines Zeitraumes von sechs bis zehn Jahren geht. Dieser Umstand ist auch dem Softwareunternehmen aus Walldorf kurz nach der Einführung von S/4 HANA bewusst geworden. Im Ergebnis erlebte die bereits totgesagte ArchiveLink-Schnittstelle (folgend AL) so etwas wie eine Renaissance. Auf Druck der im DSAG** organisierten Kunden ist AL lebendiger denn je – auch in der S/4-HANA-Welt. Im Zuge dieser Diskussion sah sich SAP darüberhinaus genötigt, den einstigen Ladenhüter „ILM“ mit seiner BC-ILM-Schnittstelle den Kunden quasi kostenfrei zur Verfügung zu stellen.
Im zeitlichen Verlauf wurde das Thema SAP-Datenverwaltung, Auslagerung und Archivierung durch ein weiteres Ereignis verstärkt: das Inkrafttreten der DSGVO. Durch die DSGVO entstand die Notwendigkeit, sich auch um Lösch- und Aufbewahrungskonzepte von SAP-Daten zu kümmern – unabhängig davon, wo die SAP-Daten verwaltet werden. Aufgrund der geschilderten Kausalitäten ist die Verfügbarkeit der AL- und BC-ILM-Schnittstelle nicht konsistent innerhalb des gesamten HANA-Kosmos und somit auch nicht für jedes SAP-Modul gleichermaßen verfügbar.

ArchiveLink versus BC-ILM
Wichtig ist vor allem, sich die unterschiedlichen Use Cases der beiden Schnittstellen bewusst zu machen. Bei AL geht es um die klassische Daten- und Objektarchivierung – also die Ablage von Ausgangs- und Eingangsbelegen sowie Drucklisten und Reorg-Daten. Hauptgründe für die Nutzung dieser Schnittstelle ist die Erfüllung der GoBD-Anforderungen (Langzeitarchivierung) und eine Verschlankung der produktiven SAP-Datenbanken (Reorg). Der fachliche Kontext und die Benutzeroberfläche verbleiben vollständig im SAP. Das Archiv ist somit nicht mehr als ein nicht fachlicher Compliance-Storage hinter dem ERP. Das funktionale Portfolio klassischer ECM-/DMS-Systeme, wie OpenText, d.velop oder SER kann man sich in diesem Szenario sparen – das geht billiger und besser. Firmen wie KGS oder nextevolution bieten schlankere Lösungen an, wobei sich hier die Spreu auch vom Weizen trennt, wenn es um echte Cloudtechnologie (Container Services unter OpenShift oder Kubernetes) geht.
Mit der Notwendigkeit, Daten oder Informationen auch DSGVO-konform zu verwalten, kommt SAP-ILM mit seiner BC-ILM Schnittstelle in Betracht. Über die reine Archivierung und Aufbewahrung hinaus kann mithilfe dieses Ansatzes auch sicher gestellt werden, dass z. B. auch berechtigte Löschanforderungen für bestimmte Daten gewährleistet werden können (Data Retention Manager). Weiterhin werden Funktionen wie Systemstilllegungen unterstützt, ohne dabei auf die Möglichkeit zu verzichten, die archivierten Daten weiterhin für Berichts- oder Auditzwecke im Zugriff zu behalten. Das gilt für Informationen innerhalb und außerhalb des SAP-Systems. Man könnte also BC-ILM als die potenziell klügere und mächtigere Variante von AL bezeichnen, obwohl der Aufwand einer Implementierung innerhalb von SAP aufwendiger ist oder sein kann. Es kommt ganz darauf an, was genau getan werden soll.
Halten wir fest: Sowohl die AL- als auch die BC-LIM-Schnittstelle kann dazu genutzt werden, Daten im Sinne der GoBD für die gesetzliche Aufbewahrungsfrist zu nutzen. Darüber hinaus kann mit beiden Schnittstellen auch ein produktives SAP-System von unnötigen (Alt-)Daten entlastet werden, um Kosten in der Infrastruktur zu reduzieren.

SAP-CMIS – der Link in die ECM-Welt
Schon 2010 beteiligte sich SAP im Rahmen einer OASIS-Initiative zusammen mit anderen Unternehmen an der Gestaltung von CMIS (Content Management Interoperability Services). Dabei handelt es sich um eine offene API, um im Kern ein beliebiges ECM-System anzusprechen, ohne dabei die proprietäre API des jeweiligen ECM-Produkts zu kennen oder zu nutzen. Es geht also um mehr als die einfache Datenablage wie beim klassischen AL-Szenario, gleichwohl man AL-Use Cases auf einer fachlichen Ebene auch mit CMIS adressieren könnte. Zusätzlich ergibt sich die Möglichkeit, z. B. auch fachliche Indexdaten aus SAP heraus in eine ECM-Plattform zu übertragen. Somit wird der „dumme“ Storage des ECM-Systems potenziell mit beliebig vielen Informationen oder Daten erweitert, die dann auch innerhalb das ECM-Systems autark genutzt werden könnten (z. B. für Workflows, Aktenmodelle etc.). Sofern das SAP-System aber die fachlichen Prozesse beherbergen soll und die Schnittstelle lediglich zur technischen Datenauslagerung oder Erfüllung rechtlicher Anforderungen dient, ergibt sich technisch kein zusätzlicher Nutzen durch CMIS. Im Gegenteil, es ist in diesem Fall eher die berühmte Kanone, mit der auf einen Spatzen geschossen wird. Die Entscheidung, welche Use Cases adressiert werden sollen bzw. welche technische Strategie ein Unternehmen eingeschlagen hat, hilft also bei der Entscheidung für oder gegen CMIS, AL oder BC-ILM.

Und in der Cloud …?
Im SAP-Kontext ist es nicht ganz einfach, über „die Cloud“ zu sprechen. Das was SAP selbst als seine Cloud-Welt für HANA anbietet, hat meiner Meinung nach nun wirklich nichts mit Cloud-Technologie zu tun. Früher hat man so etwas Managed Services in einem externen Rechenzentrum genannt. Aber Cloud klingt deutlich moderner. Und machen wir uns nichts vor: SAP ist alles, aber keine Software, die man in einer echten Cloudumgebung mit den Mehrwerten einer Cloud-Native-Technologie sinnvoll betreiben kann. Mal schnell ein S/4 HANA deployen, dann horizontal „raus skalieren“, wenn die Last steigt und anschließend die PODs einfach im Kubernetes Cluster terminieren? Wenn ein Leser das schon mal geschafft hat und mir dies live demonstrieren kann, spendiere ich auch einen Kasten Bier oder wahlweise Club-Mate.
Aber SAP hat auch seine Qualitäten. Ein Ozeanriese mag zwar nicht sonderlich agil und flexibel sein, dafür ist er aber in der Lage, auf fest definierten Wasserstraßen ordentliche Mengen und große Lasten zu bewegen. Es gibt ja auch Gründe, warum Banken ihre relativ teuren Hostsysteme nicht loswerden.
Wie auch immer: Die Frage ist, welche der Schnittstellen aus technischer Perspektive Cloud-fähig ist und dort am besten betrieben werden kann. Die kurze und einfache Antwort: Diese Frage stellt sich gar nicht, da SAP selbst keine Cloud-Native-Technologie ist. Aus diesem Grund ist die Illustration zu diesem Beitrag unter ironischen Gesichtspunkten ausgewählt worden. Ob SAP – aus welchen Gründen auch immer – es mal schaffen wird, sich von ArchiveLink zu trennen, bleibt das Geheimnis der Walldorfer Softwareschmiede. Von daher sollten Unternehmen zuerst auf ihren Use Case und die IT-Strategie schauen und sich nicht anderweitig nervös machen lassen.
*GoBD = Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff = Verwaltungsanweisung des Bundesministerium der Finanzen der Bundesrepublik Deutschland

**DSAG = Deutschsprachige SAP Anwendergruppe e. V.