dataso HUB als Cloud-native Speedboot im SAP-Ökosystem

dataso HUB: Ein Cloud-natives Satellitensystem für das SAP-Ökosystem

Warum die Clean-Core-Strategie eine neue Klasse von Erweiterungen erzwingt

SAP-Landschaften haben in den vergangenen zwei Jahrzehnten eine technische Schuldenlast aufgebaut, die heute zum strategischen Bremsklotz wird. Z-Programme, User-Exits und tief verankerte Modifikationen in Modulen wie FICA, SD oder MM waren historisch notwendig, um regulatorische Anforderungen und Legacy-Integrationen abzubilden — lange bevor API-Gateways oder eventbasierte Architekturen verfügbar waren. Die Folge: Jedes Support Package, jedes Enhancement Package und insbesondere die S/4HANA-Konvertierung erfordern monatelange Regressionstests, das Wissen liegt bei wenigen Entwicklern, und der Upgrade-Zyklus diktiert das Innovationstempo, nicht umgekehrt.

Die Clean-Core-Strategie im Rahmen von RISE with SAP ist die Antwort auf diese Lähmung. Sie verlagert Individualentwicklung aus dem ERP-Kern in Satellitensysteme und definiert über das ABAP-Cloud-Tier-Modell präzise, welche Erweiterungsformen zulässig sind. Die Default-Empfehlung von SAP lautet: Side-by-Side für Custom Applications. Damit ist die Richtung gesetzt, aber nicht die Umsetzung. In der Praxis entsteht eine fragmentierte Peripherie aus Excel-Workarounds, unkontrollierten SaaS-Abonnements und Schatten-IT — also genau das, was Clean Core eigentlich vermeiden sollte.

dataso adressiert diese Lücke mit einem cloud-nativen IP-SaaS, das als formeller Side-by-Side-Satellit fungiert und ausschließlich über veröffentlichte APIs mit S/4HANA kommuniziert. Wenn der Kern upgegradet wird, bleibt das dataso HUB unberührt — zero-impact upgrades sind kein Versprechen, sondern eine Konsequenz der Architektur.

SAP BTP oder Custom Cloud: Die Architekturentscheidung

Der Standardweg führt über die SAP Business Technology Platform. Für Kunden, die native Integration über Integration Suite, Fiori, Build und Identity Services wünschen, ist BTP eine valide Wahl. Für einen ISV mit eigenem IP-Stack ergeben sich jedoch drei strukturelle Probleme:

Kostendynamik. BTP rechnet consumption-basiert ab. Das ist planbar bei niedrigem Integrationsgrad, skaliert aber bei hohen Transaktionsvolumina überproportional — insbesondere bei Datentransfers zwischen Diensten. Der Business Case eines SaaS-Abonnements kann auf Infrastrukturebene erodieren, bevor er reift.

Architektur-Abhängigkeit. Eine Anwendung, die tief mit Event Mesh, Destination Service und SAP-eigenen Build-Tools verwoben ist, verliert ihre technologische Eigenständigkeit. Für ein ISV-Geschäftsmodell ist das ein strategisches Risiko.

Stack-Marge. BTP läuft de facto auf AWS, Azure oder GCP. Der Endkunde bezahlt die Hyperscaler-Marge plus die SAP-Marge — ohne dass SAP an dieser Stelle einen technologischen Mehrwert schafft.

dataso hostet das HUB stattdessen auf STACKIT, der Cloud-Plattform der Schwarz-Gruppe. STACKIT betreibt Rechenzentren in Deutschland und Österreich; die Eigentümerstruktur ist europäisch. Das reduziert die Angriffsfläche unter dem US CLOUD Act erheblich, auch wenn vollständige juristische Immunität in der Fachdebatte umstritten bleibt und stets an den konkreten Vertrags- und Datenflüssen hängt. Die Abrechnung erfolgt nutzungsbasiert auf Stundenbasis ohne Egress-Sondermetriken zwischen eigenen Microservices, was die Total-Cost-Modellierung gegenüber BTP deutlich vereinfacht.

Confidential Computing: Datenschutz im Zustand Data-in-Use

Klassische Cloud-Sicherheitskonzepte adressieren Data-at-Rest und Data-in-Transit zuverlässig. Die strukturelle Lücke liegt im dritten Zustand: Während der Verarbeitung im RAM liegen Daten entschlüsselt vor und sind potenziell Side-Channel-Attacken, Memory-Scraping durch kompromittierte Hypervisor oder neugierigen Cloud-Administratoren ausgesetzt.

STACKIT adressiert dies über Confidential Kubernetes, eine Implementierung auf Basis der Open-Source-Engine Constellation von Edgeless Systems. Worker- und Control-Plane-Nodes laufen in hardware-isolierten Enklaven (AMD SEV-SNP, Intel TDX), die den Speicherinhalt auf CPU-Ebene verschlüsseln. Node Attestation verifiziert die Integrität jedes Knotens kryptografisch, bevor er dem Cluster beitreten darf — eine Anforderung, die direkt der BSI-Empfehlung APP.4.4.A17 entspricht.

Für das dataso HUB heißt das: Der Container läuft in einer Umgebung, in der selbst privilegierte Plattform-Administratoren keinen Zugriff auf die verarbeiteten Speicherinhalte haben — innerhalb des durch das Threat-Modell von Confidential Computing definierten Rahmens. Diese Eigenschaft ist für Dritte verifizierbar und macht den Betrieb auch in regulierten Branchen wie Gesundheits-, Finanz- oder Energiewesen vertretbar.

Applikationsschicht: Remix als Backend-for-Frontend

Die Applikationsebene des HUB basiert auf Remix, einem Full-Stack-Web-Framework, das Datenbeschaffung serverseitig in Loaders (GET) und Actions (POST/PUT/DELETE) kapselt. Für eine SAP-Integration ist diese Architektur aus zwei Gründen relevant.

Erstens verbleiben API-Schlüssel, Destinations-URLs und OData-Payloads strikt auf dem Server und werden nie an den Browser exponiert. Remix fungiert als integrierter Backend-for-Frontend-Proxy — ein Modell, das in modernen B2B-Architekturen ohnehin als Best Practice gilt.

Zweitens ist die Containerisierung schlank: Eine Multi-Stage-Docker-Build erzeugt ein Image, das in einem einzigen Pod auf Kubernetes lauffähig ist. Die Anforderung an die Kundeninfrastruktur reduziert sich auf einen Container plus Persistenz-Layer.

Die Enterprise-Authentifizierung wird über remix-auth als strategie-basiertes Modell gelöst, mit httpOnly-Cookie-Sessions und Anbindung an Microsoft Entra ID, Okta oder andere IdPs via OIDC und SAML 2.0. Die signierte Assertion landet am Assertion Consumer Service der Remix-Anwendung, wird kryptografisch validiert, und etabliert eine Session, die später für die Identitätsweitergabe an SAP genutzt wird.

Netzwerktopologie und SAP-Konnektivität

Die anspruchsvollste Disziplin der Architektur ist der sichere Kanal zwischen STACKIT-Container und S/4HANA-Kern.

Der SAP Cloud Connector arbeitet als Reverse Invoke Proxy — ausgehender Tunnel vom Kundennetz in die Cloud, keine offenen Inbound-Ports. Das Sicherheitsmodell ist exzellent, der Connector ist allerdings für die Terminierung an BTP konzipiert. Eine Anbindung an Container außerhalb von BTP ist möglich, aber nicht nativ unterstützt und operativ komplex.

Für die meisten dataso-Szenarien ist daher der direkte Weg sinnvoller: öffentlich exponierte OData-APIs, abgesichert über TLS, mTLS und ein vorgeschaltetes Enterprise-API-Gateway (etwa Azure API Management oder Kong) mit Web Application Firewall, IP-Allowlisting und Rate Limiting. Bei S/4HANA Public Cloud ist dieser Weg ohnehin der vorgesehene.

Datenseitig stehen zwei Protokollwelten zur Verfügung. OData (v2/v4) ist der moderne RESTful-Standard, JSON-basiert, CRUD-fähig und über Remix-Server-Fetches direkt ansprechbar. Für Szenarien, in denen kein OData-Service existiert — typisch bei ECC-Brownfield-Landschaften oder bei spezifischen BAPIs — kapselt das Open-Source-Modul node-rfc das proprietäre SAP NW RFC SDK. Hier ist allerdings zu berücksichtigen, dass SAP RFC/JCo im Cloud SDK als deprecated markiert und langfristig auf OData migrieren wird. Eine RFC-Strategie sollte daher als Übergangslösung designt werden.

Principal Propagation ohne BTP

Wenn das HUB im Auftrag eines Endnutzers in SAP schreibt, muss aus Audit- und Compliance-Gründen die echte Nutzeridentität an SAP weitergegeben werden — nicht ein generischer Service-User. Auf BTP übernimmt der Destination Service diese Aufgabe. Außerhalb von BTP wird Principal Propagation über Standardprotokolle orchestriert.

Der Ablauf nutzt den OAuth 2.0 SAML Bearer Assertion Flow in Kombination mit X.509-Zertifikaten. Der Nutzer authentifiziert sich gegen Entra ID. Die Remix-Anwendung extrahiert das resultierende Token und stellt eine signierte SAML-Assertion an den OAuth-Endpunkt von S/4HANA (/sap/bc/sec/oauth2/token) aus, beglaubigt durch das X.509-Zertifikat des HUB. S/4HANA verifiziert die Trust-Beziehung zum IdP, prüft das Zertifikat und gibt ein nutzerbezogenes Access Token zurück. Dieses wird im Bearer-Header der eigentlichen OData-Aufrufe verwendet.

Das Modell ist secret-less — keine statischen Passwörter, keine manuelle Rotation, vollständige Audit-Trails auf SAP-Seite. Es zeigt, dass tiefe, benutzerzentrierte SAP-Integration ohne BTP technisch sauber realisierbar ist.

KI-Schicht: Open-Source-Modelle über STACKIT AI Model Serving

Der funktionale Treiber des HUB ist die KI-gestützte Prozessbeschleunigung. dataso setzt bewusst auf Open-Source-Modelle statt auf SAP Joule, weil Joule primär auf Navigation und Standardtransaktionen innerhalb der SAP-UIs fokussiert und für ISV-Workflows zu restriktiv ist.

Relevant sind drei Modellfamilien: Llama 3.3 (70B) für komplexes Reasoning und strukturierte Extraktion, Mistral (Large und Ministral-Reihe) als europäische Alternative mit guter Mehrsprachigkeit, sowie Mixtral 8x7B — ein Sparse Mixture-of-Experts-Modell, das pro Token nur zwei von acht Experten-Subnetzen aktiviert und damit bei 46,7 Mrd. Parametern Gesamtkapazität eine Inferenzgeschwindigkeit auf dem Niveau eines 13B-Modells erreicht.

Self-Hosting wäre möglich, aber kapitalintensiv: VRAM-Bedarf liegt bei Faktor 1,2 bis 1,5 der Modellgröße, das Kontextfenster skaliert linear. dataso nutzt stattdessen STACKIT AI Model Serving. Der Service stellt die genannten Modelle als geteilte Instanzen über eine OpenAI-kompatible REST-API bereit; die Migration aus bestehenden LangChain- oder Vercel-AI-SDK-Implementierungen reduziert sich auf einen Wechsel der Base-URL. Abrechnung erfolgt token-basiert (Llama 3.3 70B liegt im Premium-Tarif bei rund 1,50 € pro 1 Mio. Input-Token), und die Datenverarbeitung verlässt den europäischen Rechtsraum nicht.

Ein typischer Workflow: Ein Anwender lädt unstrukturierte Bestelldokumente hoch. Der Remix-Loader übergibt sie an die STACKIT-AI-API, extrahiert Materialnummern, Mengen und Lieferdaten in ein JSON-Schema und generiert anschließend per OData einen Sales Order in S/4HANA. Realistische Effizienzgewinne liegen bei 40–60 % verkürzter Prozesslaufzeit, je nach Komplexität und Datenqualität.

Die Lizenzfrage: SAP Digital Access

Eine technisch saubere Side-by-Side-Architektur löst nicht automatisch die kommerzielle Frage. Jeder schreibende Zugriff aus einem Drittsystem berührt das Digital-Access-Modell, das SAP 2018 als Antwort auf Fälle wie SAP gegen Diageo eingeführt hat. Lizenziert wird nicht mehr der Zugriffsweg, sondern die Erstellung einer von neun definierten Dokumenttypen — Sales, Purchase, Invoice, Manufacturing, Quality, Service & Maintenance, Time Management, Material und Financial Document.

Drei architektonische Hebel reduzieren die Belastung:

Read-Heavy-Design. Lesende Operationen sind unter Digital Access nicht kostenpflichtig. Dashboarding, Analytics und KI-gestützte Auswertungen verursachen keine zusätzlichen Dokumentkosten. Named-User-Lizenzen können je nach Konstellation dennoch erforderlich sein — die Lizenzlandschaft sollte pro Kunde geprüft werden.

Kaskadenbeleg-Effekt. Wenn das HUB einen Sales Order anlegt und SAP daraufhin Finanz- und Materialbelege generiert, werden diese Folgebelege nicht separat abgerechnet.

Batching. Aggregation von Transaktionen zu gebündelten Postings reduziert die absolute Dokumentenzahl.

Ergänzend lohnt die Beratung der Kunden zum Digital Access Adoption Program (DAAP), das beim Umstieg vom Named-User-Modell unter Option B bis zu 90 % Rabatt auf bestehende Verbrauchsmengen gewährt und historische Indirect-Access-Risiken bereinigt.

Fazit

Clean Core zwingt zur Auslagerung, definiert aber keinen verbindlichen Zielort. Wer den Weg über BTP wählt, gewinnt native Integration und akzeptiert die kommerziellen und architektonischen Implikationen. Wer den Weg über eine souveräne Cloud wählt, übernimmt mehr Eigenverantwortung bei Konnektivität und Identity Federation, gewinnt dafür Kontrolle über Stack, Kostenstruktur und Datenraum.

Die Architektur des dataso HUB — Remix als schlanker Backend-for-Frontend, STACKIT Confidential Kubernetes als Laufzeitumgebung, OAuth-basierte Principal Propagation, OpenAI-kompatible Open-Source-KI und ein digital-access-bewusstes Datenmodell — zeigt, dass die zweite Variante belastbar umsetzbar ist. Sie ist kein Ersatz für BTP in jedem Szenario, aber sie ist eine ernstzunehmende Option dort, wo Datensouveränität, Kostenkontrolle und ISV-Unabhängigkeit zu den priorisierten Anforderungen gehören.