Does SAP’s SaaS News Impact Their Java Strategy?

A couple months ago, I wrote a blog entry entitled “Oracle, Sun, and the Triumph of ABAP Over Java” which raised a bit of a ruckus. I stand by the research and fundamental message of the piece. However, the title of the blog (“Triumph of ABAP”) might have been misleading. My intention with that blog title was to make clear that ABAP was the programming language SAP had settled on for the Business Suite. I was not trying to imply that Java had no relevance to SAP development. I always felt that Java would retain relevance on the “edges” of the Suite, as well as in third party plug-ins and service composition. My recommendations in that piece that SAP developers acquire a “hybrid” of ABAP and web-based skills reflected my views.

Two months forward: with the recent developments in SAP’s SaaS market play (see Peter Russo’s entry on the developments from John Wookey's internal SaaS group), Java has returned to the center of the discussion. So does this change anything I said in my last piece on ABAP versus Java?

To get to the bottom of this, I talked to a few folks inside of SAP to find out if the Wookey announcements had changed the conversation inside of SAP. Bottom line: not much - except for some surprised folks who were not in the loop with what Wookey was up to until he went public. “I was just as surprised as you were” was one such reaction. (For those who are interested, Wookey’s entire keynote for the SIIA On Demand Europe Conference has been made available online)

One of the people I contacted was Thomas Jung of SAP Labs, who is also part of the “Enterprise Geeks” team that issues regular podcasts on SAP technical trends in a very listenable style (they just posted a podcast that delves into the latest Wookey/SAP SaaS news). Before I share Thomas’ view on this from inside SAP, we should note: Wookey’s group is basing its SaaS development on the Frictionless Java technology SAP acquired in 2006 by purchasing Frictionless Commerce, which is a Java-based platform.

“This is perfectly in line with the development strategy we’ve been using,” said Thomas. We went on to discuss some of the nuances of this strategy, almost all of which I have already published in the “ABAP Triumphs” blog. Add this to the mix: SaaS will present another way for companies to plug into the ABAP-based Suite. Originally, the vision of SAP Java was centered on composing on top of the suite using the tools of the NetWeaver Composition Environment (CE), a Java-based platform. But SaaS adds another way of enhancing the core ABAP-based Business Suite functionality using Java-based SaaS apps. As Peter stated in his SaaS piece, this may mean two routes to SOA and SAP's future...

The only change I would add is that in some cases, these SaaS apps will not be about competitive differentiation, which is at the heart of SAP’s vision of service composition. For SaaS, we may be talking more about cost savings or ease of deployment. In these cases, it’s possible we will see more overlap between SaaS services and what SAP offers on premise, SAP CRM On-Demand being an obvious early example. Whereas the original view of service composition is intended to extend the Business Suite functionality, SaaS may also present overlapping functionality that would win out based on ease of use, cost factors, or cloud convenience.

However, that doesn’t change the fundamental approach to “ABAP in the Suite and Java beyond the suite,” it's just two different delivery models. We can expect some twists, though, such as SAP’s “Blue Ruby” project, which involves embedding Rich Internet Applications (RIA) inside of ABAP programs. Another surprise came from Leo Apotheker in a recent Wall Street Journal blog interview, suggesting that putting the entire Business Suite in the cloud (or a version of it) remained a possibility: “Apotheker will also push SAP to develop more online software, saying that efforts are already underway to make SAP’s entire portfolio available this way.”

So does this mean that I should title this new blog entry “The Triumph of Java Over ABAP?” Not so fast. The Business Suite has hundreds of millions of lines of code. Many inside SAP, including CTO Vishal Sikka, point out that customers are cautious about which kinds of data they want to put into the cloud. ABAP is here to stay, but then again, so is Java and many other web-based standards like Ruby and Adobe Flex. Whether you’re an SAP customer, service firm, or individual, you’d be well-advised to pursue the same ABAP/web hybrid model that SAP itself is adopting.

That leaves us with one final piece of business: does SAP’s SaaS strategy play into Oracle’s hands given the Sun acquisition and SAP’s obvious continued dependence on Java? If you poll those inside SAP, you will hear a wide range of views on this controversial topic, but the consensus is that it’s either a small concern or a non-issue. Certainly Wookey has not adjusted his team’s approach post-Oracle/Sun. However, I continue to believe that Oracle is going to seize the opportunity with Java to stick it to SAP a little bit.

Think of it this way: Oracle doesn’t operate any free highways. They operate toll roads. Could Oracle legally charge only SAP a Java toll? Of course not. But could they decide to place some tolls on a Java thoroughfare that SAP drives over frequently? You bet your Oracle stock they could! So my prediction is that SAP (and other companies) will eventually pay an ongoing financial price as Oracle attempts to monetize Java in some way. However, this will simply become a cost of doing business for SAP, which I suspect is how the current lawsuit with Oracle is viewed internally as well. SAP and Oracle have a “cooperate when necessary” policy – I simply don’t see the Java part of their relationship as falling into that cooperative realm. But this is pure speculation, and if the two companies collaborate on future Java standards for the benefit of all, I’ll be glad to be wrong. What is not speculation is that ABAP is alive and well inside of SAP, and so is Java.