SAP spent 50 years building proprietary development tools. That strategy ended this week in Berlin.

SAP spent 50 years building proprietary development tools. That strategy ended this week in Berlin.

BackerLeader posted 7 min read

SAP Abandons Proprietary Developer Tools. Here's What That Actually Means.

The Shift Everyone Missed

SAP TechEd 2025 opened with Muhammad Alam, SAP's board member for Product and Engineering, making an unusual promise: developers can now "build, extend, and automate using the tools they love most."

Not SAP's tools. The tools developers already use.

It's a complete reversal of SAP's historical approach. For decades, working with SAP meant learning SAP's proprietary environments, SAP's frameworks, and SAP's way of doing things. That created a moat around SAP's business but also created a developer experience problem.

Bharat Sandhu, SVP and CMO of SAP's Business Technology Platform, addressed it directly in an interview: "The biggest misconception developers have about SAP BTP is that it's not open."

The technical implementations announced at TechEd demonstrate that SAP is backing this up with actual infrastructure.

What Changed Under the Hood

SAP announced three significant technical capabilities that fundamentally change how developers can work with SAP:

Model Context Protocol (MCP) Servers for SAP Frameworks

SAP now provides local MCP servers for its Cloud Application Programming Model, SAP Fiori elements, SAPUI5, and the mobile development kit. These are available now.

What this means: Developers using AI code assistants like Cursor can access SAP development frameworks directly in their preferred environment. They don't need to switch to SAP's tools.

An ABAP-based MCP server is planned for H1 2026, which will expose ABAP Cloud development capabilities to coding agents.

Sandhu emphasized the importance: "Model-driven tooling, like SAP Cloud Application Programming Model, SAP Fiori elements, SAPUI5, and SAP's mobile development kit, increases developer productivity and supports consistency across SAP Build projects."

MCP Gateway in SAP Integration Suite

The MCP Gateway (general availability planned Q1 2026) enables customers to expose custom APIs and integration flows that can be dynamically consumed by AI agents.

The practical value: "It provides a unique capability for customers to enrich custom agents built in Joule Studio or extend Joule Agents by integrating data from legacy SAP systems and third-party ERP, CRM, and HR vendors, composed as MCP tools for smooth agentic consumption," according to one SAP technical lead during the experience center tour.

This addresses a real problem. Enterprises don't just have SAP data. They have decades of data in various systems. The MCP Gateway enables agents to work across the entire landscape with standardized access, centralized governance, and simplified discoverability.

VS Code Extension Pack

SAP Build capabilities now work directly in Visual Studio Code. Individual extensions are available now. The full extension pack will be published on the Open VSX Registry for other development environments in Q2 2026.

Sandhu noted that SAP's own IDE is "built on VS and a VS Code extension," acknowledging that the underlying technology already comes from Microsoft's open-source project.

Why This Matters: The Developer Scarcity Problem

This isn't about being nice to developers. SAP is responding to a crisis.

In the fireside chat with Alex Kantrowitz, Muhammad Alam shared a customer example: "We have a customer who says we have a backlog that if I had to do with my existing capacity would take me 20 years to deliver."

Another data point from the same conversation: "40,000 workers with enough backlog for 200,000."

The math is brutal. Enterprises can't hire their way out of this problem. The only solution is making existing developers dramatically more productive.

Alam framed it clearly: "AI is going to be about acceleration. How do you ensure they have the right tools to deliver innovation faster?"

Alam added, "We saw metrics showing 7x to 12x value with AI in sprints as learning increases."

The Business Logic Behind Open Development

Brenda Bown, CMO of SAP Business AI Marketing, said that customers asking "why SAP AI vs. building our own with ChatGPT" receive three answers: trust, governance, and the "breadth and depth of the data."

The open development strategy supports this positioning. SAP provides the business context and data semantics. Developers use whatever tools they want to build upon it.

It's a different kind of moat. Instead of trapping developers in proprietary tools, SAP is betting that the value is in the data layer, not the development environment layer.

When asked how much SAP BTP development actually happens in external tools versus SAP's native environments, Sandhu acknowledged it's early: "Too early" to have meaningful usage statistics.

The infrastructure is being built to support developer choice. Adoption patterns will emerge over the next few quarters.

Two Paths to Agent Development

The open development strategy creates two distinct paths for building AI agents:

Path 1: Joule Studio (Low-Code)

Joule Studio (general availability: December 2025) enables developers to create and deploy custom AI agents with assistance from Joule itself. New features coming in H1 2026:

  • Support for system-triggered agents (not just user-initiated)
  • Extensibility of SAP-delivered Joule Agents
  • Centralized enterprise-grade agent monitoring
  • Support for Agent2Agent protocol

This path is designed to enable the rapid development of building agents while leveraging SAP semantics and maintaining alignment with SAP data.

Path 2: Pro-Code Frameworks on SAP BTP

SAP BTP provides comprehensive support for popular open-source frameworks, including Crew.AI and LangGraph. The platform provides:

  • End-to-end identity and authorization
  • Governance and integration capabilities
  • Access to the AI Foundation for the latest AI models
  • SAP HANA Cloud for agent memory and secure tool execution
  • SAP Integration Suite for smooth integration with applications

Sandhu was clear about which path most customers are choosing: when asked if customers building custom agents with pro-code tools are deploying to SAP BTP or running in their own infrastructure, he said, "Mostly to BTP."

The Partner Impact

The open development shift is already affecting SAP's partner ecosystem, and not always in a positive way.

When asked about partners' biggest complaints, Sandhu said: "Used to charge for dev tools, now for free. More help on training and enablement."

Making development tools free eliminates a revenue stream for some partners. They're asking for more training resources to help them add value in other ways.

SAP's response: a new free SAP Build test, demo, and development license specifically for partners. This lets partners experiment, build demos, and develop solutions without purchasing licenses.

The partner ecosystem is also building agents. Sandhu said there will be "40 by the end of the year" partner-built agents available, in addition to SAP's own Joule Agents.

What's Available Today vs. What's Roadmap

This matters for developers planning projects now:

Available Today:

  • Local MCP servers for SAP frameworks
  • Individual VS Code extensions for SAP Build
  • Support for Cursor and other code assistants with SAP frameworks
  • Pro-code agent development with LangGraph and similar frameworks

Q1 2026:

  • MCP Gateway in Integration Suite
  • ABAP-based MCP server
  • Enhanced monitoring for custom agents

Q2 2026:

  • Full SAP BTP extension pack on Open VSX Registry
  • ABAP support in the extension pack
  • Additional agent development capabilities

When asked what customers can do today if they want to start building agents this week, Sandhu said, "Go build. Everything will be more generally available in a couple of weeks."

That "couple of weeks" qualifier is important. Some capabilities are available now. Others are imminent. Developers need to verify specific features before committing to project timelines.

The Critical Technical Requirement

One point came up repeatedly across interviews: understanding SAP's data semantics.

Sandhu emphasized this as the most common integration mistake: "Don't take data out without the semantic understanding."

This is the real value SAP is protecting. You can use whatever development tools you want. You can deploy agents as you see fit. But if you want SAP's business context—the relationships, the business meaning, the validated transformations—you need to work with SAP's semantic layer.

That semantic layer lives in SAP Business Data Cloud and SAP HANA Cloud. Those are not optional if you want agents that understand SAP business processes.

What Developers Should Actually Do

Based on the announcements and interviews, here's the practical path:

If you're building applications: Use VS Code with SAP's extension pack. Work in your preferred environment while maintaining access to SAP frameworks and business context.

If you're building agents for common use cases: Start with SAP's Joule Agents. 40+ are available across finance, HR, supply chain, and other functions. Extend them using Joule Studio when you need company-specific modifications.

If you're building custom agents: Use pro-code frameworks on SAP BTP. You get access to SAP's governance, security, and data semantics while maintaining full control over agent logic.

In all cases: Understand SAP's data products and business semantics before building. The compute platform is flexible. The semantic layer is not.

The Real Test

Muhammad Alam closed the keynote with a direct challenge: "SAP's announcements today give developers the tools they need to deliver at the speed of AI."

The test of whether SAP's open development strategy is effective will be simple: do developers choose to use these tools, or do they remain in proprietary SAP environments because the open options do not work well enough?

That evidence will emerge over the next two quarters as these capabilities move from announcement to production use. Developers will vote with their toolchain choices.

For SAP, the bet is clear: giving developers choice while maintaining control over data semantics creates a more sustainable platform than forcing them into proprietary environments.

For developers, the practical question is whether this actually makes building on SAP easier or if it's just more complexity to navigate.


Recommended Hashtags:

Twitter: #SAPTechEd #DeveloperTools #OpenSource #SAPBTP #AgenticAI

LinkedIn: #SAPTechEd #EnterpriseDevelopment #DeveloperExperience #OpenDevelopment #AIAgents

1 Comment

0 votes

More Posts

Theory Ventures has more engineers than investors. Here's why that matters for dev tools.

Tom Smith - Sep 29, 2025

Google Drive Sync

Pocket Portfolio - Jan 5

Salesforce shifts developer focus from building data pipelines to orchestrating AI agents at scale.

Tom Smith - Oct 2, 2025

Agents Aren't Apps: Why Your UI Strategy Just Changed

Tom Smith - Dec 31, 2025

34,000 SAP customers are using AI agents. The hard part isn't deployment. It's what comes after

Tom Smith - Nov 6, 2025
chevron_left