One common theme on the JonERP.com web site is how to transition your SAP skills in the NetWeaver and eSOA era. A big challenge here is figuring out the timing of the skills changes that are in the works. Change your skill set too soon, and you are ahead of the curve with few projects to choose from. Wait too long to make your skills transition, and you have fallen behind. From the back of the pack, it’s hard to catch up. So what’s an SAP consultant to do?

There’s no one right answer to this question. We’ve touched on these themes in many of our recent JonERP.com podcasts, and we’ll continue to do so. One thing I have always believed in: take your skills tips from the real leaders in the industry. Recently, I posted a transcript of the "TechEd 2007 in Review" podcast I did with Enterprise Horizons CTO Krishna Kumar.

He had the following response: "Well, right from the onset, I was a big skeptic of this whole technical consultant/functional consultant dichotomy. For starters, if you look at SAP, historically SAP has an extremely powerful, very strong ABAP platform, and then you have extremely powerful business processes that piggyback on the strong ABAP platform. Now, as much as this seems like a sound architectural idea, one of the unfortunate byproducts of this whole paradigm has been two communities, or two sets of people.

"So there’s one set, which is hard-core technical consulting, and there’s the other set, who claim to be like the functional Business Process Expert. History tells us that such a dichotomy never really works in the interest of a successful SAP implementation. For the most part, a technical person has to have very sound functional skills, and the functional person has to have, at the very least, reasonable debugging skills to go under the hood and fix the issues as they happen.

"One of the good byproducts of this newfound on-demand eSOA initiative is the seamless amalgamation of technical and functional skills. Picture a technical consultant not having the know-how of how to expose a business function as a web service. This is definitely not going to work in the interest of the whole picture, because he has to understand, for example, the web service definition needed to call the service. It’s seemingly impossible for a technical consultant to orchestrate a web service without knowing the impact on the underlying business engine."

There has already been debate in my SAP Career Blog about what the ideal functional/technical skills mix is for the SAP consultant, and we can continue to argue about the exact combination of skills that will be needed for future projects. But taking Krishna’s perspective into account, he believes, and I agree, that the "SAP technical consultant of the future" is absolutely going to have to understand how to expose the inner workings of SAP as a service. We can look at this as a new age of integration, using the same philosophies of integration that drove the EDI and EAI marketplaces, but with a new set of Internet-based tools and a new methodology.

Now, exactly how those tools are acquired and how a consultant applies them comes down to the individual. Obviously, the classic "Basis" systems administrator is going to use these skills differently than the SAP developer or the SAP DBA. Part of our job as SAP professionals is understanding just how our existing skills plug into SAP’s Enterprise Service Architecture.

We have to find a way to bridge the gap between the skills we have and the skills we need. For the technical person, Krishna mentions Visual Composer and the NetWeaver Composition Environment (CE) as two areas that are worth mastering. And based on the potential of analytics-driven eSOA, Krishna would probably add at least a working knowledge of NetWeaver BI to that wish list also.

During the podcast and our offline discussions, Krishna has made a point of how powerful Visual Composer can be when applied to analytics-driven eSOA. But the goal of the SAP consultant is not just to acquire a hot new skill or tool, but to acquire that know-how within a broader context.

Krishna framed the situation of the SAP technical consultant in this manner: "The technical consultant has been ABAP-heavy all the time. Now all of a sudden, he’s exposed with three new sets of tools: on one end of the spectrum, you have BI analytics, which, again, has been primarily a technical tool. BI analytics, now, with this newfound eSOA strategy, is going to take more of a business approach. With acquisitions such as Business Objects (BO), the technical mainstay is going to diminish dramatically. A lot more effort is going to be put into actually building the business solutions.

"The second element is the NetWeaver technology. A lot of energy has been put into building the NetWeaver plumbing, but with new technology, such as Visual Composer and the NetWeaver Composition Engine, the technical complexity is now abstracted. You will very soon see the technical consultant now starting to talk business, and he has to learn business, otherwise he’s going to become a dinosaur in the industry."

So Krishna believes, and I would agree, that the writing is on the wall for the technical consultant: learn business process know-how in order to keep yourself relevant on projects. In my view, the impact of offshoring on the technical side of SAP increases the urgency of this transition. What we can say about SAP is that as skills become commoditized, the chances that they will be offshored or outsourced increases. The way to stay ahead of that curve is to create innovative mixes of functional and technical SAP skills, combining the latest modeling tools with core industry and business process knowledge.

Taking a look at the functional side of SAP, as you would expect, Krishna believes functional consultants are going to need to get exposure to NetWeaver technologies. But beyond that, Krishna believes that the SAP functional consultant needs to get a handle on the Internet Cloud: "The functional consultant now has to be aware of the repercussions of exposing his business process over the Internet Cloud, the possibility of exposing his business process analytics over the Internet Cloud. So, there’s going to be a slow metamorphosis, but you’ll definitely see the technical consultant and functional consultant talking the language that’s more synonymous."

Some readers may be unfamiliar, as I was, with the term "Internet Cloud." I asked Krishna to define it during the podcast: "With the proliferation of the Internet, you basically now have a computing layer between different computers. The computers are all connected to each other through the Internet. But the fact that now we have self-running services - through eSOA, through Google analytics, through Yahoo analytics - your Internet is not a passive ecosystem anymore. It is a live, intelligent breeding ground for computing power. That collectively is represented as an Internet Cloud. So an Internet Cloud is an ability for computers to talk to each other and an ability for smart business processes or smart systems to exist in either."

The bad news about the proliferation of these new eSOA technologies is that they span a range of tools and approaches, some inside of SAP and some outside. To make things more complicated, we don’t necessarily know which of these emerging standards will become the most widely accepted. But there is good news here too: historically, it was very difficult to acquire hot new SAP skills "on the fly."

With these eSOA technologies, many of them are skills that can be experimented with in the sandbox of your own home computer on nights or weekends. We may reach a point where the only excuse for falling behind in SAP is not the lack of access to an SAP system, but the temptations of flat screen TVs and the obligations of yardwork on weekends.

Every time I do an "SAP skills of the future" blog post, I feel like I have raised more questions than provided comprehensive answers. But that’s the nature of SAP right now. No one, to my knowledge, has developed a perfect SAP skill roadmap. But on this web site, we will do our best to assemble the proper route, one tip (or roadsign) at a time.