Oracle, Sun, and the Triumph of ABAP over Java

Breaking news: Timing is not always a blogger’s best friend. I had already cooked up the following piece on SAP’s ABAP and Java strategy when Oracle’s Sun acquisition was announced. Back to the cutting room floor! As you read the following piece, you’ll see that fortunately for me, SAP’s ABAP strategy plays directly into the Oracle-Sun news. At the end, I’ll make a couple more comments about how this looks through the lens of Oracle’s pending “control” over Java.

SAP and its customer base agree on some things and not others. This is especially true when conference season hits. The headlines SAP features at Sapphire in Orlando may or may not be the same ones that customers would have chosen to feature. Unless SAP announces at Sapphire that maintenance fees will remain at 17 percent; in that case, there will be as much agreement as there was last year about Eric Clapton. Sometimes the real headlines in SAP sneak up on you. This is the case with SAP's gradual recommitment to ABAP development. Prior to the Oracle-Sun announcement, SAP's plans for ABAP had already reached a critical mass. No, we didn’t hear about it, because ABAP doesn't make for sexy headlines. Buzz-free or not, the apparent triumph of ABAP over Java has implications for those who are trying to cultivate the skills that are relevant to the next phase of SAP project work.

It's important to remember that early in this decade, the possibility that SAP's entire stack would be rewritten in Java was a looming possibility. Java was in, ABAP seemed dated, tied to legacy environments that were supposed to go away after Y2K. Many ABAP programmers bailed out in pursuit of functional work or greener development pastures. But behind the scenes, ABAP chugged along, proving to be better suited for SAP's high-volume transactional environments than Java. Yes, SAP came out with the NetWeaver Development Studio, a Java based environment, and later the Composition Environment (CE), another Java platform.

But behind the scenes, ABAP didn't go away. A good chunk of NetWeaver Process Integration (PI) was written in ABAP, and SAP's latest and greatest GUI tool, Web Dynpro, eventually got an ABAP version, known as Web Dynpro for ABAP. Java was still getting the headlines by virtue of CE and the buzz-filled world of SOA and mashups, but ABAP was there too, a trusty old friend to SAP customers who have counted on its stability from release to release.

This issue came to a head last week during a webcast on SAP's UI strategy that was presented to SAP Mentors by Thomas Jung, fellow SAP Mentor and SDN blog legend in ABAP circles (disclosure: I am an SAP Mentor). Thomas, who works for SAP Labs, is as good at articulating SAP's development strategy as anyone. You can catch him yourself on Enterprise Geeks, a weekly podcast series on SAP technical trends that features Thomas, co-host Ed Herrmann and special guests riffing on SAP "geek stuff" that most of us need to know something about in order to be effective in today's "suits needs geeks and geeks need suits" IT world.

During the UI webcast, which was supposed to be about SAP's UI strategy going forward, it became clear that a major underlying theme of the webcast was that ABAP is not only here to stay, but is now asserting its dominance. Example: Employee Self-Service, which has always been a Java-based app, is being rewritten as an ABAP-based application, likely to be released as part of Enhancement Packs 5 and 6 (details still to be decided). With Web Dynpro for ABAP (WDA) gaining traction, it's clear that ABAP is moving into territory historically reserved for Java within SAP. More evidence of this shift in emphasis: SAP has publicly stated that it is beefing up its own Web Dynpro for ABAP resources by adding ten more FTEs to the WDA Foundation team.

This doesn't mean that Java is going away. In fact, SAP Chief Technology Officer Vishal Sikka would encourage us to remember that a key to his vision of "timeless software" is moving past obsessions with a particular programming language and focusing more on supporting business processes using re-usable building blocks that are not language-dependent (see Dr. Sikka's white paper on "timeless software" in PDF format here). What we do know, however, is that SAP is pushing Java back to the "edges" of the enterprise, where other web-based standards like XML also live in order to provide SAP users with options to connect to other platforms beyond traditionally closed enterprise systems. That’s why, when it comes to combining web services from different sources into composites using the Composition Environment, we can expect Java to remain the language of choice. But ABAP is still the main tool for building Business Suite Core web services.

We could spend time debating the "whys" of these technical shifts. My own take is that SAP really did listen to its users, who were not happy about their deep ABAP investments being threatened by an uncertain Java future. SAP also realized the hard way, as in Employee Self-Service, that Java is just not the ideal language for SAP's enterprise apps. There have been rumblings that SAP is internally disappointed with the robustness of the Java EE platform.

Whatever the reason, a more important question is for those in the services field is: what does this mean for skills? What we know is that most of SAP is going to run on ABAP, but for the foreseeable future, we can still expect Java-related SAP work in Portals, PI, CE, and soon with NetWeaver BPM. And yes, for a while, we’ll have Java-related needs in ESS. But clearly, the Java-related SAP skills areas are mostly at the “edge” of the enterprise where the emphasis is on either heterogeneous connectivity or Internet-based UI experiences.

Going forward, we can expect SAP to keep Java at the edges whenever it can, and when you add the Oracle-Sun news to this mix, I would not be surprised if the aforementioned list of Java-dependent SAP apps continues to shrink. At the least, a la Web Dynpro, we can expect ABAP-based alternatives to keep coming up, including areas pertaining to web service composition. Clearly, internal SAP applications have a future that looks a lot like....ABAP. Of course, this is not your grandpappy's "R/3 version 2.0" ABAP. This is object-oriented ABAP, informed by SAP's forays into service-oriented architecture.

We asked Jung about the dilemma of the SAP programmer during the webcast, and he flat-out said, "If your programming work is Business Suite focused, you should be thinking about focusing on ABAP." But on the edges of the enterprise, where Rich Internet Applications and mashups loom, there are all kinds of opportunities to dive into the web-based programming languages that are grabbing all the headlines. Speaking of which, we'll be hearing more about Ruby within ABAP environments as the year goes on, further reinforcing my long-standing recommendation that the best SAP programmers are "hybrids" who understand both ABAP and web-based protocols. With the SAP version of Java now facing an uncertain future, Jung had a sensible piece of advice for SAP Java developers: instead of working solely within SAP Java, why not master common Java standards such as JSP and JSF? Since web-based apps are all about standards-driven development, it makes sense for those with a commitment to Java to master broader standards in addition to working in SAP's Java flavor.

In my first version of this piece, I wrote that “we're not going to hear Leo say anything close to ‘let me clarify SAP's ABAP and Java strategy’” during his Sapphire keynote. Now, given Oracle’s Sun acquisition and the obvious questions about SAP’s future commitment to Java that headline raised, it’s entirely possible that Leo may buck tradition and say something about ABAP after all. But whether he touches this hot coal or not, the “triumph of ABAP” is still a headline for SAP, even if it sometimes gets buried in the back pages of release notes.

With the latest developments tossed into the mix, we can expect customer confusion about SAP's ABAP-versus-Java strategy to continue. Firms that can explain SAP's rationale and what this means for the long term are going to have a big edge over those who have yet to wade through the implications of this steady stream of smaller product announcements. As for the future of Java post-acquisition, that’s a story we’ll have to monitor in the coming months. One thing I feel pretty certain of: somewhere in Walldorf, SAP folks who preached the gospel of ABAP-over-Java are patting themselves on the back as they read the latest headlines.