SAP zu BigQuery: Datenbrücke mit Architekturfolgen

SAP Business Data Cloud Connect für Google BigQuery steht laut SAP Architecture Center im zweiten Quartal 2026 als allgemein verfügbar. Für viele DACH-Unternehmen entfällt damit der Umbau über fragile ETL-Ketten. Cloud-Architekten und IT-Leitung brauchen eine Einordnung, was sich an Latenz, Governance, Lizenzlogik und Betriebsmodell ändert und wo Multi-Cloud-Risiken neu entstehen. Die GA-Einordnung greift in die Architekturentscheidungen bestehender SAP-Landschaften ein.

Das Wichtigste in Kürze

Verwandt:AWS und Google Cloud: Multi-Cloud ohne Umwege nutzen  /  Hybrid Cloud: So treibt Multi-Cloud den Mittelstand voran

Was die GA-Ankündigung für bestehende SAP-Landschaften bedeutet

Laut dem SAP-Community-Blog zur General Availability von Business Data Cloud Connect für Google BigQuery stellt SAP einen produktseitig gestützten, bidirektionalen Zero-Copy-Pfad bereit: Organisationen greifen auf freigegebene SAP-Datenprodukte (Tabellen, Metadaten und fachliche Semantik) direkt in BigQuery zu und können Google-Datenprodukte zurück in SAP BDC veröffentlichen. Die Daten bleiben im jeweiligen Quellkontext; Teams kopieren sie nicht über manuell orchestrierte Extrakte, Transformationsjobs und Staging-Tabellen. Das SAP Architecture Center verortet die GA im zweiten Quartal 2026 und beschreibt die Freigabe von Data Products aus SAP-Line-of-Business-Anwendungen, die über geregelten Zugriff in BigQuery und im Google-Knowledge- bzw. Dataplex-Katalog auffindbar werden.

Zum GA-Zeitpunkt läuft Connect für BDC-Deployments auf AWS und Google Cloud Platform; Azure steht laut demselben Blog auf der Roadmap. Die Einrichtung verlangt laut SAP-GA-Anleitung auf BigQuery-Seite Enterprise Plus inklusive Reservation und auf SAP-Seite die Provisionierung einer Connect-Instanz in SAP for Me. Die Vertrauensbeziehung entsteht über mTLS und OpenID Connect. Data Stewards teilen anschließend Katalogobjekte; der Zugriff in BigQuery folgt den Standard-IAM-Rechten auf dem Lakehouse-Katalog.

Für Bestandsinstallationen mit ECC-Restbeständen, S/4HANA on-prem und S/4HANA Cloud ändert sich vor allem die Planungslogik. Teams entscheiden, welche Domänen den SAP-nahen Connect-Pfad nutzen und welche weiter über klassische Integration laufen; ob Daten in die Analytics-Cloud kommen, ist nur noch die Vorfrage. Wer heute BW/4HANA, Datasphere oder selbst gebaute Replikationsstrecken betreibt, muss die Überlappung klären. Doppelte Pipelines erzeugen sonst Kosten und widersprüchliche Kennzahlen. Connect transportiert freigegebene BDC-Datenprodukte und lässt beliebige Roh-Tabellen aus ECC aus; Primary Data Products stammen typischerweise aus Anwendungen wie S/4HANA, SuccessFactors oder Ariba, Custom Products können unter anderem über den BW Data Product Generator entstehen.

Rechtlich und vertraglich greifen zwei Welten parallel: SAP-Nutzungsrechte und Kapazitätsmodell von Business Data Cloud einerseits, Google-Cloud-Nutzungsbedingungen und BigQuery-Abrechnung andererseits. SAP lizenziert BDC als SaaS-Abonnement über Capacity Units; der Listenpreis steht auf Anfrage. Verbindliche Regelungen zu indirekter Nutzung und zur Hyperscaler-Weitergabe im Connect-Kontext stehen in den frei einsehbaren Materialien nicht als detaillierte Vertragstexte. Sie ergeben sich aus dem individuellen Vertragspaket und sind vor dem produktiven Einsatz mit Legal, Procurement und dem SAP-Account-Team zu klären.

Architekturvarianten: direkt verbinden, entkoppeln oder hybrid belassen

Die direkte Variante bindet freigegebene SAP-Datenprodukte möglichst nah an BigQuery und lässt Downstream-Teams dort modellieren. Sie verkürzt die Integrationskette und reduziert fehleranfällige Zwischenformate. Gleichzeitig steigt die Abhängigkeit von der semantischen Abbildung und den Freigaberhythmen des Herstellers. Änderungen an SAP-Objekten wirken dann schneller in Analytics- und KI-Workloads.

Die entkoppelte Variante behält ein eigenes Landing- und Kurationsschichtmodell, etwa in einem unternehmensweiten Lakehouse oder Data Mesh. Connect liefert Domänendaten, Ownership und Qualitätsregeln bleiben aber in der eigenen Plattform. Der Betriebsaufwand steigt, dafür steuern Architekturteams Schema-Evolution und Verbraucher-SLAs selbst.

Hybrid ist in DACH-Enterprise-Landschaften der realistische Default. Kernprozesse und regulatorisch sensible Domänen bleiben enger an SAP und kontrollierte Replikation gebunden. Explorative Analytics, Feature Stores und domänenfremde BI-Teams arbeiten in BigQuery. Entscheidend ist eine dokumentierte Schnittstellenlandkarte: Welches System ist System of Record, welches System of Analytics und wo endet die Garantie der Quelle?

Datenhoheit, IAM und Audit-Trails über die Cloud-Grenze

Sobald SAP-Daten in Analytics- und KI-Pfaden von BigQuery ankommen, gilt die Verantwortung entlang der gesamten Kette. Speicherort, Verschlüsselung, Schlüsselverwaltung und Zugriffspfad müssen dem eigenen Governance-Modell entsprechen. Laut dem SAP-Security-FAQ zu Business Data Cloud wählen Kunden die Region beim Provisioning; kundendatenhaltende Komponenten inklusive Backups und DR-Ressourcen bleiben in der gewählten Region (Beispiele in der Doku: EU10, JP10, US10). BigQuery speichert Datasets in gewählten Single- oder Multi-Regionen, darunter EU-relevante Standorte wie Frankfurt (europe-west3), Belgien, Niederlande oder die Multi-Region eu. Google verschlüsselt Daten standardmäßig at rest; Kunden können zusätzlich Customer-Managed Encryption Keys (CMEK) über Cloud KMS und bei Bedarf Cloud External Key Manager einsetzen. Assured Workloads mit EU-Data-Boundary ergänzen Residenz- und Personalzugriffskontrollen, wo das Governance-Modell das verlangt.

Weil Connect über Delta Sharing und federierte Kataloge arbeitet, bewegen Teams Daten oft nicht physisch in ein BigQuery-Storage-Bucket. Sie müssen trotzdem klären, welche Query-Ergebnisse, Materialisierungen und Downstream-Exports wo landen und welche Unterauftragsverarbeiter berührt werden.

IAM wird zur Schnittstellenfrage. SAP-Berechtigungen und Google Cloud IAM sind unterschiedliche Modelle. Wer fachliche Sichtbarkeiten aus dem ERP 1:1 erwartet, unterschätzt die Neumodellierung von Rollen, Service Accounts und Datenfreigaben. Laut GA-Blog steuert Google Cloud IAM den Zugriff auf freigegebene SAP-Daten im Katalog. Ohne saubere Trennung von technischen Integrationsidentitäten und fachlichen Leserechten entstehen überprivilegierte Pfade, die Audits nur schwer erklären.

Audit-Trails müssen Cloud-Grenzen überstehen. Extraktion bzw. Share, Transformation, Query und Downstream-Export brauchen korrelierbare Protokolle mit nachvollziehbaren Zeitstempeln und Akteuren. BigQuery erzeugt Admin-Activity- und Data-Access-Audit-Logs; Data-Access-Logs sind für BigQuery standardmäßig aktiv. Google Cloud hält eine C5:2020-Attestierung inklusive BigQuery und veröffentlicht Orientierung zu NIS2-Anforderungen an Lieferanten und Dienstleister. SAP BDC protokolliert laut Herstellerangaben sicherheitsrelevante Aktivitäten wie Rollenänderungen und Katalogadministration. Ein fertiges, produktübergreifendes Kontroll-Mapping von NIS2, C5 und branchenspezifischen Vorgaben auf Connect- und BigQuery-Logging liefert kein Herstellerdokument. Architektur- und Compliance-Teams übersetzen die Anbieterkontrollen in die eigene Matrix und testen sie.

FinOps: Abfragekosten, Speicher und versteckte Netzwerkpfade

Connect verschiebt Kostenstrukturen. Weniger ETL-Infrastruktur heißt nicht automatisch weniger Gesamtaufwand. BigQuery rechnet über Speicher und Abfragevolumen ab. Die offizielle Preisseite trennt Compute und Storage: On-Demand misst gescannten Datenumfang (die ersten 1 TiB pro Monat und Konto sind kostenfrei), Capacity rechnet Slot-Stunden in den Editions Standard, Enterprise und Enterprise Plus ab. Für Abfragen gegen die SAP-BDC-Instanz verlangt die SAP-GA-Anleitung Enterprise Plus mit Reservation. Storage unterscheidet Active und Long-term (nach 90 Tagen ohne Änderung ungefähr halb so teuer) sowie logische und physische Abrechnung. Google veröffentlicht Listenpreise regional, unter anderem für EU-Standorte; bei Abrechnung in Euro gelten die EUR-Positionen der Cloud-Platform-SKUs.

Auf SAP-Seite kaufen Organisationen Capacity Units im Abonnement. Zusätzliche Connect-seitige Verbrauchskomponenten (etwa Inter-Region-Transfer oder API-Verarbeitung) können je nach Vertrags- und Preismodell Capacity Units verbrauchen; verbindliche Euro-Stückpreise sind öffentlich nur als Anfragepreis dokumentiert. Explorative Analysen, breite Joins und unkontrollierte Self-Service-Queries treiben die Rechnung, auch wenn die Datenbrücke technisch schlank wirkt.

Netzwerkpfade sind der unsichtbare Posten. Replikation, Delta-Loads, Cross-Region-Traffic und Private-Connectivity-Optionen erzeugen laufende Kosten und Latenzprofile, die in PoCs oft fehlen. Wer SAP-Workloads und BigQuery in unterschiedlichen Regionen oder über getrennte Netzsegmente betreibt, braucht eine belastbare Kostenprognose inklusive Peak-Lasten am Monats- und Quartalsende.

FinOps braucht Ownership. Ohne Budget-Zuordnung auf Domänenteams, Query-Guardrails und Speicher-Lifecycle-Regeln wird die neue Brücke zur gemeinsamen Kostenstelle ohne Steuerungshebel. Sinnvoll sind Verbrauchsreports pro Domäne, Quotas für teure Scan-Muster und klare Regeln, welche Daten in BigQuery materialisiert und welche nur bei Bedarf gelesen werden.

Integrationsrisiken bei Analytics, KI und nachgelagerten Domänen

Analytics lebt von stabilen Definitionen. Wenn Kennzahlen parallel in SAP-Semantik und in BigQuery-Modellen existieren, entsteht Drift. Besonders riskant sind abgeleitete KPIs, die in Dashboards und Management-Reports als „eine Wahrheit“ erscheinen, aber unterschiedliche Aktualitätsfenster und Filterlogiken nutzen. Eine Domänenkatalogisierung mit verbindlichen Definitionen ist Voraussetzung, nicht Nacharbeit.

KI- und ML-Pipelines verschärfen das Problem. Feature Stores und Trainingsdaten brauchen reproduzierbare Schnitte. Wer SAP-Daten ad hoc nach BigQuery zieht und daraus Modelle baut, riskiert schlechte Modellgüte und schwer erklärbare Entscheidungen in regulierten Prozessen. Datenherkunft, Zustimmungslogik und Löschketten müssen bis in Trainingsartefakte nachgezogen werden.

Nachgelagerte Domänen wie CRM-Analytics, Supply-Chain-Steuerung oder Finance-Forecasts hängen oft an stillschweigenden Annahmen über Latenz und Vollständigkeit. Fällt Connect aus oder ändert sich das Objektmapping, brechen Reports und automatisierte Entscheidungen. Betriebsmodelle brauchen daher Fehlerbudgets, Fallback-Pfade und klare Eskalation zwischen SAP-Basis, Data Platform und Fachbereich.

Entscheidungsmatrix: wann Connect sinnvoll ist und wann nicht

Connect ist sinnvoll, wenn BigQuery bereits strategische Analytics- und KI-Plattform ist, SAP die führende Quelle für die betroffenen Domänen bleibt und die Organisation IAM, Katalog und FinOps über Cloud-Grenzen hinweg beherrscht. Dann reduziert die Brücke Integrationsschuld und beschleunigt den Zugriff auf fachlich relevante Objekte.

Connect eignet sich schlechter, wenn die Datenstrategie noch auf ein einziges SAP-nahes Analytics-Zielbild setzt, wenn regulatorische Anforderungen eine eng kontrollierte und einseitig auditierbare Pipeline verlangen oder wenn die Organisation keine Ownership für Multi-Cloud-Kosten und Berechtigungen hat. In diesen Fällen bleibt eine entkoppelte, selbst betriebene Integrationsarchitektur oft transparenter.

Zwischen beiden Polen liegt der Hybridfall mit klarer Domänentrennung. Kritische Ledger- und Meldewesen-Daten bleiben auf streng kontrollierten Pfaden. Explorative und produktnahe Analytics nutzen BigQuery. Jede Domäne braucht einen dokumentierten Entscheid: Quelle, Latenzklasse, Berechtigungsmodell, Kostenverantwortung und Exit-Option.

Für IT-Leitung und Architektur ist die Konsequenz pragmatisch: Die GA-Fähigkeit ersetzt keine Zielbildentscheidung. Sie erzwingt eine Neubewertung von Integrationsmustern, Governance und Betriebsverantwortung. Wer Connect einführt, sollte parallel Besitz an Semantik, Kosten und Audit über die Cloud-Grenze hinweg festlegen. Ohne diese drei Anker bleibt die Datenbrücke technisch elegant und organisatorisch teuer.

Häufige Fragen

Bildquelle: KI-generiert (Juli 2026)