ABAPConf 2025 keynote – Capabilities

For ABAPConf 2025 I decided to accompany my sessions with blog posts. Providing an overview not only of the content of the session, but the motivation behind it. This should help you to understand better the intention of each session.

This post is to explain in more detail the ABAPConf 2025 keynote. Here the focus is on the capability part. The AI part of the keynote will be discussed in another post. You can watch the Video of the keynote on YouTube.

Why do companies use SAP?

Developers might work with SAP at their employer or customer for years without even knowing why. Why is the company using SAP at all? Too many SAP professionals assume that a company is using SAP simply because, why not? It’s a large company, and don’t use large companies SAP? The reasoning regarding the future usage can be summed up that the company has been an SAP customer for so many years, they will be it forever. This ignores the fact that enterprise architects are charged by the business with the task of selecting software that best fits the business requirements. Software that enables a company to run their business. Preferably better, faster, more efficient than the competition. That’s what enterprise architecture is all about. Aligning IT and business. Ensuring that the IT is not slowing down the business’ ability to perform. At best, even enabling the business to be innovative.

Companies and their line of businesses have certain requirements, and they need software that fulfills these requirements. That’s what SAP is doing: producing and selling software that helps companies to fulfill certain business requirements. SAP provides software for standard business processes. SAP is not selling a developer platform. That you can develop custom software using SAP as a platform is a side effect. SAP cannot fulfill all business requirements for all customers. All customers using the same implementation of a process would eliminate a customer’s individual advantage by running only a variant of a standard process. To ensure customers can run their own optimized variant of a standard business process, SAP needs to ensure their software can be adjusted. The gaps that arise through this requirement need to be filled with custom development. These gaps are an opportunity for SAP developers and something they should be happy about. The gaps mean: we do have a job.

Custom development

Custom development is something you normally do not want. Architects prefer off-the-shelf solutions over custom development. Being able to buy software, including support, consulting, and partner add-ons is better than having to manage your own custom developed solutions. A solution that you can plug in to your landscape and later replace with a different one is what companies want. Yet, in the case of SAP, custom development is very efficient.

An SAP developer – specifically ABAP developer – is super-efficient. NetWeaver is a proven platform for running enterprise apps. Developers can rely on strong foundations like the data dictionary and reuse resources and components that are simply available in ABAP. On top, the language is very business friendly as it natively supports domain modeling. Therefore, the SAP developer is a full stack developer, handling everything from database to business logic to UI, and is the single point of contact for the business users. This makes app development very efficient for customers. This is one of the main capabilities regarding SAP development. One SAP developer can deliver high value to the business. The full stack developer capabilities that come with SAP (S/4HANA, ABAP) are unmatched. To highlight this fact the tagline for ABAPConf is: The conference for SAP full-stack developers.

SAP Developer Capability

Even with the benefits of the SAP developer capability, writing custom code is a risk. While the SAP developer capability transforms this risk normally into an opportunity. Due to the strategic changes done by SAP over the last years, these opportunities are now challenges. SAP puts at risk the developer capability. To be an efficient full-stack developer, having an integrated system available is mandatory. By removing functionality from the core ERP solution and moving it to SaaS or handing it over to other companies, the integrated approach is coming to an end. SuccessFactors, Ariba, Concur, Emarsys, Commerce Cloud, etc. Best of breed is back. What once was part of an integrated technology stack are now separate offerings. Each solution comes with its own tech stack and ways to integrate and connect. A problem for customers, as the integrated platform that easily enabled us to deliver custom apps to close functional gaps is gone.

Adding to this complexity is BTP with services that are also changing constantly. This adds new challenges to every SAP project. One of the main capabilities that made SAP even with higher license, consulting, IT costs, a competitive solution was the developer capability. A common data model that was available is now distributed across several components, demanding a costly integration of all these SAP components. As a result of this change driven by SAP, the time needed to implement a solution increases. Several technologies, components, systems, landscapes are involved. More people need to be involved and with this, the time needed increases. The time needed to transform an idea to product and set it live went from weeks (if not days!) to months, or even years. Adding the probability to never go live due to higher costs and overall project execution time.

These changes are not only tangible because developers now must work with different technologies, languages and platforms like ABAP, JavaScript and web and everything that is needed to get this working: BTP, Cloud Foundry, Single Sign-on, etc. Plus, all the non-SAP products added. The strength that made companies build their processes on top of SAP was that it was “easy”. One person or a small team could deliver exceptional results. One person was able to cover a business area and deliver apps to close functional gaps. With S/4HANA and cloud, SAP decided to abandon this approach. Developers have now to choose a solution, use different technologies and find a way to manage these. Side effect here is that business users that could talk to maybe only one SAP developer now have deal with several developers, maybe even teams.

Short: the SAP advantage given by the developer capability is gone. Every technology added to the stack increases complexity. The old flow of requirement -> report/app -> result is replaced with workshops, UX analysis, API design, extensibility, programming model and still returning an app that might not do what the business expected.

One IDE

One aspect where the developer capability is falling behind is IDE. IDE stands for Integrated Development Environment. Once there was one IDE that deserved the I: Integrated. Nowadays, developers must use ADT with Eclipse, BAS / VS Code, SAP Build and might still have to use SAP Gui and transactions. And this is not just for ABAP developers. Even for those that are developing side-by-side apps on BTP using e.g. CAP: they might be able to develop the extension service and UI app in BAS / VS Code, but when they must change something in the S/4HANA system: it is Eclipse. Or maybe SAP Gui, depending on the change. Not to mention the Screen Personas editor. Changing context when developing a single app is a productivity killer. There is hope. At least starting the Fiori development process after creating the OData service in Eclipse is possible. Although it took SAP years to deliver this and it still means to switch IDEs. Not to mention cleaning OData and Fiori app caches. Will there be a simple “just clear the cache” button in ADT? Or BAS? Or VS Code? Or a report accessed via SAP Gui?

Integrated system

But it is not only that SAP is abandoning the developer capability by making it harder to focus on the development task. The individual SAP solutions that compose nowadays the normal SAP landscape means to deal with integrations. Just think of the new business suite idea SAP wants customers to adopt. That’s a lot of different technologies to take care of. And this is one of the problems that will make it harder for companies to stay with SAP: debugging. In the “old” SAP systems a developer was able to debug an application. Well, actually, the whole tech stack. Everything was just available. Nowadays, good luck. On premise and cloud systems, different technologies, programming languages, concepts, etc. During the SAP Portal days, there was Wily Introscope to get some sort of end-to-end tracing, and it was a nightmare to get an overview of what does not work in a distributed system. Especially when a technology break occurred.

Starting from a transaction, finding out the fields, tables, report used down to debugging the problem live in minutes. It is not rare that a problem found by the end user is debugged and fixed the same day. This speed makes up for additional costs that come with using SAP. If you first must coordinate a team of 3 developers, 4 infrastructure people and their manager, plus any other overhead just to find out the information flow and possible component to debug, you lose track of what you want to do when you finally find a meeting spot that works for all. The value /H offers is unbeaten.

Focus on the developer capability

This does not mean that developing SAP apps is too complex. The normal high risk associated with custom development is manageable. We must deal with challenges that arise with how SAP is positioning their portfolio. We have to accept that the one integrated platform is gone. Today there are cloud solutions provided as SaaS. They run on a different technology stack. Some on ABAP, others on Java, or JavaScript or maybe something else. But what we can ask for, and what SAP must deliver, is to make SAP developers as efficient as possible. One single IDE that deserves the name IDE. I as integrated. I as the Roman numeral for 1. I as in intuitive.

With this, it is important that SAP is reminded that whatever they do, the developer capability must be the center of it. It must be the north star of everything done that slightly touches the work of a developer. From the community, there are projects that focus on the developer. There is, of course, abapGit that allows ABAP developers to benefit from git. There are ADT plugins to make life easier (SSO to an SAP system. Change language of a SAP System), an ADT builder for Eclipse. But there is so much more SAP must do to enable SAP developers to focus on their work.