Analytics Legends Die Wissensplattform für SAP Analytics
Academy-Modul

Spaces & Verbindungen

Space topology — 4 domain spaces sharing one foundation space, one-way — architecture diagram for Spaces & Connections, Analytics Legends Academy module M002

Stand 2026-09-03

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

Datasphere Spaces sind Governance- und Abrechnungseinheiten, keine Ordner. Erfahrenes Muster: 4 Domänen-Spaces (Finance/Supply/HR/Sales) + 1 Foundation-Space, NICHT 1 pro Rechtseinheit. Connections laufen über den Cloud Connector mit Allow-Lists; Service-Accounts nie domänenübergreifend teilen. Die CU-Baseline fällt pro aktivem Space an — Gesamtzahl der Spaces klein halten, Demos konsequent stilllegen.

Was Sie lernen

  • Die Kernkonzepte hinter Spaces & Connections verstehen
  • Spaces in einem typischen SAP-Analytics-Engagement anwenden
  • Die 3-5 häufigsten Fehler erkennen und wissen, wie man sie vermeidet
  • Diese Fähigkeit in der eigenen Personal Brand und im Tagessatzgespräch positionieren

Modulüberblick

Datasphere-Spaces sind die Einheit für Governance, Abrechnung und Zugriff — nicht nur ein Ordner. Werden Spaces in Woche 1 falsch angelegt, werden die nächsten zwölf Wochen zu einem dauerhaften Refactoring. Ein erfahrener Berater entwirft die Space-Topologie, BEVOR die erste View geschrieben wird: ein Space pro Geschäftsdomäne (Finance, Supply Chain, HR, Sales), gemeinsame technische Objekte in einem dedizierten Foundation-Space und klare Cross-Space-Sharing-Verträge.

Connections sind die Türen zwischen Spaces und Quellsystemen. Der Katalog ist klein und bewusst gehalten: SAP S/4HANA Cloud, S/4HANA on-premise (via DPA / SDA), SuccessFactors, Ariba, Concur, BW/4HANA, HANA Cloud, generisches JDBC/ODBC, File-Uploads, OData und der Cloud Connector für Nicht-SAP. Die Connection-Technologie nach Latenzbudget und Sicherheitslage wählen, nicht danach, was das Quell-Team bevorzugt.

Warum erfahrenes Handwerk hier zählt. Der klassische Junior-Fehler: 12 nach Rechtseinheiten benannte Spaces (FR_HOLDING, DE_GMBH, IT_SPA…) mit ad hoc verdrahtetem Cross-Space-Sharing. Nach sechs Monaten erfordert das Finance-Reporting 4-fach-Joins über Spaces hinweg, und die CU-Kosten verdreifachen sich. Das erfahrene Muster: 4 Domänen-Spaces + 1 Foundation-Space + explizite Verträge für geteilte Dimensionen; das Cross-Entity-Reporting ist ein Analytic Model mit einer Länderdimension, nicht 12 zusammengeflickte Spaces.

Voraussetzungen

  • Zuerst die Kernkonzepte durcharbeiten: C008, C002, C003

Lernergebnisse

  • Ein realistisches Szenario durcharbeiten: europäischer Handelskonzern, 12 Landesgesellschaften, S/4HANA + SuccessFactors + Salesforce. Der Junior-PoC lieferte 12 nach Ländern benannte Spaces. Sie kommen in Woche 5 dazu, mit noch 4 Wochen Zeit.
  • Das Anti-Pattern erkennen und vermeiden: 1 Space pro Rechtseinheit — das Cross-Entity-Reporting wird zum 4-fach-Join, die CU-Kosten verdreifachen sich.
  • Die Kernentscheidung des Moduls anwenden: Space-Granularität — 1 Space pro Geschäftsdomäne wählen (Finance, Supply Chain, HR, Sales), nicht 1 Space pro Rechtseinheit, Land oder Quellsystem.
  • Die Beherrschung anhand des KPI verfolgen: Anzahl aktiver Spaces insgesamt (Ziel: ≤ 6 in der Foundation-Phase; Warnsignal: > 8 = Governance-Schuld).

Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.

In der App öffnen →

Weiter in diesem Lernpfad