Konzeptkarte

SAP Datasphere für eine Décisionnel-Praxis — das klassische Modell abbilden, ohne es zu brechen

Stand 2026-08-02T22:40: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 Datasphere für eine Décisionnel-Praxis — das klassische Modell abbilden, ohne es zu brechen?

Wer mit dem klassischen Décisionnel-Modell im Kopf zu Datasphere kommt, macht einen kostspieligen Denkfehler — es als „das neue BW“ zu behandeln. Drei Unterschiede sprengen die Analogie: Föderation ist erstklassig, der Space ersetzt das Projekt-Silo, und die semantische Schicht speist mehr als nur Berichte.

Französische SAP-Teams sagen immer noch décisionnel, wo ein englisches Deck BI sagt, und das Wort trägt eine ganze Architektur mit sich: ein Warehouse, Universes, eine von einem zentralen Team gepflegte semantische Schicht und Reports, die ein Business User anfordert, statt sie selbst zu bauen. Wer mit diesem Modell im Kopf bei SAP Datasphere ankommt, wird es falsch abbilden — meist, indem er Datasphere als „das neue BW" behandelt —, und der Abbildungsfehler ist teuer, weil er ins Design überlebt.

Datasphere ist nicht das neue BW, und keine Universe-Schicht

Datasphere ist die vereinheitlichte Daten- und Semantikschicht im Zentrum von SAPs modernem Analytics-Bestand: Föderation, Replikation und Modellierung in einem Produkt, aufgebaut auf HANA Cloud mit integriertem Delta Lake. Was es ersetzt, ist kein einzelner Vorgänger, sondern ein Muster — der Flickenteppich aus Punkt-zu-Punkt-Extrakten, handgebauten Warehouses und brüchigen BEx-Queries, den ein langlebiger décisionnel-Bestand anhäuft.

Drei Unterschiede zählen für jeden, der das klassische Modell überträgt.

Föderation ist erstklassig. Eine Live-Query kann zur Quelle durchgereicht werden, ohne dass etwas kopiert wird. Im klassischen Warehouse-Modell wird alles geladen, bevor es modelliert werden kann; hier ist Laden eine Entscheidung, die man begründet, kein Standard, den man erbt.

Der Space ersetzt das Projekt-Silo. Jedes Objekt lebt innerhalb eines Space — einer governten Partition mit eigener Sicherheit, eigenen Verbindungen und eigenem Lebenszyklus. Space-übergreifender Konsum läuft über den Catalog als versionierte Data Products, niemals als Ad-hoc-Tabellenfreigabe. Das ist der Teil, der einem an ein gemeinsames Schema gewöhnten Team bürokratisch vorkommt, und genau dieser Teil verhindert den irgendwann eintretenden Kollaps des gemeinsamen Schemas.

Warum es zählt

Ein Team, das Datasphere als neu gehostetes BW modelliert, verschifft die Schuld des alten Bestands in die neue Plattform und zahlt dafür danach in jeder konsumierenden Anwendung.

Kernpunkte

„Décisionnel" trägt eine ganze Architektur mit sich — Warehouse, Universes, zentrales semantisches Team, angeforderte Reports —, und sie naiv auf Datasphere abzubilden, ist der teure Fehler.
Datasphere ist Föderation + Replikation + Modellierung in einem Produkt, auf HANA Cloud mit integriertem Delta Lake.
Was es ersetzt, ist kein einzelner Vorgänger, sondern ein MUSTER: Punkt-zu-Punkt-Extrakte, handgebaute Warehouses, brüchige BEx-Queries.
Unterschied 1 — Föderation ist erstklassig: eine Live-Query wird durchgereicht, ohne dass etwas kopiert wird. Laden wird zu einer Entscheidung, die man begründet, kein Standard, den man erbt.
Unterschied 2 — der Space ersetzt das Projekt-Silo; Space-übergreifender Konsum ist ein versioniertes Data Product über den Catalog, niemals Ad-hoc-Tabellenfreigabe.
Unterschied 3 — ein Analytic Model speist SAC, Joules Grounding-Schicht UND externe Werkzeuge über Delta Sharing. Mehrere Arten von Konsumenten lesen eine Definition.
Der Marktkontext: ~4.000 BW-Kunden im europäischen Hauptmarkt plus ~17.000 ECC-Kunden, unter dem Zeitdruck von SAPs Roadmap Richtung S/4HANA.
Die Entscheidung ist nicht, OB Datasphere — bei einer S/4HANA-+-SAC-Festlegung ist das effektiv geklärt —, sondern WIE VIEL man dort baut.
Ein Einmal-Report über ein oder zwei Tabellen ist legitim eine SAC-Live-Verbindung direkt zu S/4HANA. Datasphere verdient sich seinen Platz durch Wiederverwendung.
Die Einmalfälle in Datasphere zu modellieren, schafft den Engpass des zentralen Teams neu, der das klassische décisionnel überhaupt erst unbeliebt gemacht hat.

Begriffe auf dieser Seite

Décisionnel: Der französische Begriff für Business Intelligence, der die klassische Architektur mit sich trägt: Warehouse, Universes, ein zentrales semantisches Team und angeforderte statt selbstgebaute Reports.
Föderation: Live-Query-Durchreichung zu einer Quelle ohne Datenbewegung — erstklassig in Datasphere, und der Grund, warum Laden eine begründete Entscheidung sein sollte.
Space: Datasphere's governte Partition, mit eigener Sicherheit, eigenen Verbindungen und eigenem Lebenszyklus. Eine Governance-Grenze, kein Ordner.
Data Product: Die versionierte, katalogisierte Einheit, über die ein Space die Semantik eines anderen konsumiert. Die Alternative zur Ad-hoc-Tabellenfreigabe.
Analytic Model: Das Datasphere-Objekt, das die Geschäftssemantik trägt; gelesen von SAC, von Joules Grounding-Schicht und von externen Werkzeugen über Delta Sharing.
BEx-Query: Das klassische BW-Reporting-Objekt. Seine Brüchigkeit ist Teil des Musters, das Datasphere ersetzt, keine Komponente, die neu gehostet werden sollte.
Delta Lake: Das offene Speicherformat, das in Datasphere's HANA-Cloud-Fundament integriert ist, und das, was externes Multi-Konsumenten-Sharing möglich macht.
Landing Zone: Die Plattform, zu der SAPs Roadmap ECC- und klassische-BW-Kunden für Analytics steuert — das ist es, was den Migrationszyklus unter Zeitdruck setzt.

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 →