Zum Inhalt springen
Enterprise Data Marketplace auf Databricks: SAP- und Non-SAP-Daten Zero-Copy vereinen

Enterprise Data Marketplace auf Databricks: SAP- und Non-SAP-Daten Zero-Copy vereinen

Case Study: Wie ein Industriekonzern SAP- und Non-SAP-Daten in einem Enterprise Data Marketplace auf Databricks vereint. Zero-Copy Zugriff, weniger Data Footprint, geringere Storage-Kosten, bei zentraler Governance über Unity Catalog.

Lesedauer7 Min.
VeröffentlichtJuli 2026

Die wichtigsten Ergebnisse

  • Zero-Copy statt Datenkopien

    Delta Sharing stellt Datenprodukte aus SAP- und Non-SAP-Quellen bereit, ohne dass physische Kopien entstehen — kontrollierte Zugriffe statt Replikate.

  • Ein Marketplace für den Konzern

    Fachbereiche finden, prüfen und beantragen Datenprodukte in einer Oberfläche — und konsumieren sie im Tool ihrer Wahl.

  • Sinkende Storage-Kosten

    Weniger Kopien und Sync-Strecken reduzieren Data Footprint sowie Storage- und Betriebskosten.

  • Governance durchgängig

    ACLs, Row- und Column-Policies, ABAC, Lineage und Audit Logs laufen zentral in Unity Catalog zusammen.

Zusammenfassung

Der Konzern gehört zu den weltweit führenden Industrieunternehmen mit mehreren Divisionen, Business Units und Produktionsstandorten in zahlreichen Ländern. Die Datenlandschaft war entsprechend gewachsen: SAP-Kernsysteme, SAP Business Data Cloud, SAP Datasphere, Salesforce, Databricks und weitere Data Warehouses liefen parallel, jeweils mit eigenen Datenkopien, Zugriffswegen und Governance-Regeln.

Für Fachbereiche bedeutete das: Relevante Daten waren vorhanden, aber schwer auffindbar und nicht einheitlich zugänglich. Zugriffe mussten pro Plattform, Anwendung oder Report neu geklärt werden. Datenqualität, Herkunft und Verantwortlichkeit waren zwischen den Systemen nur begrenzt nachvollziehbar. Für viele Analysen musste zunächst geklärt werden, welche Quelle maßgeblich ist und wie der Zugriff darauf organisiert wird.

Für einen Konzern dieser Größe wurde der fragmentierte Datenzugang zum strategischen Skalierungsthema. Redundante Datenhaltung erhöhte Storage-, Compute- und Betriebskosten. Unterschiedliche Berechtigungsmodelle erschwerten Audit und Compliance. Mehrere Datenkopien und Kennzahlenvarianten belasteten Steuerungsentscheidungen und bremsten neue Data-&-AI-Initiativen.

Die Zielsetzung war deshalb klar: ein zentraler Access Layer für SAP- und Non-SAP-Datenprodukte, weniger Data-Copy-Volumen, durchgängige Governance über Unity Catalog und ein standardisierter Data-Shopping-Prozess für Fachbereiche. Aus vielen Plattformzugängen sollte ein Enterprise Data Marketplace entstehen, der Datenprodukte auffindbar, kontrolliert anforderbar und zero-copy konsumierbar macht.

True Data Democratization wurde damit nicht als offenes Datenversprechen verstanden, sondern als kontrolliertes Betriebsmodell: einfacher Zugang für Fachbereiche, klare Rollen für Data Owner und Data Stewards, zentrale Security und nachvollziehbare Nutzung über Business Units, Divisionen und Regionen hinweg.

Übersicht

Kunde
Industriekonzern
Anonymisierte Referenz
Branche
Produktion

Verwendete Technologien & Systeme

SAP Datasphere
SAP Datasphere
Azure Cloud
Azure Cloud
Power BI
Power BI
Databricks Unity Catalog
Databricks Unity Catalog
SQL Warehouse
SQL Warehouse
Databricks Delta Lake
Databricks Delta Lake
Die Transformation

Von fragmentierten Datenplattformen zum unternehmensweiten Data Marketplace

01Ausgangssituation

Wenn jede Plattform ihren eigenen Zugang und ihre eigene Kopie mitbringt

Die gewachsene Analytics-Landschaft war das Ergebnis vieler richtiger Einzelentscheidungen. SAP Datasphere unterstützte SAP-nahe Analytik, SAP Business Data Cloud bündelte Business-Daten, Databricks wurde für Data Science und Advanced Analytics genutzt, Salesforce lieferte Vertriebs- und Kundendaten, weitere Data Warehouses deckten Legacy-Anwendungen ab. Jede Plattform hatte ihren Zweck und ihre operative Berechtigung.

Über die Jahre entstand daraus jedoch ein fragmentierter Datenzugang. Fachbereiche mussten relevante Datenbestände je Plattform suchen, Zugriffe individuell klären und Daten häufig in eigene Arbeitsumgebungen kopieren. Dieselben Daten lagen mehrfach vor, mit unterschiedlichen Berechtigungslogiken, unterschiedlichen Verantwortlichkeiten und begrenzter übergreifender Nachvollziehbarkeit.

Mit der wachsenden Zahl an Data-&-AI-Use-Cases wurde dieses Muster zum Skalierungsproblem. Neue Modelle und Analysen brauchten Daten aus mehreren Domänen. Jeder Zugriff bedeutete erneute Abstimmung, zusätzliche Freigaben und oft eine weitere Kopie. Das Data-Copy-Volumen wuchs schneller als der geschäftliche Nutzen aus den Daten.

Für den Konzern ging es deshalb um eine strukturelle Frage: Wie wird aus einer Multi-Platform-Landschaft ein integrierter Datenraum, in dem Fachbereiche Datenprodukte zuverlässig finden, kontrolliert anfordern und ohne neue Kopierlogik nutzen können?

Solange jede Analytics-Plattform ihren eigenen Zugang und ihre eigene Datenkopie mitbringt, bleibt Data Democratization ein Anspruch ohne operatives Betriebsmodell.
Industriekonzern: Kapitel 01
02Herausforderung

Zugang, Redundanz und Governance in einer Multi-Platform-Landschaft

Die Herausforderung lag in drei Bereichen: Daten finden, Daten teilen und Daten kontrolliert nutzbar machen.

Erstens fehlte ein einheitlicher Zugang. Fachbereiche wussten oft nicht, welche Datenprodukte im Konzern verfügbar sind, wer sie verantwortet, welche Qualität sie haben und über welchen Prozess Zugriff beantragt werden kann. Data Discovery lief informell, Anfragen liefen über Tickets, E-Mails oder direkte Kontakte. Der Weg vom Datenbedarf zur produktiven Nutzung war lang, uneinheitlich und schwer nachvollziehbar.

Zweitens wuchs die Datenredundanz. Um Daten zwischen Plattformen nutzbar zu machen, wurden häufig Kopien erzeugt: Snapshots, Exporte, Replikationen oder plattformspezifische Sync-Strecken. Jede Kopie erhöhte Storage-, Compute- und Betriebsaufwand, erschwerte Konsistenz und schuf zusätzliche Prüf- und Sicherheitsflächen. Zero-Copy-Zugriff war als Zielbild klar, aber noch nicht als konzernweiter Standard etabliert.

Drittens war Governance über Plattformgrenzen hinweg schwer durchsetzbar. Berechtigungen, Row-Level Policies und Column-Level Policies wurden je System gepflegt: in SAP anders als in Databricks, in Power BI anders als in Salesforce. RBAC, ABAC, Lineage, Audit Logs und Impact Analysen folgten keinem gemeinsamen Betriebsmodell. Für Compliance, interne Revision und skalierende Data-&-AI-Use-Cases wurde das zunehmend schwer tragbar.

Die Aufgabe war deshalb keine reine Integrationsfrage. Benötigt wurde ein gemeinsamer Access Layer, der Data Discovery, Data Shopping, Zugriffskontrolle und Zero-Copy-Sharing in ein standardisiertes Data-Product-Modell überführt.

Ohne einen governance-geführten Access Layer bleibt Data Democratization abhängig von Einzelabstimmungen, Kopien und plattformspezifischen Sonderwegen.
Industriekonzern: Kapitel 02
03Strategie

Vom Plattformzugang zum Enterprise Data Marketplace

Vor dem technischen Aufbau entstand gemeinsam mit ruhrdot eine Datenstrategie für den Enterprise Data Marketplace. Der Grundgedanke: Datenbestände werden nicht mehr als einzelne Exporte oder Plattformobjekte bereitgestellt, sondern als Datenprodukte mit klarer Verantwortung, Beschreibung, Zugriffskontrakt, Freigabeprozess und Lifecycle.

Fachbereiche sollen relevante Datenprodukte über eine zentrale Discovery-Oberfläche finden, fachlich einordnen und über einen standardisierten Request-Prozess Zugriff beantragen können. Governance läuft dabei nicht neben dem Marketplace, sondern durch ihn: Wer ein Datenprodukt besitzt, wer es freigibt, wer es konsumiert und welche Policies gelten, wird Teil des Betriebsmodells.

Fünf Bausteine bildeten das strategische Fundament:

Technisch wurde dafür eine Hub-and-Spoke-Architektur auf Databricks in Azure definiert. Databricks bildet den Hub: den zentralen Access Layer über Unity Catalog. Die bestehenden Plattformen, darunter SAP Business Data Cloud, SAP Datasphere, Salesforce und weitere Warehouses, werden als Spokes angebunden. Datenprodukte werden dort konsumierbar, wo sie gebraucht werden, ohne für jeden Use Case neue Kopien aufzubauen.

Das Betriebsmodell wurde von Beginn an mitgedacht. Data Owner verantworten fachliche Definition und Datenqualität, Data Stewards pflegen Metadaten und Nutzbarkeit, das Plattformteam stellt technische Bereitstellung und Governance sicher, Konsumenten nutzen die freigegebenen Datenprodukte im Fachkontext. So entsteht ein wiederholbarer Data-Product-Lifecycle vom Onboarding über Freigabe und Nutzung bis zur Abkündigung.

Leitprinzip: Datenprodukte werden wie Produkte betrieben: mit Owner, Beschreibung, Zugriffskontrakt und Lifecycle statt als Ad-hoc-Extrakt.
Industriekonzern: Kapitel 03
04Lösung

Hub-and-Spoke Data Platform mit Zero-Copy Sharing und zentraler Governance

In der Umsetzung entstand eine hochskalierbare Middleware-Plattform, die Datenquellen, Enterprise-Applikationen, Identity- und Zugriffsmanagement sowie das Data-Product-Lifecycle-Management verbindet. Die Middleware übernimmt die Katalogisierung der Datenprodukte, den Shopping- und Freigabeprozess und die Anbindung an Identity-Provider (IdP) und Identity-Access-Management (IAM). Freigegebene Datenprodukte werden anschließend im Unity Catalog auf Databricks verfügbar gemacht.

Delta Sharing bildet den technischen Kern für Zero-Copy Access. Datenprodukte aus SAP Business Data Cloud, SAP Datasphere und weiteren Non-SAP-Quellen werden über den offenen Delta-Sharing-Standard bereitgestellt und in Unity Catalog registriert. Konsumenten greifen von Databricks, Power BI, externen Anwendungen und aus verschiedenen Programmiersprachen auf dieselben Datenprodukte zu, ohne dass an anderer Stelle eine physische Kopie liegt. Zwischen den Plattformen fließen keine Datenreplikate, sondern kontrollierte Zugriffe.

Das Governance-Framework wurde durchgängig auf Unity Catalog aufgesetzt. Access Control Lists (ACLs) regeln Zugriffsrechte auf Katalog-, Schema-, Tabellen- und Spaltenebene. Row-Level-Policies filtern Datensätze nach Rolle, Region oder Business Unit. Column-Level-Policies maskieren sensible Attribute. Attribute-Based Access Control (ABAC) ergänzt klassische RBAC, wo eine dynamische Berechtigungslogik nötig ist. Lineage macht die Herkunft und den Verarbeitungsweg jeder Kennzahl nachvollziehbar. Audit Logs, Impact Analysen und Nutzungsstatistiken laufen im Katalog zusammen und liefern der Data-Governance-Organisation eine belastbare Grundlage.

Die Konsumenten-Erfahrung ist bewusst einheitlich gestaltet. Ein Fachbereich sucht ein Datenprodukt in der Marketplace-Oberfläche, prüft Beschreibung, Owner, Datenqualität und Zugriffskontrakt, beantragt Zugriff über den standardisierten Prozess und konsumiert die freigegebenen Daten anschließend in dem Tool, mit dem er ohnehin arbeitet. Ob Databricks-native, Power BI, eine externe Applikation oder Python, der Zugriffspfad geht durch Unity Catalog, das Berechtigungsmodell bleibt gleich.

Das Betriebsmodell begleitet die Technologie. Rollen und Freigabeprozesse für internes und externes Data Sharing wurden standardisiert. Data Owner und Data Stewards arbeiten mit Plattformteams und Konsumenten in einem gemeinsamen Governance- und Operating-Model. Neue Datenprodukte durchlaufen einen definierten Onboarding-Prozess mit Datenqualitäts-Checks, Zugriffsvergabe und Marketplace-Publikation.

Aus vielen isolierten Plattformzugängen wird ein Enterprise-weiter Data Marketplace, in dem Fachbereiche Datenprodukte finden, beantragen und ohne Kopien konsumieren.
Industriekonzern: Kapitel 04
1 Access LayerZentraler Zugang
0 DatenkopienZero-Copy via Delta Sharing
1 MarketplaceDatenprodukte konzernweit bestellbar

Zielarchitektur

Hub-and-Spoke Data Platform auf Databricks mit Delta Sharing als Interop-Standard

SAP- und Non-SAP-Datenquellen fließen über eine Middleware-Plattform in das Data-Product-Lifecycle-Management und werden anschließend über Unity Catalog auf Databricks als zentraler Access Layer bereitgestellt. Delta Sharing öffnet die Datenprodukte für weitere Plattformen und Anwendungen, ohne physische Kopien anzulegen. Governance, Berechtigungen und Auditing laufen einheitlich über Unity Catalog. Datenquellen Databricks Data Intelligence Platform Managed · Azure · Unity Catalog Middleware und Data-Product-Lifecycle Konsum-Kanäle Governance und Betrieb

Bausteine

  • SAP Business Data Cloud: konzernweite Business-Daten und Analytics-Modelle
  • SAP Datasphere: SAP-nahe Analytics und Semantik-Layer
  • SAP S/4HANA und angrenzende Systeme über die SAP-Datenplattformen
  • Salesforce: Vertriebs-, Kunden- und CRM-Daten
  • Weitere Data Warehouses und operative Systeme im Konzernumfeld
  • Access Layer: Unity Catalog als zentraler Konsum- und Zugriffslayer für SAP- und Non-SAP-Datenprodukte
  • Zero-Copy Data Sharing: Delta Sharing als offener Interop-Standard über Plattformgrenzen
  • Data Foundation: Delta Lake für versionierte, kuratierte Datenprodukte
Platform Outcomes

Was sich durch den Enterprise Data Marketplace verändert hat

Zentraler Einstiegspunkt für Datenprodukte

Fachbereiche finden verfügbare Datenprodukte plattformübergreifend, ordnen sie fachlich ein und beantragen Zugriff über einen standardisierten Prozess. Statt in jeder Plattform einzeln nach Daten zu suchen, führt der Data Catalog Discovery, Beschreibung, Freigabe und Zugriff in einem gemeinsamen Prozess zusammen.

Konsolidierter Access Layer für SAP- und Non-SAP-Daten

Der Zugriff auf SAP- und Non-SAP-Datenprodukte läuft über eine gemeinsame, governance-geführte Konsumschicht. Databricks, Power BI, Fachanwendungen und programmatic Access greifen auf dieselben freigegebenen Datenprodukte zu, ohne kanalabhängige Sonderwege oder zusätzliche Kopien aufzubauen.

Zero-Copy Sharing mit reduziertem Data Footprint

Delta Sharing ermöglicht den kontrollierten Zugriff auf bestehende Datenbestände, ohne für jeden Konsumenten neue physische Kopien zu erzeugen. Weniger Exporte, Replikationen und Sync-Strecken senken Storage-, Compute- und Betriebsaufwand und reduzieren zugleich zusätzliche Audit- und Sicherheitsflächen.

Zentrale Governance über Unity Catalog

Berechtigungen, Ownership, Row-Level Policies und Column-Level Policies werden zentral über Unity Catalog gesteuert. RBAC und ABAC bilden ein gemeinsames Rechtemodell, das unabhängig vom konsumierenden Tool durchgesetzt wird.

Nachvollziehbare Nutzung und bessere Priorisierung

Lineage, Audit Logs, Nutzungsstatistiken und Impact Analysen zeigen, woher Daten stammen, wer sie nutzt und welche Reports, Anwendungen oder Datenprodukte von Änderungen betroffen sind. Die Data-Governance-Organisation kann Investitionen, Konsolidierung und Qualitätsverbesserungen auf Basis realer Nutzung priorisieren.

Einheitliches Operating Model für Data Sharing

Rollen, Freigabeprozesse, Verantwortlichkeiten und technische Bereitstellung werden standardisiert. Data Owner, Data Stewards, Plattformteam und Konsumenten arbeiten in einem gemeinsamen Data-Product-Lifecycle, vom Onboarding über Freigabe und Nutzung bis zur Abkündigung.

Vorher / Nachher

Was sich konkret verändert hat

Vorher

Nachher

Datenzugang

Fachbereiche mussten pro Plattform, pro Anwendung und pro Use Case Zugänge klären.
Ein zentraler Marketplace mit Data Discovery und standardisiertem Request-Prozess.

Datenhaltung

Dieselben Daten wurden mehrfach zwischen Plattformen kopiert.
Zero-Copy Data Sharing über Delta Sharing zwischen SAP- und Non-SAP-Plattformen.

Data Footprint & Kosten

Redundante Kopien, parallele Replikationen und Sync-Strecken trieben Storage-, Compute- und Betriebskosten dauerhaft nach oben.
Deutlich schlankerer Footprint über die gesamte Analytics-Landschaft, mit direkter Wirkung auf laufende Kosten und Betriebsaufwand.

Governance

Berechtigungen, Row- und Column-Level-Policies wurden pro System vergeben.
RBAC, ABAC und Datenrichtlinien werden zentral über Unity Catalog durchgesetzt.

Nachvollziehbarkeit

Lineage und Audit-Informationen mussten pro System zusammengetragen werden.
Lineage, Audit Logs und Impact Analysen laufen im Katalog zusammen.

Datenprodukte

Ad-hoc-Extrakte ohne Owner und Lifecycle.
Datenprodukte mit definiertem Owner, Kontrakt und Lifecycle im Marketplace.

Nächste Schritte

Vom Access Layer zum unternehmensweiten Data-Product-Portfolio

Die erste Phase schafft das Fundament für den Enterprise Data Marketplace: einen konsolidierten Access Layer über Unity Catalog, Zero-Copy Data Sharing über Delta Sharing, ein standardisiertes Governance- und Operating Model sowie erste produktive Datenprodukte. In der nächsten Ausbauphase wird daraus ein breiteres Data-Product-Portfolio für Business Units, Divisions und Regionen.

1

Datenproduktangebot gezielt erweitern

Weitere Datenprodukte aus zusätzlichen Domänen und Business Units werden in den Marketplace aufgenommen. Nutzungsstatistiken, Popular-Data-Sources-Reports und Feedback aus den Fachbereichen steuern die Priorisierung. Datenqualität, Beschreibung und Zugriffskontrakte werden auf Basis realer Nutzung nachgeschärft.

2

Governance und Freigaben weiter automatisieren

Access Reviews, Compliance-Kontrollen und Impact Analysen werden stärker automatisiert. ABAC-basierte Policies werden ausgebaut, damit Berechtigungen dynamischer nach Rolle, Region, Business Unit oder Nutzungskontext greifen. Die Integration mit IAM- und IdP-Systemen des Konzerns wird weiter vertieft.

3

Self-Service-Analytics und AI auf Datenprodukten aufbauen

Fachbereiche nutzen freigegebene Datenprodukte für Reports, Analysen, Machine-Learning-Modelle und AI-Anwendungen. Der Marketplace wird damit zur gemeinsamen Grundlage für Reporting, Analytics und AI: von Wissensassistenten über Prognosemodelle bis zu operativer Optimierung auf denselben governance-geführten Datenprodukten.

Steht eure Datenplattform vor einer ähnlichen Skalierungsfrage?

Wenn Daten über viele Plattformen, Systeme oder Geschäftsbereiche verteilt liegen, entstehen schnell parallele Zugriffe, doppelte Datenhaltung und uneinheitliche Governance. Entscheidend ist dann ein gemeinsames Betriebsmodell: Daten auffindbar machen, Zugriffe kontrolliert steuern und Datenprodukte ohne unnötige Kopien nutzbar machen. Wir prüfen mit euch, ob ein Enterprise Data Marketplace für eure Datenlandschaft sinnvoll ist, welche Datenprodukte den größten Hebel haben und wie Governance, Self-Service und Zero-Copy Sharing in ein tragfähiges Plattformmodell passen.

Alexander Rabe
Alexander Rabe
Co-Founder · Head of Data & AI

FAQ

Häufig gestellte Fragen