CAP vs. RAP

I attended the DSAG AK Dev Zukunftstag in January 2025 in Hockenheim. In the morning the focus was on CAP vs. RAP. The positioning made it look like there is a competition between CAP and RAP. That there is a winner and looser. That you must choose one over the other. This is simply wrong. Both exist in parallel. Their usage is defined by customers and their specific requirements given by the solution scenarios. Which, in turn, means that both are rarely competing at customers.

Scenarios where CAP excels

• Non-SAP centric solutions. This is when maybe not even an SAP system is involved.
• Broad range of users. If the solution is intended to be used by a large number of users (100,000s or even millions). You want to have this load handled by a cloud native solution that scales well.
• External facing scenario with a significant number of anonymous users that need to access data from internal systems. You might want to have a component between anonymous users and your internal SAP system. Or even put the data to CAP without giving access to your internal system at all.
• High number of data messages is processes, e.g. a non-user based scenario and the target of those messages is not an S/4HANA system.
• Access mostly to JavaScript / TypeScript / Java developers, but not to ABAP developers. If, however, the scenario is listed in the RAP excels list, maybe consider upskilling the developers to ABAP developers.
• Cloud native culture. When all apps are cloud native apps that run on e.g. Kubernetes and teams have easy access to this information.
• Fire-and-forget solutions. Simple solutions with low budget and a short lifetime. But also, only if it is not part of the RAP excels list – specifically the developers skills.
• Scenarios for JS/TS and Java developers and where CAP with CDS and OData with Fiori is better than an alternative tech stack (e.g. Spring, Angular).

Short: In case you need an app for hundred thousand of users that might not even access SAP data, the better match is CAP. Although, the following question might need an answer: why CAP and not some non-SAP technology?

Scenarios where RAP excels

• S/4HANA based scenarios.
• SAP centric scenario where access to an S/4HANA system is needed.
• Majority of developers available for the solution are ABAP developers.
• Mostly named users are going to the solution.
• A rather recent S/4HANA release is available (2023), S/4HANA Public Cloud or BTP, ABAP environment. Allowing to use write RAP apps or extensions side-by-side or on-stack. If you are on an older release: update!
• Business relevant data is exchanged via APIs over an integration scenario with SAP systems involved.
• Typical SAP solutions: rather monolithic architecture, long running apps that need to be maintained over several years.

Short: for whatever task you would normally take ABAP, RAP is the better match.

Where do both excel?

Many would say: side-by-side extensibility. While both can be used for side-by-side extensibility, you’ll have to look at both excel lists. And then the CAP and RAP decision becomes again mutual exclusive. Side-by-side means: S/4HANA centric, SAP centric. That’s RAP. If a wide range of users will use the extension: CAP. If you only have non-ABAP developers at hand: CAP. And if your developers are ABAP developers, which is likely given the extension scenario, then it is RAP. There is no real CAP vs. RAP. Slightly exaggerated you can say: they are disjoint sets.

The imaginary overlap

Considering the sweet spots for using CAP or RAP, why is there so much noise around this topic? Well, first, this is a developer topic. People will make some noise around it. Learning a technology takes time. A significant amount of lifetime is invested. Developers want to get something back from their learning investment and turn into advocates for a technology. The outcome of this might look as there is a constant overlap between CAP and RAP.

Looking at some discussions it seems that choosing between CAP and RAP is an irreversible decision and valid for most, if not all, future development. There is advice out there that go as simple as: when you are on BTP, use CAP. This view is simplifying way too much. The world, and specifically, the SAP world at customers, is not so simple. Look at the “excels at” lists: selection depends strongly on the customer situation. And yes: this might even differ between projects at the same customer. Let’s ignore companies or developers that put their future only on CAP/RAP. General advice for SAP customers is always: do not sell into a partner story. Select your partners depending on your needs.

The extensibility overlap

Why is there the perceived overlap regarding extensibility? CAP and RAP are marketed by SAP to serve an overlapping use case (extensibility).

This overlap is the sweet spot of justification of existence for different stakeholders. One being, of course, SAP. The overlap is justified by the corporate strategy of clean core. A side-by-side extension is an app developed to run on BTP. CAP is recommended when developing an app on BTP. These two points get merged into: use CAP for extensibility. Yet, CAP is one option for side-by-side extensibility. The other one is RAP (yes, RAP includes here all what is needed to run it on Steampunk / BTP, ABAP environment). That CAP is an option, and that the customer needs to choose what is best for him is way too often overseen. That there is more to be added to the decision (see “excels at” list) is not very well communicated by SAP. Partners and freelancers that bet on BTP and CAP as their technology stack are also more than happy to state that CAP is a good fit for an extension, referring to SAP. And why should SAP do something against this? As long as customers keep staying with SAP and pay money, everything is OK. For extension scenarios you should always be curious when CAP is positioned. An S/4HANA system is going to be extended? So, there are ABAP developers already available?

Another reason that is responsible for causing the CAP vs RAP confusion is SAP marketing. SAP is not really promoting CAP outside the (small) SAP ecosystem. This eliminates a good part of the CAP “excels at” list. Resulting in extensibility getting the main attention (aka: low-hanging fruit). RAP and CAP are now positioned to serve the same purpose: extensibility. Marketing is aiming at SAP customers for selling BTP for clean core. Typical win-win situation: SAP sells BTP and any customer that is going for clear core, can be later easily tempted to buy RISE or Public Cloud. I can’t count how many times people are surprised to hear that it is possible to use ABAP Cloud on stack. SAP marketing focuses on existing SAP customers, and this is causing a severe problem: exactly those have ABAP developers at hand, and seldomly CAP developers. One of the main reasons there is CAP vs. RAP. The message is too much focused on a scenario that share the same target group: SAP customers and SAP developers.

Let’s add one more problem: lack of skills. There are not enough CAP developers in the market (Hello SAP: do something, like: 5 years ago!). Upskilling ABAP developers to CAP developers? Companies have a better usage of the rare skillset ABAP. Which brings back an old problem: companies must train people to be CAP developers. But why go for CAP when ABAP is for a company the better skill? Remember: extensibility: there is an S/4HANA system in use. It is better to have ABAP developers in such a case (again: look at the “excels at” lists).

Why is this not understood? Same answer as before: marketing. Having learning sessions, tutorials and videos showing how easy it is to write a CAP app and connect it to an OData service is just cool. For SAP it is nice to demonstrate at their events that it is easy to get a CAP app started. But this has nothing to do with the real-world situations at customers. Here, the “excel at” list is important. What does it help to know that a simple CAP app can be created in a few minutes? How to get this into production? How to run it enterprise ready (scale, security, tracing, transports, monitoring, …)? While this could still be acceptable, the marketing decided to go after the SAP ecosystem for this. Instead of showing this to non-SAP developers, and bring new people to the SAP universe, and upskilling them, they focus on the SAP developers. The lowest common denominator for those is: migrate an SAP system to S/4HANA and applying clean core and side-by-side extensibility. Result: CAP is positioned artificially into the same area where RAP excels. If you think that the push to adopt CAP is not aligned with the sweet spot of CAP (again: “excels at” list is important): wait until you have SAP Support or some S/4HANA transformation services added to your calendar.

Conclusion

All of this creates an artificial competition where normally a friendly co-existence should be. To the “excels at” lists, several other points need to be added. But these are more of a side effect and should be automatically included in the selection process. Even when a solution is evaluated, and a technology stack selected: remember that one needs to maintain it. Ensure that for long running solutions there are in the future enough people available with the required skill available. In case you buy a packaged solution: check that the technology used by the partner does what you need. SaaS: extensions via API. Whatever is used to provide this API: does not matter. Is the partner all-in into one technology? Check that you as a customer are not exploited and must pay for the lessons learned of the partner. For customers, partners, freelancers: I recommend coming up with your own “excels at” lists. Communicate them and if a customer project does get categorized into one, does not force it to switch category. If it is CAP, it is CAP. Don’t force a RAP project to be a CAP project and vice versa.

What can be done to ensure people see that there is no competition? One approach can be to focus from the CAP side on projects where CAP can show what is possible. To use CAP to bring people from the non-SAP developer world to the SAP world. Less focus on the SAP ecosystem. Less on extensibility of S/4HANA and more cloud native solutions. More on CAP for add-on solutions. For RAP, it means: show more on how to extend SAP: public cloud, on stack, on premise, with BTP. Trainings for upskilling ABAP developers. Also: RAP for add-on solutions.

I think the only intersection between CAP and RAP might be: add-ons