The good news? If the purpose behind these tools can be clearly understood, and if the skills needed for each development approach can be identified, then the SAP manager has a much more flexible (and bottom-line friendly) approach to development than ever before.

In February of 2008, I did a podcast with Thomas Jung, SAP NetWeaver Product Manager, on the future of SAP development (this podcast is available on the SAP Developer Network, where Thomas writes a popular blog on SAP development). In the podcast, Thomas did an excellent job of summarizing SAP's development strategy and suggesting practical next steps that individual consultants (and SAP shops) could do to stay on track.

In this article, I will feature the key points Thomas made in the podcast, with the goal of addressing the some of the burning questions facing SAP development teams.

1. The Importance of Object-Oriented Programming to eSOA

I started out the podcast by asking Thomas about the adjustment that SAP programming teams need to make in order to get the most out of SAP's NetWeaver platform. He pointed out that the first step is to make sure that everyone is well-versed in the fundamentals of object-oriented (OO) programming.  "The biggest adjustment is designing and building in an object-oriented way," said Jung. "But there is no reason why people on the 4.6 level shouldn't already be doing that. The core ABAP object-oriented concepts were all there in 4.6c, but people don't take advantage of it."

Thomas went on to explain that programming teams may be wary of making an initial investment in the OO learning curve, because it is a new programming paradigm. But in the long haul, Jung believes that the investment will pay off, because so much of SAP's eSOA strategy is founded on object-oriented programming concepts. It's also a lot easier to bring in (and train) ABAP Objects talent than it is to invest in those rare outside consultants who have already been though an actual eSOA project.

Thomas explained how OO skills can be applied to eSOA projects. "If you've already mastered or at least feel comfortable with OO, then truly the biggest adjustment that you should make is this idea of Service-Oriented Architecture," said Jung. Jung pointed out that eSOA is driven by simple concepts of re-useable code. "It's taking those concepts of encapsulation, of reuse, of smaller units of work that have their own unit test built into them, and applying that to everything that you build," he said. "Whether it's a one off accounting financial report or a big custom application, these concepts will make you a better programmer and will benefit whoever you're developing for."

2. Java Doesn't Replace ABAP - Java Compliments ABAP

With the possible exception of outsourcing, no subject has generated more controversy in the SAP community than the supposed "death of ABAP." For SAP developers, the notion that SAP is abandoning ABAP has led to massive career uncertainty. For SAP project teams, questions about SAP's commitment to ABAP have led to difficulties planning future development efforts.

Fortunately, we can now say that the so-called "death of ABAP" was always more fear than reality. Certainly, the global SAP labor pool has changed how ABAP projects are staffed, but ABAP work is alive and well. On the other hand, the eSOA era has definitely changed how SAP customers should think about their development efforts. During the podcast, Thomas described how the SAP Labs team views ABAP, Java, and model-driven development. As it turns out, it was never about "ABAP versus Java," with one language winning out across the board.

As Thomas explained, it's more about understanding the relative strengths of each. "If you look at ABAP and Java, each have their inherent strengths and weaknesses, and there's no value in turning Java into ABAP or vice versa," said Jung. "If you look at where SAP is primarily using each language internally, the Business Suite continues to have its business logic written in ABAP. ABAP is an excellent language for multi-user session environments; it doesn't just go to the language - all the inner guts of an ABAP-based system are well tuned to those types of massive user systems. Obviously, the ABAP language is well suited to writing business logic. We also have a huge investment in ABAP, and so do our customers; there's just not tangible value in rewriting it in Java for the sake of rewriting it in Java."

According to Jung, the savvy SAP development team uses ABAP for established, high-volume systems, but turns to Java for middleware and web-based development. Thomas and many others refer to these cutting edge projects as "edge applications," because these  apps sit at the edge of the enterprise, often running on top of the ERP system, and they communicate seamlessly with the applications of customers and suppliers because they share the same web-based protocols. "Middleware is often better served by Java," said Jung. "Because Java is based upon open standards, being able to leverage community development, open source development and edge applications, as well as composite applications where you're combining multiple systems, maybe SAP and non-SAP systems together - these are obviously areas where Java is strongest."

An even more interesting discussion is how SAP is trying to move its platform to the point where the development language of choice is not important. At TechEd 2007, in a group interview session, I had the chance to ask SAP Chief Technology Officer Vishal Sikka about which programming language SAP was favoring going forward. He basically said that we need to reframe the question. His point was that with the new NetWeaver-driven eSOA development platform, the idea is to make it irrelevant which programming language we choose to use.

Essentially, the eSOA layer is designed to work with any open standard, so whether a company chooses to program in Java, ABAP, or .NET would not really matter, because the code would be "wrapped" in an SOA layer that would be able to communicate seamlessly with any non-SAP or external systems.

I asked Thomas if he agreed with that perspective. "Obviously, if we follow an eSOA paradigm, if we truly open and enable everything that we build, and we build in these smaller units of work that can be tested individually, and that opens things up," said Jung. "Then, when SAP delivers something - business logic for example - maybe it's written in ABAP, but like we said earlier, it doesn't matter any more. I can consume that in .NET, I can consume that in Java, I consume it in another ABAP environment, so it does open things up."

Thomas did emphasize, however, even though SAP is "opening up" its architecture, there is still a major advantage to standardizing on SAP's own eSOA tools. "Although it doesn't matter what programming language we choose, I would say that SAP provides the best tools in the marketplace for building Enterprise Services," said Jung. "And when it comes to security and scalability, it can matter who you get your tools from to build Enterprise Services: Although we're all based on open standards, not everybody's performance and security running within that is the same. So at SAP, we feel that we still provide the best tools, but at the same time, they're inter-operable, and how you consume what's been built as an enterprise service is an open option as well."

Returning to the question of ABAP versus Java, in Thomas' view, "interoperability" means that SAP customers have the freedom to choose the development approach that is best suited to their own internal staff and business model. "To the question of ABAP or Java, it becomes a bit of a moot point and I recommend to people that they use the one that they are most comfortable with," said Jung. "That means to work in the areas where they already have a skill set investment, where they already have transport and versioning mechanisms set up, and where they see their company being the most efficient because, at the end of the day, it's about providing value to the business.

"The business end-user doesn't care whether you used ABAP or Java to implement your service, and even when it comes to user interfaces, much of the user interface technology looks the same to the end-user, so whether using ABAP or Java, they care about how quickly you delivered it to them, at what cost and how flexible it is moving to the future. Those are the real questions that IT departments should be concerned with."