Ask the SAP Career Expert Archive

SAP Career Questions for B2B Workforce, April 2008 edition What do you think is a better career path, J2EE programming, ABAP, or SAP NetWeaver? JR: I get this type of question a lot and what I find strange about it is that it puts at odds several technologies that actually work best when used in conjunction with each other. SAP's NetWeaver platform actually involves all three of these areas, so going forward, the best SAP developers will be the ones who understand how to bring these skills together into a "hybrid" skill set. Let's start with the J2EE side. There are a lot of J2EE programmers out there who have no exposure to SAP or any other major ERP package. To the best of my research, when you add enterprise-level ERP skills to a Java-based background, your salary or rate should jump up at least twenty percent. When you think about it, this makes sense. Companies are willing to pay a premium for those who can work in a higher stakes environment, and working on production-level ERP systems is certainly higher stakes. Perhaps we could say in the past that SAP was not a state-of-the-art J2EE environment, but I don't think that's true today. SAP's Composition Environment (CE), the focal point of much of its Enterprise SOA development, is a Java EE 5 environment. So at this point, a seasoned J2EE programmer does not have to choose between Java and SAP. If you get on the right project, you can do both. Then there's the matter of ABAP. ABAP has gotten a bad rap as a "dead" language, not unlike Cobol (though there are still some Cobol projects out there too). But in fact, it's only certain kinds of ABAP functions that have become either obsolete or so commonplace that they command no rate premiums and are easily outsourced. In fact, object-oriented ABAP skills are still very important to SAP shops of all sizes. Many NetWeaver applications are written at least partially in ABAP, and many of SAP's biggest customers are heavily invested in ABAP and need folks who understand ABAP-based techniques. If I were an SAP developer, I'd want to be equally comfortable with both object-oriented ABAP and Java-based techniques. More often than not, today's SAP projects involve both, and if you can work on both sides, you have the potential to become the "glue" that holds the technical team together. Now, we can expect in the coming years that modeling tools will change how SAP development works. SAP's Enterprise SOA platform is designed to help build add-on, web-based applications without the need to alter the core code base. The best SAP developers will shift from customizing the core to learning how to tie these web-based composite applications and services into SAP. It will be years, if ever, before business users can design perfect add-on applications with code that integrates seamlessly with SAP. That means there will be a huge need for the rare technical folks who can take those modeling-based projects the final mile and tie everything together. With this type of work, we can expect to see more Java-based development than ABAP, as SAP has favored Java for its web-driven tools, but ABAP is still a big part of how the transaction-driven ERP core is optimized. This is a skill set that is evolving rapidly, so it's impossible to have the final word now, but I think there are two important breakthroughs here: one is to stop pitting J2EE and NetWeaver and ABAP against each other, but to see them as part of the same service-enabled platform. The second is to make a commitment to self-education on a number of levels, including the mastery of object-oriented programming, composite applications, and the visual modeling tools that are starting to gain more traction in SAP development shops. If you'd like more information on these topics, I highly recommend the podcast on the future of SAP development we did on B2B Workforce with Thomas Jung of SAP Labs and SDN. Is it better to pursue SD or CRM right now? I am especially interested in Service Management versus CRM Service. JR: When I get this question, people usually expect me to answer "CRM," but that's not always the case. Right now, with so many core SAP upgrades going on, the SD module has regained a bit of the sizzle it had in the mid to late '90s. In recent years, the on-site CRM market also slowed a bit, hampered by tougher ROI expectations on the one hand and increased competition from hosted solutions like SalesForce.com on the other. There are still great opportunities in SAP CRM, but the "SD versus CRM" question is a much tougher call than it would have been five years ago. The first thing I would do if I were choosing between SD and CRM, would be to see how my existing skills compare with the functionality SAP has in each product. For example, if I had a background in eCommerce and Internet-based sales, I would focus on CRM and the Internet Sales component. Likewise, if I was strong in marketing solutions, I'd also focus on SAP CRM, due to its strengths in marketing and opportunity management. On the other hand, if my background was more on the transportation and logistics side, the "Distribution" side of SD if you will, then I would focus more on the SD module. So, to a degree, your previous experience can help you to decide whether to pursue SD or focus on CRM. That's why it's a good idea to study the components of each product before you make a move. But what about Service Management? This is an interesting area of functionality to look at, because to an extent, it exists in both products. So if you have expertise in Service Management, do you focus on the ERP side or the CRM side? This is not an easy choice. Some years ago, SAP made the decision to focus on expanding the functionality on the CRM Service side and not adding further functionality to the Service Management, or SM side. Many of us thought this would lead to SAP customers standardizing on CRM Service and transitioning out of Service Management, but that hasn't been the case on a widespread basis. This kind of product adoption is important to monitor, because it has a strong impact on the level of consulting demand for particular skills. At this point, there are plenty of SAP customers who are still entrenched in the R/3 version of SM, often in conjunction with either the CS (Customer Service) or PM (Plant Maintenance) modules. The one time when we see more CRM Service work is with companies that are new to SAP or who are putting in a range of CRM products and want the latest CRM Service functionality. There is some new Service functionality in SAP CRM 7.0, but the biggest enhancements to that product, at least from a marketing angle, had to do with user-friendly Web 2.0 additions rather than hardcore CRM Service functionality. With all that in mind, "Service" is one of those rare SAP areas where I can see either option working out equally well. ERP-driven Service Management and CRM-based Service are both viable consulting areas, and it's even possible to spend time in both products, though for now, I recommend choosing a consulting focus on one or the other. Across the board, I think that the demand for SD module skills is a little higher than SAP CRM right now but not to the degree that it's worth abandoning one area for the other. Again, I think a more savvy approach is to figure out which aspects of SD or CRM your skills line up best with, and let that influence your decision. It's also worth remembering that there are often key integration points between SD and CRM. These integration points vary from project to project, but it's a good idea to think of the SD and CRM products as having a number of connected areas, so understanding how to bridge the functionality gaps between the two can be a very fruitful area to focus on. I don't think there's really a wrong choice between SD and CRM, but it's a great idea to think through both products and come up with a well-planned career strategy. Just don't err on the side of too much planning - sometimes it's good to seize an opportunity when it hits, even if it takes you slightly off of your roadmap. As long as you are working on the latest and greatest versions of SAP, you can work out the rest as you go. Ask the SAP Career Expert Archive