Veel organisaties ondersteunen hun kritische bedrijfsprocessen met SAP, terwijl ze tegelijkertijd kiezen voor platforms zoals Databricks of Snowflake als hun strategische enterprise data platform. Hierdoor ontstaat een logische behoefte: SAP-data moet onderdeel worden van het bredere datalandschap van de organisatie.
Op het eerste gezicht lijkt dit vooral een connectivity-vraagstuk. In werkelijkheid ontwikkelt het zich steeds meer tot een enterprise-architectuurvraagstuk.
SAP Note 3255746 maakt duidelijk waarom.
SAP’s Operational Data Provisioning (ODP) framework biedt geavanceerde mogelijkheden voor data-extractie, waaronder SAP-specifieke datastructuren en delta processing via de Operational Delta Queue. Deze mogelijkheden zijn aantrekkelijk wanneer grote hoeveelheden SAP-data efficiënt moeten worden gerepliceerd.
SAP stelt echter dat de RFC-modules van de ODP Data Replication API — ODP-RFC — uitsluitend zijn ontworpen voor dataoverdracht tussen SAP-applicaties. Klanten en third-party applicaties mogen ODP-RFC niet gebruiken om data uit SAP ABAP-systemen te extraheren naar niet-SAP-applicaties. In juni 2026 heeft SAP technische maatregelen geïntroduceerd om ongeautoriseerde ODP-RFC-calls te identificeren en te weigeren.
Dit betekent nadrukkelijk niet dat SAP het extraheren van data naar niet-SAP-platforms verbiedt, of dat het gebruik van RFC in algemene zin niet is toegestaan. De beperking heeft specifiek betrekking op deze ODP-RFC-interface.
Organisaties worden hierdoor geconfronteerd met meerdere, onderling samenhangende uitdagingen.
Efficiënte extractie. SAP-data uitlezen is relatief eenvoudig; continu miljarden records extraheren zonder steeds volledige tabellen opnieuw te kopiëren is dat niet. Enterprise-architecturen vereisen betrouwbare delta processing, waarbij tegelijkertijd de belasting van productie-SAP-systemen tot een minimum wordt beperkt.
Business semantics. SAP business objects zijn zelden gelijk aan individuele databasetabellen. Het verplaatsen van ruwe records is daarom iets anders dan het extraheren van betekenisvolle businessdata. Hoe verder de extractie zich verwijdert van SAP’s application-level representaties, hoe meer verantwoordelijkheid bij het externe platform komt te liggen om die semantiek opnieuw te reconstrueren.
Technisch mogelijk versus toegestaan gebruik. Een interface kan technisch toegankelijk zijn zonder dat SAP het gebruik ervan voor een bepaald scenario toestaat. Note 3255746 dwingt architecten daarom om precies te begrijpen hoe een integratieproduct toegang krijgt tot SAP, in plaats van alleen te vragen of het product een “SAP connector” heeft.
Operationeel risico. SAP handhaaft de ODP-RFC-grens inmiddels ook technisch. Een security patch die door een SAP Basis-team wordt geïnstalleerd, kan daardoor gevolgen hebben voor pipelines die door een afzonderlijk cloud data engineering-team worden beheerd.
Uiteindelijk worden organisaties geconfronteerd met een strategisch spanningsveld.
Ze willen SAP-data steeds meer behandelen als onderdeel van hun bredere datalandschap. Tegelijkertijd blijft de toegang tot die data afhankelijk van SAP application semantics, SAP-extractietechnologieën en door SAP gedefinieerde integratiegrenzen.
Het beschikbaar maken van SAP-data op platforms zoals Databricks of Snowflake is daarmee veel meer dan alleen een connector-vraagstuk.
Het is een enterprise-architectuurvraagstuk.
Dit is de eerste blog in een serie waarin we onderzoeken hoe organisaties in de praktijk met deze uitdaging kunnen omgaan. We bekijken de verschillende architectuuropties om SAP-data beschikbaar te maken op niet-SAP-dataplatforms, waaronder SAP Datasphere en SAP Business Data Cloud (BDC), OData-based extraction, SAP Landscape Transformation Replication Server (SLT), third-party CDC- en extractietechnologieën, database-level extraction en andere opkomende oplossingen.
Daarbij kijken we niet alleen naar de vraag of een bepaalde optie technisch in staat is om data te verplaatsen. We vergelijken de verschillende opties vanuit een enterprise-architectuurperspectief: schaalbaarheid en delta capabilities, het behoud van SAP business semantics, de impact op het bronsysteem, operationele complexiteit, kosten, openheid en — steeds belangrijker — de grenzen die SAP stelt aan support en toegestaan gebruik.
Het doel van deze serie is niet om één specifieke technologie naar voren te schuiven, maar om de informatie te bieden die nodig is om een bewuste architectuurkeuze te kunnen maken.