Additional comments on CAP

After I published my post CAP. The new Web Dynpro Java there was some discussion about it. Sadly, I have to say: most people did not get the message of my post. Even sadder: I was not surprised. Some people, and this is very highly pronounced by IT people, tend to take things personally or from the impact something could have on their own life. From basic concept misunderstanding (CAP is not about UI) to a comparison of development effort 20 years ago (CAP starts on a laptop in seconds, WDJ not) or comparing the effort of developing in CAP against RAP. All of this was not part of my blog post.

The post was not about if RAP is superior to CAP. While they share 66% of the acronym, and the underlying modelling, CAP and RAP development differ. The post was also not intended to say that CAP is useless, and you should always go for RAP. Both have their scenarios where they make sense. It is just that when you have RAP available for your scenario, what can the scenario be about? Let me guess: extend S/4HANA. This is what RAP is made for. Why add a whole new technology stack and landscape when you can achieve the same with RAP, maybe even in the same stack? In such scenarios, CAP is brought up by architects or developers that want to use CAP. Personal opinion is a bad driver for architecture. I added this in my post as a reminder that personal preferences are bad for companies that must deal with badly justified decisions for the next years or decades.

The simple message of the post was that SAP is SAP. CAP is made by SAP for SAP. The focus of CAP is SAP centric. It is driven by internal SAP demand. The potential CAP offers is not used. Any customer or partner that wants to use CAP should be aware of the simple fact that all of CAP is centered around SAP. Products from SAP that use CAP drive the feature requests. The – as stated now in more than one ReCAP event – understaffed CAP team is busy working on the internal requests. SAP has a great software with CAP. The focus yet is not on CAP as a standalone product. That makes it dependent on the SAP organization. People brought up that CAP is tightly coupled with BTP, therefore it is not possible for SAP to end it. Sure, this is valid for as long as SAP is committed to this marketing message. BTP, or SCP, or HCP, or Neo, that once had XS as the preferred technology for development. For sure this will work for CAP in Neo, sorry, I mean Cloud Foundry, or is it K8s? Or Kyma? You see, it does not take much to put a big question mark behind the message that CAP will be around the next years just because of BTP.

There is no real open-source version of CAP (yet?). And even if: this doesn’t mean that you can contribute to CAP as you might hope. SAP is the benevolent dictator for life of CAP, just as for OpenUI5. There is no governance board, no community driven board or committee that can influence the roadmap or decisions. Decisions regarding CAP are done by SAP and therefore internal. First and foremost, you need to be an SAP employee to have committer permission. In case SAP abandons CAP one day, and it is available under an open-source license, you might be able to fork it and hope to find enough other people or companies to join you. But will this happen? Most probably not, as customers and partners will have to adopt whatever SAP will be promoting than and resources in the SAP universe are short. So why invest into something that was dropped from the original creator? And then having to compete with SAP sales going to customers saying they should use technology XYZ instead of CAP? Because, well, XYZ is where the future is.

We all know what happens to a technology that does not fulfill its expectations. In the SAP context, the more a technology is seen only as a simple enabler, or with a very SAP centric usage, it is easy to kill it. All it takes is a decision or change at the top, and SAP employees search a new task. So far, I see nothing that makes CAP more than a simple enabler for some SAP related scenarios. It is not used by SAP to run a core module of S/4HANA. How many SaaS solutions are fully dependend on CAP? In case SAP decides to end active CAP development, this will have the most impact for Fiori developers, as they will lose a tool for creating mock services. CAP is not really used outside the SAP universe. If I’d do a risk analysis of CAP, I will give it a high-risk rating.

To sum it up: CAP is from SAP, for SAP, controlled by SAP, for a specific SAP-centric use case. The wide range of opportunities CAP can offer is ignored. CAP’s future is decided solely by SAP internal decisions, by SAP’s strategy and there is not much you can do. SAP can end CAP development at will. And while some people believe that this will never happen: why? What did SAP do to justify such trust? SAP owns CAP, the developers, and its future. The future is the usage of CAP at SAP customers? SAP customers face the problem of S/4HANA upgrades, skill shortage, budget restrictions and still must deliver to business. All of this puts classical SAP with ABAP, RAP and of course ABAP Cloud into a very beneficial situation. Simply because of the current situation I think that customers are going to adopt ABAP Cloud. This might be a difference between CAP and WDJ faith: instead of SAP announcing the end of WDJ, customers will decide the faith of CAP. But I don’t think that the outcome will change.