ABAP is here and it stays in the DNA of SAP even in the New Age of SAP Development

After having followed the other blogs you will have your own SAP Cloud Connector (SAPCC), your own NW ABAP, both of them running in separate Docker containers on your own laptop, and you’ll have setup all configuration needed to connect your very own NW ABAP through your SAPCC to your own SAP Cloud Platform (SAPCP) trial account – non-trial works as well. You will also learn how to configure Principal Propagation which basically allows you to get Single-Sign-On (SSO) easily working.

In the end, you’ll learn how you can manage your users and roles on your own NW ABAP as the central user store while syncing them to your SAPCP account using one of my favorite SAPCP services: the Identity Provisioning Service (IPS). With our setup you can control on your (on-premise) ABAP system which Fiori/UI5 applications running in the SAPCP are visible for your users. Docker will be part of the SAP ecosystem in future, and you’ll see some Docker basics in action in the blogs. Of course, you will see an in-detail demonstration of everything so that you can follow each step on your own. In the end, you will see and understand the following setup which should also help you making better decisions (abstracted + avoiding the details for now):

All resources used in the blog are available free of charge, and you’ll see where to get them from (of course, the SAP software is only for your private and non-productive usage). I’ve already published content on GitHub and YouTube (all free of course), stay tuned to see where exactly – or google for it if you can’t wait.

Seeing is Understanding. Understanding before Deciding.

About a thousand years ago the Persian poet Ferdowsi was offered by a sultan one piece of gold for each couplet he writes in the “Book of Kings” (Persian: Shahnameh). A book that shall manifest the historical and mythical past of the Persians prior to the Islamic conquest of Persia in the 7th century. Ferdowsi agreed and planned to spend the gold on rebuilding dykes. After having spent almost his whole life to write this masterpiece of literature Ferdowsi proudly went to the sultan to receive his very own honor after 30 years of passion and hard work. The legend that I choose here claims that the sultan took the epic book and payed Ferdowsi without even looking into it; he threw a few pieces of gold in front of Ferdowsi’s feet. Ferdowsi was deeply hurt by this reaction, he rejected the gold and left without the book. Years later, the sultan had a look into the book. Now he understood how much he had hurt the poet. Immediately, he decided to send a huge amount of gold to Ferdowsi. Ferdowsi never received the money; he had died without even knowing about the late recognition. The sultan desperately regretted his own behavior and felt ashamed to the remainder of his life. Today, every Persian knows about Ferdowsi and his Shahnameh, but nobody cares about the sultan. The sultan made a decision without even looking into the book.

Motivation

I strictly believe that Seeing is Understanding. And Understanding before Deciding is the right way. Within the last years I keep seeing SAP customers running their On-Premise SAP systems with an outstanding availability and performance. At the same time some of them simply don’t want to jump on SAP’s cloud train for different (arguably good?) reasons, i.e. just to name a few:

1. We don’t want our business data in SAP’s cloud!

2. We don’t want to have our user data in any cloud!

3. We don’t want our data to be spread across cloud infrastructures used behind SAP Cloud Platform (SAPCP) like Google, Amazon, Microsoft,…!

4. We want to keep our custom apps and processes in terms of “Intellectual Property”, not SAP and no one else should see or have our code or “gain” our business process know how!

5. We have a much better availability than SAPCP

6. We don’t see any benefit as of today because we have everything we need On-Premise

7. Every time the SAPCP is not available it would mean we’re not making hundreds of thousands

8. If our data runs through their infrastructure at runtime, then who knows what data they are logging? Nothing? All? Passwords? Business Data?…

9. We can’t use the Cloud because our ABAP was never made for the Cloud.

I can’t answer all of the questions, but I can offer this blog  including videos allowing you to answer some of the questions on your own. I’d also like to correct wrong assumptions or rumors derived from unclear communication or unclear knowledge of how things work together. In fact, I have made a demonstration for one customer with basically the content of the blog. Guess what: while seeing what I demonstrated, they started to understand – and suddenly a constructive reconsideration and discussion about using the SAPCP seems to start soon.

Another motivation for writing this blog is helping native SAP developers aka ABAP developers to understand how they can join SAP Cloud development with the ABAP skills they already have today – and that works even today prior to the release of ABAP in the Cloud (which I expect to arrive hopefully later this year). Furthermore, the more ABAP developers see and experience the new age of SAP development they start to understand. This understanding will shift automatically to the management of the companies they work for causing more awareness. And that finally helps to make better decisions instead of “Is it cloud? Get out of here!” (exaggerated). In the end, I firmly believe it’s not about Cloud vs On-Premise, it’s more about using the “best of both worlds” together for given scenarios. In fact, using the “best of all worlds” is even a better wording to me. And again, before deciding how to use the best of all worlds together we need to understand how things work first before we decide for the “how” when implementing the chosen solution for achieving the “what”.

While the SAPCP is maturing more and more, it’s not too late for SAP backed companies reconsidering their cloud strategy as part of their technology strategy (in case they are still avoiding cloud). Don’t be like the sultan, don’t wait until it gets too late while your competitors leverage from the new power they suddenly got thanks to SAPCP. Instead, start reading the book – now. Then you will understand before making the decision. There are simply too many rumors out there, get your own experience. And I’d like to help you seeing really cool things in action. And guess what – you can keep your ABAP systems and your ABAP developers together with all their experience!

We have native and non-native SAP Developers

We’ve all been watching how SAP has become more and more a first-class technology company over the last years (of course besides their unique and outstanding business know how etc.). “SAP is a technology company” – these words we would’ve never said let’s say 15 year ago, do you agree? The strong shift to technology has opened doors for many non-native SAP developers.

As a native SAP developer I would definitely call someone with ABAP background. A unique selling proposition of ABAP in the past has been (but not only) offering career changers to step into software development. I remember one of the best developers on our team about 15 years ago was a theologian – that’s not a joke! His code ran perfectly without any prayers! I’ve met so many ABAP developers with different backgrounds; biologists, chemist, pedagogues, historians,… That really is diversity! It’s worth to mention that I have never seen more career changers anywhere else in software development than in ABAP development – not in Java, JavaScript,… Of course, there have always been developers with a more technical background as well, i.e. computer science, business informatics, electrical engineering, mechanical engineering, maybe I should also count in mathematicians and physicists. These I would call more the technology affine ABAP developers while the career changes were typically more the business affine ABAP developers. It’s a benefit to have people of both groups on our projects, as it increases team diversity and thus (according to research) it positively influences software development agility (MIS Quarterly Vol. 34 No. 1/March 2010). The native SAP developer feels familiar with the SAPGUI, SE80, and related SAP/ABAP “features”. For many of them we are talking about decades of experience – what a treasure!

A non-native SAP developer to me is a person that does not necessarily know ABAP very well or not at all. Their background is typically something that is used almost everywhere outside of the SAP ecosystem for software development (actually used inside of SAP as well). For example, I clearly think of JavaScript (server side or frontend), HTML5, Java, .Net (C#,…), PHP, Perl, or maybe classic web development in general including all the great frameworks available as OpenSource, git, etc. All these people with their great skills can suddenly work easily in SAP environments even without touching ABAP at all. That works even better today, also thanks to the increased focus on technology by SAP. I’d say it all started with HANA and SAPUI5 (Node, JavaScript, HTML5,…). With the SAPCP Neo environment additional Java professionals were attracted. And with SAPCP Cloud Foundry the technology journey even continues to higher spheres by allowing “Bring Your Own Language” (BYOL). On the path, there is clearly Docker, Kubernetes, and related technology. All that stuff has been around for years if not decades, and suddenly all that cool stuff is now part of SAP as well – how cool is that? You’re right: this will attract even more developers not having classical background in native SAP technology. That’s amazing, because getting experience from outside into the SAP ecosystem will definitely help in terms of progress!

New Age SAP Development

That brings me to the term I used above: New Age SAP Development. IMHO, I’d say that the new age SAP development allows developers doing anything, from anywhere, at anytime, using the best available tools and technologies they want. Well, that’s too abstract, here is an example: last year I coded a fix during on my vacation somewhere on an island for one of our customers using the SAP Web IDE. Still a little too abstract and not a really good example, right? Think of it that way: the new age of SAP development includes the skills of both your native SAP developers, your non-native SAP developers, and all non-native SAP developers from outside the SAP ecosystem! This can only be an advantage, right? The basis for that is the SAPCP. Also keep in mind, that SAP and SAP partners as well are already offering solutions that require an SAPCP account, so the direction is pretty clear. And there is already some pretty cool stuff out there. The new age of SAP development comes with new tools and technologies, while modernizing existing tools and technologies in order to make them cloud-ready. A valid question raised is: What skills do my SAP developers need now?

That’s a tough question, and my answer will most probably not be accepted by all of you. What ever a The Well Grounded SAP Developer is, I think she should be as close as possible to being a Full-Stack developer. I’d expect ABAP + ABAP related stuff to be part of it, as well as JavaScript for the frontend and backend. Knowing about HTTP, REST, and web technologies is fundamental. This will make it easy to learn OData. Don’t forget SAPUI5! And with some JavaScript experience you can also start your first experience with native HANA via XSA. So I’d definitely add HANA to the list as well. Getting to know git is fundamental, too! And then there is the SAPCP. I want to avoid picking any specific features/services of the SAPCP as “must have”, but if I had to then I believe starting with the Portal Service + SAP Web IDE (and currently there are different Web IDEs) to create your first SAPUI5 applications could be a good start. Connecting them via destinations and Cloud Connector to your ABAP system will give you an “aha effect”. And that’s all part of this blog (except HANA and XSA). Now adding Fiori, Agile/LEAN/Scrum, etc. would make you The Well Grounded SAP Software Engineer. And that’s actually the term that I prefer, because we want to “do the right thing right”! Why didn’t I add Java, PHP, Perl, Go, iOS,…? Feel free to add any of them, really! The point is companies will find a common denominator. If everybody brings in her own language, framework, etc. into companies then this should definitely be aligned with the companies. Be careful, we’re talking about fragmentation of technologies in enterprise software! We’re talking about maintainability and extensibility – what if your only PHP developer left the company and suddenly her cloud service doesn’t run anymore? What else would you add to the common denominator? I’m really interested to know, simply leave a comment.

I know some people might prefer to kick ABAP out of the list. ABAP? Isn’t it dead? This brings me to my next motivation which deserves a separate headline.

ABAP vs Other Programming Languages? Stop the Debate!

Recently, I’d say within the last 2 years, I’ve seen an increasing number of blogs and people discussing the relevance of ABAP, ABAP skills, or even the relevance of ABAP developers in the new age of SAP development (sometimes only between the lines, sometimes very obvious). I never left a comment, but I really enjoyed them with popcorn. Without offering any references (because I want to avoid finger pointing, also some of the comments were deleted), I remember comments like (not exact wording, not saying right or wrong):

◉ As an SAP consultant I never needed ABAP within the last 20 years

◉ ABAP salaries are decreasing

◉ ABAP developers are too expensive for what they can do

◉ ABAP is an outdated/dead language

◉ Java is superior to ABAP

◉ JavaScript is a better choice

◉ ABAP developers don’t want to learn new things

I know some ABAP developers read those blogs as ABAP bashing, or as an aggression against ABAP developers, even though this was maybe not even the intention of the blogs/discussions directly. Interestingly, I don’t remember any bashing from ABAP developers against other programming languages or non-ABAP developers except for one article discussing that “ABAP developers are not stupid” (and that was not a real bashing). I hope you get how far this has gotten. What I read is actually not really new to me: I do a lot of stuff including frontend, backend, ABAP, non-ABAP, Scrum, SAPCP,… And I’m happy to learn new stuff while accepting anything I don’t know as a new challenge. Not having only a hammer really helped me a lot not seeing everything as a nail. I discussed and worked with people sitting in the different “corners” of the room, while trying to convince people being open minded for the one or other technology, programming language, platform, framework,… Often I’m convinced by my colleagues. All is well, as long as we have reasonable and rational arguments – and they must be constructive!

IMHO it’s not even fair to compare the ABAP we know today with other programming languages. That’s because ABAP is way more than just a programming language. This reminds me of comparing SAPUI5 to Angular etc – even that is not a fair comparison. By the way, what’s better: Java or C? Java or C++? PHP or Assembler? JavaScript or Java? A chair or a car? I remember such discussions while studying computer science in my first semester. Today, I avoid these kind of discussions because in most cases they don’t help anyone and they are more like comparing apples with oranges without a clear context or goal. Often, there might also be some personal interests behind the discussions. Remember how everybody suddenly talked about NetWeaver around the early to mid 2000s (ESA, ESOA, SOA… OMG)? At that time SAP NetWeaver Java was introduced, and SAP decided to implement their own JVM. I clearly remember discussions claiming that SAP wants to get rid of ABAP and will replace all ABAP code with Java. Well, if you’ve put all your money on that bet then you would’ve been bankrupt today. I guess these people would feel ashamed today – just like the sultan, if they remember what they said back then. Sometimes, we implicitly think spreading the word about things we don’t know very well as being “unimportant”, “weaker”, or “uncompetitive” could lead to “strengthen” our own situation (i.e. we get more important because we claim to have the right skills).

In fact, ABAP itself is a pretty modern programming language. Believe it or not, but with ABAP, SAP is actually one of the very first OpenSource companies – something that has opened the doors for a unique way of customizing and extending standard solutions! ABAP has served SAP to become the market leader with more than 75% worldwide! ABAP even has some pretty cool and unique features other languages often do not have. On a regular basis, pretty cool new features are introduced into ABAP, which means we have an ABAP evolution! So, SAP is really investing a lot into the progress of ABAP. And don’t forget that ABAP in the Cloud is on it’s way! Soon in future, I’ll expect we’ll have something like an ABAP MicroProfile (Java EE / Jakarta EE know the term MicroProfile), allowing ABAP developers to create ABAP based MicroServices and running them in the cloud, i.e. via SAPCP CloudFoundry, Docker, Kubernetes… We can also expect that SAP will introduce further unique features into the “new” ABAP in the Cloud – and SAP knows better than anyone else what an Advanced Business Application Programming language needs. They keep improving ABAP.

The conclusion is simple: ABAP is not dead. It is living more than ever – both on-premise and in the cloud. ABAP is here and it’s here to stay. ABAP stays in the DNA of SAP – period. However, DNA can change, and thus ABAP will change. Let’s stop the debate and acknowledge the best of all worlds. The truth is ABAP developers should be prepared to learn new stuff, while others should probably start thinking about adding ABAP to their skills. At least on a level that allows us to understand before making decisions. And that’s exactly one goal of this blog. Making decisions based on a wrong understanding are the best ingredients for prejudice.

How to teach old dogs new tricks?

I still have decades to code before I get retired, but sometimes I feel old seeing all the cool stuff the new kids on the block can do. It turns out I have to learn new stuff pretty often, and often I learn from those new kids. The SAP ecosystem is rapidly changing these years, and this rapid change happens outside of the SAP ecosystem as well. A lot of that change is happening around all the different clouds, but we’ve got also web development changing rapidly, and even more… It can be hard for some of us to cope with all the change. At the same time, we know changing old habits is already hard enough. However, I believe it could be possibly easier for technology affine ABAP developers than for business affine ABAP developers to step into the new age of SAP development from a technology perspective. This is no generalization at all! My suggestion would be to keep having diverse teams in order to foster team learning. Make sure to understand that this can also be a change of mindset for some of us. Organizations are asked to offer the space and environment making it as easy as possible for people to learn new things – be it alone, or from others, or together.