Konzeptkarte

BDC Connect

Stand 10. 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 BDC Connect?

BDC Connect beantwortet die entscheidende Frage, an der jedes Verkaufsgespräch hängt – „muss ich meine Snowflake-/Databricks-/Iceberg-Daten nach BDC verschieben?“ – mit Nein, über vier Föderationsmuster, die BDC zum Hub statt zum geschlossenen Garten machen.

Worum es geht

BDC Connect ist die Schicht, die die Frage beantwortet, auf die jedes Verkaufsgespräch zu Business Data Cloud früher oder später stößt: „Ich habe bereits Daten in Snowflake, in Databricks auf meinem eigenen Cloud-Konto, in einem Iceberg-Lake auf Objektspeicher oder von einem Partner als Delta Share geteilt – muss ich das alles zuerst in Business Data Cloud verschieben?“ Die Antwort, die BDC Connect gibt, lautet: Nein. Es föderiert und, wo nötig, lädt aus diesen externen Quellen und stellt sie als vollwertige Catalog-Objekte bereit, die Datasphere-Views, Joule-Agenten und Zugriffskontrollregeln genauso governen können wie SAP-native Daten. Ohne BDC Connect wäre Business Data Cloud eine geschlossene Plattform, die nur funktioniert, wenn ein Kunde zuerst alles hinein migriert; mit BDC Connect wird Business Data Cloud zum semantischen und Governance-Hub über einem tatsächlich heterogenen Datenbestand – für nahezu jeden Enterprise-Kunden der realistischere Ausgangspunkt.

Warum es zählt

Ein typischer Kunde hält 2026 rund 30 % Nicht-SAP-Daten in Snowflake, Databricks und Iceberg – ohne BDC Connect bleibt diese Schicht in einem parallelen BI-Tool isoliert.
Delta Sharing Inbound und Iceberg-Föderation bedeuten beide null Lift-and-Shift – bestehende Data Lakes bleiben an Ort und Stelle und werden zu Catalog-Objekten statt zu Migrationszielen.
Snowflake-Föderation führt Live-Abfragen aus, bei denen die Rechenleistung auf Quellsystemseite verbraucht wird – keine Kopie, keine doppelten Speicherkosten, aber die Last auf dem Quellsystem muss berücksichtigt werden.

Kernpunkte

Vier Muster: Delta Share ein/aus · Iceberg-Föderation · Snowflake-Föderation · Databricks-außerhalb.
Föderierte Objekte sind vollwertige Catalog-Bürger – DAC, Lineage und Data Products gelten für sie.
Der Kunde migriert Nicht-SAP-Daten nicht, sondern föderiert sie – BDC wird zum semantischen und Governance-Hub.
Föderationskosten fallen als Rechenleistung auf Quellsystemseite an (Snowflake Credits, DBU, S3-Reads) – getrennt von den BDC-CU verfolgen.
Hochvolumige Faktdaten nach BDC HANA/Delta replizieren; nur Dimensionen und sich selten ändernde Referenzdaten föderieren.
DAC auf föderierten Objekten greift zum Zeitpunkt des Query-Rewrite, mit denselben 3–5 ms wie bei nativen Objekten.
Schema-Drift wird genauso behandelt wie bei nativen Objekten – die Quell-CI an die BDC Connect REST API anbinden.
Roadmap: BigQuery- und Fabric-OneLake-Föderation in der Preview, tiefere Integration des Polaris-Apache-Katalogs.

Begriffe auf dieser Seite

BDC Connect: Stack-übergreifende Integrationsschicht, die es BDC ermöglicht, aus Nicht-BDC-Quellen zu konsumieren, ohne zu migrieren.
Delta Sharing inbound: Abonnement-Muster – Delta-Tabellen eines externen Anbieters erscheinen als BDC-Catalog-Objekte.
Iceberg federation: Live-Lesezugriff auf Apache-Iceberg-Tabellen aus S3/ADLS/GCS über den Iceberg-Katalog (Glue, Polaris, Unity).
Snowflake federation: Föderiertes SQL-Push-down an ein Snowflake-Warehouse – Live-Abfrage, Rechenleistung wird auf Quellsystemseite verbraucht.
Databricks-outside connector: Verbindungsmuster für Databricks-Workspaces im eigenen Cloud-Konto des Kunden, getrennt vom von BDC verwalteten Databricks.
External-bill attribution: TCO-Modellierung, die Föderationskosten auf dem externen System getrennt vom BDC-CU-Verbrauch nachverfolgt.
Outbound Delta Share: BDC veröffentlicht governte Delta-Tabellen zur Nutzung durch externe Partner – DAC-Regeln werden weitergegeben.
Cross-stack DAC: DAC-Regel, die auf Ebene des BDC-Catalog definiert wird und zum Zeitpunkt des Query-Rewrite auf föderierte externe Objekte angewendet wird.

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.