Konzeptkarte

Spaces & Workspaces

Stand 2026-07-24T14: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 Spaces & Workspaces?

Ein Space ist eine Umsetzungsgrenze, kein isolierter Tenant – der gesamte Datasphere-Tenant teilt sich weiterhin einen HANA-Cloud-Pool, ein CU-Budget, einen Catalog und ein Berechtigungsmodell.

Was es ist

Ein Space in SAP Datasphere ist eine logische Partition innerhalb eines Tenants, die eigene Tabellen, Views, Analytic Models, Hierarchien, Währungen und Berechtigungen trägt. Er ist die grundlegende Einheit für Auslieferung und Governance in Datasphere — jedes Objekt, das ein Modeler baut, lebt in genau einem Space, gehört einem Team und folgt einem Release-Rhythmus.

Warum es wichtig ist

Das Space-Design ist die einzelne architektonische Entscheidung mit der längsten Halbwertszeit in einem Datasphere-Programm. Trifft man sie richtig, läuft die teamübergreifende Zusammenarbeit über saubere, versionierte Verträge; trifft man sie falsch, erstarrt die Plattform entweder zu einem Monolithen, den niemand mehr gefahrlos ändern kann, oder zu einem Labyrinth aus Punkt-zu-Punkt-Abhängigkeiten zwischen Spaces, das jede Schemaänderung zu einer teamübergreifenden Verhandlung macht. Weil Spaces zugleich Sicherheit, Kostentransparenz und Lebenszyklus-Eigentümerschaft steuern, prägt die Entscheidung aus Woche eins eines Programms noch immer, wie schmerzhaft sich Jahr drei anfühlt.

Wie es funktioniert

Jeder Space teilt sich denselben zugrunde liegenden HANA-Cloud-Compute, denselben tenantweiten Capacity-Unit-Pool und denselben Catalog — Spaces sind keine isolierten Tenants, sie sind Governance- und Auslieferungsgrenzen, die über gemeinsam genutzter Infrastruktur liegen. Space-übergreifender Konsum erfolgt über den Catalog: Ein produzierender Space veröffentlicht ein Data Product, einen versionierten und dokumentierten Vertrag, und ein konsumierender Space abonniert eine schreibgeschützte Assoziation davon. Ein Space durchläuft vier Lebenszyklusphasen — Provisionierung, in der Mitglieder und Quellverbindungen verdrahtet werden; Build, in der der Modeler Tabellen, Views und Modelle befüllt; Publish, in der Data Products zertifiziert und freigegeben werden; und Maintain, in der Schemaevolution und Zugriffsreviews im laufenden Rhythmus stattfinden.

Warum es zählt

Ab vier oder fünf fachlichen Spaces übersteigt Space-übergreifendes Sharing typischerweise 50 % der Objekte — das Signal, dass ein Organigramm statt eines Delivery-Modells auf die Plattform projiziert wurde.
Direkter Shared-Object-Zugriff zwischen Spaces umgeht den Data-Product-Vertrag und erzeugt undokumentierte Kopplung, die bricht, sobald das produzierende Team refaktorisiert.
Die kanonische Tier-1-Form sind 3-4 fachliche Spaces plus ein Shared Space für Stammdaten — der Mittelstand sollte auf 1-2 Spaces reduzieren, statt das Enterprise-Muster standardmäßig zu spiegeln.

Kernpunkte

Space = Auslieferungsgrenze (ein Team, ein Rhythmus, ein Vertrag). KEIN Tenant.
Tier-1-Muster: 3-4 fachliche Spaces + 1 Shared Space für Stammdaten. Über 5 Spaces = Geruch.
Space-übergreifendes Sharing via Data Products im Catalog — versionierte Verträge, keine Shared Objects.
Space-Lebenszyklus: Provision (operator-geführt) → Build (delivery-geführt) → Publish (Steward-Freigabe) → Maintain (vierteljährliche Hygiene).
Vierrollen-Berechtigungsmodell: Admin / Modeler / Integrator / Viewer. DAC schichtet sich darüber.
CU-Pool ist tenantweit; Chargeback pro Space über den Tenant Monitor rollierend über 30 Tage, keine plattformseitig erzwungenen Obergrenzen.
Multi-Region mit harter Residenzanforderung = mehrere Tenants + Delta-Sharing-Federation; nicht mehrere Spaces in einem Tenant.
Vierteljährliche Catalog-Hygiene räumt 30-40 % angesammelten Ballast in jedem 2+ Jahre alten Space auf.
Spaces & Workspaces ist erst gemeistert, wenn es eine benannte Buyer-Entscheidung verändert.
Mit dem semantischen Vertrag und dem Kontrollmodell beginnen, bevor das Tool vorgeführt wird.

Begriffe auf dieser Seite

Space: Logische Auslieferungsgrenze in einem Datasphere-Tenant. Besitzt Tabellen, Views, Modelle und Berechtigungen für eine Domäne. KEIN Tenant.
Shared Space: Space für querschnittliche Stammdaten (Kunde, Material, Zeit, Währung, Kostenstelle). Standardmäßig lesbar für andere Spaces.
Data Product: Versionierter, dokumentierter Schemavertrag, veröffentlicht im Catalog. Der kanonische Mechanismus für Space-übergreifendes Sharing.
Catalog: Tenantweite Metadatenschicht mit semantischen Typen, Lineage, Data Products, DAC-Regeln. Steht über allen Spaces.
Space Admin: Rolle, die Space-Mitglieder und Integrationen verwaltet. Einer pro Space, idealerweise der Data Steward des Fachbereichs.
Modeler: Rolle, die Objekte erstellt und bearbeitet (Tabellen, Views, Analytic Models). Typisch 2-4 pro Space.
Integrator: Rolle, die Connections und Replication Flows konfiguriert. Typisch 1-2 pro Space.
Tenant Monitor: Eingebautes Dashboard, das den CU-Verbrauch pro Space, die Query-Auslastung und den Replikations-Health-Status zeigt.

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 →