Jon Reed on SAP SOA Skills: Podcast Transcription

jonerp_full_logo.PNGHow to Acquire the Right Skills for SAP SOA Consulting: Podcast Transcription
Demir Barlas, Site Editor, with Jon Reed, President of
Podcast Interview Date: September 19, 2008
Download Podcast (Must Be Registered and Logged In!)

Demir Barlas: This is Demir Barlas, Site Editor of SAP is making a major SOA push via both the eSOA platform and a suite of Business Process Management tools, but many SAP end-users and technical specialists still don't know just how SOA is changing the SAP landscape. In this podcast with SAP Mentor, Jon Reed, who runs and is a site expert, we discuss the interconnection of SAP eSOA and BPM; explore how SOA skills map onto the specific SOA competencies, such as NetWeaver and Web Dynpro, that you encounter; and consider the benefits of SOA.

One SAP customer shaved its development costs by 600% using eSOA, and that should get everyone's attention. Whether you're a CIO or a developer, whether you're a business analyst or a technical consultant, SOA's going to change the way you work and the way your organization performs, whether you're an SAP shop or not. Listen to this podcast to get a sense of the SOA future and how it will impact your job role. Over to you, Jon.

Reed: So, Demir, I think what is important about the SOA space is that we're trying to understand, first of all, how this industry-wide phenomenon that goes beyond SAP impacts SAP, and more specifically, we're trying to understand how this impacts SAP professionals. I think where the issue is for SAP professionals is they want to add skills they can use on their projects, they don't want to waste time on hype that never materializes and, to a certain degree, you can level that criticism at all new SAP technologies, including SOA. Hopefully, during this podcast, we sort out a little bit of that.

As far as SOA and why it's important in the SAP space, I think we need to understand that there's been this historical problem with ERP packages in general: you go in there and you configure the functionality as best you can for your business, but especially in mission-critical areas of your business, there could be some areas that you just can't configure properly to match your specific best practices. Along those lines, you might want to custom develop some specific functionality that you perceive will give you an edge in your industry.

Up to this point, what that involved doing was altering the code base of the ERP core. Of course, that created a host of problems because not only is that kind of custom development expensive, but it makes it very difficult to upgrade your software - and then you're doing it all over again and banging heads on the wall and people are getting pink slips and having tense meetings with budget override issues. So the dream of SOA is the possibility of basically being able to compose applications on top of the ERP core.

When you look at SAP with the NetWeaver releases that are supporting ERP 6.0 and such, you have built-in eSOA compatibility and you have the ERP 6.0 increasingly service-enabled at various points within the package so that you can build on top of the SAP system. So the promise of eSOA, as SAP currently calls it - although I think they're about to change that to SAP SOA - the promise of it is to be able to innovate, as they say, on top of the core, which would essentially give you the best of both worlds. What we're seeing is the beginning of that paradigm shift from, say, just a happy idea, a sexy slideshow, to actual practical demonstrations of the value of this.

What we're seeing now when we go to Sapphire and TechEd are presentations from what you might call "flagship customers," or leading edge SAP customers, that are actually using these techniques to improve their development process and save money. Perhaps during this podcast I can refer to one or two of them, but the gist of it is we're starting to see the case studies happen, and it's becoming more of a proven technology. The adoption is gradual, so if you don't have these skills tomorrow, you aren't going to be out of the loop, but we're seeing a bit of "proof in the pudding" as far as the value of these technologies.

Barlas: I think a very natural follow up to your line of reasoning there is how you get hands on SOA experience. Let's think about this from the perspective of both someone who's a permanent hire, long term, in an IT position and someone who is in a freelance consulting position.

Reed: That's a great question. One thing that's helpful to understand is that, for the most part, you're not going to get too involved in SOA unless you're writing on the latest releases of SAP. So part of it is simply getting yourself onto projects and situations where you're working with the latest releases of SAP because as you get familiarity with those NetWeaver components and the latest versions of the software, that's going to be a key entry point in terms of how you're going to connect that to the so-called SOA world. A large part of it is just getting the latest and greatest exposure and, for consultants, that may mean different project choices and considering projects that will give you that exposure even if the rate is a little less than what you're looking for.

Obviously, for the person you refer to who is an in-house professional, they may not have a lot of control over that. You might be on an earlier release of SAP and sort of chasing it a bit to get that experience, but you can't actually get the hands-on version yet. The good news is that there's a lot of self-education available around these topics: the obvious choices such as book study but also a lot of hands-on options you can look into.

Again, this depends a little bit on where your skills fall within SAP as far as which part of this you need to self-educate on, but for the developer, for example, there's the trial version of the Composition Environment available on SDN right now. In fact, SAP's latest Business Process Management application, NetWeaver BPM, hasn't ramped up fully yet, but a trial version of that is also developed, so you can also download that in addition to the Composition Environment. There's some self-education that can be done around getting familiar with some of the tools of SOA that are used as well, so I guess that would be my answer: wise project choices and the beginning of some self-education - sandboxing around some of these tools.

Barlas: You said something very interesting, which is that eSOA is really practical only with newer versions of SAP. So is this a driver for people who are moving up now to the newer versions of SAP, or is this more sort of a nice-to-have thing that you happen to get the latest version of SAP and, hey, as a bonus, I'm going to do some of this SOA stuff?

Reed: I don't think you necessarily have to be running the latest version of SAP to do some targeted projects. I've seen, for example, what you'd call mashups: taking demographic information perhaps from GoogleEarth and mashing it up with BW to get some interesting analytics going, what are called "spatial analytics." You can use some of that stuff on older versions of SAP as well.

But the challenge you run into is that, when you get really serious about SOA, you get into issues such as needing a service registry or repository for these services and needing governance. These are the kinds of things that are built into the latest version of NetWeaver, so that's why the upgrade to the NetWeaver stack is important when you look at really seriously getting involved in SOA.

It is a major incentive; it is one of the major reasons that companies do upgrades. Whenever you look at upgrade cycles in software, I talk about the carrot and the stick. The stick is the bad things that happen if you don't upgrade. One of the obvious issues is the sunsetting maintenance, where the maintenance fees increase for the older releases and some of that will kick in. So that's the stick, and the carrot would be some of the bells and whistles around SOA and around composition.

The difference between composition and development - the long-term view of composition is obviously to make it increasingly possible not only to have more efficient and reusable development, but, eventually to get business users involved in modeling what essentially becomes executable code at the end of that modeling process. That's not where we're at yet, but that's kind of where some of this is going and why the BPM Tools are getting pushed as well as the SOA and the connections between them.

Barlas: Let's pick up on that and talk about why BPM is so prominent right now in SAP's messaging and SOA is not really quite as prominent.

Reed: It's an interesting shift. One thing is that marketing requires buzz, and you can't really recycle the marketing of two years ago and get the same buzz. SAP has been pushing eSOA for a couple of years now, so there is a need for something new, but part of it is also what is being learned on project sites about these technologies. The BPM effort is basically informed by the understanding that if your business processes are not properly conceived, then your SOA work, which is sort of the enabling technology, is not going to be effective. So, if your business processes are not modeled properly and don't represent so-called "best practices," then your SOA is just not really going to work well.

In fact, in one of the presentations I attended at TechEd, Puneet Suppal of Capgemini basically said - and I'm paraphrasing here - that if your BPM or your underlying business processes are not sound, then your SOA is going to be pretty crummy. That's one of the reasons why that's being pushed right now by SAP and SAP is billing itself as a so-called Business Process Platform.

What you're looking at is the emergence of process modeling tools that will allow companies to model processes, not just in hypothetical, but to convert that into real code. That's really why SAP is so much behind their new BPM tool. It won't have full ramp-up probably until next year, but this is basically the first modeling tool from SAP where the end result is executable code.

So this is what we're seeing, but of course at this juncture a business person can't generate all the bells and whistles that are needed for good development product. So what we're seeing with this SOA BPM stuff is a lot of jobs that are going to emerge in the middle of this stuff, both from the technical and functional side, for people who can step in the middle and help translate this stuff back and forth.

It's not a complete hand-off, and it won't be probably for a number of years, so we're going to need folks who have the ability to collaborate with business users or compose services, but then tie things together properly or install the latest version of SAP and make sure it's connected to the web architecture that you're using, or the e-commerce platform. There are all kinds of stuff happening around connecting these things, and a way you can talk about it is the convergence of the technical and functional skillsets; it's going to happen gradually, but there's a sweet spot there that consultants and in-house SAP professionals can push for. Even if your project isn't doing it yet, there's a lot you can learn online in terms of self-education around this stuff.

Barlas: Let's take it back to end-users for a second. You said you've come across some interesting use cases. Can you tell our listeners about some interesting on-the-ground uses of the stuff?

Reed: You can kind of look at some of SAP's early adopters, and one of the neat things about it is that a lot of these are available online, so you can basically go to and look at past Sapphire presentations and kind of see what some companies are doing. I can throw out a couple that I've seen a fair amount. One is Home Depot. They have done a lot with formulating some of these new roles, and we haven't really made a list of them today, but one of them that you see a lot is the Enterprise Architect. Home Depot, from what I've seen in their presentations, is one of the companies that has gotten a little more aggressive about defining what some of these roles are.

Another leader in this area has been Cardinal Health. They have also presented at a number of these shows, and they have done a lot of composition using NetWeaver Composition tools and have shown surprising savings on their projects. I think I recall some stats around saving - basically that they're spending six times less than their traditional development projects using some of these new approaches.

Of course, what this means for developers is understanding the principles of reusable code and object-oriented programming, and there's really no excuse to not learn it. It doesn't matter whether you're an ABAP person or a Java person, or wherever you are: you really want to understand what these xApps or composite applications are all about and how to construct the enterprise services that build these applications. It's basically all about pretty solid principles around reusing code and object-oriented programming, and it's out there for you to study, it's just a matter of learning.

Barlas: You mentioned xApps. What else is there that someone would have to add to their toolset to become proficient at SOA? Understanding that SOA is a really big domain, I think it would be helpful if we could kind of map that onto specific competencies.

Reed: First of all, you want to understand the business drivers behind why certain things are chosen because the one thing to remember is that with all this hot new technology, it's not worth doing if you can configure this within your standard SAP processes. This is where it's really starting to pay off for functional consultants, for example, to really understand the industries they're working in and the optimal process for those industries and specifically what SAP can currently do with that. Why do a SOA project if you can do something within SAP that works?

Of course, where SOA can kick in a little bit is more around sometimes extending those processes to customers and suppliers, so then you're looking at web-based technologies. When we talk about xApps, it sometimes just represents web-based alternatives of doing business to an internal business practice that you've done for a long time. So if you understand what that internal practice is, then you understand at least the theory behind what the xApp is going to be doing.

From there, it's simply a matter of understanding how these applications are enabled, and there are baby steps along the path to being a sophisticated composer of new applications. The baby steps for, say, a system admin would be to understand more of the integration technologies. So for someone who knows, for example, a lot about EDI, it's obviously time to learn more about XML and web-based integration. The latest for SAP involves what's now called NetWeaver PI - it used to be called NetWeaver XI, but now is PI, or Process Integration. It's a matter of getting a handle on some of these NetWeaver components around that stuff.

For the developer, it's a matter of getting comfortable with the Composition Environment, which is readily available online at least in a trial version, and you can even consider a full subscription if you want to go that route and really get the state-of-the-art NetWeaver. But even with the trial stuff, you can begin to get a feeling for the different tools. Remember, there's not standardization yet, there's not one way to go about this, so there's all kinds of things you can do.

For example, with the process modeling tools you might not have access to IDS Scheer's enterprise modeling tools on your project - that's one example of some of the tools that are coming into play. That's fine, but you probably have access to Solution Manager on your project, and while Solution Manager isn't a modeling environment, it is a repository of business processes for SAP, and there are things you can learn about Solution Manager functions that can help you. Or, alternately, you can learn about Vizio, which is pretty readily available. While it's not exactly a next generation tool, it's a good start. And Intaglio has an open source Business Process Management tool.

For the functional person, these tools are a little bit of a stretch still; there's not that easy, friendly application that's perfect for the business user who doesn't know much code yet. But you can still start getting your feet wet with the look and feel of these systems, and I think eventually they will be more business user-friendly. Certainly NetWeaver BPM is a step in that direction as well.

Finally, don't forget about the visual rendering of this stuff. You're still rendering stuff either on a portable device or mobile device or on a traditional SAP portal, so there's different rendering technologies, whether it's the Web Dynpro or Visual Composer. Visual Composer is often used in mashup scenarios that I described earlier. These are tools that are readily available on a lot of SAP project sites.

So a lot of it is being willing to take this on and start learning, and maybe you can even develop a pilot project or mashup on your own time that helps your company with a specific problem - you can demo it. I've heard of things like that taking steam: there can definitely be a bottom-up movement around this stuff, which is one thing that's really cool. Eventually, you have to have executive buy-in to get farther down the road with this stuff, but there's really not a whole lot of excuses for sitting around on this because the tools are out there to play around with.

Barlas: That's a great level of detail. To close out this podcast, I have a more high level, general question. It's the fact that there may be a tension between this world of services. I think of ESR, almost like iTunes, being able to create and move these services flexibly, versus the old SAP that everyone knows which has a reputation for being monolithic and "do it my way," like buying the whole CD with all 15 tracks and listening to them the way they organized them.

How is that going to work out in the long term? Somehow I feel that there's an essential tension between these two ways of doing business and designing software, so I'm just curious what you think about that.

Reed: I think you're right. That's one reason why when I talk about self-education, I never advise abandoning your current core competency. That's not what I'm talking about at all, because you want to pay a good deal of attention as well to the core skills in SAP that got you to this point.

The issues you raised are valid ones, and part of what you hear about with SOA is that, first of all, you have regulatory issues: you can't just do stuff on the web and have data out there that isn't standardized with whatever you owe for various regulatory bodies in your industry. So there's a whole governance piece that comes in; it's not just that these developers are having some wacky fun developing this new initiative. At some point, the chaos of that does have to be governed.

As you said, in addition to that there are a lot of cultural issues around how SAP has traditionally worked and how companies are traditionally used to working. Some of them may not be all that enthusiastic about some of the ways in which SOA can democratize information or participation in processes, and sometimes that's just not a good formula. You can imagine, for example, that maybe this would play out differently in aerospace and defense than it might play out in new media companies, so I think you're totally right to point out that this stuff is not just going to transform organizations because there's a new tool. Organizations are going to make their own decisions about how they want to apply these tools.

I don't know exactly what the long-term future of that is going to be, but I do think it's going to come down to what makes money instead of what's cool or what's hot. Some of this stuff, if it doesn't really show a bottom line benefit, is never going to be adopted and will need some level of organization and control even if there's some freedom within those controls. How that all plays out is well worth watching, and I think your point is valid that we need to keep a healthy skepticism about this stuff.

The reason that I am advocating it is because the underlying logic - which is not to alter your source code, but to build competitive advantage on top of that source code - totally makes sense to me, and that's why I'm advocating that this probably will work. But, it's going to take some time to sort out all the tools and technology around it, and it's still kind of a wild universe of tools rather than something that works every time for every company; we have to be realistic about that.

Barlas: I think that's an excellent note to end on. Jon, thanks as always for a very insightful commentary. We sure appreciate it.

We hope you enjoyed that overview of SOA in the SAP context. It's no exaggeration to say that SOA is changing the DNA of SAP-run companies, so you should do your utmost to get educated on this topic. Thanks for listening.

Editor's Note: This interview is not a verbatim transcription of the podcast. It was edited for clarity and readability; however, no content from the podcast conversation was removed.

Download Podcast (Must Be Registered and Logged In!)