Konzeptkarte

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

Stand 27. September 2026

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

SAP Business Data Cloud vs Datasphere: Was ist der Unterschied?

„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.

Und dann der Catalog — der Baustein, der die anderen vier wie einen einzigen Stack agieren lässt statt wie vier Produkte auf einer gemeinsamen Rechnung. Er ist die vereinheitlichte Metadatenschicht, die semantische Typen, Lineage, Data Products und DAC-Regeln über beide Seiten trägt, Datasphere wie Databricks. Ohne ihn wäre BDC tatsächlich nur ein Bundle. Mit ihm gilt eine einmal geschriebene Governance-Regel für alles, was Joule in einer Antwort zeigt, und für alles, was ein Spark-Notebook liest.

Der Trade-off, ehrlich benannt

Kosten-und-Lock-in gegen Geschwindigkeit-und-Kohärenz. Das ist die ganze Entscheidung.

BDC statt einer Selbstbau-Architektur zu wählen — eigenständiges Datasphere, eigenständiges Databricks, selbstgebaute Governance dazwischen — kauft schnelleren Time-to-Value, weil die semantische und die Governance-Verdrahtung vorgefertigt ausgeliefert werden, statt als maßgeschneiderte Integrationsarbeit anzukommen, die sonst ein Systemintegrator abrechnen würde. Der Preis ist die Festlegung auf SAPs Paketierung, Preisgestaltung und Roadmap-Tempo für diese Verdrahtung, statt Best-of-Breed-Komponenten zu wählen und sie nach eigenem Zeitplan zu integrieren.

Wie es meist ausgeht

Das Problem, für das BDC gebaut wurde, war früher ein Entweder-Oder ohne gute Mitte: vollständig innerhalb von SAP bleiben und moderne Lakehouse- und Machine-Learning-Werkzeuge verlieren, oder auf einen offenen Stack wechseln und ein achtzehnmonatiges Projekt investieren, um SAPs Geschäftssemantik von Grund auf neu aufzubauen — wobei man typischerweise einen erheblichen Teil dieser Modellierung falsch macht, weil es nie SAPs eigenes Team war, das sie gebaut hat. BDCs Antwort ist, die Semantik nativ zu halten, da Datasphere plus mitgeliefertem S/4-Content mit vorgefertigten Modellen ausgeliefert wird, und auch das Lakehouse nativ zu machen, da Databricks jetzt innerhalb von SAPs Abrechnungs- und Governance-Grenze läuft.

Für einen Kunden, dessen Analytics-Bestand tatsächlich SAP-mehrheitlich ist — die Form, die BDC voraussetzt, etwa siebzig bis achtzig Prozent der analyserelevanten Daten innerhalb des SAP-Footprints —, begünstigt dieser Trade meist BDC. Für einen Kunden, dessen Daten-Footprint tatsächlich ausgeglichen oder offen-stack-mehrheitlich ist, ist eigenständiges Datasphere, föderiert in ein Lakehouse, das der Kunde bereits governt, die besser passende und weniger lock-in-behaftete Antwort.

Beachten Sie, dass keiner der beiden Zweige sagt „Datasphere nicht nutzen“. Diese Option steht nicht auf dem Tisch.

Fallstricke

BDC als „Datasphere mit Extrafunktionen“ verkaufen. Das verkauft die Governance-Vereinheitlichung, die eigentlich das Unterscheidungsmerkmal ist, unter Wert und weckt beim Kunden die falsche Migrationserwartung — der mit Abstand häufigste Positionierungsfehler bei diesem Produkt.

Annehmen, BDC beseitige die Notwendigkeit eines Databricks-Spezialisten. Es ändert, wer für das Lakehouse abrechnet; es ändert nichts daran, dass jemand Spark, Delta und Unity Catalog im Tagesgeschäft verstehen muss.

Kapazität als eine einzige Position behandeln. BDCs Verbrauchsmodell hat seine eigene Capacity-Unit-Arithmetik; ein eigenständiges Datasphere-Sizing in ein BDC-Angebot zu übertragen, erzeugt eine Zahl, die in eine Richtung falsch ist, die niemand bemerkt, bis die Rechnung kommt.

Das Bundle kaufen, um ein Governance-Problem zu lösen, das man noch nicht definiert hat. Der Catalog setzt Regeln durch; er erfindet sie nicht. Ein Kunde ohne vereinbartes Datenverantwortungsmodell kauft eine sehr gute Durchsetzungs-Engine und nichts, was sie durchsetzen könnte.

Die Joule-Perspektive, September 2026

Die eigentliche KI-Aufgabe des Catalog ist nicht das Katalogisieren — es ist, der eine Ort zu sein, den sowohl der SAP Knowledge Graph als auch Joules Grounding-Schicht lesen, sodass eine Agentenantwort und ein Lakehouse-Lesevorgang denselben Entitätsdefinitionen und denselben Data Access Controls unterliegen. Das ist der konkrete Mechanismus hinter der abstrakten Behauptung, dass BDC Datasphere „enthält“: Ohne den Catalog hätten ein auf Dataspheres Analytic Models verankerter Joule-Agent und ein Databricks-Notebook, das dieselben Quelldaten über Delta Sharing liest, keine gemeinsame Garantie, dass „Customer“ für beide dasselbe bedeutet, und für SAC geschriebene DAC-Regeln würden sich nicht automatisch auf einen Lakehouse-Lesevorgang erstrecken. Der Catalog macht diese Garantie strukturell, statt zu einer Frage der Disziplin zu werden, die das Projektteam von Hand durchsetzen muss.

Das wirkt sich direkt auf die Selbstbau-Alternative aus, mit der diese Karte BDC vergleicht. Ein Team, das eigenständiges Datasphere plus ein föderiertes Databricks-Lakehouse aufbaut, erhält Joule-Grounding auf der Datasphere-Seite und Mosaic-AI-Agenten auf der Databricks-Seite, aber nichts zwingt beide, sich auf Entitätsdefinitionen oder Sicherheitsregeln zu einigen, sofern das Team diesen Abgleich nicht selbst baut — typischerweise als von Hand gepflegte Zuordnung zwischen Dataspheres DAC und Databricks' Unity-Catalog-Berechtigungen, die abdriftet, sobald sich eine Seite unabhängig ändert. Dies in einem Entscheidungsrahmen-Gespräch explizit zu benennen, verwandelt eine abstrakte Behauptung zur Governance-Vereinheitlichung in eine konkrete Frage, die ein Kunde für den eigenen Bestand beantworten kann: Wer hält heute die SAP- und Databricks-Berechtigungsmodelle synchron, und was passiert in der Woche, in der es jemand vergisst.

Eine Vorsicht, die es lohnt, in die Scoping-Gespräche 2026 mitzunehmen: SAPs eigene SAP-Anthropic-Partnerschaft leitet Claudes Reasoning über MCP in denselben AI Core und Orchestrierungsdienst, der sich auf dem Knowledge Graph verankert, was bedeutet, dass das KI-Qualitätsargument fürs Kaufen von BDC statt des Selbstbaus nicht nur „Sie bekommen Joule“ lautet — es lautet „Sie bekommen Joules Grounding-Pfad bereits verdrahtet mit den leistungsfähigsten Reasoning-Modellen, die SAP zu unterstützen zugestimmt hat“, eine Verdrahtungskosten, die bei der Selbstbau-Alternative eindeutig auf der Seite des Kunden landen.

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.

Quellen

In der App öffnen →

Offene SAP-Projekte

Aktuelle SAP-Analytics-Projekte und Stellen im DACH-Raum: SAP-Analytics-Projekte im DACH-Raum.