Insights
SAP Clean Core: Erweiterungen auf souveräner Cloud statt auf der SAP-Plattform
Clean Core sagt, dass Erweiterungen aus dem SAP-Kern müssen, aber nicht wohin. Was für die SAP-Plattform spricht, was dagegen, und welche drei Aufgaben Sie außerhalb der BTP selbst lösen müssen.
Die Clean-Core-Strategie von SAP zwingt Sie, Individualentwicklung aus dem ERP-Kern in Satellitensysteme auszulagern, sagt aber nicht, wo diese laufen sollen. Die Wahl steht zwischen der SAP Business Technology Platform (BTP) und einer eigenen, souveränen Cloud-Umgebung, und sie entscheidet über Kosten, Datenraum und Ihre Unabhängigkeit auf Jahre.
Warum Clean Core eine neue Klasse von Erweiterungen erzwingt
SAP-Landschaften haben über Jahrzehnte Modifikationen angesammelt: eigene Programme, User-Exits, tief verankerte Anpassungen in den Kernmodulen. Sie waren nötig, weil es damals keine Schnittstellen dafür gab. Die Folge kennen Sie: Jedes Support Package und erst recht die Umstellung auf S/4HANA verlangt wochenlange Regressionstests, das Wissen liegt bei wenigen Entwicklern, und der Upgrade-Zyklus diktiert das Tempo.
Clean Core verlagert die Individualentwicklung in Satellitensysteme, die ausschließlich über veröffentlichte Schnittstellen mit dem Kern sprechen. Wird der Kern aktualisiert, bleibt der Satellit unberührt. In der Praxis entsteht dabei allerdings oft eine Peripherie aus Excel-Behelfen und unkontrollierten SaaS-Abonnements, also genau der Wildwuchs, den Clean Core vermeiden sollte. Die Frage ist deshalb nicht, ob Sie auslagern, sondern wohin.
Mehrere Systeme über REST API verbinden: BTP oder eigene Cloud?
Der Standardweg führt über die BTP. Wer native Integration über Integration Suite, Fiori und die SAP-Identitätsdienste will, ist dort richtig. Für Erweiterungen mit eigener Fachlogik sprechen drei Punkte dagegen.
Die Kosten werden nach Verbrauch abgerechnet. Bei geringem Integrationsgrad ist das planbar; bei hohen Transaktionsvolumen und Datentransfers zwischen Diensten wächst die Rechnung überproportional, und der Nutzen einer Erweiterung kann auf Infrastrukturebene aufgezehrt werden, bevor er sich zeigt.
Die Abhängigkeit wächst. Eine Anwendung, die mit den SAP-eigenen Ereignis-, Ziel- und Build-Diensten verwoben ist, lässt sich nicht mehr woanders betreiben.
Die Marge verdoppelt sich. Die BTP läuft ihrerseits auf den Hyperscalern von Amazon, Microsoft und Google. Sie zahlen deren Marge und die von SAP, und die Daten liegen bei einem US-Konzern.
Die Alternative ist ein Satellit, der bei einem europäischen Betreiber läuft, etwa STACKIT mit Rechenzentren in Deutschland und Österreich und europäischer Eigentümerstruktur, und der über die OData-Schnittstellen von S/4HANA mit dem Kern spricht. So betreiben wir das dataso HUB: als Side-by-Side-Erweiterung, die nur veröffentlichte Schnittstellen nutzt. Ein Kern-Upgrade ist für den Satelliten kein Ereignis.
Was Sie außerhalb der BTP selbst lösen müssen
Der Weg über die eigene Cloud bedeutet mehr Verantwortung an drei Stellen.
Konnektivität: Der SAP Cloud Connector ist für die BTP gebaut. Außerhalb davon führt der saubere Weg über öffentlich erreichbare OData-Schnittstellen, abgesichert mit TLS, beidseitiger Zertifikatsprüfung und einem vorgeschalteten API-Gateway mit Firewall, Zugriffslisten und Ratenbegrenzung. Für die Public-Cloud-Variante von S/4HANA ist das ohnehin der vorgesehene Weg. Ältere Landschaften ohne OData-Dienste brauchen eine RFC-Anbindung, die als Übergangslösung geplant werden sollte, weil SAP diesen Weg langfristig ablöst.
Identität: Schreibt der Satellit im Auftrag eines Nutzers in SAP, muss aus Prüfgründen dessen echte Identität ankommen, nicht ein technischer Sammelbenutzer. Auf der BTP übernimmt das ein Plattformdienst. Außerhalb wird es mit Standardprotokollen gelöst: Anmeldung am Identitätsanbieter des Unternehmens, Weitergabe als signiertes Token an S/4HANA, Prüfung der Vertrauensbeziehung, nutzerbezogenes Zugriffstoken. Keine statischen Passwörter, vollständige Prüfspur auf SAP-Seite.
Datenschutz während der Verarbeitung: Verschlüsselung bei Übertragung und Ablage ist Standard. Die Lücke ist der Arbeitsspeicher, in dem Daten während der Verarbeitung offen liegen. Vertrauliches Rechnen, wie es STACKIT mit hardwareisolierten Kubernetes-Knoten anbietet, schließt sie: Selbst Plattformadministratoren sehen die verarbeiteten Daten nicht. Für regulierte Branchen ist das häufig die Bedingung, unter der ein Cloud-Betrieb überhaupt vertretbar wird.
KI im Satelliten, ohne dass Daten Europa verlassen
Der fachliche Treiber solcher Erweiterungen ist meist KI-gestützte Prozessbeschleunigung: Ein Anwender lädt unstrukturierte Bestelldokumente hoch, ein Sprachmodell extrahiert Materialnummern, Mengen und Liefertermine, und der Satellit legt daraus über OData einen Kundenauftrag in S/4HANA an. Offene Modelle über einen europäischen Modelldienst halten die Verarbeitung im europäischen Rechtsraum, und der Modellanbieter bleibt austauschbar, weil die Schnittstelle standardisiert ist.
Die Lizenzfrage nicht vergessen
Eine saubere Architektur löst die kommerzielle Frage nicht. Jeder schreibende Zugriff aus einem Drittsystem berührt das Digital-Access-Modell von SAP, das die Erzeugung bestimmter Belegtypen lizenziert. Drei Hebel senken die Belastung: lesende Zugriffe für Auswertungen und KI-Analysen, die nicht lizenzpflichtig sind; Folgebelege, die SAP selbst aus einem angelegten Auftrag erzeugt und die nicht separat zählen; und das Bündeln von Transaktionen. Welche Named-User-Lizenzen daneben nötig bleiben, ist je Kunde zu prüfen.
Legen Sie Ihre geplanten oder bestehenden SAP-Erweiterungen in eine Liste und notieren Sie zu jeder, wo sie läuft, welche Schnittstellen sie nutzt und ob sie schreibend zugreift. Mit dieser Liste kommen Sie in den Potenzial-Check: eine halbe Stunde, kostenlos, und Sie erfahren, welche Erweiterung auf die BTP gehört und welche in eine souveräne Umgebung. Potenzial-Check buchen