Direkt zum Inhalt

Offenheit der SAP Business Data Cloud

Flugzeug

Was hinter der aktuellen API-Diskussion steckt


Die Diskussion rund um die Offenheit der SAP Business Data Cloud (BDC) und die zukünftige Nutzung von SAP-Schnittstellen sorgt aktuell für erhebliche Aufmerksamkeit im Markt. Auslöser dafür ist unter anderem die SAP-Note 3255746 sowie die angekündigte Anpassung der SAP-API-Policy, die insbesondere das Thema ODP via RFC betrifft – also einen heute weit verbreiteten Mechanismus zur Extraktion größerer Datenmengen aus SAP-Systemen.

In den vergangenen Wochen war das Thema auf Veranstaltungen, in Kundengesprächen und in Fachkreisen stark präsent. Dabei entsteht teilweise der Eindruck, SAP wolle den Zugriff auf Daten grundsätzlich einschränken und Kunden stärker in Richtung eigener Plattformen lenken. Gleichzeitig kommuniziert SAP selbst eine andere Perspektive: mehr Sicherheit, bessere Governance und eine modernere Integrationsarchitektur.

Doch was bedeutet das konkret für Unternehmen? Wie ist die aktuelle Entwicklung einzuordnen? Und welche Auswirkungen ergeben sich tatsächlich für bestehende Data- und Analytics-Landschaften?

Worum geht es bei der SAP-Note?


Im Kern betrifft die Diskussion den Zugriff auf Daten über bestimmte RFC-basierte Schnittstellen. Besonders im Fokus steht dabei ODP via RFC, ein Mechanismus, der heute in vielen ETL-, Analytics- und Integrationsszenarien genutzt wird – häufig auch über Drittanbieter-Lösungen.

Nach aktueller Interpretation betrifft die Änderung nicht nur eine technische Empfehlung, sondern die Zulässigkeit bestimmter ODP-/RFC-basierter Zugriffsmuster für Kunden- und Drittanbieteranwendungen. Unternehmen sollten daher nicht nur technische Alternativen prüfen, sondern auch Compliance, Supportfähigkeit und Vertragslage bewerten.

Hintergrund ist eine neue API-Policy der SAP, die offenbar darauf abzielt, nur noch offiziell freigegebene und kontrollierte Schnittstellen langfristig zu unterstützen.

Wichtig ist die Differenzierung: SAP schaltet Datenzugriff nicht grundsätzlich ab, kanalisiert ihn aber stärker über veröffentlichte APIs, dokumentierte Use Cases und SAP-endorsed Architekturen. Für bestehende Landschaften kann das dennoch erhebliche Auswirkungen haben, wenn sie auf nicht freigegebenen oder nur historisch geduldeten Zugriffspfaden beruhen. Vielmehr verändert sich die Art und Weise, wie dieser Zugriff künftig erfolgen soll.

SAP argumentiert dabei insbesondere mit drei Punkten:

• Stabilität transaktionaler Systeme
• Security-Anforderungen
• Kontrolle und Governance von API-Zugriffen

Vor allem im Kontext von AI- und agentischen Workloads beobachtet SAP offenbar eine massiv steigende Last auf produktiven ERP-Systemen. Gleichzeitig entstehen durch offene Schnittstellen und Open-Source-basierte MCP-Server zusätzliche Sicherheitsrisiken.

Aus SAP-Sicht sind viele der heute genutzten RFC-basierten Mechanismen ursprünglich nicht für diese Art der Nutzung vorgesehen gewesen.

Aus Kundensicht geht es jedoch nicht nur um technische Hygiene, sondern auch um Investitionsschutz, Wahlfreiheit, Tool-Kompatibilität und potenzielle neue Lizenz-/Plattformabhängigkeiten.

Warum die Diskussion aktuell so emotional geführt wird


Die Unsicherheit im Markt entsteht vor allem deshalb, weil viele Unternehmen heute auf etablierte Extraktionsverfahren setzen. Zahlreiche Data-Warehouse-, Analytics- und KI-Szenarien basieren auf genau diesen Zugriffsmöglichkeiten.

Wenn nun Begriffe wie „Security Patch“, „nicht autorisierte Zugriffe“ oder „Blockierung bestimmter Interfaces“ fallen, entsteht schnell die Sorge vor einer strategischen Abschottung.

Gleichzeitig zeigt sich jedoch ein differenzierteres Bild.


SAP kommuniziert deutlich, dass alternative Integrationswege weiterhin bestehen bleiben sollen. Dazu gehören unter anderem:

• OData-basierte APIs
• Event-getriebene Integrationen
• CDC-basierte Verfahren
• SAP Datasphere
• Business Data Cloud
• Zero-Copy-Integration
• Agent-to-Agent-Kommunikation

Damit verändert sich weniger die grundsätzliche Verfügbarkeit von Daten – vielmehr verschiebt sich die bevorzugte Architektur hin zu stärker standardisierten und kontrollierten Integrationsmodellen.

Die strategische Rolle der Business Data Cloud


Parallel zur API-Diskussion wird deutlich, welche strategische Bedeutung die Business Data Cloud künftig einnehmen soll.

In verschiedenen Gesprächen und Veranstaltungen wurde mehrfach betont, dass SAP künftig stärker auf Plattform- und Semantik-orientierte Integrationsszenarien setzt. Besonders relevant ist dabei das Konzept der sogenannten Zero-Copy-Integration.

Die Idee dahinter: Daten sollen nicht mehr zwangsläufig physisch repliziert werden, sondern über standardisierte Zugriffsmodelle und virtuelle Integrationsmechanismen genutzt werden können.

Interessant ist dabei, dass SAP gleichzeitig eine deutlich offenere Partnerstrategie verfolgt als noch vor einigen Jahren. Kooperationen mit Databricks, Microsoft Fabric, Google BigQuery oder Snowflake zeigen, dass die strategische Richtung keineswegs ausschließlich auf einen isolierten SAP-Stack hinausläuft.

Vielmehr entsteht aktuell ein Plattformmodell, in dem SAP versucht, die eigene Business-Semantik und Governance-Schicht stärker zu kontrollieren, während gleichzeitig externe Plattformen integriert werden.

Bedeutet das einen Vendor Lock-in?


Genau an diesem Punkt wird die Diskussion besonders spannend.

Historisch wurde SAP häufig für starke Vendor-Bindung kritisiert. Die aktuelle Entwicklung könnte auf den ersten Blick als weiterer Schritt in diese Richtung interpretiert werden.

Auf der anderen Seite zeigt sich aber auch: SAP ist auf Plattformebene sichtbar offener geworden, insbesondere durch Partnerschaften mit Databricks, Snowflake, Google BigQuery, Microsoft Fabric und weiteren Ökosystempartnern. Diese Offenheit bedeutet jedoch nicht freien, beliebigen Datenzugriff, sondern eine stärkere Standardisierung über SAP-definierte Data Products, Governance-Mechanismen und Zugriffspfade.

Die eigentliche Frage lautet deshalb vermutlich nicht mehr, ob ein Lock-in existiert, sondern wie bewusst Unternehmen ihre Integrations- und Plattformstrategie gestalten.

Denn natürlich entsteht immer eine gewisse Abhängigkeit – sei es durch:

• Datenmodelle
• Integrationslogiken
• Prozesse
• Governance-Strukturen
• oder AI-Architekturen.

Entscheidend wird künftig sein, wie flexibel Unternehmen ihre Datenplattformen orchestrieren und welche Standards sie dabei nutzen.

Welche Auswirkungen ergeben sich konkret für Kunden?


Pauschal lässt sich das nicht für jeden Kunden identisch beantworten, aber im Umfeld verschiedener Integrationsanbieter wird die Situation derzeit eher als evolutionäre Veränderung denn als disruptiver Bruch bewertet. Für sauber dokumentierte Standardintegrationen mag der Handlungsdruck begrenzt sein. Für ODP-/RFC-basierte Drittanbieterstrecken, Eigenentwicklungen und großvolumige Replikationsszenarien sollte jedoch kurzfristig eine technische und lizenzrechtliche Prüfung erfolgen.

Klar ist:

• Bestehende Extraktionsmechanismen müssen überprüft werden.
• Nicht dokumentierte oder nicht freigegebene APIs könnten künftig problematisch werden.
• Standardisierte APIs und moderne Integrationsmuster gewinnen an Bedeutung.

Unternehmen sollten deshalb frühzeitig prüfen:

• Welche Schnittstellen heute genutzt werden
• Welche davon offiziell freigegeben sind
• Wo perspektivisch Migrationen notwendig werden könnten
• und welche Rolle BDC, Datasphere oder Event-Architekturen künftig spielen sollen.

Die eigentliche Dimension: AI, Semantik und Kontrolle


Die technische Diskussion rund um APIs ist letztlich nur ein Teil eines deutlich größeren strategischen Wandels. Im Hintergrund geht es zunehmend um die Frage, wie AI-Systeme künftig auf Unternehmensdaten zugreifen und mit ihnen arbeiten.

SAP betont dabei stark die Bedeutung von Business-Semantik. Die Argumentation lautet vereinfacht:

Ein leistungsfähiges Sprachmodell allein reicht nicht aus, wenn die zugrunde liegenden Unternehmensdaten semantisch nicht korrekt beschrieben sind.

Gerade im Unternehmenskontext seien eindeutige Definitionen, Kontextinformationen und semantische Beziehungen entscheidend, damit AI-Agenten konsistente und verlässliche Ergebnisse liefern.

Damit wird auch verständlich, warum SAP künftig stärker kontrollieren möchte, welche APIs und Datenzugriffe genutzt werden.

Denn wer die semantische Schicht kontrolliert, kontrolliert langfristig auch:

• Governance
• Kontextmodelle
• AI-Agenten
• Datenorchestrierung
• und letztlich die Business-Prozesse selbst.

Unser Fazit


Die aktuelle Diskussion rund um die SAP-API-Policy sollte weder dramatisiert noch unterschätzt werden.

Ja, SAP verändert die Spielregeln für bestimmte Integrationsszenarien. Ja, Unternehmen werden ihre bestehende Datenarchitektur überprüfen müssen. Und ja, die Business Data Cloud wird strategisch klar in den Mittelpunkt gerückt.

Gleichzeitig sprechen viele Entwicklungen gegen eine vollständige Abschottung:

• die Öffnung gegenüber Hyperscalern,
• Partnerschaften mit führenden Datenplattformen,
• moderne Zero-Copy-Ansätze
• sowie neue Event- und AI-basierte Integrationsmodelle.

Die eigentliche Veränderung liegt daher vermutlich weniger im „Ob“ des Datenzugriffs – sondern im „Wie“.

Unternehmen sollten die aktuelle Entwicklung deshalb vor allem als Anlass verstehen, ihre zukünftige Daten- und AI-Strategie bewusst zu gestalten:

• Welche Plattformen sollen zusammenspielen?
• Wo sollen Daten physisch liegen?
• Welche APIs und Standards werden genutzt?
• Und wie bleibt die eigene Architektur langfristig flexibel?

Genau diese Fragen werden in den kommenden Jahren entscheidend dafür sein, wie offen und zukunftsfähig moderne SAP-Datenlandschaften tatsächlich bleiben.

Wenn Sie sich mit diesem Thema beschäftigen, dann laden wir Sie ganz herzlich ein zu unserer SAP BDC Roadshow am 18. Juni in Wien:

SAP Business Data Cloud Roadshow 2026 in Wien