SAP API Disruption

SAP-API-Architektur-Management

Sofern das API-Architektur-Management nicht exakt in das von SAP vorgesehene ERP-Schema passt, gibt es für SAP-Bestandskunden erhebliche Einschränkungen und Restriktionen. Besonders alarmierend ist die Tatsache, dass viele Anwender und Partner in der Vergangenheit aus Mangel an Alternativen auf undokumentierte, aber von SAP lange Zeit geduldete Schnittstellen zurückgreifen mussten. Deren Nutzung wird nun plötzlich vertragswidrig und zerstört funktionierende Geschäftsmodelle.

Open Data Infrastructure Scorecard (ODI) untersuchte kritisch, wie bereitwillig Cloud-Softwareanbieter ihren Kunden den freien Zugriff auf ihre eigenen Unternehmensdaten gewähren. In derartigen Bewertungen schneidet SAP traditionell äußerst schlecht ab, da der Konzern zunehmend proprietäre Barrieren errichtet, den direkten Datenbankzugriff blockiert und performante Schnittstellen für die Datenextraktion durch Drittanbieter gezielt sperrt.

ODI-Scorecard bestätigt dieses Bild schonungslos, da SAP den direkten Weg von S/4 zu externen Data Warehouses wie Microsoft Fabric verbietet, und die effiziente ODP-Schnittstelle (Operational Data Provisioning) für den Massendatenabzug durch Konkurrenten blockiert. Diese restriktive Architekturpolitik zwingt die Kunden de facto dazu, die teuren, SAP-eigenen Integrationswerkzeuge zu nutzen, was dem Grundgedanken einer offenen Dateninfrastruktur diametral entgegensteht und einen knallharten Vendor-Lock-in zementiert.

API-Doktrin für SAP BTP, SAP BDC und SAP Integration Suite

Für SAP-Bestandskunden bedeutet diese restriktive API-Doktrin, dass sie bei der Nutzung der Business Technology Platform (SAP BTP), der Business Data Cloud (SAP BDC oder wie der Anwenderverein DSAG meint: Business Data Complexity) und der SAP Integration Suite äußerste Vorsicht walten lassen müssen. Die Sperrung der direkten Massendatenextraktion zu externen Data Lakes zwingt Anwender in die SAP-Lösungen BDC oder Datasphere, was den Eindruck erweckt, dass SAP eine geschlossene Zollschranke für den digitalen Datenfluss errichtet hat.

Zwar positioniert SAP die BDC vollmundig als offenes Datenökosystem mit Zero-Copy-Technologie über Partner wie Databricks, doch das Kleingedruckte der AGBs offenbart massive Fallstricke, da die Nutzung von SAP-APIs zur Datenextraktion in Nicht-SAP-Software explizit verboten ist, sofern dies nicht ausdrücklich als Funktion der API dokumentiert wurde (siehe auch SAP Digital Access). Kunden müssen bei der Architekturplanung auf der BTP penibel darauf achten, ausschließlich freigegebene Schnittstellen zu orchestrieren, was den Entwicklungsaufwand für individuelle End-to-End-Prozesse drastisch erhöht und die dringend benötigte unternehmerische Agilität massiv bremst (siehe auch SAP-Clean-Core-Konzept).

Betrachtet man die Lizenzen und Lizenzbedingungen für SAP API und SAP BDC kritisch, offenbart sich ein hochgradig toxisches Kommerzmodell zulasten der Bestandskunden. Das von SAP etablierte Digital-Access-Modell sorgt bereits seit Jahren dafür, dass die indirekte Anlage von Belegen durch Drittsysteme teuer bezahlt werden muss, was nun durch die neue API Policy im KI-Zeitalter völlig zu eskalieren droht, wenn autonome KI-Agenten massenhaft Daten lesen und schreiben.

Fair-Use für Business Data Complexity (SAP BDC)

Der Anwenderverein DSAG befürchtet eine schleichende Kommerzialisierung und fordert transparente Fair-Use-Modelle für den API-Zugriff, da sich andernfalls die Kosten für die digitale Transformation ins Unermessliche steigern. Bei der SAP Business Data Cloud (BDC) verbergen sich in den Nutzungsbedingungen zudem eklatante vertragliche Einschränkungen, wie beispielsweise harte Begrenzungen auf lediglich 2000 OData-API-Aufrufe pro Gigabyte Compute-Memory im Monat, was bei jeder Überschreitung unkalkulierbare Zusatzgebühren nach sich ziehen kann.

Zudem stuft SAP wichtige BDC-Connect-Services in die sogenannte Group-2 der Capacity Services ein, wodurch sich der Konzern das Recht vorbehält, diese Dienste mit einer Vorlaufzeit von sechs Monaten ersatzlos zu streichen, was jede langfristige Investitionssicherheit für den Anwender im Bereich Dateninfrastruktur zunichtemacht.

Angesichts dieser Daumenschrauben müssen SAP-Bestandskunden dringend unabhängige Alternativen für das API-Management und die Datenintegration evaluieren. Anstatt sich blind in die Abhängigkeit der SAP BDC und der SAP Integration Suite zu begeben, bieten unabhängige Integration-Platform-as-a-Service-Anbieter (iPaaS) wie Boomi entscheidende Ausweichmöglichkeiten, um APIs flexibel, kosteneffizient und ohne den Zwang zu proprietären Abap-Entwicklungen zu verwalten.

Boomi und JiVS: Alternativen zu SAP BTP und BDC

Boomi ermöglicht es, Daten netzwerkunabhängig in beliebige Cloud-Data-Lakes zu leiten, ohne sich der strikten Datenhegemonie der Walldorfer unterwerfen zu müssen. Für das Management historischer Altdaten und die Bewahrung der Datensouveränität abseits der teuren SAP-Infrastruktur positionieren sich zudem Plattformen wie JiVS von Data Migration International als wertvolle Alternative, um das Erbe der ERP-Ära rechtskonform zu verwalten und den S/4-Kern dauerhaft zu entlasten.

Dennoch bleibt das fundamentale Problem bestehen, dass auch externe Werkzeuge auf die von SAP hart reglementierten APIs angewiesen sind, weshalb alternative Anbieter verstärkt nach kreativen, aber rechtlich abzusichernden Wegen suchen müssen, um die durch SAP gesperrte ODP-Schnittstelle zu kompensieren.

Clean Core als notwendiges Feigenblatt

Soll das SAP-API-Management in einer S/4-Cloud-Umgebung dennoch streng nach der Clean-Core-Doktrin der SAP organisiert werden, erfordert dies einen radikalen organisatorischen und technischen Umbau im Customer Center of Expertise (CCoE) des Bestandskunden. Das CCoE wandelt sich vom reinen operativen Basis-Administrator zur strategischen Governance-Instanz, die jeden API-Aufruf und jede BTP-Erweiterung unerbittlich überwachen muss.

Im Rahmen des strengen Clean-Core-Modells dürfen für Side-by-Side-Erweiterungen auf der BTP ausschließlich Whitelisted APIs (Level A) verwendet werden, die über den SAP Business Accelerator Hub bereitgestellt und zwingend über die SAP Integration Suite orchestriert werden. Jegliche direkte Modifikation oder der unautorisierte Lesezugriff auf interne Datenbanktabellen (Clean-Core-Level C und D) sind strikt verboten.

Diese Clean-Core-Restriktionen erfordern zwingend den Einsatz professioneller Überwachungstools wie SAP Cloud ALM, um die Einhaltung dieser rigiden Vorgaben zu garantieren, sowie den Aufbau völlig neuer Kompetenzen in modernen Programmiermodellen wie CAP (Cloud Application Programming Model) und RAP (RESTful Application Programming Model), um geschäftskritische Logiken zukunftssicher und API-konform auf der BTP abzubilden.

SAP-API-Fazit

Die dringende Empfehlung des deutschsprachigen Anwendervereins DSAG an die Mitglieder und an alle SAP-Bestandskunden lautet daher, der neuen SAP-Politik auf keinen Fall unvorbereitet und unkritisch zu begegnen. Die Interessenvertretung fordert von SAP unverzüglich klare Definitionen, eine vollständige und vertraglich bindende Dokumentation aller betroffenen APIs sowie realistische Übergangsfristen, damit bestehende und hochkomplexe Integrationsmodelle nicht von heute auf morgen kollabieren.

SAP-Bestandskunden wird dringend geraten, bestehende Proof-of-Concepts und KI-Pilotprojekte sofort rechtlich abzusichern und bei anstehenden Vertragsverlängerungen peinlich genau darauf zu achten, dass keine nachträglichen technischen Einschränkungen oder versteckten Kostensteigerungen durch die Hintertür der API-Nutzung akzeptiert werden.

Letztlich ruft DSAG die SAP-Community dazu auf, die eigene digitale Souveränität aktiv zu verteidigen und von SAP die bedingungslose Transparenz über Nutzung, Verbräuche und kommerzielle Konsequenzen der API-Strategie einzufordern, um in dieser riskanten Transformationsphase nicht die vollständige operative Handlungsfähigkeit an den Softwarekonzern zu verlieren.

Die DSAG fordert daher klare Definitionen, eine vollständige Dokumentation der betroffenen APIs und verlässliche Planungssicherheit für Kunden und Partner sowie eine Abbildung in den Verträgen, welche auf Kundenseite eine belastbare Beurteilung der Anwendungsfälle erlaubt. Die entsprechenden Regelungen sollten verständlich und gut nachvollziehbar sein. Zudem dürfen sie nicht zu Kostensteigerungen für Kunden und Partner führen. „Vor dem Hintergrund eines sicheren und stabilen Betriebs ist auch für uns als Anwender wichtig, volle Transparenz über Nutzung, Verbräuche und Konsequenzen zu haben“, sagt Stefan Nogly, DSAG-Technologievorstand.

Kontrollgriff: SAP API Policy

Aus Sicht der DSAG wirft die aktuelle Ausgestaltung der API Policy Fragen auf. Der Umfang der Einschränkungen scheint über das notwendige technische Maß hinauszugehen. Um Innovationsfähigkeit und Planungssicherheit bei Kunden und Partnern langfristig zu sichern, müssen diese offenen Punkte schnellstmöglich in Zusammenarbeit zwischen SAP und DSAG geklärt werden.

Die aktuelle API-Strategie der SAP gleicht bei genauer Betrachtung einem strategischen Kontrollgriff nach der absoluten Datenhoheit, der die Innovationskraft der Bestandskunden massiv bedroht. Mit der im April 2026 verschärften SAP API Policy reglementiert der Walldorfer Softwarekonzern rigoros, unter welchen Bedingungen Kunden und Partner Daten in Drittsysteme übertragen dürfen. Zukünftig sind ausschließlich jene Schnittstellen erlaubt, die im „SAP Business Accelerator Hub“ oder in der offiziellen Produktdokumentation explizit ausgewiesen sind. Die deutschsprachige SAP-Anwendergruppe (DSAG) kritisiert diesen Vorstoß in einer aktuellen Pressemitteilung scharf und bemängelt die fehlende vertragliche Verbindlichkeit dieser Dokumentationen, was die rechtliche und technologische Planungssicherheit der Anwender existenziell gefährdet.