ABAP is here and it stays in the DNA of SAP even in the New Age of SAP Development
Welcome to this little blog series. I’ll add the missing links once I publish the other blogs starting next week:
- Part 1: ABAP is here and it stays in the DNA of SAP even in the New Age of SAP Development
- Part 2: Installing SAP Cloud Connector into Docker and connecting it to SAP Cloud Platform
- Part 3: Installing SAP NW ABAP into Docker
- Part 4: Configure SAPCC + NW ABAP for Principal Propagation + Docker Network config for both Containers
- Part 5: SAPCC, NW ABAP, SAPCP config for the Identity Provisioning Service to sync users from ABAP to SAPCP
The target audience of this blog series is
- ABAP Developers
- Non-ABAP Developers
- On-Premise ABAP diehards
- SAP “Learners”
- Developers who want to follow some of the OpenSAP courses easily on localhost
- People who want to see if some of the prejudices against SAP Cloud Platform (SAPCP) are correct
This first blog in the series is basically describing my motivation for writing the other blogs. 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 series 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 for this blog series
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:
- We don’t want our business data in SAP’s cloud!
- We don’t want to have our user data in any cloud!
- We don’t want our data to be spread across cloud infrastructures used behind SAP Cloud Platform (SAPCP) like Google, Amazon, Microsoft,…!
- 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!
- We have a much better availability than SAPCP
- We don’t see any benefit as of today because we have everything we need On-Premise
- Every time the SAPCP is not available it would mean we’re not making hundreds of thousands
- If our data runs through their infrastructure at runtime, then who knows what data they are logging? Nothing? All? Passwords? Business Data?…
- 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 series 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 series. 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 series 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.
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?
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
- 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!
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 series. 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.
Wow exciting blog series -- really looking forward to seeing all of these blogs! Thanks for sharing.
Looking forward to hearing opinions about ABAP being here to stay 🙂
Waiting to see the following blogs of the serie!
Wow, this looks like being an exciting blog series, Nabi. I agree that showing people new technologies in action really helps them to see the potential.
I think the project team of the future will be a 'blended' one. There might be dedicated ABAPers, web- and cloud-natives with zero ABAP experience and also a few people with both. The good news is that everyone should learn a lot from everyone else! What many long-time ABAPers bring to the party is 'deep insight' into how SAP modules & systems work. That knowledge is priceless even if the latest project is being written in another language.
SAP passed up the opportunity to 'kill' ABAP when they decided on the architecture for S/4HANA. Now, with the cloud ABAP investment, it seems that they are doubling down on that bet. I often joke to people that I'm convinced that some of my ABAP code will outlive me.
I await the rest of the series with interest...
I absolutely agree, Mike Doyle: "The good news is that everyone should learn a lot from everyone else!" That's team learning, and there is research about it.
To be honest, I don't even believe SAP really ever considered to kill ABAP. I'd love to hear comments from the "inner circle", only for entertainment 🙂 It's just interesting how this topic comes up from time to time, typically when there are larger technology disruptions coming into the SAP ecosystem. Apple has a unique ecosystem allowing them to "do things only Apple can do" - that's their marketing! Sometimes, I use the same slogan for SAP: "SAP has a unique ecosystem allowing them to do things only SAP can do". Having the "ABAP platform" is such a major component for that, and without it SAP would only be yet another provider of repetitive technologies.
Thanks Nabi for the great blog, waiting for the rest of the parts. As clearly pointed out by Graham Robinson in one of his old blogs A Call to Arms for ABAP Developers keeping our skills up to date is the priority. We shall be open to all programming skills and ready to learn.
ABAP is not dead for sure, important thing to understand is ABAPer's have to start becoming receptive to this paradigm shift and change, be ready to learn and embrace the change. One of the ongoing OpenSAP course regarding cloud native, the prerequisite is to understand what is Java, Spring, Maven etc.. The list goes on.
The plus point which we enjoy as an ABAPer apart from Non Native one's ,is that we know how the SAP system works, how different things communicate in SAP etc. This is kind of actually a headstart for Native ABAP developers to learn as much as they can the new stuff.
PS: I have see this happening where a non native guy had trouble handling gateway etc. where as a native guy handled gateway in a better way after just being trained only for 1 day, the reason being he understand the SAP system well.
Thanks Nabheet Madan, I almost forgot the great blog by Graham Robinson because the new SAP Community doesn't show my old bookmarks/favorites - still!
Your GW example reminds me of an experience which I have added to my "all time classics" memories: I guess because of my background my customers often ask me to work not only with SAP developers, but also with developers that work in departments outside of my customer's SAP organization. So I do work with web developers (think of AngularJS, Angular, Vue, Polymer), .Net/C# developers, Java developers,... When I typically show up I'm typically the guy "that only knows SAP" until they find out I speak their language. When I introduce Apache Olingo & OData to the Java and web developers the first feedback is typically "It's from SAP, so it can't be good. We have better options", or "SAP doesn't really know about Software Engineering". That's what I call biased. After giving them a training about SAPUI5 and OData they were pretty much excited with comments like "We were told it's from SAP", "If we only knew we could have saved so much time, trouble, and spaghetti code",... So the initial problem here was that without seeing and understanding the decision was already made - that's wrong prejudice, and thus the decisions made were not rational. Then I was sent to the .Net team to show them the benefits of SAPUI5, Fiori, and OData. When I started talking about OData someone raised his hand and said "How about Security? Do you think OData is secure?". I was irritated by the question although I had a feeling what's behind the question. So I thought a few seconds and answered "Yes, you can use HTTPS...". Then I was challenged with "I don't agree, because our consultants directly from Microsoft suggest us not to use OData because it's absolutely insecure". Excuse me? OData is actually from Microsoft, and it's supported by many of their Products (not only Excel), and you really think it's insecure? Unfortunately, he could not elaborate, because he just repeated a statement from someone he might not have clearly understood. Claiming OData is insecure because i.e. it could expose too much data which could lead to DoS etc would also mean any other REST queries not based on OData would have the same problem. It's the developers responsibility to take care of such things. This is yet another example of having prejudice against everything that seems to have an SAP label on it. Same with UI5 by the way: after sitting with the Java + Angular developers for 3-4 hours on the same desk migrating one Angular app to UI5/Fiori there were no rational arguments against UI5 (instead I found bugs in their Angular + Java/Jersey based REST services). These are examples illustrating we all should be open for new learning and we should have an open mindset. And that's part of the DNA of the profession we chose: Software Engineering.
I know it's not a replacement for lost bookmarks, and that following by tag doesn't work until you can combine RSS from more than one tag (or until we get ABAP in SAP Cloud Platform as a tag), but as far as Graham and others' articles on ABAP in SAP Cloud Platform, we have a feature on the community page -- I'll be sure to add this to it! :
Looking forward, popcorn + ABAP + Docker, whats not to like :o)
What an absolutely beautiful metaphor at the start of this blog. Outstanding. Great read and lovely to see the art of poetry woven into a tech article.
Thank you, Leigh! Glad to see you recognized.
Hi Nabi, very interesting blog thanks, and a great show case for AS ABAP 7.5 developer edition #ABAP_Trial.
Just one question: SAP Cloud Connector should be included in the dev edition, so why have you included a new one in a 2nd container?
I am looking forward to the rest of the series though!
Best wishes, Julie .
more info on the developer edition here 😉 : https://www.sap.com/developer/trials-downloads.html)
Thanks – the links are already mentioned in my corresponsing github repos, i.e. https://github.com/nzamani/sap-nw-abap-trial-docker
in SAP Store it is clearly mentioned that
So you are correct. However, I did not really use it, and at the beginning I did not find where the out-of-the-box SAPCC was installed. But that's not the main reason for the showcase. What I'd like to achieve is to illustrate things as close as possible to a somewhat real scenario where you often would install both on separate servers (well, I know SAPCC and ABAP are often insalled on the same host as well). However, having separate containers + doing things from scratch clearly illustrates how things work together - with the benefit of some important learning: docker. I believe everybody should get familiar with docker, at least with the basics. The blog series gives a chance start with the basics of docker. You'll also see how to connect to two containers with Docker Networks (instead of using the deprecated docker links). Why doing all the setup by hand? Because that allows to connect all the dots when seeing things in actions.
Thanks Nabi! I was just wondering. I strongly agree re Docker.
Great blog. Reports of ABAP's imminent demise have been a recurrent theme over the last twenty years.
Just curious, but as I have qualifications in Computer Science, Maths and Theology, am I a technology affine ABAP developer or a business affine ABAP developer?
I liked your ABAP bashing list. I know you're not ABAP bashing, but I offer these comments in addition to your own.
I've never needed to configure an invoice process...
I wonder if these two are related. Salaries decrease, so people who are good can earn more doing other things, so quality of developers largely decreases, justifying salary decreases... As I've often pointed out, research by IBM decades ago demonstrated that a "good" programmer outperforms a "bad" programmer, in terms of total cost of ownership of development, by around 50x.
OK - tell that to Horst Keller!
Nah. I program in both. Java is better at some things. ABAP is better at others. For rapid development of powerful applications, I'll take ABAP thanks.
Said no-one ever. 🙂
Sadly, this appears to be true. The majority want to program as it was done in the 1990s. I think their trainers are from that era, and few developers seem to want to move on. They use standard tables instead of hashed or sorted, they use function modules for ALV instead of CL_SALV_TABLE (or the ALV gui framework directly), they use FORMs, prefix everything....
But hey - there's many who do want to learn new things, and are excited to learn - e.g. Test Driven Development.
Good points, thanks! You've got some interesting background(s) 🙂 While I agree to your points, especially telling Horst Keller, I'd like to add a few things...
I try to avoid stereotyping, but sometimes knowing someones background together with some other aspects (i.e. interests, strengths, weaknesses, behavior, attitude, mindset, culture, and many many more) helps to create empathy. And that in turn can help a lot to improve collaboration, create shared knowledge together, work as a team, etc. I know people with a Computer Science background who have become business affine ABAP developers over time (maybe ABAP itself is the reason this can happen). Can someone be both a business affine and technology affine ABAP developer? I'd say yes, and maybe that could be you 😉 However, I cannot answer your question because I do not know much about you. Where do you see yourself? (not expecting an answer)
I agree, these two might be related. However, that's nothing we have only among ABAP developers. In other words: salaries of non ABAP developers (can) decrease as well. There are too many people focusing only on web (ui) development, or only Java EE backend, or Spring while trying to avoid Java EE (now Jakarta EE) whenever possible, or JUnit and Selenium, or Scrum, or still avoiding ES5/ES6/... I'm sure you can add more to that list. Of course, the one who can do it all will most probably get a higher salary compared to others who have the focus only on their island. I'm sure you agree to some extent, because you wrote "quality of developers largely decreases" and not "quality of ABAP developers largely decreases" 😉 The research you mentioned leaves an important challenge: How do I as a company turn my developers identified as bad developers into good or at least better developers? And that includes ABAP and non ABAP developers.
I agree that there are ABAP developers writing 90's style ABAP code. However, while it's tempting to blame them with "you don't want to learn new things" I believe reality is a little more complex. There have been too many companies raising their ABAP developers like sitting in front of their SAPGUI and SE80, not sending them to certain trainings, and doing basically the same things for the last 2+ decades. It's easy to derive that these developers are only a few years away from retirement. And now they are asked to learn new things as the SAP ecosystem has started to open up widely. I'm not blaming anyone for her age, in fact, I have a colleague who will turn 61 in a few months and he really is an SAP/ABAP hero! Part of that is also having the right mindset; something important for software craftsmanship. By mindset I mean both the developer's and companies' mindset. Just like you I'm glad there are many people who want to learn new things! That's a good finish - thanks 🙂
Thanks for sharing this blog series, it’s definitely interesting and widens the horizon for ABAPers. I just wanted share a couple of points.
Is ABAP dying?
Like you and many other commenters mention, that has been a popular gossip material whenever SAP released radical changes in its ecosystem. Actually when HANA platform was released, seeing SAP’s new acquisitions like Hybris, at first made me a little bit anxious about ABAP. Then seeing NW ABAP as an S/4HANA stack, new robust frameworks like BOPF and new features like CDS ABAP, AMDP available, I realised ABAP is going nowhere.
But! Having said that I believe the market for ABAPers will continue to shrink. That has always been the case for a while.
Do you remember when we were building the UIs for applications with dynpros? Back then we never needed to extend our skillset to build UIs. It was ABAP only. Then BSP was introduced but we were still in ABAP Workbench developing applications. Same for WebDynpro for ABAP.
Although SAP was introducing new UI technologies, it was easier for us to learn them. However, it has changed recently, hasn’t it? UI development now is not necessarily a skill that is necessarily sought for the title of ABAP developer; although it does not say ABAPers can learn JS and be full-stack.
Lots of developers coming from non-technical backgrounds. Yes, but this was because it was more or less easy back then. Netweaver and ABAP was taking care of lots of headache for ABAPers so that they only focus on development. For example, were we really thinking how to handle authentication, most of the security aspects? Not really. I have seen very few who utilises SAP authorisations properly. The platform was so big that naturally this type of concerns were isolated to a separate area, i.e. BASIS.
Stepping in the new world where ABAPers need to extend theirs skills now means lots of new things they need to care about. I mean if they step out of the boundaries of NW ABAP.
So rightly, you also advise ABAPers to learn new things while you advocate ABAP’s position in the new world. And that’s a good thing. I studied Electronics Engineering and started my career in ABAP. In the beginning, did not bother learning other things not related to ABAP development. But after a while I cursed myself because you cannot be agile to do some stuff by only knowing ABAP as it needs a relatively heavy platform in place and good that this is changing. How easy was it to get a Tomcat container compared to a NW stack for personal trials. Remember sleepless nights trying to install miniSAP, expecially in the early years of SAP WAS?
Comparing ABAP and others
You are totally right when you say it’s about how to make the most of different options. However, the comparison is not always between apples and oranges. With the scope set right, proper comparison can be made. So, it may be about “developing enterprise applications” with a Java setup compared to NW ABAP. If NW is already given, there is not a choice anyway. If it is about “language features”, again a comparison may hold a value especially if ABAP can make its way out to be a language isolated from the NW platform or at least if NW can become a lighter option.
ABAP salaries decreasing
I believe there are two factors here:
1. Like I mentioned above, ABAP’s presence in the entire SAP ecosystem is shrinking. Both from the technical aspect, e.g. UI development and from product aspect, e.g. SAP Hybris Commerce. Although there are innovations which ABAP is trying to catch up with, e.g. support for native TCP/IP protocols, websockets, etc. These are very specific cases.
2. Historically, ABAP developer roles was attracting higher pays. And this was tempting for many. And like you mentioned it was more open to people even from non-technical background. And now, we have a bit too many ABAP developers in the market.
With ABAP’s presence having a narrower boundary and having many ABAP developers in the market means a decrease in pays. Surely, exceptions will exist.
Ooops. I wrote too much for a comment and should shut up now. Thanks again!