Konzeptkarte

SAP Datasphere

Stand 18. Oktober 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.

Was ist SAP Datasphere?

SAP Datasphere ist die einheitliche Daten- und Semantikschicht im Zentrum von SAPs moderner Analytics-Landschaft.

Was es ist

SAP Datasphere ist die einheitliche Daten- und Semantikschicht im Zentrum von SAPs moderner Analytics-Landschaft. Aufgebaut auf SAP HANA Cloud mit integriertem Delta Lake, ermöglicht es einer Organisation, Unternehmensdaten – sowohl SAP- als auch Nicht-SAP-Daten – zu modellieren, zu governen und als vertrauenswürdige, wiederverwendbare semantische Objekte bereitzustellen, die SAP Analytics Cloud, den Joule-KI-Assistenten und Drittanbieter-BI-Tools über offene Sharing-Protokolle versorgen. Praktisch gesehen ersetzt Datasphere das, was früher ein Flickenteppich aus Punkt-zu-Punkt-Extrakten, handgebauten Data Warehouses und brüchigen BEx-Queries war, durch ein einziges governtes Data Fabric.

Warum es wichtig ist

Jeder große SAP-Kunde, der noch ECC oder klassisches BW betreibt, steht unter Zeitdruck: SAPs Roadmap steuert alle in Richtung S/4HANA und eine cloud-native Analytics-Schicht, und Datasphere ist die Landing Zone für diese Migration. Sie ist zugleich die Konsumtionsschicht unterhalb von SAP Business Data Cloud – wer die Modellierungs- und Governance-Grundlagen in Datasphere richtig legt, bestimmt damit, wie gut jeder nachgelagerte KI-Agent, jedes Dashboard und jede Planungsanwendung performt. Ein Team, das Datasphere falsch aufsetzt, zahlt doppelt – einmal im ursprünglichen Projekt, und ein zweites Mal in jeder konsumierenden Anwendung, die drumherum navigieren muss.

Wie es funktioniert

Datasphere vereint drei Fähigkeiten, für die früher separate Produkte nötig waren: Federation (Live-Query-Durchreichung an ein Quellsystem, ohne Datenkopie), Replikation (deltabasierte Bewegung von Daten in den eigenen Speicher von Datasphere) und Modellierung (grafische, SQL- oder skriptbasierte Views, die rohe oder föderierte Daten in geschäftsfertige semantische Modelle verwandeln). Der Konsum erfolgt dann entweder über Live- oder Import-Verbindungen von SAP Analytics Cloud, über Delta Sharing an externe Plattformen wie Databricks oder Snowflake, oder über die Grounding-Schicht von Joule für KI-Agenten. Alles läuft innerhalb eines Space – einer governten Partition mit eigener Sicherheit, eigenen Verbindungen und eigenem Lebenszyklus –, und Space-übergreifender Konsum erfolgt über den Catalog mittels versionierter Data Products, nicht über Ad-hoc-Tabellenfreigaben.

Wann man es einsetzt – und wann nicht

Die wichtigste Entscheidung ist nicht „sollen wir Datasphere einführen“ – für jede Organisation, die sich bereits auf S/4HANA und SAP Analytics Cloud festgelegt hat, lautet die Antwort fast immer Ja, weil es die einzige Schicht ist, in die SAP aktiv für Federation, semantische Modellierung und KI-Grounding investiert. Die eigentliche entscheidungsrelevante Frage ist, wie viel man dort baut im Vergleich zu Alternativen. Für einen kleinen Reporting-Bedarf, der nur ein oder zwei Quelltabellen betrifft und keine Wiederverwendung erfordert, kann eine direkte Live-Verbindung von SAP Analytics Cloud direkt zu S/4HANA schneller zu liefern und günstiger zu betreiben sein als ein Datasphere-Modell aufzusetzen – der Trade-off ist, dass man keine semantische Wiederverwendung, keine Governance-Schicht und später keinen Pfad zum KI-Grounding erhält. Für wirklich unternehmensweite, multi-konsumierende, multi-quellige Bedarfe ist Datasphere die einzig vernünftige Wahl gegenüber dem Bau eines maßgeschneiderten Data Warehouse auf rohem HANA Cloud oder einem externen Lakehouse, weil es das semantische und Governance-Tooling mitliefert, das eine rohe Plattform monatelanges kundenspezifisches Engineering erfordern würde, um es nachzubilden. Der Trade-off dort sind Kosten und Komplexität: Datasphere wird in Capacity Units lizenziert, entkoppelt von Benutzer-Seats, und ein unterdimensionierter Tenant schafft seine eigene Performance-Obergrenze.

Eine zweite, ständig wiederkehrende Entscheidungsfrage: federieren oder replizieren, entschieden pro Quellobjekt und nicht pro Quellsystem. Federation ist die richtige Voreinstellung, wenn das Quellsystem zusätzliche Query-Concurrency verkraften kann, wenn Nahe-Echtzeit-Aktualität für den Konsumenten wichtig ist und wenn die Datenvolumina moderat bleiben – ihr Trade-off ist, dass jede föderierte Query das Quellsystem zusätzlich belastet. Replikation ist die richtige Voreinstellung für hochvolumige Faktendaten oder Quellen, die keinen gleichzeitigen analytischen Query-Druck vertragen – ihr Trade-off sind Speicherkosten, Pipeline-Latenz und der operative Aufwand, Change-Data-Capture zu verwalten.

Fallstricke und Anti-Patterns

Der teuerste Fehler ist, Datasphere als reinen HANA-Cloud-Ersatz zu behandeln und beide separat zu bepreisen – Dataspheres Capacity Units berücksichtigen bereits den zugrunde liegenden HANA-Cloud-Compute, sodass eine doppelte Budgetierung den Business Case aufbläht und bei der Anbieterverhandlung Verwirrung stiftet. Das zweite wiederkehrende Anti-Pattern ist die Standardeinstellung „alles replizieren“, weil sie sicherer wirkt als Federation; in der Praxis sprengt das die nächtlichen Batch-Fenster, sobald die Volumina der Faktentabellen wachsen, und Teams müssen die Ladestrategie unter Produktionsdruck neu konstruieren, statt sie von vornherein zu entwerfen. Ein drittes Anti-Pattern besteht darin, semantische Modelle zu bauen, bevor die Space- und Catalog-Governance-Struktur vereinbart ist – Teams, die zuerst modellieren und später organisieren, enden mit duplizierter Logik über mehrere Spaces hinweg, die später zu realen Kosten konsolidiert werden muss. Schließlich verbrennt es Capacity Units und Modellierungsaufwand für Wegwerf-Use-Cases, die eine direkte Verbindung ebenso gut bedient hätte, jeden Reporting-Bedarf als Datasphere-würdig zu behandeln, unabhängig von Umfang oder Wiederverwendung. Die Disziplin, die ein gut geführtes Datasphere-Programm von einem kämpfenden unterscheidet, ist fast nie technisches Können – es ist die konsequente Anwendung dieser wenigen Entscheidungsregeln, bevor das erste Modell gebaut wird.

Die Joule-Perspektive, September 2026

Dataspheres Rolle hat sich dieses Jahr auf eine konkrete, überprüfbare Weise verändert: Joule ist jetzt direkt in die Datasphere-Oberfläche selbst eingebettet — Navigation in natürlicher Sprache, Aufgabenausführung und Space-übergreifende Fragen und Antworten für Architekten, Analysten und Fachanwender, GA laut einem help.sap.com-Dokument vom 24.09.2026 — statt ein separat von außen angeflanschter Assistent zu sein. Das ist eine engere Aussage als „Datasphere hat jetzt KI“: Es handelt sich konkret um konversationellen Zugriff auf die Modellierungs- und Administrationsoberfläche, nicht um eine Veränderung, wie die zugrunde liegende Semantikschicht funktioniert. Getrennt davon, und für Architekturentscheidungen folgenreicher, sind Dataspheres Analytic Models und Data Products das, was der SAP Knowledge Graph und das Dokument-/DB-Grounding des Orchestrierungsdienstes tatsächlich lesen, wenn ein Joule-Agent oder eine auf dem Generative AI Hub aufbauende Anwendung eine Geschäftsantwort in echten SAP-Entitäten verankern muss statt im parametrischen Gedächtnis des Modells. Das ist der Grund, warum Datasphere-Modellierungsdisziplin jetzt über die reine Dashboard-Korrektheit hinaus KI-Zuverlässigkeitsrisiken trägt: Ein Analytic Model mit schlampiger Benennung, ungelöster Währungsumrechnung oder ohne Data Access Control erzeugt eine Joule-Antwort, die genauso falsch oder übermäßig freigegeben ist wie ein schlechtes Dashboard — nur mit mehr scheinbarer Autorität.

Die Entscheidung, die das einem Berater abverlangt, ist, welche Schicht des Modells für das Grounding freigegeben wird, und das geschieht nicht automatisch. Eine Knowledge-Graph-Referenz oder einen Dokument-Grounding-Filter des Orchestrierungsdienstes auf einer rohen replizierten Tabelle statt auf einem veröffentlichten, katalogisierten, DAC-geschützten Analytic Model oder Data Product zu verankern, umgeht stillschweigend dieselbe Zugriffskontrolle, die jeder andere Konsument respektiert — Joule hat kein separates, schwächeres Sicherheitsmodell, aber nur, wenn das gelesene Objekt von Anfang an so gebaut wurde, dass es DAC trägt. Die praktische Regel: „für KI verankerbar“ als eine Eigenschaft behandeln, die bereits zur Modellierungszeit zu entwerfen ist, genauso wie „für SAC konsumierbar“ es bereits ist, nicht als nachgelagertes Integrationsproblem.

Eine weitere Unterscheidung, die einem Kunden gegenüber präzise zu halten ist: Datasphere steht unterhalb von SAP Business Data Cloud, das selbst jetzt Teil der breiteren SAP Business AI Platform ist (BTP + BDC + Business AI, vereint seit Sapphire am 12.05.2026). Nichts an diesem Marken-Dach ändert, was Datasphere technisch tut — es ändert, wer den Vertrag unterschreibt und wie die Roadmap kommuniziert wird. Ein Berater sollte die Ankündigung der Business AI Platform nicht als neue Datasphere-Fähigkeit darstellen; die tatsächlich neue Fähigkeit ist die eingebettete Joule-Oberfläche und der Knowledge-Graph-Grounding-Pfad, beide datiert und unabhängig vom Marken-Dach GA-überprüfbar.

Was sich seit Ende September 2026 geändert hat

28. September 2026 — ein Beitrag der SAP-Community-Lerngruppe zu den Integrationstechnologien von Datasphere beschreibt ein zweistufiges Muster nah an einer geschichteten BW-Architektur: schnelle, deltafähige Integration der Rohdaten über Replikationsflüsse, um die Quelle zu schonen, danach Transformationsflüsse für Joins, Bereinigung und Harmonisierung, darüber eine fachliche Datenschicht. Für Praktiker ist diese Aufteilung eine Kosten- und Latenzentscheidung; es legt zudem fest, welche modellierten Objekte ein KI-Grounding-Pfad später lesen kann (Quelle).
29. September 2026 — SAP hat eine Anleitung für Replikationsflüsse nach AWS S3 über einen privaten Pfad veröffentlicht: SAP Cloud Connector auf einem EC2-Host im selben VPC und Subnetz wie ein S3-Interface-Endpoint (RHEL 9 oder Amazon Linux 2023, mindestens 2 vCPU / 4 GB), sodass der Datenverkehr im AWS-Netz bleibt. Sicherheitsteams, die öffentliche S3-Endpunkte ablehnen, blockieren den ausgehenden Feed damit nicht mehr, doch ein Cloud-Connector-Host muss eingeplant und betrieben werden (Quelle).
29. September 2026 — ein Mitgliederbeitrag, „Dynamic Top-N Waterfall Analysis in SAP Analytics Cloud: Why I Moved Ranking to SAP Datasphere“, plädiert dafür, die Ranking-Logik aus der SAC-Story in die Datasphere-Schicht zu verlagern. Das entspricht der Empfehlung dieser Karte: Einmal in Datasphere modellierte Logik ist für alle Konsumenten wiederverwendbar, SAC wie KI (Quelle).
1. Oktober 2026 — ein Q&A-Beitrag zu grafischen Sichten, die SAC-Live-Modelle speisen, führt fehlschlagende Drill-downs auf fehlende Primärschlüssel, falsche Beziehungen, fehlende Hierarchien, falsche Spalteneigenschaften und Live-Modell-Grenzen zurück. In der Praxis: diese fünf Punkte in der Sicht prüfen, bevor ein Ticket gegen SAC eröffnet wird (Quelle).

Warum es zählt

‚HANA Cloud‘ separat von Datasphere zu bepreisen, zählt Ausgaben doppelt, da HANA Cloud automatisch aus dem eigenen Capacity-Unit-Plan des Tenants bereitgestellt wird.
Die Entscheidung federieren vs. replizieren wird pro Quellobjekt getroffen, nicht pro Quellsystem – die Standardeinstellung ‚alles replizieren‘ lässt drei von vier Architekturen an nächtlichen Batch-Fenstern scheitern.
Es gibt einen konkreten Sizing-Ankerpunkt für Verhandlungen: Ein Analytic Model mit 100 Mio. Zeilen, täglichem Refresh und 50 gleichzeitigen SAC-Nutzern läuft im Steady-State bei ~32 CU, gegenüber einer Untergrenze von 64 CU zu rund 52.000 €/Jahr.

Kernpunkte

Nachfolger von Data Warehouse Cloud (DWC); Rebranding Q1 2023; die Konsumtionsschicht der BDC.
Läuft auf HANA Cloud + managed Delta — Datasphere ist das Modellierungs-/Governance-Fabric, nicht die Engine.
Drei Säulen in einer Plattform: Federation (Live-Push-down), Replikation (Replication Flows, CDC), Modellierung (Graphical / SQL / Script).
Dreischichtige Modellierung: Raw → SQL View → Analytic Model. Raw Views vor der Freigabe an SAC immer wrappen.
Data Access Controls (DAC) auf Catalog-Ebene = eine Regel greift für SAC + Joule + Delta Sharing + OData + JDBC.
Capacity-Unit-Pricing: 64 CU Minimum, ~52.000 €/Jahr FY26; CU von Benutzer-Seats entkoppelt, aber durch Concurrency × Datensatzgröße aufgezehrt.
Die BDC-Deployment-Form ergänzt ein Databricks-Lakehouse mit bidirektionaler Governance — DAC reicht bis zu den Delta-Tabellen.
Performance: 100-500 ms p50 bei vollem HANA-Push-down; 50-200 k Zeilen/Sek. Replikation; 200-Nutzer-Concurrency-Obergrenze bei SAC Live.

Quellen

In der App öffnen →

Leitfäden, die mit dieser Seite antworten

Diese Leitfäden nennen diese Seite als eine der Quellen, auf die sich ihre Antwort stützt.

SAP Datasphere Zertifizierung: welche Prüfung gilt

Offene SAP-Projekte

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