What Does SAP Say About the Future of ABAP?
One of the hottest topics at SAP TechEd 2007 was the changing nature of the SAP developer skill set. It’s easy to see why people care so much about this topic: SAP customers don’t want to find themselves with a development team that lacks the skills to implement the latest SAP functionality, and SAP programmers are facing enough challenges without having to worry that their skills will no longer be needed on project sites. So what’s the latest on the future of ABAP?
I have written about the evolution of SAP programming on this blog before (check the "ABAP" category at the bottom of this entry for more posts on this topic). It’s a subject I will return to frequently. I also touched on these themes during my "TechEd in Review" podcast with Krisha Kumar of Enterprise Horizons.
One of the benefits of going to TechEd is talking directly with folks from SAP about the road ahead. So when it came to the future of SAP programming, who better to ask than the SAP Labs team? One of the guys at SAP who is doing the most interesting thinking on SAP development is Thomas Jung. His four hour sessions at TechEd on "ABAP Development: Update Your Skills to SAP NetWeaver 7.0" were some of the best attended workshops at the conference.
In the following section from my longer piece on TechEd, I incorporated a few of Thomas’ insights with some of the most memorable comments I heard from Vishal Sikka, SAP’s Chief Technology officer. Here are the highlights from that part of my article:
I get a lot of questions from readers who worry that ABAP is dead. They point to ominous signs: they tell me that all the new SAP programs are written in Java (not true), and they are concerned that the NetWeaver CE is an exclusively Java-based environment (true). The NetWeaver Developer Studio is also almost exclusively Java-based (also true).
But ABAP is not as dead as some might think. During my group interview with SAP CTO Vishal Sikka, he said that there are still 238,000,000 lines of ABAP code in SAP. The message? ABAP is still entrenched in SAP, and SAP is still entrenched in ABAP. Vishal also noted that while some new SAP programs are written in Java, some are written in ABAP too.
ABAP is still making its presence felt: some of the new NetWeaver PI functionality was written in ABAP. You might not see it when you work with PI, but the ABAP is there underneath, keeping things humming along. True, I talked to some SAP representatives who didn’t even know if ABAP was part of NetWeaver at this point, but the SAP Labs team assured me that it is.
Thomas Jung of SAP Labs, who writes an outstanding developer’s blog on SDN, told me that some of the underlying NetWeaver functions were written in ABAP, and of course there is the Web Dynpro for ABAP. Jung also told me that the ABAP Workbench is indeed part of NetWeaver, and is being equipped with many of the bells and whistles that the Java side of NetWeaver is receiving.
So, ABAP is still a valid part of the SAP landscape. But there’s no question that when it comes to designing new enterprise services, Java is the language of choice in most cases. No, we can’t say that the ABAP outlook is dreamy, but it’s not going away anytime soon.
On the other hand, we must remember the warning Vishal Sikka gave me during our interview. He feels strongly that the entire SAP landscape is changing, and that the emphasis on ABAP versus Java is not the right way to understand the transitions that are underway. The design of the new eSOA NetWeaver development platform is specifically intended to make it irrelevant which programming language you are using. The eSOA layer is designed to work with any open standard, so between eSOA and PI, programmers should be able to use their environment of choice and be interoperable with SAP.
Of course, Vishal would go farther than this, as many executives did, to emphasize that SAP’s modeling tools (Visual Composer, the upcoming Aris for NetWeaver, as well as a new Eclipse modeling environment) are all designed to change the development process and emphasize the design of re-usable components over arduous hand-coded customizations.
Soon, these modeling environments might even generate enough automated code to make it possible for the "Business Process Experts" of the future to do all the development work. Some have suggested that as much as 70 percent of all hand-coding will go away once these tools are fully realized.
So that gets us beyond the ABAP-versus-Java debate to a much broader debate on the future of development work in general, inside and outside of SAP, in an SOA and visual modeling world. That discussion goes beyond the scope of this piece, but we’ll return to it in future columns and podcasts. "The future of SAP development," and more specifically, the skill set of the "SAP developer of the future," will be a common theme on this web site.
For now, I won’t go into more detailed advice for developers, except to try to get your hands on all the new modeling tools, to check out in particular the new CE environment on SDN, and to also check out the BPX community to get a better feeling for the convergence of IT and Business.
November 9th, 2007 at 1:52 pm...
Howdy JonERP.com readers.
After I posted this initial blog entry, I asked Thomas Jung to take a look at what I had written and add any clarifications.
Here is what Thomas had to say: “Jon, nice articles. I did see one thing I thought was interesting. You said, ‘But there’s no question that when it comes to designing new enterprise services, Java is the language of choice in most cases.’ You might want to ask someone at SAP what nearly all of Business Suite and Business by Design Enterprise Services are written in. You will find that the answer isn’t Java. But you make an excellent point in this article: does it really matter if the Enterprise Services themselves are written in Java or ABAP? No, not as long as the results are ‘open standards based.’”
Thomas went on to add: “Yes, to the outside world, it really doesn’t matter if it is ABAP or Java, since either way, the services are exposed via open standards. That is true. But at the same time, it is important to note that we continue to leverage the investment SAP, its partners and its customers have already made in the business logic written in ABAP. Our ESOA strategy doesn’t mean that you have to discard that investment. Quite the opposite. You can continue to gain benefit from that investment while also extending it to new and open opportunities.”
Perhaps the most important point Thomas wanted to get across to me, and to the readers of this blog, is that the question of whether Enterprise Services are written in ABAP or Java is not the most key issue. Thomas wants us to remember Vishal Sikka’s message that the underlying programming language is not as crucial as understanding how SAP is “wrapping” the code and exposing applications via Enterprise SOA.
So how do we summarize the question of whether ABAP is dead? We can start by saying that you can’t answer it completely in one blog entry. We’ll return to this topic frequently as more information comes to light.
But for now, we can safely say that ABAP is not going anywhere. It’s also becoming clear that whether you’re an SAP ABAP person or an SAP Java person, if you don’t make a commitment to understanding the latest generation of modeling tools (CE, Visual Composer, Aris for NetWeaver, etc.), and how they fit into the emerging Enterprise Architecture, you’re going to be left behind.
As of this writing, the final word on “is ABAP dead?” is not “yes” or “no.” The answer is that we’re asking the wrong question.
December 9th, 2007 at 11:28 pm...
I still wonder we are thinking in terms of SOA,SaaS,REST architecture and still we are lokking for a particular language, i think there are so many options now like Groovy,Rails,PHP,JEE. java is becoming a platform rather than a language.
December 10th, 2007 at 10:13 pm...
Puneet,
I don’t disagree with your comments. It remains to be seen how well the big ERP players like SAP and Oracle truly “play nice” with open standards and options like Rails or RHP. And we have to see how some of these new platforms can handle high volume transactions on an enterprise level securely.
To me, the best thing to do is to strike a balance between learning the skills clients need now, while also keeping one eye ahead to the trends in the SAP development world. You’ll be glad to know that it looks like in early 2008, I’ll be doing a podcast with Thomas Jung of SAP Labs on this site to get into those exact issues.
The podcast is not a done deal yet but it looks promising. Either way, I’ll continue to post content on these themes as we look forward.
- Jon Reed -
February 18th, 2008 at 7:13 pm...
Hi Jon, hope you are doing great! I have been working in SAP Since the last 6 years and I have been a workflow consultant all the last 4 years; now my company is assigning me to work on non-workflow projects….as an ABAP developer. Should someone who has good expertise in Workflow consider going back to work on ABAP or continue working on Worklflow…Please advise…Thanks, Yogesh.
February 20th, 2008 at 8:24 pm...
Hi Yogesh.
Thanks for your question. “The Future of ABAP” and SAP Development is an important topic on my web site. Make sure to listen to my podcast with Thomas Jung of SAP Labs which is now on the JonERP.com home page. It’s important to remember that all ABAP is not the same. As Thomas points out in the podcast, object-oriented ABAP skills put you very much on track with where SAP is going. So, I wouldn’t assume that ABAP is a setback in your skills.
Also, I have never been all that confident in Workflow as a focus of your SAP skill set. That’s only because I have known very few successful SAP Workflow consultants over the years, and that goes back to 1995. I have always liked Workflow as a component of a development skill set, but only a small selection of folks have had good luck specializing in SAP Workflow. When you think about it, this is kind of surprising, because Workflow should really help with automating core SAP functions and you would think there would be very strong demand for this skill set.
There is some demand for Workflow, but it’s just never been a super high demand market. So, I would say that the combination of Workflow and ABAP is often better than one or the other, so it may be a false choice you have set up. Having said that, if you have a real passion for Workflow and your company is pushing you in another direction, then maybe you should go ahead and leave that company and look at continuing your Workflow skills elsewhere.
If you do continue in Workflow, I highly recommend looking into Guided Procedures, the new SAP Composition Environment (CE) component that is, perhaps you could say, “Workflow on steroids.” Here’s a good SDN link on Guided Procedures…
I have seen a lot of buzz about Guided Procedures and this might fit in well with your overall Workflow skills. Good luck!
- Jon Reed -
January 26th, 2009 at 4:06 pm...
Enough of all this ESOA, Web Services and Java. Can any body give me stats on if anyone is using those services? Anybody consuming those thousands of services being published exposed by SAP? Why would businesses invest in those services? I don’t think any SAP ERP implementation is possible without ABAP customization/enhancement.
January 27th, 2009 at 9:14 am...
Thanks for your strong words Dharmaveer. You cannot arrive at the truth without dissent. One of the reasons I wrote this entry is because SAP still believes that ABAP is very important and still invests a lot in ABAP environment support, even within NetWeaver. So, I writing this entry to support ABAP more than anything because many seemt to think it is dead! However, it is important to keep in mind that the SAP’s Composition Environment is entirely Java-based. Putting eSOA aside, there’s no question that Java and web-based programming have continued relevance in SAP shops also.
Keep in mind as well that Business Objects is entirely a Java-based environment, and this product is certainly a key part of SAP’s future as well. So, Java is not necessarily just about eSOA. And remember, it is going to be possible to do some eSOA work in ABAP as well.
As for SOA, no one knows exactly what will happen with the future of SOA. Some customers have reported good case studies on their SOA installs - you can see some of these webcasts on SAP.com. I’m a small shop myself and have not been able to conduct a comprehensive research on SOA myself. But it’s good to remember that SAP is banking a lot of their future on SOA-based principles. They may be wrong, but they are certainly serious about SOA. No one if forcing you to learn anything you don’t want to learn, so that’s the good news. If you think SOA is hype, ignore it and go on your way. Same with ABAP.
- Jon Reed -
February 7th, 2009 at 4:55 pm...
Thanks for throwing more light on my questions Jon. Yes you made a point that Business Objects is a key part of SAP’s future and that Java and ABAP are equally important.
You are right that ABAP is Alive and Kicking.
To those who think ABAP is dead: You can’t implement SAP ERP without ABAP guy but u can certainly do it without having a Java guy in your team. As of now even if you are a functional consultant and if you know little bit ABAP u can easily look at the program (which is of course in ABAP) and understand the functionality in order to implement or customize it.
Regarding learning new things, ABAP guy can learn the domain and become a very good techno functional consultant. But if he tries to learn JAVA then he’ll be gone from both sides
I strongly support SOA but wondering if customers are really using that in SAP world. Maybe my experience is too little for that. I’ll try to look for the webcasts.
Regards,
Dharm
May 8th, 2010 at 10:23 am...
Being a SAP-ABAP consultant I will always say that without ABAPers SAP implementation is just impossible.
But at the same time I agree with the Jon’s last statements of the blog.
He is saying that - “if you don’t make a commitment to understanding the latest generation of modeling tools, you are going to be left behind.”.
There is no alternatives to learn new techniques, so whatever is Jon wants to share is hundred percent true.
Jon I think this will be a great blog for those who are really afraid to be in ABAP.
Thanks for your blog and explanation.
I have one thing to ask you -
Jon if you can emphasize on what one should look into while working on ABAP, I am an ABAP consultant and want to look after some functional module. Can you please shade some light on doing what will help me/people like me in future?
Thanking u in advance.
Regards,
Ravi