Layers of Integration

Enterprise systems seem to grow like rings on a tree. Ideally, the vendor starts with a grand blueprint that can evolve. However, as history tends to toss curveballs, it’s difficult for vendors to 100% “future proof” their architectures. So they end up adding new layers of technology. While the extensions draw vendor support, the drawback is added complexity and cost.

SAP is a good (but not the only) example of this. Since introducing R/3, the client/server successor to the mainframe R/2 app, it has superimposed new technology demand changed. Of course, that makes sense given that SAP customers are not about to rip out billions of dollars of R/3 investment every time they want some new capability.

So, when demand first materialized for the need for a simpler alternative to ABAP4 programming for exposing R/3 to other systems, it devised Business APIs (BAPIs) containing pre-defined paths to SAP’s data and process models. As need for web enablement and business intelligence emerged, SAP introduced the web infrastructure, complemented by a series of SAP BW analytic applications. And when it came to enterprise integration, SAP responded last year with NetWeaver, a new services-oriented architecture for building “composite applications.”

While a good start for customers with SAP-centric environments, until now, NetWeaver was just the latest SAP tree ring. You still needed other SAP tools and middleware if you wanted to access core R/3 processes, build portals, or enable mobile devices. A year later, SAP has taken the logical next step by integrating NetWeaver with most of its middleware. That’s an approach that looks a lot like BEA’s and Oracle’s, but with native R/3 connectivity added.

We’d like to see SAP take matters a step further. Today, MySAP and NetWeaver remain separate. Maybe that makes sense for customers that simply want web access without the integration or portal. But in the long run, that’s an artificial separation. For instance, if you let customers place orders via the web, sooner or later it may make sense to tie that to related processes such as invoicing or customer history without awaiting batch updates. As SAP is competing largely on its ability to deliver soup-to-nuts solutions, why not finally put and NetWeaver together where they belong?

Alright Already

Today, no vendor would be caught dead labeling its technology proprietary. Yet, getting the balance right has always been a perennial challenge. If you don’t offer something that’s unique, why would anyone buy your product?

Although at first glance Linux tears that argument to shreds, on closer examination, it reaffirms the value of uniqueness. Customers buy distributions from Red Hat or SuSE because they arbitrate and support what would otherwise be a chaotic update process.

Which brings us to the matter of why doesn’t Sun open source Java. Sun has always competed on “open” standards. It won the workstation wars because it made its file system available to anybody, leading NFS to become a UNIX standard. And it was the dot in dot com because UNIX servers were more “open” than mainframes, drawing more third party software (OK, they were also more scalable than Windows). Significantly, Java triumphed on the server for many of the same reasons.

Yet Sun has always walked a tightrope with Java. They created the Java Community Process (JCP) that was open to any Java licensee, but governed by Sun. With the latest version of the JCP, Sun is striving to open up the process further. It wasn’t that Sun was trying to monopolize Java, the reality was that they never knew where to let go. Ironically, while Sun has continued to control Java, so far it’s made little money from it. Yet.

So we’re glad to hear that Sun is seriously considering open sourcing Java. Yes, there are issues with compliance testing to iron out. But our response is, why not, what have you got to lose? More than getting on the “right side” of the issue, open sourcing would further knock down barriers to individual developers improving Java. It won’t mean anarchy either. Look at the most popular open source technologies — Linux, the Apache webserver, the Tomcat Java servlet container. They’re all governed by a single person or organizational entity.

It’s interesting that as these discussions are proceeding, Sun might be on the verge of finally making real money from its invention. Having recently announced agreements with China and several other countries to sell the Java Desktop System, we believe Sun has a unique opportunity to penetrate developing nations where (1) Microsoft Office has not yet saturated the market, and (2) demand exists for cheaper alternatives. Significantly, whether the Java Desktop System succeeds will have nothing to do with who controls or has access to the underlying Java spec.