Konzeptkarte

BDC Connect for Snowflake (+ SAP Snowflake Solution Extension)

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 for Snowflake (+ SAP Snowflake Solution Extension)?

Anders als beim OEM-in-BDC-Modell von Databricks bleibt Snowflake eine partnerschaftlich angebundene Architektur — eigenständige kommerzielle Beziehung, Preisgestaltung über Snowflake-Credits, Cortex Analyst/Agents auf Snowflake-Seite —, weshalb Tier-1-Kunden zunehmend beide Plattformen parallel betreiben, statt sich für eine zu entscheiden.

Worum es geht

SAP und Snowflake kündigten am 04.11.2025 zwei parallele Wege an: SAP Snowflake (eine Solution Extension, bei der SAP Snowflake verpackt) und SAP BDC Connect for Snowflake (der bidirektionale Zero-Copy-Kanal). Beide erreichten GA innerhalb des Zielfensters H1 2026: Der BDC-Connect-Zero-Copy-Konnektor erreichte GA am 04.05.2026 (laut Snowflakes eigenen Release Notes), und SAP bestätigte GA für die Solution Extension SAP Snowflake etwa zur gleichen Zeit, nach der Sapphire 2026. Anders als bei Databricks (C166, OEM-innerhalb-BDC) ist Snowflake das kanonische „partnerschaftlich angebundene“ Modell — die kommerzielle Beziehung des Käufers ist dual (SAP + Snowflake), die Preisgestaltung bleibt in Snowflake-Credits (C233), und Cortex Analyst (C175) + Cortex Agents (C176) sitzen auf der Snowflake-Seite der Grenze. Der Kompromiss: Snowflake bringt eine erstklassige Trennung von Speicher und Compute im Warehouse, die Databricks bei reinen BI-Workloads nicht erreicht; Databricks bringt über das OEM-Modell eine tiefere Joule-Integration. Tier-1-Kunden werden 2026 BEIDE betreiben — trilaterale Architektur (C245).

Die Unterscheidung zu C169 ist am Scoping-Tisch wichtig: BDC Connect for Snowflake ist der technische Kanal — der Zero-Copy-, bidirektionale Pfad, der governte Daten zwischen Datasphere und Snowflake bewegt, ohne einen physischen Export/Import-Schritt —, während SAP Snowflake (die Solution Extension) ein separates kommerzielles Vehikel für den Kauf von Snowflake-Kapazität über SAPs eigene Rechnungsstellung und Support ist. Ein Kunde kann den Konnektor übernehmen, ohne jemals Snowflake über SAP zu kaufen, und umgekehrt konfiguriert ein Kunde, der Snowflake über SAP kauft, weiterhin denselben Konnektor für die technische Integration; die beiden Entscheidungen sind unabhängig, und ein Berater sollte es niemals zulassen, dass ein Kunde sie zu einem einzigen Kaufgespräch vermischt.

Warum es zählt

Der Punkt der kommerziellen Unabhängigkeit ist speziell für CFOs wichtig: Die kreditbasierte Abrechnung von Snowflake bleibt von SAP getrennt und vermeidet eine tiefere Single-Vendor-Bindung.
Der genannte Kompromiss ist konkret und überprüfbar: Snowflake gewinnt bei der Trennung von Speicher und Compute für reine BI-Workloads mit hoher Nebenläufigkeit; Databricks gewinnt bei der nativen Joule-Integration über seinen OEM-Status.
Sowohl SAP Snowflake (Solution Extension) als auch BDC Connect for Snowflake (Zero-Copy-Kanal) erreichten GA innerhalb von H1 2026 — der Konnektor am 04.05.2026 laut Snowflakes Release Notes — zwei verwandte, aber getrennte Angebote, die beim Scoping auseinanderzuhalten sind.

Kernpunkte

SAP und Snowflake haben am 4. November 2025 zwei parallele Wege angekündigt: SAP Snowflake (eine Solution Extension) und BDC Connect for Snowflake (den bidirektionalen Zero-Copy-Kanal).
Anders als das OEM-Modell von Databricks innerhalb von BDC bleibt Snowflake partnerverbunden: doppelte Geschäftsbeziehung, Preise in Snowflake-Credits, Cortex Analyst und Agents auf Snowflake-Seite.
Für große Kunden folgt daraus Koexistenz — beide Plattformen nebeneinander — statt einer Entscheidung für eine einzige Plattform.
Den aktuellen GA-Status jedes Wegs in den Release Notes prüfen, bevor ein Liefertermin zugesagt wird; die beiden Wege wurden nicht am selben Tag ausgeliefert.
Der Konnektor ist eine Datenbrücke, keine Modellbrücke — Cortex Analyst und Cortex Agents laufen vollständig auf Snowflake-Seite, nie über SAPs Generative AI Hub.
SAPs Data Access Controls in Datasphere bleiben das einzige Zeilen-/Spalten-Sicherheitsregelwerk, identisch durchgesetzt, egal ob die Abfrage von Snowflake, Databricks oder SAC kommt.
In einer trilateralen Landschaft (SAP + Snowflake + Databricks) nach Workload-Form routen, nicht nach Anbietervorliebe: prozessbewusste Fragen an Joule, deterministische deklarierte Kennzahlen an Cortex Analyst, ML-Trainings-förmige Arbeit an Databricks.
Ein explizites Register veröffentlichen, welches System die Definition welcher Kennzahl besitzt, bevor drei KI-Oberflächen über demselben Geschäft laufen — die Konnektoren machen Koexistenz technisch möglich, lösen aber keine semantischen Konflikte.

Begriffe auf dieser Seite

Partnerverbundenes Modell: SAPs kommerzielles Muster für Snowflake, im Unterschied zum OEM-in-BDC-Modell von Databricks: Der Kunde hält zwei getrennte Geschäftsbeziehungen (SAP und Snowflake) statt eines gebündelten Vertrags.
Trilaterale Architektur: Ein Tier-1-Muster (C245), bei dem SAP, Snowflake und Databricks nebeneinander auf denselben governten Datasphere-Data-Products laufen, jeweils für die Workload-Form, die am besten passt.
Cortex Analyst: Snowflakes native Text-to-SQL-Fähigkeit (C175), governt durch ein formal deklariertes Semantikmodell — die deterministische NL-zu-SQL-Oberfläche auf der Snowflake-Seite eines BDC-Connect-for-Snowflake-Einsatzes.
Cortex Agents: Snowflakes mehrstufige agentische Orchestrierungsschicht (C176), die Cortex Search, Cortex Analyst und SQL/Python-Tasks verkettet — die agentische Oberfläche auf Snowflake-Seite, vollständig getrennt von Joule-Agenten.
Data Access Control (Datasphere): Das Regelwerk von Datasphere für Zeilen- und Spaltensicherheit auf Katalogebene, identisch durchgesetzt auf einem geteilten Data Product, unabhängig davon, ob die lesende Plattform Snowflake, Databricks oder SAP-eigenes SAC ist.
Kennzahl-Eigentumsregister: Ein explizites, veröffentlichtes Dokument, das benennt, welche Semantikschicht welches Systems für jede Geschäftskennzahl maßgeblich ist, gepflegt im gleichen Takt, in dem sich die Kennzahldefinition ändert — die praktische Lösung für plattformübergreifende Zahlenabweichungen.

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.