For years, SAP’s data strategy focused on rewarding customers who centralized their data on SAP. But as enterprises have scattered their data across disparate systems and hyperscalers, that pitch has grown harder to sustain.
With SAP Business Data Cloud (BDC), SAP has made a strategic pivot: rather than insisting customers conform, SAP will meet them wherever their data already lives. The BDC Connect service, announced at SAP Connect, enables bidirectional, zero-copy sharing of data products between SAP BDC and partner systems; already, announcements this year that key partners including Databricks, Google Cloud, Microsoft, and Snowflake will adopt SAP BDC Connect have underscored how serious that commitment is.
As President and Chief Product Officer of SAP Data & Analytics, Irfan Khan owns the portfolio spanning SAP HANA Cloud, SAP Analytics Cloud and SAP BDC. In this role, Khan sits at the intersection of SAP’s legacy strengths and its agentic AI ambitions, where the value of intelligent applications depends entirely on the business-contextualized data beneath them.
Khan spoke with ASUG about BDC’s rapid evolution, the principle of openness reshaping SAP’s platform strategy, and why data architects may be the most critical hires enterprises make in the AI era.
This interview, conducted at the SAP Connect conference, has been edited and condensed for length and clarity.
Though it was first announced only months ago, SAP Business Data Cloud has already become a central solution in terms of bringing together lines of business, furthering the vision for a unified business data fabric, and fueling the agentic-AI innovations that dominated SAP’s announcements this year. How have you seen BDC develop in terms of its importance within SAP strategy?
At SAP Connect, you saw every presentation start off with this idea of the “flywheel”: apps, data, AI. If we go back 18 to 24 months before SAP Business Data Cloud, we had SAP Business Technology Platform (BTP) — which is still a significant part of the SAP tech stack but used more as a technology foundation. There was an opportunity to start showing that SAP has a foundation in data and in data management that allows us to harmonize SAP data.
That’s not a trivial problem. If you know, you know. If you look at the core ERP, it has its hallmarks — a very technical heritage with hundreds, if not thousands, of objects with terse, unreadable names. It’s almost chaotic to make sense of that data model, particularly if you want to use it in a precise way to get to some business outcome.
This is where BTP and the ability to abstract complexity came into play. But customers would be heavily reliant on ecosystem partners. As you know, there was a rule of six: if you spent one euro on SAP, you’d probably spend six on the ecosystem, typically with consultants and service folks who gave you support. Many customers have built huge investments in their own SAP back-office teams.
What’s happened now, with SAP BDC, is that this has evolved toward supporting SAP strategy—that flywheel— as well as how AI takes value from SAP’s data harmonization layer. BDC has been in the market since April. We’ve worked diligently on building out data products covering the entire breadth of the business suite. Our goal by H1 next year is to have almost 100% mapping of all primary data products available within BDC.
By virtue of them being in BDC, you can bring AI over the top; you can hydrate data products into a knowledge graph, build a foundation model for SAP, and build the tabular data model — with highly curated data, driven by accuracy and precision, always coming from the back-end systems that have been very difficult to access in the past.
One historical issue SAP has faced—and that we regularly hear about from ASUG members—involves integration between SAP applications, as well as between SAP and third-party applications. Tell me about SAP BDC in terms of overcoming that issue.
There are three key aspects. First, there’s our acknowledgement that SAP customers have huge investments in different data tools—such as Databricks, Google BigQuery, hyperscalers, and best-of-breeds—and we have to meet them where they’ve invested.
Second, when you integrate at the technical level, it doesn’t always give you what you desire. The technical integration is relatively easy. “Here’s a server or database, I need to build a connection or pipeline” — that’s straightforward. But the shape and format of that data is often not relevant to the system you’re consolidating into.
We’re looking at BDC to deal with zero-copy sharing, popularized by Databricks and Snowflake. You copy data into BDC, it persists there, then we share those data products via BDC Connect. We have BDC Connect with Google Cloud Platform BigQuery and Databricks. In time, we’ll add a comprehensive number of BDC Connects addressing integration to other data venues. [A/N: Since this interview took place, SAP and Snowflake announced the SAP Snowflake solution extension for SAP BDC, and SAP and Microsoft announced SAP BDC Connect for Microsoft Fabric.]
By providing data product sharing bidirectionally, we’ve accelerated integration enormously. I can be on a Databricks cluster where 90% of my enterprise data sits. I don’t need to keep copying SAP data into that environment. I can share it, almost like an old-school network drive. You give an endpoint, and the endpoint is what’s advertised to the consumer, and they can share and participate in the data products SAP has been building out.
Why were Google BigQuery and Databricks specifically the first partners announced?
Databricks has an amazing data platform used by data scientists and data engineers. The AI and machine learning tooling is very commonly used. They have Jupyter Notebook — the best friend of a data scientist. It makes sense for us to have that as a first-party service, hence SAP Databricks. SAP Databricks is SAP data. But what about non-SAP data?
That’s where BDC Partner Connect comes in — a software development kit (SDK) we give partners, who use APIs for integration between catalogs. Databricks uses Unity catalog; if we do interoperability between Unity catalogs, anything in our catalog will be visible on the other side. Say I’ve got my Jupyter Notebook, and I want to find SAP data; I look at what data products are available and can immediately start using them without an IT-driven project to find, extract, format, and transform. Immediate productivity gains.
Because of our first-party service with Google, we already had integration via Datasphere. That’s why BigQuery came next. By the midpoint of next year, we’ll have a full roster of hyperscaler tech stacks and best-of-breeds through BDC Connect.
This reflects a more open approach to the data ecosystem than SAP has committed to this past year. What could you share about that underlying principle of openness that’s characterizing SAP’s approach?
SAP has been open on infrastructure — essentially multi-cloud. Pick your cloud service provider, and we’ve supported them. BTP was deployed everywhere across hyperscalers. Where we had more friction was the data foundation. 15-odd years ago, when SAP introduced HANA, it was a revolutionary in-memory compute engine. To get performance and scale, you bring data to HANA. That was a gravitational pull towards SAP primary persistence.
Whilst 60,000–70,000 customers have HANA as a critical foundation, we recognize customer archetypes are going with modern lakehouse design — storage tier and compute tier. You see the rise of Databricks, Snowflake, and hyperscalers with substantial object storage like Amazon S3.
SAP has accepted that reality. You could naively assume that, if you build the best runtime, they’ll come. Or you accept that the strategy needs to be more open. We’ve chosen the latter. It doesn’t mean we’ve given up on HANA; we have an amazing compute engine. You can run primary persistence on object storage with HANA Cloud. HANA participates in Business Data Cloud because it can consume data products. You can build primary data products using BTP CAP, the Cloud Application Programming model.
Working with different partners has given us the means to support the customer journey and meet them wherever their gravity resides, supporting their needs for growth wherever it may be, on their timeline.
That idea of "centers of gravity" makes me think about SAP's intelligent applications based in specific business areas. What can you tell me about the intelligent applications rising out of this BDC agentic capability?
Intelligent applications are cross-functional by definition. A use case touching supply chain, core ERP, and procurement assumes SAP has done the necessary integration. Business Data Cloud identifies primary data products harmonized within SAP’s one domain model. The intelligent app consumes that one domain model, accessing all data horizontally.
Now, you can bring in agentic assistants, like a receivables assistant. The agentic movement is also consuming primary data products. You’re dealing with highly curated, business-contextual data, not raw data that an agent has to somehow make sense of. This is the key differentiation.
There are a number of data clouds out there. I think you’ll find no other called Business Data Cloud. Why? Because we hydrate it with business-harmonized, concentric data.
Why is SAP such a particular leader in tabular data? We've seen lots of progress in this area this year.
The shape and breadth of our data. Salesforce has commerce, sales, and marketing data. What about manufacturing? GL data? There’s a shortage of business context in that subset.
SAP’s data is highly structured. But we also need to interpret external signals. Tabular data doesn’t mean just structured SAP data — we influence that data with other signals. In a retail application checking stock replenishment, you need to combine data sets. Foundational models are good for analytical workloads, but you also have transactional workloads. That’s how we bring the two together. [A/N: After this interview took place, SAP additionally unveiled its first relational foundation model, SAP-RPT-1, specifically designed for tabular business data.]
When you refer to signals, is that semantic context?
It’s more than that. If you’re doing a credit score for a customer in a default scenario, you’d go to Moody’s for credit score data—that’s a signal—and enrich your data with it. Signal doesn’t mean just internal. It could be external, like a supply chain disruption.
Many in the ASUG audience are moving from on-prem to cloud, still in the midst of their SAP S/4HANA Cloud journeys. With all this momentum from SAP Business Data Cloud, do you already see data architects becoming more central in guiding business transformation?
Without hesitation, if you’re a data architect today, you will have no shortage of work. There is an incredible amount of effort and time that customers still have to put in. Think about master data. You need to know: Where is your customer master? Supplier master? Inventory master? You can have multiple definitions that don’t align, so you cannot assume a well-aligned data strategy.
It’s almost as if you have to acknowledge: I’m a customer with a significant amount of enterprise data, but I haven’t got my data strategy organized well. Data architects will play a pivotal role in defining that strategy — what tech stack is necessary, integration points, networking, data protection, privacy, and authorizations. Data architects and enterprise architects will need to work hand in glove to support these requirements.
Do enterprise customers typically have appointed data architects, or is that more a capability than a job title?
Most enterprise architects have a strong data bias, but that doesn’t mean 100% overlap with a data architect. Progressive customers invest in data teams — chief data officer, chief data architect. The forward-looking ones are thinking about a chief AI officer role to own the data strategy, because those two things are incredibly linked. No reliable AI without reliable data. That’s where we’re seeing convergence of these roles.
Looking ahead to 2026, what capabilities should organizations be thinking about—especially in line-of-business functions like people, finance, or spend—when considering intelligent applications?
The intelligent application is a set of models, data products, and analytical views. In People Intelligence, for example, you’d know workforce composition, headcount, and FTEs needed for growth. There’s a variety of use cases already covered. Beyond that, you get into what-if scenarios and forecasting. We bring Joule in, because Joule answers those open questions using data products and analytical models.
Think of intelligent apps as role-specific and persona-specific, but not two-dimensional. They give you breadth to do many things. Over time, we’ll add more capabilities. As data products expand, we’ll tie more use cases into them. Customers will start using it almost as the equivalent of their Jupyter Notebook. If you’re an HR leader, you go to People Intelligence, and it opens the door to all the KPIs you’d expect given your role.
Independent of that is the agentic world — how orchestrations work within a receivables assistant doing autonomous activity; we see five archetypes of scenarios, from headless AI services to pro-code intelligent applications.