Konzeptkarte

SAP Snowflake Solution Extension — Die dritte Best-in-Class-Runtime

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 SAP Snowflake Solution Extension — Die dritte Best-in-Class-Runtime?

SAP Snowflake Solution Extension ist vollwertiges, ungedrosseltes Snowflake (Cortex AI, Snowpark, 90-tägiges Time Travel), das unter dem einheitlichen SAP-Vertrag verkauft wird — und den 3-6-monatigen Vendor-Onboarding-Zyklus für Kunden abkürzt, die den SAP-Einkaufsprozess bereits durchlaufen haben.

Worum es geht

SAP Snowflake Solution Extension ist die kommerzielle und technische Vereinbarung, mit der SAP die vollständige Snowflake-Plattform als eine von drei „Best-in-Class-Runtimes“ innerhalb der Intelligent-Compute-Schicht in die SAP Business Data Cloud bringt, neben SAP HANA Cloud und SAP Databricks. Um zu verstehen, was das bedeutet, müssen zwei leicht zu vermischende Fragen getrennt werden: was sich kommerziell ändert und was sich technisch ändert — denn die Antwort auf die erste ist erheblich, und die Antwort auf die zweite ist, bewusst, fast nichts.

Kommerziell wickelt ein Kunde, der SAP Snowflake Solution Extension kauft, den Kauf über SAPs eigenes Vertragswerk ab, statt eine separate Snowflake-Vereinbarung auszuhandeln: eine Bestellung, ein Support-Eskalationsweg, eine Sicherheits- und Compliance-Prüfung, bepreist nach SAPs kommerziellen Konditionen statt nach Snowflakes eigener Listenpreis. Für ein Unternehmen, bei dem SAP als strategischer Lieferant Einkauf, Rechtsabteilung und Sicherheitsprüfung bereits durchlaufen hat, verkürzt das einen sonst mehrmonatigen Vendor-Onboarding-Zyklus für eine völlig separate Plattform zu einer Erweiterung einer bestehenden, bereits genehmigten Beziehung. Technisch wird durch die SAP-Hülle so gut wie nichts an Snowflake selbst gedrosselt oder abgespeckt: Der Kunde erhält die volle Cortex-AI-Oberfläche — Text-to-SQL, Document AI, Modell-Fine-Tuning und -Serving —, die volle Data-Sharing-Fähigkeit über den Snowflake Marketplace und Cross-Cloud-Shares einschließlich Data Clean Rooms, Time Travel für Point-in-Time-Recovery, Snowpark zum Ausführen von Python-, Java- oder Scala-Compute innerhalb des Warehouse sowie Dynamic Tables für Streaming-Transformationen. Nichts davon ist SAP-spezifisches Tooling als Ersatz für das Original; es ist echtes Snowflake.

Warum es zählt

Der kommerzielle Mechanismus ist konkret: eine Bestellung, ein Support-Eskalationsweg, eine Sicherheitsprüfung, bepreist nach SAPs Rahmenwerk, nicht nach Snowflakes Listenpreis.
Auf der technischen Oberfläche ist nichts gedrosselt — Cortex AI, Data Sharing, 90-tägiges Time Travel (EE), Snowpark und Dynamic Tables sind vollständiges Snowflake, was zählt, weil der Pitch auf Beschaffungsgeschwindigkeit zielt, nicht auf ein Feature-Paritätsrisiko.
Die Passungsregel ist explizit: pitchen bei Kunden mit bestehendem Snowflake-Bestand, die zusätzlich die SAP-native Semantikschicht (Datasphere + SAC) darüber wollen — nicht bei Greenfield-Kunden, die stattdessen eine einzelne Intelligent-Compute-Runtime wählen sollten.

Kernpunkte

Dritte Best-in-Class-Intelligent-Compute-Runtime unter der BDC, neben SAP HANA Cloud + SAP Databricks — jede für ein anderes Workload-Muster optimiert.
„Solution Extension“ = von SAP weiterverkauft, von Snowflake technisch betrieben: eine Bestellung, ein Support, eine Sicherheitsprüfung unter SAPs Vertragswerk.
Volle Snowflake-Feature-Oberfläche — Cortex AI (Text-to-SQL, Document AI, LLM-Serving), Data Sharing, Time Travel bis zu 90 Tagen (EE), Snowpark (Python/Java/Scala), Dynamic Tables.
HANA Cloud gewinnt bei Sub-Sekunden-In-Memory-S/4-Analytics; Databricks gewinnt bei Spark+ML-Engineering; Snowflake gewinnt bei elastischem Cloud-Warehouse + Cross-Cloud-Data-Sharing.
Nur pitchen, wenn der Kunde einen bestehenden Snowflake-Bestand hat, den er nicht ablösen will, UND zusätzlich die Datasphere + SAC-Semantikschicht darüber möchte; nicht bei Greenfield-Kunden pitchen.
Die Solution Extension verkürzt den 3-6-monatigen Vendor-Onboarding-Zyklus bei Kunden, bei denen SAP bereits genehmigter Lieferant ist.
Snowflakes Data Sharing und Clean Rooms ermöglichen Multi-Party-Analytics (z. B. Händler + Lieferant), die weder HANA Cloud noch Databricks nativ erreichen.
Die Storage/Compute-Trennung in Snowflake ermöglicht elastische Kostenskalierung — relevant für Workloads mit stoßweiser Query-Nachfrage (Monatsabschluss-Reporting, saisonaler Handel).
Dynamic Tables in Snowflake bieten deklarative Streaming-Transformation — das Databricks-Äquivalent ist Structured Streaming, das mehr Engineering-Aufwand erfordert.
Cortex AIs Text-to-SQL arbeitet über Snowflakes eigenen Schemakontext; um es in SAP-Semantik zu verankern, ist die Datasphere-Virtual-Layer erforderlich — die Architektur erfordert das Zusammenspiel beider Produkte.

Begriffe auf dieser Seite

Solution Extension: Ein SAP-Kommerzmodell, bei dem ein Drittprodukt (Databricks, Snowflake) unter SAPs Vertragswerk weiterverkauft, aber technisch vom zugrunde liegenden Anbieter betrieben wird; der Kunde erhält Single-Vendor-Beschaffung und die volle Feature-Oberfläche des Drittprodukts.
Intelligent Compute: Die Compute-Schicht innerhalb des Knowledge Core der BDC — beherbergt HANA Cloud (In-Memory-OLAP), Databricks (Spark+ML), Snowflake (Cloud-Warehouse + Sharing) sowie AI-Database- und Data-Warehouse-Bausteine; jede Runtime ist zweckoptimiert, nicht austauschbar.
Snowflake Cortex AI: Snowflakes native KI-Servicelayer — umfasst Text-to-SQL (SQL-Generierung aus natürlicher Sprache), Document AI (Zusammenfassung, Extraktion), LLM-Fine-Tuning und Model-Serving; innerhalb von SAP Snowflake Solution Extension vollständig zugänglich.
Snowpark: Snowflakes Compute-Framework zum Ausführen von Python-, Java- und Scala-Code direkt im Warehouse, das Data-Engineering- und ML-Workflows ermöglicht, ohne Daten in einen externen Compute-Cluster zu verschieben.
Dynamic Tables: Snowflakes deklaratives Feature für Streaming-Transformationen — man definiert die SQL-Logik der Zieltabelle; Snowflake aktualisiert sie fortlaufend, sobald sich die Quelldaten ändern. Geringerer Engineering-Aufwand als Databricks Structured Streaming für Standard-ELT-Muster.
Data Clean Room: Eine governte Snowflake-Umgebung, in der zwei Parteien gemeinsame Analytics über ihre kombinierten Datensätze ausführen können, ohne dass eine Partei die Rohdaten der anderen sieht — ermöglicht Händler+Lieferant-, Pharma+Versicherer- oder Bank+Partner-Analytics unter Datenschutzauflagen.
Storage/Compute-Trennung: Snowflakes Architekturmuster, bei dem Storage (S3/Azure Blob/GCS) unabhängig von Compute (virtuelle Warehouses) abgerechnet wird; Compute kann im Leerlauf auf null herunterskalieren und parallel auf mehrere Warehouses hochskalieren — das ermöglicht elastisches Kostenmanagement für stoßweise Workloads.
Best-in-Class-Runtime: Eine zweckgebaute Compute-Engine, optimiert für ein bestimmtes Datenverarbeitungsmuster: HANA Cloud für In-Memory-Analytics, Databricks für Spark + ML, Snowflake für Cloud-Warehouse + Cortex AI + Data Sharing.

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 →