Monday morning thoughts: more on ABAP in the cloud
In this post, following my previous post on the subject, I think a bit more about the SAP Cloud Platform ABAP Environment, inspired by the conversations around the subject at SAP TechEd in Las Vegas last week.
Last month, Harald Kuck published a post “SAP Cloud Platform ABAP Environment” which many of us had been eagerly anticipating. The post has already had around 24K views and over 60 likes, which says something for the popularity of the subject matter. I followed up with a Monday morning thoughts post “ABAP in the cloud” a few days later.
Last week at SAP TechEd, Bernd Leukert included references to this new ABAP environment in his keynote, which was wonderful to hear. (There were a lot of other great things in the keynote, such as SAP Cloud Platform Functions, but that’s a subject for another time). And so the conversations that started last month were reinvigorated, which is always a good thing. There’s a lot of different opinions out there, so I thought in this posts I’d share some of my own thinking on the subject.
To set the scene, though, I first wanted to share a couple of tweets from our Developer Garage at SAP TechEd last week*. One of the areas offered workstations and a number of tutorial missions for attendees to come and work through (and win prizes, hurray!).
*The Developer Garage will of course also be at SAP TechEd in Barcelona later this month!
This year there are four missions:
- SAP Cloud Platform (Application Programming Model)
- SAP Cloud Platform ABAP Environment
- SAP Cloud Platform Portal
The developer garage with tutorial missions in full swing at SAP TechEd Las Vegas last week, from a tweet by @sapdevs
Throughout most of the week, not surprisingly, the SAP Cloud Platform ABAP Environment mission was leading the pack, in terms of number of tutorials completed. There is huge interest in the offering! In a fun bit of technology rivalry, however, at one stage the SAP Cloud Platform (Application Programming Model) took the lead, as you can see from this tweet:
#SAPTechEd the application programming model for @sapcp tutorials at the @SAPdevs garage are in the lead – yas!” — @qmacro
But in the end, the sheer weight of enthusiasm and desire to get a first hands-on experience meant that the SAP Cloud Platform ABAP Environment mission ended up on top, as you can see from this tweet from Andre Fischer (the total number of tutorials completed finished a little bit over 2000 by the time SAP TechEd finished last week):
#abap in front again. 30 minutes to go” — @anfisc
Although I’m a huge fan of the new Application Programming Model (which also drew great interest last week), I have to say that the new SAP Cloud Platform ABAP Environment was a worthy winner in this case.
I’m going to refer to the SAP Cloud Platform ABAP Environment in the rest of this post unofficially as “ABAP PaaS”, as that’s what others are calling it too. In fact, that’s already sparked some interesting conversation, as some folks are not convinced that the moniker is appropriate.
I remember the first release of Google’s App Engine, quite a few years ago now. What that offered at the outset was a cloud based runtime for Python based apps. There was a particular deployment process, and you had to think in a certain way if you wanted to take advantage of the features offered, especially when it came to using facilities such as the persistence layer or message queues. This was fine, and sort of part of the point of the “platform” part of PaaS – the platform offered certain features and required you to think in certain ways and employ certain approaches.
To me, ABAP PaaS is similar, in that it allows me to write in a language with which I’m familiar, take advantage of certain platform level features — such as a HANA-backed persistence layer — and also causes me to think in a particular way (more on this shortly). Like App Engine, I don’t have to worry about the maintenance, operation or upkeep of the ABAP platform – it just happens. New features are rolled out and available to me as they appear. I don’t have to concern myself with differing releases of differing target runtimes – unlike in the on-prem world.
The ABAP language
ABAP appeared on the scene in the late 1980’s, and I have fond memories of trying early versions of this new “report writing” language, as an alternative to the 370 assembly language in which R/2 was written by the SAP developers themselves, but which was also used by customers who needed extensions and custom reports.
The language has grown over the decades, taking on significant new features along the way (such as support for SQL and object orientation) and today enjoying rather modern features, not only as part of the language itself but also within the layers of the greater ABAP environment as a whole – I’m thinking of Core Data Services (CDS), for example. The article “ABAP and the Cloud” by Karl Kessler gives a good overview of what today’s ABAP looks like.
And this is something that I think about a lot, in the context of the modernisation of ABAP as we move to the cloud. Some language features are being deprecated, perhaps those that should have been deprecated a long time ago if it hadn’t been for the requirement for backward compatibility – again, on-prem legacy challenges which disappear in the ABAP PaaS context.
The ABAP environment
But ABAP in general, and ABAP in the cloud in particular, is more than just a language. It’s a whole set of building blocks that together present a rich set of features for building business apps – whether they’re new apps or extensions to existing functionality. Some of the building blocks are themselves written in ABAP (rather than at kernel level). One notable example that comes to mind immediately is the layer supporting the development of HTTP based services in general, and supporting the development of OData services in particular. That layer itself is written in ABAP.
So I find it more useful to think about the “ABAP environment” rather than the “ABAP language”. It’s greater than the sum of its parts. And with the advent of excellent initiatives from the community (abapGit from Lars Hvam immediately comes to mind) it’s becoming even greater.
When we think of the ABAP language itself, there is sometimes the objection that it’s proprietary. But for me, that’s not the point. Open sourcing the language would be one thing, but is it really what we should be focusing on right now? As I’ve already mentioned, ABAP is more than a language. Moreover, there are other environments with their own language. An example that immediately comes to mind is Apex, a language specific to Salesforce for developing flow and transaction control in conjunction with calls to various APIs. And that’s OK too.
ABAP PaaS’s focus
That mention of APIs brings me to the primary focus for ABAP PaaS. There are many reasons why I think ABAP PaaS is important.
One is that we have a rich intellectual ocean of knowledge and experience in ABAP, amongst customers, partners and of course developers inside SAP too. To ignore that would be to effectively discard a vast skill base as we move to a cloud-first solutions paradigm.
I do think that developers should master more than one language, but not everyone agrees with me, and that’s OK. Moreover, considering that ABAP is more than just a language, as I’ve mentioned, there’s plenty of scope for individuals to focus on an ABAP flavoured career and do very well. With ABAP PaaS, these individuals get to extend their career and their skills, and customers benefit from that. ABAP PaaS presents modern possibilities for these individuals, and for others who are deliberately and consciously versed in other languages, ABAP PaaS represents choice.
That said, I think an even more important focus for ABAP PaaS is the use case which is one that is general to the cloud environment and a major raison d’être for the initiative. That is the ability to stop customising the core and build out extensions and new apps in a separate environment.
Business solutions these days span entire cloud and on-prem landscapes. We’re moving away from monolithic runtimes for business applications, due to the distributed nature of apps and services in a cloud-first context. Implicit in that nature is the concept one level up from PaaS, which is SaaS (Software-as-a-Service) – business solution software that to all intents and purposes only has a consumption surface layer, rather than any depth into which we can dig.
That surface layer consists of two types of interface – a user interface (UI) that is usually web-based, and a machine interface that is API (application programming interface) based. We can’t see inside these systems, and it’s not possible to extend or customise them directly. The massive advantage of this is that we don’t have to worry about their operation, much less their maintenance or upkeep. But we need to differentiate ourselves somehow – to extend the solutions to meet our own business needs, to give us that competitive advantage or to solve an organisation-specific challenge.
That’s where ABAP PaaS comes in, as one of a set of environments perfectly suited for building these extensions (another is of course the Application Programming Model and the Cloud Foundry environment).
But it’s not just extensions to SaaS solutions (like SuccessFactors or S/4HANA Cloud), it’s extensions for existing on-prem solutions, whether that’s S/4HANA, Business Suite or something else R/3 based. Yes, there are plenty of these on-prem systems that have been customised, but that’s not a reason to continue doing so. We need to think about making the journey to separate these concerns out – standard software and extensions to that standard software. And when I look at how ABAP PaaS has been designed, with the focus on CDS based and API focused service solutions, it starts to make a lot of sense to me.
From “SAP Cloud Platform ABAP Environment” by Harald Kuck
There’s no concept of UI as we understand it from the traditional on-prem R/3-based world. No dynpros, no transactions, no reports, no SAPGUI. Thinking back to the reference to Google’s App Engine earlier, it’s very similar – that PaaS offering doesn’t have a UI either. The focus of a PaaS is to provide facilities for “headless” solutions that both present and consume APIs that partake in landscape-wide solutions. The UI is separate – whether that UI follows the Fiori design language and is built with UI5, or whether it’s with another Web UI framework altogether. There may not even be a UI in the traditional sense – one thing today’s computing fabric is bringing us is a wider choice of how one interacts with solutions – think custom Internet of Things (IoT) devices and conversational UI such as bots in Slack and speech recognition in the form of the Google Assistant platform or Alexa (and of course there’s SAP CoPilot too).
What we miss from from the “legacy” ABAP platform is replaced by a sharp focus on openness – using git for software versioning and logistics, a RESTful programming model as the de facto approach to building solutions, and the use of HTTP in general to consume services from (and offer services to) other parts of the landscape.
The near future
There’s so much more to think about on this subject, but this post is already long enough. I think it’s a rather exciting time for SAP’s cloud-first initiatives in general, and for the ABAP community in particular. Many of us have already been learning about the programming model that is key to building solutions on ABAP PaaS, and that is the ABAP RESTful Programming Model. If you haven’t yet had chance to dig in, I’d recommend this SAP TechEd session, which is available online already: “CNA215 – See the Big Picture of the ABAP RESTful Programming Model, 2018 Las Vegas” by Marcel Hermanns. If you’re coming to SAP TechEd in Barcelona later this month, drop in to the Developer Garage to work through the SAP Cloud Platform ABAP Environment tutorials (access to an ABAP PaaS system will be provided).
It’s early days for ABAP PaaS. The team is taking a “release early, release often” approach to delivery, so I’m seeing today’s ABAP PaaS offering as a minimum viable product. Over time I expect to see the environment grow – in terms of whitelisting, in terms of comprehension and of course in terms of developer access.
For me, ABAP PaaS is full of potential and I for one welcome the prospect of building extensions and net new apps using this modern environment. I’d love to hear from you too. Let me know what you think in the comments section below.
This post was brought to you by Pact Coffee’s El Silencio which is helping me battle the jet lag after returning home from Las Vegas, by the hashtag #ABAPsNotDead, and by the clackety-clack of the Cherry MX Blue switches in the mechanical keyboard I’m trying out, as I embark upon a new
Read more posts in this series here: Monday morning thoughts.
Mmmmm... I wonder how far ABAP PaaS is going to change from - I guess I can call it - ABAP on-premise? A long time ago I had heard that on-premise and on-cloud would end up being 2 different products. (Not sure who said that) It's beginning to seem like there is some truth to that statement.
More than one language? Of course. The problem is if you don't use it, you lose it. 😉
Wow, that's a superfast comment Michelle - only a minute or two after the post was published! I think that wins some sort of prize 🙂
Definitely concur with "if you don't use it you lose it" - it is a struggle to keep sharp in everything one learns, but I find there's a natural level at which I find my skills remain, to be "rehydrated" after a bit of revision and practice.
It makes sense to me to think of the ABAP environment as an eventual single codebase, but to be honest I'm not privy to the detailed plans. But I can think of another example where this is the case - SAPUI5 and OpenUI5 are two separate "products" and have some differences, but share the same core codebase.
the ABAP in SAP CP is a bit more restictive compared to standard "on premise" ABAP. Only a subset of statements is allowed (No FORM routines for example) and only whitelisted objects can be used in customer code.
If you like you can already analyse your ABAP programs for "Cloud-Readiness" by some new checks in the ABAP Testcockpit.
See the blog from Olga Dolinskaja
So many thing I have to agree with in this post, whilst I use my Chrome PaaS to write this message. (In case others don't pick up on the sarcasm, I am one of those who strongly believes calling this environment a PaaS is a devaluation of the term that does SAP out of much of the value that it has worked for years to develop through its Cloud Platform. Throwing a cut down (admittedly enhanced) version of an on-prem environment on to a hosted solution isn't a PaaS, or if it is, it's a serious debasing of the term.)
I hope that SAP actually move to change up ABAP so that whilst the very useful and enhance-able environment can still be used, we move to separate out the run-time from the environment. Then we might be able to consider a true lightweight ABAP possibility that might be able to be used for FaaS and other more cloud native possibilities.
In the meantime, the more that this enables businesses to extract out from their core the years of enhancements that they have made so that they can turn up the cadence of their core refreshes from a once a year (if lucky) update to a more cloud like quarterly update, will deliver the kind of innovation and ability to adapt to changing market conditions that businesses so desperately need.
In summary - it's not a PaaS in the terms that you would want CIO's who are deciding whether there is an advantage to go with Workday or SAP to consider (SAP have a PaaS, it's SAPCP, Workday don't really) but anything that enables SAP to bring the huge number of business experts that are masquerading as ABAP coders into the light, sounds good to me.
The journey to the cloud will be an exciting and bumpy ride for SAP and customers alike and no doubt there will be some injuries along the way. I don't think there is the possibility to be everything for everyone and also be profitable, however, the more that SAP can do to smooth the ride (by introducing options like SAPCP ABAP environment) the easier it's going to be to get there.
Thanks Chris, super thoughts as always. Terminology is hard (what's that about the "two hard problems in computer science" again?) and I'm completely open to your challenge. After all, the proper name is "SAP Cloud Platform ABAP Environment" as I referred to in the preamble; the term ABAP PaaS is something that's easier to write, but I can see how different understandings of what a PaaS is will lead to these sorts of thoughts.
I remember Fotango, a photo sharing website that was bought by Canon, in the earlyish days of the web. Some friends and fellow Perl aficionados from London Perl Mongers (I was a proud member, and have happy memories from that era) went to work for Fotango, so it was a company that was known to me. They produced Zimki which was arguably a PaaS even back then. And IIRC it was a JS based environment, i.e. single-language. That said, you make a good point about separation of design time and runtime, but I do wonder how one should define or understand PaaS from a language support perspective.
Anyway, the one word that strikes me from your comment is "exciting" - just as one might have thought the general SAP computing landscape couldn't get any more interesting - it just did. What we call it is one thing, what choice it offers is another. Cheers!
* cacheing, naming things and off-by-one errors 😉
Nice post as always and very interesting new area that I myself wrote a blog about which focused more on the transformation of SAP from 20 years ago being very proprietary to now being very open - which benefits us all.
I'm not so interested in what it is eventually called - SAP Cloud Platform ABAP Environment seems to be pretty bang on so happy with that. I like the delivery approach focused on bringing incremental improvements over time and regular releases most cloud customers are already accustomed to and these are well received.
Thanks for sharing your thoughts on the topic!
Cheers Phil! Yes, it's definitely fascinating to see how ABAP has evolved over the decades, and also that it's still around and stronger than ever.
I'm not that bothered about the name either, but I thought it would be interesting to think about the concept of PaaS in the context of the new cloud ABAP environment (and I got a bonus comment from Chris Paine for that, which was great).
And yes, the incremental improvements in the delivery approach that is "native" to cloud services is something to look forward to.