SAP Datasphere & Business Data Cloud
Was sich seit 2024 verändert hat
Bis Mitte 2024 war die Daten-Welt um SAP herum zweigeteilt: SAP-Daten in BW/4HANA oder HANA Live, alle anderen Daten im Lakehouse (Databricks, Snowflake, BigQuery). Brücken zwischen beiden Welten brachen regelmässig oder hatten Performance-Probleme.
Mit SAP Datasphere (vormals Data Warehouse Cloud) und der Business Data Cloud (BDC, Verfügbarkeit ab 2025) gibt es jetzt eine durchgängige Schicht:
- Datasphere ist die Daten-Plattform mit semantischem Layer
- BDC ist die kuratierte SAP-Daten-Sicht mit garantierter Aktualität und Geschäfts-Semantik
- Beide arbeiten Hand-in-Hand mit Databricks, Snowflake, BigQuery via Data-Sharing-Protokollen (Delta Sharing, Iceberg) ohne Daten-Replikation
Das ist ein architektonischer Bruch mit dem klassischen ETL-Modell.
Architektur
mermaid
flowchart TD
S4["SAP S/4HANA<br/>live und historisch"]
NS["Nicht-SAP<br/>CRM, Webshop, IoT"]
LH["Lakehouse<br/>Databricks, Snowflake"]
BDC["Business Data Cloud<br/>kuratierte Datenprodukte"]
DS["Datasphere<br/>Modellierung, ETL, Semantic Layer"]
SL["Semantic Layer<br/>Business-Objekte, KPIs, Hierarchien"]
AC["Analytics Cloud"]
CA["Custom App"]
JO["Joule<br/>als RAG-Quelle"]
DW["Drittwerkzeuge<br/>Tableau, Power BI via OData/SQL"]
S4 --> BDC
NS --> DS
BDC --> SL
DS --> SL
LH -->|"Federated Query"| SL
SL --> AC
SL --> CA
SL --> JO
SL --> DW
click S4 call mmdInfo() "Live- und historische S/4HANA-Daten kommen als kuratierte Datenprodukte über die Business Data Cloud – ohne eigene Extraktions-Strecken und ohne Replikations-Wildwuchs."
click NS call mmdInfo() "CRM, Webshop und IoT-Quellen werden in Datasphere modelliert und angebunden – dort, wo ETL und Semantik ohnehin gepflegt werden."
click LH call mmdInfo() "Bestehende Lakehouse-Investitionen bleiben, wo sie sind: Federated Query bindet Databricks oder Snowflake ein, ohne die Daten zu duplizieren."
click BDC call mmdInfo() "Die Business Data Cloud liefert SAP-Daten als fertig kuratierte Produkte mit Semantik – der Bruch mit dem klassischen ETL-Modell."
click DS call mmdInfo() "Datasphere ist der Modellierungs-Ort: ETL, Harmonisierung und der fachliche Zusammenhang zwischen SAP- und Nicht-SAP-Welt."
click SL call mmdInfo() "Eine gemeinsame semantische Schicht: Business-Objekte, KPIs, Hierarchien und Berechnungen werden einmal definiert – jeder Konsument nutzt dieselbe Wahrheit."
click JO call mmdInfo() "Auch der Assistent zieht aus derselben Schicht: Joule nutzt die kuratierten Daten als RAG-Quelle statt eigener Schatten-Kopien."
click DW call mmdInfo() "Tableau, Power BI und andere Werkzeuge greifen per OData oder SQL auf dieselbe Semantik zu – kein zweites Kennzahlen-Universum."
Drei strategische Vorteile
1. Clean Core durchsetzbar
Klassisch wurde Custom-Code im S/4HANA-Core platziert, weil Reports darauf angewiesen waren. Mit Datasphere und BDC können Sie die Reports auf den Semantic Layer legen – der Core bleibt sauber, Releases bleiben einspielbar.
2. Self-Service-BI mit kontrolliertem Semantic Layer
Fachbereiche bekommen Geschäftsobjekte präsentiert, nicht Tabellen. "Umsatz nach Kunde, Region, Produktgruppe" – ohne dass jemand KNVV mit VBAK joinen muss. Konsistente Definitionen (was ist "Umsatz"? mit oder ohne Skonto?) sind im Layer versioniert hinterlegt.
3. GenAI-fähige Datenschicht
Der Semantic Layer ist die natürliche Grundlage für GenAI-Apps – Joule kann via Datasphere strukturierte SAP-Daten abfragen, ohne direkten S/4HANA-Zugriff zu brauchen. Das entkoppelt die GenAI-Schicht vom S/4HANA-Release-Lebenszyklus.
Technische Bausteine
Spaces
In Datasphere organisiert man Daten in Spaces – gekapselte Bereiche pro Domäne (Finance, HR, Sales, Operations). Jeder Space hat eigene Berechtigungen, eigene Connections, eigene Modelle. Das passt zu Data-Mesh-Prinzipien.
Data Builder vs. Business Builder
- Data Builder ist die technische Modellierungsschicht (Tabellen, Views, Joins, SQL-Logik)
- Business Builder legt darüber den Semantic Layer mit Geschäftsobjekten, Dimensionen, Kennzahlen – die Sprache der Fachbereiche
Klare Trennung von "wie sind die Daten technisch verbunden" und "was bedeutet das fachlich".
Replication vs. Federation
Drei Modi für den Daten-Zugriff:
| Modus | Wann sinnvoll |
|---|---|
| Replication | Hohe Last, Reporting auf Cold Data |
| Federation (live) | kleine Datenmengen, immer aktuell |
| Hybrid (Hot/Cold) | grosse Tabellen, partitioniert nach Zeit |
BDC-Quellen (Stand 2026)
Vorgefertigte Modelle für:
- Finance (FAGLFLEXA, BSEG, BSAK, COSP)
- Sales (VBAK/VBAP, VBRK/VBRP, KNVV)
- Procurement (EKKO/EKPO, LFA1, EBAN)
- HR (mit SuccessFactors als Quelle)
- Inventory (MARA, MARC, MBEW, MSEG)
- Production (AUFK, AFKO, MAST, STKO)
Diese Modelle sind von SAP gepflegt – Updates kommen mit jedem Release, ohne dass Kunden eingreifen müssen.
Drei realistische Use-Case-Szenarien
a) Profitabilitäts-Sicht über Märkte hinweg
Fakten aus S/4HANA (Umsatz, Kosten, Marge), kombiniert mit Marktdaten aus dem Lakehouse (Branchen-Indizes, Wechselkurse, Wettbewerbs-Preise). Reportet quartalsweise im Vorstand, ohne dass jemand einen Excel-Konsolidierungs-Marathon macht.
b) Predictive-Maintenance-Schicht
SAP Plant Maintenance Notifications + IoT-Sensor-Daten aus Databricks + Wartungs-Historie aus dem Lakehouse → ML-Modell auf Databricks → Vorhersagen via Semantic Layer in Field-Service-App.
c) GenAI-Reporting-Co-Pilot
Joule-Skill "Reporting" greift auf den Semantic Layer zu – der User stellt eine natürliche Frage, das Modell übersetzt in eine SQL-Abfrage gegen den Semantic Layer (nicht die rohe Tabelle), bekommt ein wohldefiniertes Ergebnis, formuliert die Antwort.
Wann Datasphere/BDC die richtige Wahl ist
Sinnvoll: - Sie haben eine Lakehouse-Strategie, aber SAP-Daten sind isoliert - Sie wollen Custom-Reports aus dem S/4HANA-Core bekommen - Sie planen GenAI-Anwendungen auf Geschäftsdaten - Sie wollen Self-Service-BI mit Daten-Governance
Eher nicht sinnvoll: - Sie haben < 100 Reports und ein gut funktionierendes BW-Setup – Migration lohnt sich nicht zwingend - Sie sind reine SAP-Welt ohne Lakehouse-Ambitionen – Embedded Analytics in S/4HANA reicht oft - Sie haben kein Team, das den Semantic Layer pflegen kann
Risiken, die wir nüchtern benennen
- Lizenz-Komplexität: Datasphere + BDC + ggf. Databricks sind separate Lizenzen. Die TCO muss sauber gerechnet werden.
- Ramp-up-Zeit: ein produktiver Semantic Layer entsteht nicht in 4 Wochen. Realistisch sind 4-8 Monate für eine Domäne, dann iterativ Skalierung.
- Skill-Lücke: Datasphere ist kein BW. Vorhandene BW-Modellierer brauchen einen Übergang.
- Provider-Lock-In: weniger als bei klassischem BW, aber nicht Null. Federation auf Snowflake/Databricks ist solide, ein späterer Wechsel des Lake-Providers bleibt aber Aufwand.
Was wir liefern
- Daten-Strategie-Workshop mit Bewertung Ihrer aktuellen Daten-Landschaft und Empfehlung Datasphere/BDC vs. Alternativen
- Pilot-Domäne (z.B. Finance) – komplette Modellierung, Semantic Layer, ein Reporting-Use-Case
- Skalierung auf weitere Domänen mit Wiederverwendung der Pattern aus dem Pilot
- GenAI-Vorbereitung – Semantic Layer so strukturieren, dass Joule darauf operieren kann
Was wir nicht liefern
- Lift-and-Shift von BW. Wir migrieren nur das, was fachlich noch tragend ist. Alt-Reports sterben in der Migration.
- Lakehouse-Aufbau. Wenn Sie noch keinen Lake haben, ist das ein Vor-Schritt mit eigenen Partnern.
- Daten-Pflege. Modellierung ja, aber Daten-Qualität bleibt ein Fachbereichs-Thema (Stewardship, MDM).
Stand: 2026-05-10
