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 250,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.

As one consultant asked me recently, "Is it true that ABAP development and SAP configuration jobs are both going away?

In a nutshell, yes, I believe it is – though there’s no need to hit the panic button. This should be a gradual evolution. However, it’s one we need to pay attention to. A helpful way of looking at it is this: in the SAP eSOA era, IT and Business is converging – therefore SAP technical and functional skill sets are converging.

The first part of this sentence, that IT and Business are converging, is really the great inarguable point that SAP is wisely betting its future on. The second part is the implications of this for technical and functional SAP consultants. The idea that the skill set of the technical and functional SAP consultant is converging is not my own - it was offered up in a workshop I attended on becoming an SAP Business Process Expert that was hosted by Marco ten Vaanholt, Global Director of the SAP BPX Community, and Puneet Suppal of Capgemini.

The official title of the workshop was "How to Transform from a Technology or Business Consultants to a Business Process Expert and put eSOA to Work." This workshop was significant enough that I’m going to write a longer piece on it, and I’m also going to have Marco on for a podcast on my site shortly.

But let me summarize a couple very interesting implications out of this presentation. First key point: it would be a mistake to assume that when we say that functional and technical SAP skill sets are converging that technical SAP folks will start configuring tables and functional folks will start cranking out ABAP.

In the view of Puneet Suppal of Capgemini, both the traditional SAP skills sets: (1) ABAP and (2) configuring the IMG, are going to either phase out though automated tools or become utterly commoditized. A similar view was echoed by SAP Chief Technology Officer Vishal Sikka during my TechEd interview with him, and I happen to agree with it also. I’ll go into more detail on Vishal’s views at a later point.

So for now, what are the implications? If the main SAP technical skill sets are eventually going to go away, what’s an SAP consultant to do? This is a tricky question, especially because the next generation jobs aren’t really there yet. Right now, the vast majority of SAP jobs are still in the core functional areas, involving the same IMG/configuration skills that are supposedly going away.

The answer lies in making a gradual skills transition, following one step behind SAP. Savvy consultants will ride the upgrade wave and choose forward-thinking projects that expose them to as much of this new technology as possible. Through the SAP BPX community, there will be plenty of opportunities for self-education as well. It’s not about becoming irrelevant, it’s about taking a pro-active mindset towards evolving your skills. The best SAP consultants have been following this strategy for years anyhow.

One thing I do see changing is the ideal skills mix of the SAP consultant. For many years, I have been telling SAP consultants to strive for an "80/20 skills mix." By that I mean that the ideal skills combination is either eighty percent functional or eighty percent technical. The remaining twenty percent gives you just enough knowledge of the other side of SAP to be effective on project sites.

Historically, the problem with being a techno-functional consultant with a 50/50 skills mix is that SAP rewards specialization. In my recent podcast with Rohana Gunawardena of Exium, Inc, Rohana talked about how the best SAP consultants focus on either the functional or technical side of SAP rather than trying to "straddle the fence." But in the future, I think that’s going to change, at least for these so-called "Business Process Experts." (BPEs).

Some of these BPEs will come from a technical background, and some from a functional, but overall, I think it’s safe to say that in the future, that 50/50 skills mix may actually become the ideal. But we’re not there yet. Therefore, SAP professionals are in an odd spot: the skills needed for success now are not the same as what will be needed down the road.

In the end, however, just as SAP emphasizes an evolution of product improvement that is not disruptive, SAP professionals should be able to evolve their skills in line with SAP. The key will be to anticipate which skills are actually being used on project sites, as compared to the skills that might take center stage at conferences but aren’t actually being utilized.

One of the great things about this evolution to an SAP Business Process Expert is that you don’t just have to wait on the right project to come along. Many of the tools of this skill set, such as "Web 2.0" know-how are available to learn on your own, and the SAP BPX community has a lot to offer in this area also. Of course, exactly what skills are needed to fill in the gaps depends on where you start from within SAP.

For those who are looking for more practical next steps on making the transition to BPE, rest assured, I’ll be returning to this topic frequently in my blog, in my podcasts, and in upcoming articles.

And that brings us back to the purpose of my web site, JonERP.com. My articles are intended to read between the lines of SAP market trends and attempt to spell out which SAP skills are needed now, and how that will lead to the "skill sets of the future." In this "TechEd in Review" piece, I have done my best to accurately interpret where SAP customers are at in terms of the products they are focusing on, and the skills needs that will result from those implementations. I will plan on following up on this longer article with shorter, more focused pieces that will hopefully help SAP professionals to make good project choices.

I look forward to hearing from other TechEd attendees and learning how your perspective is similar, or different, to my own. Please email me with your thoughts.