ABAP in SAP Cloud Platform – Why?
At SAP TechEd in Las Vegas last week Bjoern Goerke announced that SAP would be making the ABAP runtime available on the SAP Cloud Platform. This announcement was greeted with plenty of applause from those in the audience drawing Captain Kirk to comment “Finally – you will say”.
Bjoern explained and positioned ABAP in SAP Cloud Platform in this way.
…a successful platform needs developers, customers and partners…it takes You, the developers, to create such solutions.
…if we talk about developers we need to consider our community. This includes our community of several million ABAP developers around the globe that has been continuously growing over the past 20 years.
…ABAP in SAP Cloud Platform … enables the ABAP developer community to step into the cloud with us. Customers and Partners can build extensions for SAP products like S/4HANA cloud as well as new cloud applications. ABAP in SAP Cloud Platform is also an option to transform existing ABAP-based custom code or extensions to the cloud. And finally, it provides access to all the SAP Cloud Platform capabilities. Whether it’s the core services like integration and security or the new Leonardo innovation services like machine learning, IoT or blockchain.
Following the keynote everyone wanted to understand what exactly this meant. There is plenty of conjecture about the relevance and importance of this announcement.
From my perspective I think this is a predictable and sensible move from SAP – but I think my view is a bit more nuanced than some others.
I perfectly understand the logic of providing a cloud option for the “several million” ABAP developers.
After all, as Bjoern acknowledged, it is adoption that will make the SAP Cloud Platform successful – end of story.
SAP might build the greatest cloud platform ever but without widespread adoption it will die on the vine. If they can get a significant percentage of the existing ABAP developers to build on the SAP Cloud Platform they directly address the adoption issue.
Another issue that was expressed to me at TechEd was that SAP customers and partners are saying to SAP …
“What about my SAP developers? These are good people who have provided great service to me and my customers over many years yet they seem to have a diminishing role in your roadmaps”.
SAP felt they needed to address this.
However my thoughts return to the intrinsic value of an ABAP developer? There are plenty who misunderstand that ABAP developers are different to most other developers. Many criticise them and their craft. I often criticise ABAP developers for failing to maintain their development skills in these changing times. But I would never criticise the unique value that comes with the ABAP developer.
You see, unlike other programming languages, ABAP is not so much about syntax. ABAP is about much more than that. An ABAPer knows the SAP data model intimately. They know when to use SAP-provided API’s and when to build their own. They know about building enterprise-ready applications. They know about business process. They know about supporting multiple languages, currencies, date and time formats, etc. They know the importance of 24×7 operations, rock-solid reliability, integration, etc. They know about software logistics. And they also know about the specific characteristics of the industry or industries they work in.
I usually refer to this non-syntax skillset as SAP-specific domain knowledge. It separates ABAP developers from the rest. In my opinion it is why non-ABAP developers struggle to interact with SAP systems. After all there is no technical difficulty connecting a Java, C#, Swift, PHP, etc. application to a SAP backend. And we can assume that these developers know their chosen programming language well. So why do they tend to struggle so much with SAP projects? Why, when asked, do they invariable respond that SAP integration is “difficult”? Why are there so many stories of late, costly and failed projects? Why do we hear so often about “communication issues” between the SAP and non-SAP teams? And why do ABAP developers who use other languages find it so much easier to interact with SAP systems?
It is because when you are a good ABAP developer you have absorbed so much more than just the ABAP language syntax.
So when SAP provide a path to the cloud for the ABAP developer they also provide a long term path for the ABAP developers’ intellectual property. All that SAP-specific domain knowledge can now stay within the SAP ecosystem rather than wander off to find somewhere else to play. This stuff is valuable – dare I say essential – if people are to build S/4HANA extensions, Business Suite extensions and new applications for the SAP ecosystem.
You can’t just let that all that deep enterprise understanding and experience disappear when it will be so important for building successful SAP Cloud Platform applications.
I always thought about it… Finally Sap has listened to my voice… Looking forward to access it in the cloud.
Graham will the trial user work for this and when this is expected to be rolled out?
I think we all wanted it. I kept telling my boss - move to on-premise. Now the cloud is looking good too.
Thanks for your comments Vishnu,
The best place for your questions is the FAQ.
Cheers
Graham Robbo
Well said and 1000 likes from me. The "no ABAP in Cloud" strategy was certainly causing a lot of disturbance in the ABAP ecosphere, to the point where the ABAPers started to jump ship and urgently moving to the greener (or at least not barren) pastures.
Of course, "ABAP in Cloud" does not mean that the ABAPers can just sit back, relax and don't bother learning anything else. But at least it relieves the anxiety and, as you correctly noted, provides a way to preserve the intellectual property built by the ABAPers so far.
Hi Graham,
Well written article, but I do not fully agree your conclusions and want to add some points.
I disagree with "unlike". It should read "like in other programming languages".
Your biased comparison between ABAP developers and “the rest” of developers show that you did not yet meet good representatives of “the rest”. There are many rock solid mission-critical enterprise applications in Java that run 24×7 – really, without long downtimes because of EHPs and Netweaver release upgrades etc. Most likely a lot more than in ABAP.
I do not see the correlation between integration and failure. There are late, costly and failed projects without integration.
The integration topic is always concerning at least two parties. The ABAP developers probably are used to the ABAP monolith and data centered development and less experienced in service based thinking and architecture principals like encapsulation. This is crucial for integration and good Java developers have internalized this. This also leads to communication issues, but it should be pointed out that “the rest” has got its valuable non-syntax skills, too. I doubt that ABAP developers are in advance in integration knowledge.
Putting all together, ABAP and “the rest”, the result is more than the sum of each part. Integration is manageable and adds a lot value and long-term quality.
Regards
Hi Rolf,
Well - you are on an SAP forum with a whole lot of ABAP programers. But...
I really love your comments. So the rock solid mission critical Java programs 24/7. I smile. Yes, there probably are a lot of Java programs that are 24/7 and are amazing. However, there are (SAP only) more ABAP developers than JAVA. That's because SAP itself is written in ABAP - for the most part.
And it's interesting that you point out ABAP programmers can't write integration programs. We have so many tools to write great integration programs for incoming and outbound records. We have to understand the relationship to get the interfaces correct. There is also times where PI comes into play.
A generic statement that ABAP programmers are the only ones who have to know more than syntax. I have to agree with you. Programmers in general have to understand the business needs and what they can do for them. Then they pull together how the tables, files, objects, will work to get the data. Sound familiar? I'm sure you do this. I'm also sure some ABAP programmers do not do this. I know some that can only work from very detailed specs.
So as a mainly ABAP programmer - I understand your frustration. Possibly something you could write a blog about? A long time ago, I wrote a blog about being "Just" a programmer. It's not fun feeling like you are undervalued.
Graham's post was meant to make all of us feel a little safer in our jobs. (ABAP programmers) It also is designed to make us push to understand even more. Graham's post made me happy and thinking about what I can look forward to. I am picking up other language skills as I go along! It's so much fun. That's what I LOVE about SAP - constantly changing and learning.
So leave your comments to make us all remember you are out there. And take a look at some of Graham's other post. He knows a lot more than "just" ABAP too.
Have a great Monday!
Michelle
Hi Michelle,
Thanks and cheers to your encouraging reply. Changing and learning rocks!
Regards
Rolf
Thanks for your comments Rolf,
I absolutely take your point that I might have "over-egged" some of my observations when comparing ABAP developers to other developers.
It would be awesome if you could collect your thoughts in a blog post for all to see? #seewhatididthere
Great to engage with you.
Cheers
Graham Robbo
I might as well just turn it around and say that if that's your impression of ABAPers then you have not met very good ones either. 🙂
ABAP Rocks!
Of course it does Abdul - and just because I can let me also say that abapGit rocks too.
Cheers
Graham Robbo
Nice article Graham.
I have seen many SAP PI/PO developers, who dont write any abap programs, yet much better in integrating SAP systems with non SAP systems.
Nice article with lot of justification,
increased scope for ABAPers on SAP cloud.This was one of my strong belief like how SAP came up with web dynpro for ABAP/JAVA options.
Hi Team,
what is GA (General Availability) date for ABAP on Cloud? Do we have beta version available for some customer?
Thanks
No firm dates yet.