Konzeptkarte

Data Product Studio in SAP Business Data Cloud

Stand 6. 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 Data Product Studio in SAP Business Data Cloud?

Nicht die Modellierungskompetenz in Datasphere, sondern die Beherrschung des Studios trennt „ich kann modellieren“ von „ich kann governte Data Products im Tier-1-Maßstab ausliefern“ – die Veröffentlichung erzwingt eine verpflichtende Konsumenten-Review, bevor v1 überhaupt live geht.

Data Product Studio ist das Authoring-Cockpit innerhalb von SAP Business Data Cloud, in dem produzierende Teams Data Products entwerfen, testen und veröffentlichen — die verwalteten, abonnierbaren Datenassets, auf denen Business-Data-Cloud-Konsumenten (SAP Analytics Cloud, Joule, Databricks-Notebooks, Partneranwendungen) aufbauen. Wenn das Data Product das fertige Erzeugnis ist, ist Studio die Fabrikhalle: ein Schema-Designer, ein Service-Level-Agreement-Editor, ein Lineage-Visualisierer, ein Data-Access-Control-Regel-Binder und ein Test-Runner, zusammengefügt zu einer einzigen Authoring-Fläche mit einem darüberliegenden Versionierungs- und Deprecation-Workflow. Für einen Consultant, der im Business-Data-Cloud-Delivery-Track arbeitet, ist die Beherrschung von Studio der praktische Unterschied zwischen „ich kann Tabellen in Datasphere modellieren“ und „ich kann ein verwaltetes, vertraglich abgesichertes Data Product ausliefern, das ein Tier-1-Unternehmen sicher abonnieren kann“.

Was die fünf Bereiche leisten

Der Schema-Designer ist die Stelle, an der Spaltendefinitionen, semantische Typen, Primär- und Fremdschlüsselbeziehungen und erlaubte Null-Muster deklariert werden, mit einer Beispielwert-Vorschau, sodass der Modellierer echte Zeilen sieht, statt den Metadaten zu vertrauen. Der Service-Level-Agreement-Editor macht aus Aktualitäts-, Vollständigkeits- und Genauigkeitszusagen messbare Signale — ein Replication-Flow-Zeitstempel, eine Zeilenanzahl-Prüfung, ein Wertebereich-Validator — statt vager Versprechen auf einer Wiki-Seite. Der Lineage-Visualisierer generiert automatisch einen Graphen von der Quelle zum Ziel, der die erste Frage eines Prüfers, „woher stammt diese Spalte tatsächlich“, in unter einer Minute beantwortet statt in einem Tag stillschweigender Ausgrabung. Der Access-Control-Regel-Binder heftet Row-Level- und Column-Level-Sicherheitsregeln aus dem Catalog an und lässt den Designer die Daten so ansehen, wie ein bestimmter aufrufender Nutzer sie sehen würde, und fängt so eine Überexposition vor der Veröffentlichung ab statt nach einem Sicherheitsvorfall. Der Test-Runner schließt den Kreis mit Schema-Tests, Service-Level-Agreement-Validierungstests, Stichproben-Inspektion und Regressionstests gegen die vorherige veröffentlichte Version.

Warum es zählt

Die Stichproben-Vorschau vor der Veröffentlichung fängt Typkonflikte und Null-Muster-Probleme ab, die der Schema-Validator allein übersieht.
Breaking Changes lösen einen verpflichtenden 90-tägigen Deprecation-Zyklus aus — die Versionierungsdisziplin von Studio zu überspringen ist genau das, was stille Konsumenten-Brüche verursacht.
Die verpflichtende Review durch das Konsumenten-Team vor der Veröffentlichung validiert Schema und SLA gegen reale Anwendungsfälle, bevor irgendjemand abonnieren kann.

Kernpunkte

Fünf Bereiche: Schema · SLA · Lineage · DAC · Tests.
Fünfstufiger Workflow: Entwurf → Review → Veröffentlichung → Iteration → Hauptversions-Sprung.
Stichproben-Vorschau vor der Veröffentlichung (fängt Typ-/Null-Probleme ab).
Durchgängiger Lineage-Durchlauf für 30-Sekunden-Prüferbereitschaft.
DAC auf der niedrigsten exponierten Schicht (nie nur am Analytic Model).
SLA in der Realität des Quellsystems verankert + 50 % Puffer.
Tests verpflichtend: Schema + SLA + Regression gegen v(N-1).
Deprecation-Roadmap mit der v1-Veröffentlichung; v2 löst einen expliziten Day-1 aus.

Begriffe auf dieser Seite

Data Product Studio: BDC-Authoring-Umgebung, die Schema-Designer, SLA-Editor, Lineage-Visualisierer, DAC-Binder und Test-Runner zusammenführt.
Schema designer panel: Drag & Drop-Spaltendefinition mit semantischen Typen, FK-Beziehungen, Null-Mustern, Stichproben-Vorschau.
SLA editor panel: Aktualitäts-/Vollständigkeits-/Genauigkeitszusagen, an messbare Signale gebunden.
Lineage visualiser: Automatisch generierter Graph von der Quelle zum Ziel. Prüfer-Antwort auf „woher?“ in 30 Sekunden.
DAC rule binder: Bindet Row- und Column-Sicherheitsregeln aus dem Catalog an. Vorschau als aufrufender Nutzer.
Test runner: Schema-Tests · SLA-Validierung · Regression gegen die vorherige Version. 1–3 Min. pro Lauf.
Review gate: Verpflichtende Validierung durch das Konsumenten-Team vor der Veröffentlichung. Typischerweise 2–3 Wochen.
Deprecation roadmap: Mit v1 veröffentlichtes Dokument, das angibt, wann v2 geplant ist + welche Breaking Changes. Begleitet den 90-Tage-Zyklus aus C010.

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 →

Offene SAP-Projekte

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