Konzeptkarte

SAP Business Data Cloud vs Datasphere — Was BDC tatsächlich hinzufügt

Stand 2026-08-02T21:00:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP Business Data Cloud vs Datasphere — Was BDC tatsächlich hinzufügt?

BDC konkurriert nicht mit Datasphere — es enthält es, dazu ein Databricks-Lakehouse, Joule, den Knowledge Graph und den Catalog, der aus alldem einen Stack macht. Die Entscheidung ist, ob man die Verdrahtung kauft oder selbst baut: Kosten und Lock-in gegen Geschwindigkeit und Kohärenz.

„Business Data Cloud oder Datasphere?" ist im Gegensatz zu den meisten Gegeneinander-Fragen in diesem Stack eine echte Frage — nur nicht in der Form, in der sie meist gestellt wird. BDC ist kein anderes Produkt, das mit Datasphere konkurriert. BDC enthält Datasphere und fügt vier weitere Bausteine hinzu. Die Frage lautet daher nicht, welches man kauft, sondern ob man die Verdrahtung zwischen den Bausteinen kauft oder selbst baut.

Was BDC zu dem Datasphere hinzufügt, das Sie schon kennen

Fünf Komponenten, und nur eine davon ist neue Fähigkeit statt neuer Integration.

Datasphere tut weiterhin genau das, was es tat — Analytic Models, Hierarchien, Währungsumrechnung, Push-Down-Ausführung gegen HANA Cloud —, nur löst es sein Katalog jetzt aus dem BDC-Scope auf statt aus einem eigenständigen Tenant. Ein von Databricks verwaltetes Lakehouse liefert Delta-formatigen Speicher, governt über Unity Catalog, erreichbar über Spark-Notebooks, MLflow oder DBSQL, vorprovisioniert und über SAP abgerechnet, statt als separater Databricks-Vertrag ausgehandelt zu werden. Joule-Agenten konsumieren Datasphere-Analytic-Models für Geschäftskontext und können über bewachte Aktionen zurückschreiben. Der Knowledge Graph liegt darunter, verknüpft Customer, Material, Order und andere Kernentitäten über den gesamten Bestand hinweg und stellt sie sowohl Joule als auch Datasphere als abfragbaren Kontext bereit.

Warum es zählt

Dies ist eine der wenigen echten Kauf-oder-Bau-Entscheidungen im SAP-Analytics-Stack, und die Version, die meist diskutiert wird — „welches Produkt ist besser" — hat keine Antwort, weil das eine das andere enthält.

Kernpunkte

BDC konkurriert nicht mit Datasphere: Es ENTHÄLT Datasphere und fügt vier Komponenten darum herum hinzu.
Die fünf Bausteine: Datasphere (Semantik), ein von Databricks verwaltetes Lakehouse (Speicher), Joule (KI-Oberfläche), der Knowledge Graph (Entitätsschicht) und der Catalog.
Der Catalog macht daraus einen Stack statt vier Produkte auf einer Rechnung — semantische Typen, Lineage, Data Products und DAC-Regeln über BEIDE Seiten hinweg.
Datasphere verhält sich innerhalb von BDC wie zuvor, nur löst es sein Katalog aus dem BDC-Scope statt aus einem eigenständigen Tenant auf.
Das Lakehouse ist vorprovisioniert und wird über SAP abgerechnet, statt als separater Databricks-Vertrag ausgehandelt zu werden.
Der eigentliche Trade-off ist Kosten-und-Lock-in gegen Geschwindigkeit-und-Kohärenz — man kauft die Verdrahtung oder baut sie selbst.
BDC setzt einen SAP-mehrheitlichen Bestand voraus (~70–80 % der analyserelevanten Daten innerhalb des SAP-Footprints). Ausgeglichene oder offen-stack-mehrheitliche Bestände passen besser zu eigenständigem Datasphere.
Das Problem, das BDC löst: das alte Entweder-Oder zwischen dem Verbleib innerhalb von SAP ohne Lakehouse-Werkzeuge oder dem Neuaufbau der SAP-Semantik von Grund auf über ein achtzehnmonatiges Projekt.
Keiner der beiden Entscheidungszweige sagt „Datasphere nicht nutzen" — diese Option steht nicht auf dem Tisch.
BDC ändert, wer für das Lakehouse ABRECHNET; es beseitigt nicht die Notwendigkeit eines Spark-/Delta-/Unity-Catalog-Spezialisten.

Begriffe auf dieser Seite

BDC Catalog: Die vereinheitlichte Metadatenschicht, die semantische Typen, Lineage, Data Products und DAC-Regeln über die Datasphere- und die Databricks-Seite hinweg trägt. Ohne sie wäre BDC ein Bundle statt eines Stacks.
Knowledge Graph: Die verbindende Schicht, die Customer, Material, Order und andere Kern-Geschäftsentitäten über den Bestand hinweg verknüpft und Joule sowie Datasphere als abfragbaren Kontext bereitstellt.
Capacity Unit (CU): BDCs Verbrauchsmetrik. Ihre Arithmetik unterscheidet sich vom eigenständigen Datasphere-Sizing, weshalb die Übertragung eines Angebots in das andere eine falsche Zahl ergibt.
Data Access Controls (DAC): Row-Level-Security-Regeln. In BDC auf Catalog-Ebene definiert, gelten sie sowohl für Joule-Antworten als auch für Lakehouse-Lesezugriffe.
Bewachte Aktion: Ein Write-Back, das ein Joule-Agent ausführen darf, begrenzt durch die auf Catalog-Ebene definierten Governance-Regeln, nicht durch das eigene Urteilsvermögen des Agenten.
Selbstbau: Eigenständiges Datasphere plus eigenständiges Databricks plus selbstgebaute Governance dazwischen — die Architektur, mit der BDC tatsächlich verglichen wird.
Mitgelieferter S/4-Content: Von SAP mitgelieferte, vorgefertigte semantische Modelle — der Grund, warum es weniger kostet, die Semantik nativ zu halten, als sie auf einem offenen Stack neu aufzubauen.
Data Product: Ein governter, versionierter Datensatz mit einem Owner und einer Aktualitätszusage — die Einheit, die der Catalog über beide Seiten des Stacks hinweg verfolgt.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →