Skip to Content

Is it True That ABAP and SAP Configuration Jobs are Going Away?

In this blog for the BPX community, I’m going to do my best to look at how the SAP skill set is evolving, with an eye towards a key theme of this community: becoming a business process expert.

Of all the topics that I write about in my SAP Career Blog on that generate the most discussion, the two most controversial ones are “the end of ABAP”  and “the end of configuration skills.”

Earlier this fall, I wrote a blog entry about both these topics, and I got some excellent responses from Kent Bettisworth of Bettisworth Associates. Kent is a senior SAP consultant who currently specializes in SAP Project Systems, Fixed Assets, and Investment Management. He and I have been debating SAP skills trends since the mid-90s, and Kent always has some interesting things to say.

So, in this BPX blog entry, I’m going to share my original entry and also Kent’s response to that entry. I’m hoping that this piece will then generate some additional follow-on comments, either from Kent or other BPX community members.

Before we begin, I realize that it seems a little sensational to talk about ABAP and configuration jobs going away, and one thing I don’t want to do is fan the flames of those particular fears. But to be fair, I get these kinds of questions from many web site visitors, so this topic is on people’s minds. I hope this discussion with help calm anyone’s immediate fears and gear the thinking towards how to be strategic about anticipating SAP’s product evolution so that we can all stay marketable.

With that said, here’s the piece and Kent’s response:

Is it True That ABAP and SAP Configuration Jobs Are Going Away?

In a nutshell, yes, I believe it is true – 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 are 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.

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 and technical areas, involving the same IMG/configuration and programming 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 podcast with Rohana Gunawardena of, 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.”

Some of these BPXers 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 in a way that is not professionally disruptive. 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.

So that was my original blog post. After I wrote the post, Kent Bettisworth chimed in with the following:

“Hi Jon, hmmm…the idea that Business Process Experts is a ‘new concept’ is giving me some difficulty. From my perspective, the exceptional SAP consultants (functional or technical) have always been ‘business process’ focused first, and ‘delivery tool’ second. Configuration and ABAP are simply ‘tools’ for achieving the objective of a particular business process.

And, I think the ideal skill mix is not 50-50, but rather 60-40 or 75-25, with the business process being the 60-75% and the ‘delivery tool’ (either IMG configuration or ABAP or BW or Portal or etc) the remainder. For as long as I can remember, the IT departments in companies have always been asked to be focused on, and to learn the business first. Then, use the tools at hand to deliver business productivity.

I do agree that SAP consultants must stay in touch with the ‘delivery’ tools. So, if IMG configuration becomes automated…you need to know how to advise clients how to take advantage of the automation. This is not new…’IMG configuration’ delivered pre-built programming. HTML, Java, etc do the same thing…delivered ‘canned’ modules that perform functions. If it means learning to build ‘composite applications’ as a delivery tool, then consultants will need to learn this. Many COBOL, Fortran, PL1 IT consultants (I am showing my age) did not pick up on the shift in ‘tool’ technology pioneered by SAP and other web-focused technology companies!

I think the challenge is the same as in the past. The higher paying jobs will go to those who are primarily ‘business process’ focused. And, at the end of the day, you must decide if you are having fun. If not, get a new job!”

Kent then sent an additional comment: “Hi Jon, here’s a timely and relevant quote from an article in today’s Wall Street Journal. Mr. Szydenda is the CIO for General Motors. ‘The challenge for Mr. Szygenda isn’t just to cut IT costs, but to use tech to reduce the time and money it takes to design, build and deliver vehicles. ‘No system ever saved anyone,’ says the CIO. ‘My job is to use IT to transform the business.’

‘That’s an oft-stated goal for IT departments, but one few achieve. Too often, CIOs focus on tech rather than business problems,’ says Jerry Luftman, a professor at the Stevens Institute of Technology in Hoboken, N.J. He adds that only now are IT leaders realizing that “the job is a business executive job, not a tech job.’

Saavy SAP consultants know their job is first and foremost business process driven. The tools used are secondary and will change over time.”

Kent Bettisworth –

I had the following response to Kent’s post: “Kent, great comments as always and I would tend to agree with all of them. Agreed – the idea of a “Busines Process Expert” is surely not a new one. What I am doing in this blog entry is simply reporting on SAP’s own emphasis of the idea of a ‘Business Process Expert,’ in a way it has not been emphasized before within SAP.

I tend to agree with you that the tools always change but the mindset and business process awareness is the key. However, historically many SAP technical folks have been able to get by on their technical savvy without having to embrace the business process mentality. SAP argues that this is going to change, and this seems accurate to me. The only point of contention is how long this evolution will take.

On the functional side, the need for “configuration skills” being a the core of the skill set has not really changed since I entered the market in 1995. The idea that this would change, I feel, is a pretty significant development.

Obviously, existing SAP consultants would be in a good position to evolve their roles along with SAP, but my point, and I think it’s a valid one, is that those consultants who take a pro-active approach towards anticipating these trends are the ones who are going to benefit from it most and be the most marketable.

I doubt you would disagree with that, since you have had that attitude throughout your career and it has served you well. But, not all consultants have that attitude, so a bit of “shock value” about the changes ahead is, in my view, a relevant thing to undertake so that folks understand they have a good future in SAP, but that they will have to work for it.

I also feel that the technical tools on the horizon now are a bit different than those we have seen in the past. At TechEd, SAP did a demo of a new modeling environment, based on Eclipse, and the end result of such a tool is to automatically generate a lot of code that used to be hand-coded.

Yes, change is a constant, and the ABAP role has been changing for a while now. But I still feel these particular changes are pretty significant, even if SAP is using a term, “Business Process Expert,” that is not new in its usage as you rightly point out. I hope the folks reading this blog will take your perspective to heart, it’s a project-tested outlook as I’m sure you can attest.

This is more of an ongoing conversation than anything I can accurately predict, but I look forward to digging into this conversation further.”

– Jon Reed –

After Kent chimed in, we heard from another blog poster named “Sandy”:

“Hello Jon. I find it quite hard to fathom companies being able to use automated congiguration tools for IMG settings as the requirements are so varied it is virtually impossible to program in. I would love to see a solution which will allow easy IMG settings. The concept of the business process expert already exists. But I do agree with the point of view that it should be a healthy mix of technical and functional skills: 70-30 respectively. But for me, functional experience is harder to imbibe, as it requires a harder skill set.”

To which I responded: “Hey Sandy – Good comments and I don’t disagree. Part of what I’m trying to do on this web site is to anticipate where SAP skills trends are going so that SAP professionals can make sense of how these trends impact their area of specialization.

While the notion of business process experts has been around for a while, there are definitely some changes in how SAP is using the language now. The explosive growth of the BPX community is one illustration of that.

I would suggest listening to my podcast with Marco ten Vaanholt, Global BPX Director, and see what you think. I think Marco has a real good sense of how to put these issues in perspective – see Marco’s blog for more on this. If nothing else, I think that process modeling and visual programming tools are going to impact functional and technical skill sets.

The point I am trying to make more than any other is that SAP consultants need to think of themselves, at least on the functional side, as industry experts rather than “configuration specialists.” No, automating the IMG isn’t happening overnight. But I think there is still a message being sent by SAP and by SAP customers about some changes on the horizon in what is expected of a functional consultant. That’s one of the main things I’m trying to bring out here in my blog entries and podcasts.

This is more of a dialog than a one time answer, so thanks for joining in the discussion, and keep coming back for more!

– Jon Reed –

So that’s a wrap for our initial discussion on the so-called “end of configuration and ABAP jobs.” I wanted to share this back-and-forth with the BPX community and see if anyone else had a different perspective on this. No one person can say for certain how this will play out. Predicting SAP trends is fun, but it’s better to have a dialogue than to make bold pronouncements. Hopefully we can have a provocative discussion and make sure that we all make the best career decisions possible.

You must be Logged on to comment or reply to a post.
  • There are always a few early adopters who will champion BPX and make the big bucks. But the question for the majority of SAP consultants is the time frame it would take for IMG and ABAP work to die. 5 years? 10 years?

    Since SAP always has a concept of ‘standard relevancy” when they make a product, I do not see either functional or technical skills going away any time in near future. Who is going to do the tonnes of enhancements to make it work in projects, the way a client wants to run his business? Wizards etc have serious limitations as most of us have realized over time.

    SAP might go ahead and make several excellent advancements, but upgrading existing systems is not something every client is fond of. So, a large contingent of consultants with ‘old” skills, will still find work in production support and minor enhancements.

    Now last but not least, if SAP does all these wonderful things – probably they need a lot of top quality developers to build and support it, and some folks might just join SAP labs 🙂

    So I do not see the current skillsets going obsolete any time soon.

  • There is till date no software that caters to all companies in a domain, no matter how closely related there way of working is…so there’s always room for us, only we need to be abreast of all the technology( at least not in condition to say ” Never heard of that..” ). No one is Born & brought up in ABAP. We learned and we have the feel of SAP and this is the most important part.
    “The SAP” is of its business logics and processes mastered over years and the very core lies in ABAP. Moreover, anyone who worked for SAP projects is familiar the way SAP works and always has a lead over others who know just the new tool. So its never a big deal to grasp a new tool, except the pain in leaving the comforts of ABAP coding.
    Programming tools change over a period of time, even the programming concepts change ! Its sounds a lil weird, but still i find people coding with Header lines, although with OO, ABAP no longer supports these stuffs. But there is still place for them. There are enough and more clients who still run on R/3 and have core ABAP requirements. Every company doesn’t jump blindly onto the Technology wave. ABAP is time proven and will be there.
    So i guess we needn’t hit any panic button except slowly getting a feel of other languages and evolving technolgies.
    I am not a career consultant but aforesaid is my personal opinion.
  • I totally agree with the fact that we should all keep our business process focus. Which means we needn’t worry about the tools too much.

    The tools are clearly changing a lot faster than the business processes and that is why many tools come and go:

    – ITS came and went
    – Servlet (Java) based Internet Applications came and went
    – BSP came and is on its way out
    – Java Webdynpro has hardly seen the light and is already being overtaken by ABAP Webdynpro
    – Java will disappear completely from the SAP landscape to be replaced by Flex Applications. Go and look for Flex demos on Google, you will be amazed.

    But ABAP is here to stay. There is nothing to replace it.

    And I will learn Flex scripting on the side because you can build awesome looking webapps with it.

    • Ah – so Java’ s going to be replaced by Flex! I’ m already looking forward to the Flex Portal and the Flex TREX! Probably one should spend more time searching SDN instead of Google before posting.
      • Off course I was just voicing an extreme point of view to entice reactions. Only 3 so far… suprising. Do people agree with me maybe? 🙂

        I will make some further highly opiniated comments…

        Java is not the right choice for SAP. SAP had to look at it because of its popularity and because it wants to learn everything it can from the Open Source world. SAP has learnt from it (thank God for the new debugger), the learnings will be taken forward, but Java will be dropped.

        Let me explain why I think this is.

        If you think of the MVC principle and service oriented architecture, software functions should be developed as small(ish) standalone components, belonging to one of the three layers:

        – Information storage (DB)
        – Business logic / Comms
        – Presentation

        For information storage, the key requirement is performance: we have databases and the logic to access them needs to be as fast as possible. In my opinion, non-OO ABAP is an excellent choice. I can’t see why I would want to change my system. I  see that mainframes from the 70’s still run good old Cobol (ABAP’s mummy) !

        For presentation, SAP needs to aim at the best the web has to offer. I had a look at what we can do with Flex controls versus ABAP webdynpro controls. It’s a no-brainer. And SAP already supports Flashplayer in the Portal. (Search SDN for Flex controls) I think SAP knows why. The Flex Builder is based on Eclipse which is unrivalled, whilst the SAP development environment, well, what can I say… it’s not a finished product. SAP cannot (and should not) compete with the open source community in providing Web development tools.

        For the business logic layer, there can be some debate I guess. But for me, the best solution is the one that provides the fastest path from the presentation layer to the information storage layer. ABAP does the trick just fine. How do you justify the investment of changing existing implementations?

        Sorry, don’t know anyone who uses TREX. I’ll give you my worst thought on that one though, because it might trigger some reactions 🙂
        At the point when your BW environment has grown big and messy and noone knows what’s where due to its complexity, you install TREX, an extra piece of complexity… close?

        I’ve implemented reporting solutions for client without any need for extra hardware or expensive consultants, nor interfaces to yet another system.  Using change pointers, I can ensure a maximum 5 minute lag between the OLTP and the reporting tables. Because it takes a day or two to build a new report, the business users are forced to come up with the simplest solution and think things through before asking for just another report because they have forgotten what reports they’ve already got lying around (which is when you need TREX, I believe…).

        • I don’ t think that your posting causes no reaction because of agreement, but because of people getting tired of the ABAP-Java flame wars. This matter has been discussed over and over again, so there’ s no need for another subthread.

          Yes, WDJ applications are replaced by WDA in many ERP areas, and yes, ABAP has gone through an amazing pursuit race which – toghether with it’ s usage in ERP – makes it the most powerful SAP tool – now & in the years to come.

          I found way in SAP development through the Java corner, now programming only in ABAP OO – which by the way in my opinion is the only way to program complex ABAP solutions – so maybe I should share your opinion.

          But in many discussions I had in the forum many people pointed out that development as we know it by now, which means coding line by line, looses importance. Look at the Visual Composer (Java based, by the way) – do you think functional consultants won’ t like the idea of implementing new apps without having to code any ABAP/Java code?

          Give the modelling tools some time to spread within the market as well as the consultants to visit SAP courses and let’ s then talk again about the immortality of ABAP!

          • since the time it became WebAS, ABAP system can do (or tweaked to do) almost all the stuff that java can do. [But still BW reporting runtime moved from ABAP (webas) to java , i still dont understand the reason.]

            In my understanding the move to use JAVA was to position SAP as a platform where partners can co-innovate/develop add-ons. In such a scenario an open language like java will be more appealing than a proprietary language (ABAP)

          • Thanks Thomas,

            I didn’t mean to stir abap-java wars. It’s a bit like the farmer asking: should I keep pigs or cows at my farm? Maybe, he should keep both … depending on what he likes on his plate for supper . 🙂

            I love the drag-and-drop aspect of the visual composer. It’s certainly an area that I expect a lot from. But building Portal Apps is still slow and painfull as the visual composer isn’t always WYSIWYG…

            I totally agree with you that functional consultants would like the idea of creating apps without coding. The question is more: should they?

            I’ve always insisted that developer’s keys not be given to functional consultants or managers. The mess they cause keeps people in a job! 😉

            Writing stable and reliable business applications requires engineering skills and creativity in solving problems. Tools will never have that, but then again, they might not need it for the simple apps.

            The problem I bump into time and time again when recruiting, is the lack of engineering and computer science skills in the developer community. In Western-Europe, it certainly is a
            sad state of affairs. It would seem that the younger generation here don’t like to work hard at school, they shun away from maths and physics and other subjects that train the little grey cells.

  • Even though SAP has built business expertise in their products based on industry standards, we still require the help of core technical consultants to find workaround for complex solutions.

    I donot think its a discussion between what will stay(ABAP and IMG) and what will not since technology and business will evlove with time, but a discussion about how much of integration can be there between the skill sets of functional and technical

    We can have some overlap b/t these two skillsets but we still require specialized people for specific domains.

  • Well.. Firstly this blog really gets you thinking. About Career (read jobs) and Career (read professional skills). So are them ABAP/Config jobs going away; I dont think they’d just go away in a swish and they will take a while to gradually loose their shine. I guess you’ll slowly find yourself working less on these..
    I work on NetWevaer Portal. I learnt that you could call an ABAP function through JCo API’s or an RFC iView. Then I learnt it would be faster through Web Dynpro for Java. No sooner, it was Visual Composer. Modifying PAR files to include new things as per customer wishes was a frequent task. It really was fun (for the implementer), I guess not for the customer.
    Varied requirements will always keep the config/abap/java tasks active but yes with a very slow decline.
    I foresee as well a time when a consultant would be expected to be “TechnoFunctional”. Its like saying “I am an SAP ERP Solution Consultant with a strong domain knowledge of Finance” and so on.
    My question is if technical consultant wants to build up his/her functional (business) knowledge to that 70%, what area must they focus on? Its vast out there: Product Life cycles, CRM, SRM, Finance..
    • is in Web Dynpro for ABAP! Beats any other wrapper – PDK, WDJ, web service etc…

      I’m reasonably confident that Java will be around for a while in the SAP world, especially for low level technical comms like PI adapters etc.

  • Hi, Jon!

    What I came across quite often in my SAP career was a big gap between the visions I found in marketing material and the daily business needs of customers.

    For example let’ s take forms: SAPScript should be dead by now, but not one company I worked in where not at least a dozen applications still run on them. Smartforms should be replaced by Adobe – ha! Nobody can afford to build a second Java-based landscape just for printing in colour, no one needs interactive forms where HTML does the same thing with no additional costs.

    So when you’ re talking about BPX, I do share a vision, but see no immediate implications neither for the SAP consultant market nor the personel skill sets. Even more, I would consider it as quite dangerous for a Consultant today to jump on any train – no matter if it is called SOA, eSOA, BPX, BPM or wathever – without knowing if it will ever arrive in customers IT departments!


    • I *TOTALLY* share your opinion on this.

      Another example of that is EDI/EDIFACT. It was called “deprecated” and should be replaced by webservices using the internet. We still have a lot of new projects with new customers integrating our Business Process using EDI – just because neither they nor we are disposed to throw away a very well working technology, an accepted industry standard worldwide just because of being on the tip of the hype – and I also don´t see that in near future.

      Decades ago COBOL was factually called dead but one of the biggest banks in the US run their main business still on and with COBOL for the simple reason that it *WORKS*.

      Customers, especially the medium and bigger sized ones, often have a HUGE amount of ABAP programs developed over time and I doubt that they will reprogram (or redesign) that just by a matter of being on new technology.

      And even at SAP there are areas, where there´s backward paddling, speaking of the WD-*ABAP* travel extension in Enhancement Pack 2 compared to the Java one in ERP 6.0.

      I´m sure there is place for innovation if you do new projects but as of today I wouldn´t put mission critical operation on a “Web 2.0” platform (no matter what software or how it´s called) as long as I have a choice.

      Just my € 0.02


  • For a developer, it is nice to know the area that the programs are being developed.   For a configuration person, it is good to at least have a basic understanding of what tools need to be used.

    I’ve worked in both areas.  The functional side of things requires a strong ability to interface with the business community.   Meetings, meetings, and more meetings.   That is a completely different skill set then the development side.   The development side may sit on some meetings – to get a better understanding of how to develop.   However, they don’t have to sit thru the debates about how a process should be.  In fact they don’t have to be involved until it is determined that the standard solution won’t work.

    As we move forward, the developer will probably need to know a lot more than ABAP.  The tool set will expand, and some understanding of the business side of things is needed.  However, is it 70-30?  60% technical.   Maybe another expansion would be understanding the tools available and the ability to suggest the correct one.

    I think both areas need to be there.  The skill sets or basic strengths are different between the two.

    Also to assume that one person would “know” all of this – wow! – I’d like to meet that person. 


  • Hey folks…Thanks for the great comments so far on this entry.

    I agree with many of the thoughts below, and certainly as SAP roles evolve, it won’t happen overnight. It is certainly interesting to think about what technical/functional skill mix will be ideal in the future as well.

    A couple of people have pointed out that to manage your SAP career well, you can’t abandon your current skills just because a new skill set is getting a lot of buzz or marketing attention.

    It seems to me that the key is to combine the core skills of today with a combination of new tools and new business process centric approaches – in a gradual, evolutionary manner.

    What interested me about this presentation I wrote about in this blog post was that one of the presenters was actually in a consulting delivery role, so it seemed that perhaps his insights were coming from some changing skills requirements he was seeing on the client side.

    At any rate, I appreciate the discussion and the comments and hopefully over time we can identify the most important tools and skills to add to the technical and functional profiles.

    – Jon Reed –