Skip to Content
Author's profile photo Former Member

Avoid layoffs: new SAP job skills to learn now

Where will Basis people go in the new NetWeaver world? Is there room for classic ABAP developers? What consulting skills will be in demand in the years ahead? We interviewed career expert Jon Reed to get his take on where the new sweet spots will be.

Those who attended TechEd this year will remember that SAP executive Shai Agassi talked about four new distinct SAP jobs in his keynote. Meanwhile, developers are pinched between offshore outsouring and model-driven development tools, Basis professionals see the familiar SAP framework getting fuzzy as everything becomes Web-enabled, and consultants face a pit of uncertainty about what’ll put food on the table down the road.

Pulling your hair out isn’t the solution, Reed said. Instead, see it as an opportunity. Look at your current skills and map them to future demands. Be the first to master the new technologies in your field, and your odds of making a good living in the new SAP world increases exponentially.

Basis people should take a close look at the role of the consolidator. Consolidators look at the entire landscape of all the applications and technologies a company has and map it to core (what helps drive differentiation with the company) and context (what you do to support existing commitments.) Once there, they start looking for ways to consolidate everything.

“Classic Basis system admin people are well-positioned to evolve into this field,” said Reed. “Basis folks are often used to straddling the fence with architecture elements, and you can’t really identify redundancies without a good grasp of the current processes in use.”

Just like having security skills boosts the value of that person, the consolidation skills may become a vital edge for SAP professionals looking to move up the ranks in coming years.

“It never ends; it’s an ongoing project,” said Ori Inbar, Sr. vice president, solution marketing, SAP NetWeaver. “Every time there’s a new acquisition, there’s a slew of new systems entering the ecosystem. Somebody has to be there to keep things streamlined.”
Read more about how to get into the consolidator role here.

Repository keepers
MDM/BW workers, some developers and people already involved in the creation and management of Web services are well-positioned to capitalize on the growing need for master data and metadata management.

“SAP is really emphasizing master data and metadata as a way to make sure data is structured consistently in the company,” Reed said. “That idea is a core aspect of NetWeaver.”

A good repository keeper must have very deep understanding of the meta data and must also have a firm grip on exactly how the applications are being used across multiple departments throughout the company. Simply put, you need to be intimately familiar with both the business processes and the technology architecture to excel in this role. That’s a tricky balancing act, but those who can pull it off will be very valuable players on the IT team.
Read more about repository keepers here.

The confusion between “developer” and “composer” as an SAP role is understandable. The developer is your classic ABAP/Java programmer with varying business skills; the composer is a business process expert first and techie second. Their main function is to make business process innovation happen in real-time.

Needless to say, this trend has caused some concern in developer circles. So what can today’s ABAP developer do to avoid getting pinched between outsourcing on one hand and model-driven, do-it-yourself business people on the other?

“You can’t do everything with models,” Inbar said. “There’s going to be plenty of room for skilled programmers for areas like Java and creation of new services.”

Inbar suggests familiarizing oneself with the model-driven tools, tapping into the BPX-community and looking for ways to leverage superior technical skills to “move up the stack.” For those who work closer to the User Interface, embrace the modeling tools and start building the next generation of UI building blocks — dedicated, highly interactive components that require advanced technical skills.

“Still, the key question for many is: will these tools decrease the opportunities for classic ABAPers? The honest answer is probably yes,” Reed said. “Having said that, I think many developers can and should get on board with the modeling movement. SAP wants it to seem like a functional expert in a particular area can come in and just design all this stuff. It’s not that easy; they can do a lot, but they’ll still need considerable support from technical people.”
Learn more about how to acquire the right composition skills here.

Disruptive innovators
The disruptive innovator is something of a maverick, looking across the entire company for areas with opportunities for disruptive innovation. It can be a new product, a new business process, or whatever it takes to move the company to the next level.

“The disruptive innovator has to be a hunter,” Inbar said. “While consolidators have the luxury of tending to their niche of expertise, the disruptive innovator must be constantly on the move, looking for the next big thing.”

A Project Manager with good overall knowledge of how the technology supports the business side would make a good candidate. But all things considered, it doesn’t really matter whether that person came from a technical or functional career path prior to shouldering this new role; all that really matters is the current understanding of both sides of the fence, Reed said.

“The other new roles seem to be more hands-on, but I see the disruptive innovator as a manager or Team Lead,” Reed said. “You need a broader view as well as organizational leverage, ie. decent corporate status, in order to make things happen.”
Get more information about disruptive innovation here.

Of course, there are plenty of niche-opportunities that remain or will be created as the new technologies are rolled out. Be sure to check into the SAP Jobs Info Center for the latest articles, tips and expert advice on how to get ahead in the SAP world.

This article first appeared on Also see the BPX discussion thread ABAP-developers: relicts from the past? for additional comments.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Twan van den Broek
      Twan van den Broek
      Hi Matt,

      Good article, things are changing rapidly. So, no wonder that some of the classic ABAP developers are worrying about their future. But that is good, worrying is step 1 into your new future. I am worrying more about the developers that do not worry yet, those are the ones that should be afraid of their future.
      Back to step 1, worrying. Now it is time to go to the next step, that is stop worrying and look at the opportunities. There will always be a need for good developers both ABAP and Java. Building business logic on the backend or in services this must be done before services can be consumed in a model or composite. The challenge for the coming years is to build services that are really stable and perform well in the coming services. Make sure that you apply everything that you have learned the past years.
      Also the ‘in-between-role’, between the business analyst and the core developer, let’s say the business process expert, is gaining more and more importance. It is not just doing functional stuff, neither is it just doing technical stuff. If you can make the handshake between business problems and technical solutions you are of great value in the coming SAP years.

      So, STOP worrying and TAKE action.

      Kind regards,

      By the way, when I say ABAP, I mean ABAP objects. So for the classical ABAP developers: please make sure that you ‘migrate’ to the ABAP Objects language.
      Mind these lines, they are from a classical-old-school-ABAP-developer 😉

      Author's profile photo Former Member
      Former Member
      I agree with David's comments and also with the timelines he is quoting. We've been hearing about the "Hybrid Analysts" and what have you for years now and yet I still have to see the changes happening on a grand scale (as predicted for some time now).

      In my view the problem and bottleneck in this respect is generally to be found on middle and top management level. In a globalised economy based on shareholder value, things such as revisiting old code, upgrading systems and justifying additional spend on the latest WebApp server technolgy is a contradiction in terms. Things are generally only being made if the support runs out!

      Which leads me to the ABAP OO migration comment that Twan made. I don't disagree that ABAP OO is the way ahead, but if I start converting old ABAPs (or even write new ones) without a proper business case from my client, I can pack my bags quicker than you can say "Object Oriented". The problem simply is that the uptake on ABAP OO skills from other developers -in my view- is still very low. Clients -especially on middle management level- still can not see the benefit in it. I've seen the same with ITS migrations to BSP or even Webdynpro. Is there a tanglible value for our customer in it? No? Well, let's leave it then.

      Author's profile photo David Halitsky
      David Halitsky
      Hi Michael -

      If SAP stopped maintenance for Report Writer tomorrow, it would be amazing how fast folks would flock to AAOO docked trees and called screens with AAOO ALV's in them.

      Better yet - turn off ReportWriter all together. You don't even need it if you know how to do control breaks by chasing an ordered tree rightward/upward against a hashed itab instead of by using explicit or implicit lag keys on a sequential file. See my post here:

      Using SETNODE/LEAF to Circumvent ReportWriter


      Author's profile photo Former Member
      Former Member
      I just can't believe you didn't do this in ABAP OO.

      Only joking! 😉

      Author's profile photo David Halitsky
      David Halitsky
      Although the post only concentrates on the "non-OO" ABAP code required to do control breaks by chasing an ordered tree built from a standard SAP report set in SETNODE and SETLEAF, the overall progam WAS written in ABAP OO and in fact was based on the simple example of a docked tree plus ALV grid control provided by SAP in its ABAP OO control examples.  (I should also point out that the docked nav tree needed to select which grid to display is not the same as the ordered tree used to generate the control breaks in the grid itself ...)

      But you're right - the technique for getting control breaks by chasing an ordered tree is sufficiently general that I probably should get around to encapsulating it as a class which takes a Report Set and a hashed data itab as input.

      Also, it might be worth mentioning in relation to your post that one way to get customers to move from non-OO grids to OO grid controls is to show them how much more design flexibility they have when grids are embedded in called screens rather than popped in the old-style ALV displays which don't allow for additional items outside of the grid.

      For example, it's amazing how many folks suffer from a mysterious memory limitation that makes them want their selection criteria displayed on the same screen as the grid that results from these criteria. And you can't really do this unless you use a non-OO table control or an OO grid control embedded in a screen.

      Finally, the main reason for ABAPers to learn OO is that learning tree and table UI elements in WDA or WDJ is kind of trivial after encountering tree and ALV controls in ABAP OO.

      Author's profile photo Former Member
      Former Member
      Michael, that is such a right observation - Middle-top management related and low OO skill uptake by developers! In my case I have experienced both and understand the practical aspect of these. Since 2001 I started to develop Java skills (after reading one of John Reed's articles!) and went into moderate Java stuff with non-SAP EAI products, application integration, some functional stuff, etc. But while in the market recently for job opportunities I found myself being interviewed by classical ABAP programmers who were stuck at either definitions of polymorphism or inheritence; On the other hand I did not come across any one with ABAP-Java mix skillset requirements. The technology-business skills mix opportunities were also missing. Project Managers are still configurators or non-technical folks for various reasons.

      That made me realize that ABAP-Java mixed skillset requirements are far removed from reality in the market. I guess the top-middle management layer has to get to that level of understanding for the business benefits and the IT budgets should allow to move in that direction. Either way how soon that happens time will tell. But personally I have continued to take actions 🙂 hoping there will be a right career for a composite role !!

      Author's profile photo David Halitsky
      David Halitsky
      the problem is just the reverse, for two reasons:

      1) to paraphrase the poet Dylan Thomas, not a whole lot of SAP customers are  going "gently" into that "good future" which SAP is making available (perhaps out of a desire to stay off the bleeding ege, perhaps for other reasons as well ...)

      2) not a whole lot third-party development firms are able and, more importantly, willing to pay what's required to train up their folks up-front, so customers are lucky to get ABAP Objects Controls from these firms, much less NWDS, VC, CAF products.

      So I'm not sure that developers have to really worry for another 3-5 years or more about lay-offs (I'm not talking about obtaining positions that ask for more than adjusting 5 year old ALV grids or 10 year old WRITE statements.)

      Also, as customers do start to jump on the ES(O)A band-wagon, there will be some need for ABAP developers simply because they know where the bodies are buried - i.e. where the design of SAP's database requires the use of highly-specialized code-paths for efficient data retrieval.  (Unfortunately, most youngsters coding ES(O)A are not even aware that efficient data retrieval is a problem, so ABAP oldsters can serve as a sanity-check on pipe-dreams.)

      I'm not suggesting at all that SAP developers shouldn't get as smart as posible on as much as
      possible - I'm suggesting that they have more time to do it than your post suggests.

      BTW, to change topic - because of the current multi-part blog I'm currently doing on the need for "Diachronic Metadata Repositories" in Legacy -> ERP conversions, I'm glad your post empasized how much more important repositories are in ESOA-land.  I will be discussing this point in some detail toward the end of the current blog.