SAP has taken meaningful steps in opening its data to bidrectional sharing across the enteprise, and in decoupling the advanced analytics needed for AI from its ERP upgrade path. During a technical conference last week, the German software giant adopted native support for Apache Iceberg, the open table format, and extended its partnership with Databricks to bring data from legacy ERP systems into its modern cloud analytics platform.
"By putting [a] stake in the ground with Iceberg, we now have SAP moving from a very closed application storage model to an open lakehouse model," said Aaron Rosenbaum, Gartner senior director analyst, referring to the concept which brings together data lakes and warehouses. Also important was the bridge between modern analytics in the cloud and on-prem or hosted legacy systems such as ECC, the ERP system broadly adopted by global companies.
"SAP made a pretty big move in saying we're going to open this up, not just to S/4HANA Cloud [the latest ERP system], but ECC users. That coupling — leveraging of AI, leveraging a lakehouse for AI to the ERP upgrade lifecycle — was a problem," said Rosenbaum. In May this year, SAP bought Dremio, a lakehouse platform built around Apache Iceberg, ending its previous preference for Databricks' Delta Sharing to bring together SAP data products with existing lakehouses bi-directionally.
At SAP's TedEd conference last week, SAP said its Business Data Cloud (BDC) – the "trusted data foundation for SAP Business AI Platform" – would now support native Apache Iceberg and a universal catalog powered by Apache Polaris, "providing an open and governed data foundation for users and [AI agent platform] Joule to consume data." Together with SAP BDC Connect, the new tech policy will support platform interoperability with "zero-copy data sharing" across platforms from Databricks, Snowflake, Google, AWS, and Microsoft.
The system would also continue to support Delta Lake, the alternative open table format from Databricks, SAP said. With the integration of Dremio's SQL query engine, BDC users will also get access to relational databases including SQL Server, MongoDB, Oracle, and PostgreSQL without moving data, the vendor said. During the same conference, Databricks – the lakehouse company born out of an Apache Spark platform – extended its partnership with SAP based on the previously announced SAP Databricks, which embeds the Databricks Data + AI Platform in BDC.
That "expanded scope" promises to make data from SAP applications available for consumption in the SAP Business Data Cloud engine of choice, including SAP Databricks. The vendor said that a manufacturer running finance and supply chain on SAP ECC on-premises, for example, could use SAP Application Data Foundation to bring historic order data into SAP Databricks, combining it with third-party data, and allowing data engineers to build demand-forecasting models on SAP's business semantics, without custom extraction pipelines.
They can keep that work as they move to the cloud, Databricks suggested. This being 2026, the hoped-for output from all of this data engineering is not just business insight, but automated action, by way of AI agents. SAP has its Joule AI assistant and agentic platform, while Databricks has Genie, and the two companies have promised to bring them together.
The increasing openness is good for users who will get more options in plotting a strategy to bring together enterprise data, leaving them pondering over where to put the business context layer, which vendors will no doubt fight to control, Rosenbaum said. "You have the comment that they're going to bring Joule and Genie together in the future. This is pointing to a struggle that's going on throughout enterprises and throughout all the vendors about the context layer.
I don't necessarily see that there's one winner. You do have different points of context within the transaction system and across the whole business, and they have been points of tension. "Lack of single vendor lock-in is important.
It's something that all the customers are struggling with: how do we build these context layers and deliver sort of consistent answers?" SAP's shift in the direction of openness is likely to help users in this struggle, whether they choose to build the context layer within the ERP vendor's data platform using its semantic layer, or outside of it using tools from other vendors – there are plenty of companies offering help for those opening their wallets.
Nonetheless, whichever path users choose, a lot of work lies ahead.
Originally published at theregister.com
