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 SAP.com 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.

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.