The BDC Revolution – What Developers & Consultants Should Know

If you’ve been working in the SAP ecosystem for the past decade, you’ve likely spent countless hours doing the same thing: extracting data from SAP systems, meticulously reconstructing business context that was already there, and building integration layers to make sense of it all. It’s been the unspoken tax of enterprise development: necessary, time-consuming, and frustratingly repetitive.

That era is ending!

At SAP TechEd 2025, the announcements around SAP Business Data Cloud (BDC) marked a fundamental architectural shift in how we build on SAP platforms. SAP is finally embracing what developers have been asking for: openness, flexibility, and the freedom to use the tools and languages we already know.

SAP is moving from a “move all your data to one place” model to a “federate your metadata and keep data where it lives” approach. For developers and consultants, this translates to faster project delivery, less data plumbing, and more time building solutions that actually matter.

I had the opportunity to sit down with Daniel Yu, Chief Marketing Officer of SAP BDC, to discuss what the BDC revolution means for the technical community. 

Watch the full interview.

Here’s a breakdown of the key announcements and how you can leverage them for your daily work. 

1. SAP Snowflake: A SolEx Partnership Expanding Compute Choices

SAP announced a SolEx (Solution Extension) partnership with Snowflake, introducing SAP Snowflake as an endorsed and SAP-sold extension to BDC. This joins the existing OEM integration with Databricks and Google Cloud to create three major compute options for SAP customers.

What’s a SolEx?

For developers unfamiliar with the term, a SolEx (Solution Extension) is a third-party software solution that SAP endorses, sells, and supports as part of its portfolio. It’s SAP’s way of bringing best-of-breed technologies into the ecosystem without building everything in-house.

The Technical Details:

The Snowflake integration features bidirectional data product exchange with a zero-copy protocol. This means data stays in its source database (whether SAP Datasphere or Snowflake), but the metadata, catalogue information, and data sets become discoverable across both platforms. 

You don’t need expensive data replication or to maintain duplicate copies. Just federated access to the definitions and lineage.

This same bidirectional, zero-copy pattern now extends to all three partnerships: Databricks, Google Cloud, and Snowflake.

What this means for developers:

You’re no longer locked into a single compute engine. If your team has deep expertise in Snowflake’s SQL dialect and ecosystem, you can leverage that within the SAP environment. If you prefer Databricks for its notebook-driven workflows and MLflow integration, that’s available too. The choice becomes about what fits your team’s skills and your project’s requirements, not about what SAP dictates.

More importantly, you can run different workloads on different platforms within the same architecture. Heavy ETL transformations in Databricks. Ad-hoc analytics in Snowflake. Real-time operational queries in HANA Cloud. All federated through a common metadata layer.

2. Data Product Studio: Lifecycle Management for Modern Data Engineering

SAP also introduced Data Product Studio, a new tool designed specifically for the growing community of data engineers working with BDC. It provides visual tooling for combining SAP and non-SAP data products, managing their lifecycle, and exposing them to various consumption layers.

Data Product Studio allows you to:

• Visually combine data products from SAP (like S/4HANA tables, SuccessFactors datasets) and non-SAP sources (your data warehouse, lake house, APIs)
• Create higher-level abstractions and composite data products
• Manage the complete lifecycle: versioning, lineage, governance, access control
• Expose these products to multiple consumption patterns: AI agents, data catalogues, SQL endpoints, or downstream applications

What this means for developers:

You don’t need to write custom Python scripts to stitch together SAP and non-SAP data. Or to maintain brittle ETL pipelines that break every time a schema changes upstream. Data Product Studio shifts you from low-level data plumbing to high-level product thinking.

What makes this powerful is that the business context and semantic layer that live inside SAP applications travel with the data product. For example, SAP already knows that “Customer” in SuccessFactors isn’t the same as “Customer” in S/4HANA, and it keeps that distinction intact. You no longer have to manually rebuild those relationships or transformations yourself.

For data engineers, this is a significant productivity multiplier. You can focus on designing good data products (well-defined interfaces, clear ownership, versioned contracts) rather than the mechanics of moving bytes around.

3. HANA Cloud as the AI Database: MCP Support and Agentic Memory

SAP positioned HANA Cloud as “the AI database,” introducing support for MCP (Model Context Protocol) and agentic memory capabilities. HANA Cloud’s multi-modal compute engine now spans relational, document, graph, and knowledge graph processing; all within a single, shared-everything architecture.

Dan made a compelling point during our conversation. He said the “big data” paradigm is fading. For decades, we built databases around share-nothing architectures; spinning up clusters, dividing and conquering large datasets through distributed processing. That made sense when the goal was to crunch massive volumes of data for predefined analytics.

But AI agents and language models don’t work that way. They need complete context. They need to understand relationships. They need metadata and semantics, not just rows and columns.

HANA Cloud’s approach is fundamentally different: share everything. Keep all context together. Provide multi-modal access (relational queries, graph traversals, document searches, knowledge graphs) within the same engine so that agents can access the full semantic richness of your business data.

With MCP support, HANA Cloud can now serve as the memory layer for AI agents.

Agents can query business context, understand relationships between entities (purchase orders, suppliers, invoices, organisational hierarchies), and maintain long-term memory of interactions and decisions.

You are not just feeding cleaned CSV files into an LLM, you’re giving agents direct access to the living, breathing context of your business operations.

What this means for developers:

If you’re building AI-powered applications on SAP, your architecture just got simpler. You don’t need to build a separate vector database, maintain embeddings pipelines, and write complex orchestration logic to fetch context for your LLM.

HANA Cloud becomes your single source of truth for both operational queries and AI context. Your SQL skills remain valuable, but now you’re also working with graph queries, knowledge graphs, and agent memory patterns.

For developers currently working with traditional SQL views and materialised tables, now is the time to start learning how to model relationships and context. The future of database work is multi-modal.

4. The Business Data Fabric: Federating Metadata, Not Moving Data

One of the most important concepts Daniel emphasised was the shift from centralised data warehousing to a federated data fabric architecture.

The old paradigm said: move everything to one place. Extract data from source systems, load it into a central warehouse or lake, transform it there, and then build analytics on top. This model has dominated enterprise data architecture for 30+ years.

But it never really worked at scale. Data was always spread across multiple systems. Cloud made it worse. Now you have data in multiple SaaS applications, multiple cloud providers, hybrid environments, on-premises systems, APIs, and data lakes. The extraction-reconstruction cycle became unsustainable.

The new paradigm says, keep data where it lives. Federate the metadata, catalogues, definitions, and lineage. Let consumers discover and access data across the fabric without moving it unnecessarily.

This is what the bidirectional integrations with Snowflake, Databricks, and Google enable. This is what Data Product Studio orchestrates. This is the architectural foundation BDC is building.

What this means for developers:

Your projects get faster. Less data movement means fewer pipelines to maintain, fewer failure points, and less data drift between copies. You’re not spending weeks setting up replication jobs before you can even start building features.

Your architectures become more resilient. You’re not maintaining brittle point-to-point integrations. The fabric handles discovery, lineage, and access patterns.

But you need to learn new concepts: data mesh thinking, data product design, catalogue-driven development, and federated query patterns. 

These are the primitives of modern enterprise data architecture.

Why SAP is Opening Up for Non-SAP Technologies

During our conversation, I asked Daniel why SAP is suddenly embracing non-SAP technologies so aggressively. His answer was refreshingly honest.

SAP data has always been difficult to work with for non-SAP developers. It’s not just about accessing tables; there’s deep business context embedded in the applications that doesn’t show up in database schemas. Developers spent decades extracting SAP data and painstakingly reconstructing this context externally to build dashboards, reports, or machine learning models.

This worked (barely) when data lived primarily in SAP systems. But modern enterprises have data everywhere: multiple clouds, SaaS applications with APIs, data warehouses, lake houses, and hybrid environments. Asking development teams to extract and reconstruct context from all these sources is simply not feasible anymore.

Given that, SAP made a conscious decision to open up the ecosystem. Rather than forcing customers to pull data out and rebuild context, SAP is exposing the data with its embedded business semantics and allowing customers to access it across heterogeneous environments.

The partnerships with Databricks, Snowflake, Google, Collibra, Confluent, and DataRobot reflect this philosophy. These are tools that SAP customers are already using. SAP’s job is to make integration easier, not harder.

What this means for developers:

Your non-SAP skills are now first-class citizens in the SAP ecosystem. Python, Spark, SQL (in its various dialects), notebook-driven workflows, ML pipelines; all of these are relevant within BDC.

If you’ve been hesitant to enter the SAP space because you don’t know ABAP, that barrier is lowering. If you’re a traditional SAP consultant worried that your skills are becoming obsolete, the opposite is true: your understanding of SAP’s business context is becoming more valuable as it gets exposed to a broader developer community.

Advice for Developers and Consultants

The most memorable part of my conversation with Daniel wasn’t about specific features or partnerships. It was his advice for developers and consultants trying to navigate this rapidly changing landscape.

Think from the future backwards:

Rather than asking “what language should I learn?” or “which tool should I master?”, start with where the industry is heading:

• Agents will be pervasive in 5-10 years
• Systems will be highly connected and federated
• Data fabric and data mesh architectures will become standard

Work backwards from that reality and build the skills that support it.

Learn the concepts, then the tools. Understand data product thinking. Learn about knowledge graphs. Get familiar with catalogue-driven development and federated metadata management. These concepts will remain relevant regardless of which specific tools you’re using.

Then choose the tooling that fits your projects and your team’s strengths. SQL, NoSQL, Python, agent development frameworks, they’ll all be useful in different contexts.

Your existing skills still matter. Whether you come from a traditional SAP background or you’re a Python developer who’s never touched SAP, your skills remain relevant. The SAP Business Data Cloud is designed to accommodate both worlds.

You don’t need to become an expert in Snowflake, Databricks, HANA Cloud, knowledge graphs, and agent development simultaneously. Know what’s available. Understand what problems each technology solves. 

Spend time with the concepts that are becoming architectural primitives (data fabrics, data products, federated catalogues). Then dive deep where your projects and interests lead you.

Final Note

The BDC announcements throughout 2025 signal a fundamental shift in how SAP views its role in the enterprise data ecosystem. SAP is now becoming an open, federated architecture that meets developers where they are.

For developers and consultants, this creates genuine opportunities:

• Faster project delivery through less data movement
• More tool choice and flexibility
• The ability to leverage existing skills in new contexts
• A stronger focus on building applications rather than data plumbing

You don’t need to rebuild your career from scratch. Your SQL skills, your understanding of SAP business context, and your Python data engineering experience all remain valuable. The difference is that you now have more ways to apply those skills and more tools at your disposal.

Looking back at TechEd 2025, I couldn’t help but feel a mix of excitement and motivation. For years, many of us in the SAP community have wanted this. An ecosystem that feels modern, open, and friendly to the tools we already use every day.

I’ve spent plenty of late nights building data pipelines, debugging APIs, and trying to make sense of SAP’s “black box” layers. But what I saw this year gives me confidence that the next decade of SAP development will look (and feel) very different.

So, my advice to the community is to stay curious. Start learning the concepts. And experiment with these new capabilities as they roll out.

The tools are ready; now it’s on us to use them creatively.