Skip to Content
Personal Insights

CAP is important because it’s not important

In this post, I consider what CAP really is, what it gives us, and why we should consider it a fundamental piece of the puzzle in the cloud context and beyond.

→ Update (08 Nov): This blog post is available in audio format as an episode on the Tech Aloud podcast. Also, I recorded a CodeTalk episode on this subject with Ian Thain – watch it here:

If you read one technical article today*, make it the About CAP page in the online documentation, which starts with the following overview:

The “SAP Cloud Application Programming Model” is an open and opinionated, framework of languages, libraries, and tools for building enterprise-grade services and applications. It guides developers through proven best practices and a great wealth of out-of-the-box solutions to recurring tasks.

Key for me here is that the design principles that are at CAP’s core (open and opinionated, zero lock-in, non-intrusive and platform agnostic) and that have influenced what CAP is and what it can do for us, explain why it is fundamental.

*(If you don’t have time to read it, it’s also available as a podcast episode in the Tech Aloud podcast here: SAP Cloud Application Programming Model (About CAP) – SAP – September 2019.)

What CAP is for me

CAP provides the substrate within or upon which actual services and applications can be designed and built, cloud-ready.

It is the fresh, fertile and well-watered soil in which we can grow our flowers and food.

It is the backbone which is the stable base that connects everything together, the trunk from which all branches can flourish.

To bring these metaphors a little closer to the subject at hand, CAP is like the combination of mores and spoken languages upon which society is built … or, in a narrower computing context, it’s the programming language that we use to express our solutions.

What this suggests to me is that if we see CAP in this way, we should master enough of it to express ourselves, to start building services, to plant seeds and nurture them into blossom, to build upon and build with.

Just like we learn a language with which to express ourselves, whether that language is English, international sign language, or APL, we should make a point of learning what CAP is, how it works, what it can do for us, and how to embrace and wield the power that it gives us as developers.

A means to an end

CAP is not an end in itself, it is a means to other ends. And my goodness, in my experience, what a means it is!

It’s hard now to remember the times when the effort to create a functioning read-write OData service was so great that proof-of-concept projects didn’t even get off the ground. Now, literally with less than ten lines of declarative code you can spin up a fully formed CRUD+Q OData service, and what’s more, adding custom handlers to augment the standard handlers is also only a few lines of code away.

Similarly, I had never really seriously attempted mocking a business service from the SAP API Business Hub before, as the effort was too great. Now with CAP it’s a matter of minutes.

It’s hard to remember what it was like to explore how annotations actually drive Fiori elements, because of the complexity involved in establishing where to store and how to serve up annotations along with an existing OData service. With CAP you just add them to a file, using Notepad or similar, and you’re done. The time between tweaking annotations and refreshing your Fiori elements app to see what those tweaks do is now measured in seconds (and yes, I do that, I’m just like you :-)).

I can’t actually remember a time when I didn’t have to think about specific persistence layers and machinery when prototyping a service, until CAP came along.

And the mental heavy lifting previously needed to consider how I might go about building a solution that involved persistence, built-in extensibility, enterprise messaging and more … well, as a regular developer with limited brain power, I’m now in a much better position to create solutions like that.

Start smart

With the building blocks such as the family of Domain Specific Languages*, with the convention-over-configuration approach, with the first class support for today’s most popular language, CAP helps you start smart, start your development project at a level far higher up, far nearer the business domain, than you could have started previously.

You could say that this higher level starting point puts you closer to the cloud before you’ve even begun!

*(See the CDS language reference documentation to learn more about the CAP DSLs.)

So, my advice is – learn CAP, understand how to make use of the superpowers it gives you, and be mindful of its key role as a development substrate letting you focus on the business domain at hand.

And, in the nicest possible way, just as for me my knowledge of the English language and and my understanding of social rules and customs fades into unimportance when interacting with my fellow human beings, consider CAP as unimportant in the same way. Fundamental, something you should learn and be able to make full use of, but a means to an end.

You must be Logged on to comment or reply to a post.
  • Hi DJ,

    Interesting thoughts. I just love how easy it is to get started with CAP. I want my team to learn about CAP so we can use it for prototyping or during events such as hackathons.

    I also love the fact that CAP is open but I'd like SAP to provide more guidance on how to support other DBs and protocols. It would be nice to have some kind of guide to write our own adapters for instance.


    • Thanks Pierre (and thanks for your continued digging into CAP too!)

      I would also love to see some guides - I'll pass this feedback on to the teams.

    • ”... but I’d like SAP to provide more guidance on how to support other DBs and protocols. It would be nice to have some kind of guide to write our own adapters for instance.“

      I agree Pierre. It’s in the makes and we’ll share samples soon, likely on cap/community... just didn’t want to do so unless it’s really looking good enough... pls stay tuned on that.

  • Nice expressions as always DJ. CAP is not only a language or methodology i would see totally a mindset shift for developers and architects

  • Great to see you blogging again, DJ.  As you know I used CAP for an extension app alongside the Cloud SDK.  Recently I've been working on an older extension app at another customer and it makes me appreciate how much time & code CAP saved me.

    • Cheers Mike, I've heard some folks have missed the Monday Morning Thoughts series of last year. Who knows what will come in 2020!

      You make a good point about appreciation there, Mike. Cheers.


  • I totally agree with the superpowers it gives you 🙂 🙂 I now has a good understanding of the APIs, nodejs and many other stuff than before and feel closer to them because of learning CAP and your handsondev sessions 🙂 🙂

    • Cheers Mahesh, and it's awesome to have you and others take part and contribute regularly too, during the live stream sessions - so thank you!

  • Great stuff DJ sir, sometimes when I sit and think where we have come from(technology perspective) the progress is amazing, where we are going still don't know:). Right from ABAP( sir you have started much earlier, for me oldest one is 4.6)-> ITS, web service etc..-> REST ->CAP/Cloud what not(missed many in between), from writing tones of code to just declaring your stuff what you want and how you want to display it up and running in no time.

    One thing which is common in all this progress i find is we are bringing more and more abstraction in our tooling. All the complexity of how it works behind the scene is abstracted behind the N-layers from the developer.  Isn't too much of abstraction also bad? Doesn't it make's the trouble shooting tough, no normal developer can trouble shoot, add to it the N number of other things which the tooling depend on?

    Definitely CAP is great it almost take nil time in getting a CRUD/Q server up and running, these are just thoughts which comes to my mind when things become too easy:)



    • Indeed we have come a long way. I did start earlier, then again I have grey hair to show it! But in fact that does also give one such a wonderful perspective on how things have progressed.

      You make an interesting point about abstraction. How much abstraction is too much? Perhaps we think that right now we’re at peak abstraction, but I wonder how that contrasts with where we’ve been before (where, back in the 1980’s, we thought we’d reached peak abstraction (from machine code and assembler) when writing with 4GLs (fourth generation languages), and where we’re going (esp. with ML and AI) which suggests we’re in the dark ages right now, comparatively.

      Everything is relative ... (and just remember, it's turtles all the way down)

      Talking of abstraction, and, as you do also, of declarative programming and describing WHAT not HOW, that reminds me we need to do some more functional programming, right? ?

      • Adding abstraction layers (almost) always comes with a trade-off, you will lose the nitty-gritty details underneath, making it hard to change/optimize stuff.

        It reminds me of the blog post of a Haskell programmer trying to optimize his wc program:

        He starts with a very readable small program. To optimize it he really has to understand what Haskell is doing under the hood.


  • Great summary and perspective on the positioning of CAP in the SAP world.  As the SAP Cloud Platform transforms into a business technology platform, its increasingly clear that we need a "basic syntax" for describing and extending applications and services in this brave new world. CAP fits that need quite well for all the reasons that you explain so well here.

    • Thanks Tom, your insights are always welcome and valuable. Yes, this is at the heart of it - we can and should focus on the business domain, and that will mean, increasingly, working with the SAP Cloud Platform as the Business Technology Platform, to use the name ascribed to it at SAP TechEd this year. And what better toolset than CAP to help with that.

  • Hi DJ,

    Interesting read. I’ve been a Java developer and this introduces something new. For example, to create a OData service I used to represent domain model as Java POJOs and use Olingo library (Like wise in node). Now with CAP, the domain model and the service is taken over by CDS and we can create OData service in Java & Node without having to write(unfortunately ? ) single line of Java /node code except for custom logic /handlers. This also means I need to know CDS syntax in order to create OData API via CAP which is not necessarily the case earlier in Java or Node. But, on the other hand this creates a unified domain/service model across languages using CDS which is well known at SAP (at least ABAP world) 🙂 

    Also at several places in the documentation and the diagram here says, currently supported protocols are OData, Plain rest and few others. Is there any guideline about how to generate swagger(open api) based plain REST service instead of OData via CAP ?





    • Hey Santosh, thanks for the reply and the very good thoughts. I would say that the benefits of learning how to express oneself in CDS declaratively far outweigh any effort involved, and you pick out one of those benefits in your comment (unified domain/service model across languages (and platforms)).

      I'll perhaps leave the second half of your comment (a question about guidelines) to someone from the CAP team to answer.