IBM's unfolding power play

Are you skeptical of the justification provided by IBM and Microsoft for excluding Sun from the board of the Web Services Interoperability Organization? Perhaps you're wondering if there was something more to that decision than a simple leadership judgment call. The likely answer lies somewhere in industry history and a power play that may now be two years in the making.

The friction between IBM and Sun probably predates the two companies' cooperation and competition regarding Web services interoperability protocols. Almost two years ago, several companies, including IBM, Intel, Oracle, and Hewlett-Packard (all of which are board members of the WS-I), tried to establish OpenServer.org, an industry-wide consortium to set standards for Web applications that were viewed as superceding Java. If the WS-I is version 2 of a plan to marginalize Sun's control of Java or Sun itself, version 1 of that plan could very well have been OpenServer.org.

At the time of OpenServer.org, Oracle and IBM were holding up payments to Sun for their licenses of Sun's Java 2 Enterprise Edition. Could those licenses have served as pawns in a power play that was culminating in the launch of OpenServer.org? At the last minute, Oracle licensed J2EE, withdrew support for OpenServer.org, and OpenServer.org subsequently went poof. Sun, after patching up its J2EE license snafu with Oracle, appeared to have pulled the rug right out from under OpenServer.org, IBM, and the rest of the companies behind the consortium.

Commenting on its demise, then Sun VP George Paolini said, "In my mind, organizations of this kind succeed when there's a technology at the center of gravity, but I didn't see that."

IBM heard him loud and clear.

Since then, IBM appears to have taken a more subtle approach to turning its interoperability ideas into standards. Instead of involving itself in consortia like OpenServer.org first and developing the specifications and technologies later, IBM now starts by building the superset technologies and specs. Next, it establishes industry support by releasing the specs--sometimes in the form of open source. Finally, it emulsifies that support with an existing or new consortium.

There's another difference between WS-I and OpenServer.org. This time, with WS-I, IBM has a powerful partner who, unlike Oracle, has no allegiances to Sun and won't drop out at the finish line. Also, this partner may well view interoperability standards with the same opportunism that IBM probably views them: as a way to migrate customers away from competing solutions. Finally, this partner hates Sun with a passion: Microsoft.

Enter UDDI, WSDL and SOAP. All three protocols were pretty much developed first by IBM, Microsoft, or both, then "donated", and now, especially with the WS-I, followed perhaps by the formation of a consortium.

This history suggests that a somewhat different set of criteria was used for selecting board members than the one offered in IBM and Microsoft's explanation. Sun may not have been on the initial lists of backers of WSDL and SOAP. But that absence did not necessarily betray a lack of enthusiasm for Web services. Perhaps Sun simply was wary of protocols hatched in the labs of its rivals.

Sun has long embraced the basic premise of Web services. If all IBM wanted to do was build Web services, it could have accomplished that just as easily with Sun's Java-based technologies. But perhaps that was not enough for IBM. Perhaps IBM wanted more influence over Java. Or, perhaps IBM was motivated by more strategic goals. IBM's use of Java-only technologies may have provided a path to siphon customers away from Sun and other Java-based competitors like BEA and Oracle. But Java alone couldn't address an even bigger strategic threat--Microsoft. If a superset of Java was the superhighway to Microsoft's customers, IBM looked at Sun and saw nothing but a roadblock.

With a competing middleware from Microsoft (.Net) around the corner, IBM's pursuit of a Java-only strategy would make it much more difficult to get Microsoft customers to switch to IBM's Java-based solutions. To prevent Microsoft from locking customers into Windows, IBM needs supersets of Java that are interoperable with Windows. Such supersets would make possible Web services identical to those built on .Net, but built on IBM's solutions instead. Not coincidentally, Microsoft is looking to penetrate IBM's prized customer set in the datacenter and needs exactly the same thing.

The interoperable UDDI, for example, is rumored to have been developed at IBM's Watson facility. Regardless of where it was developed, UDDI was privately introduced to the industry, with the help of Microsoft and Ariba, in the summer of 2000, around the same time that the Organization for the Advancement of Structured Information Standards (OASIS) was exploring the idea of an XML-based registry. While its not clear exactly when in 2000 the three companies approached Sun and the other 32 initial supporters of the UDDI Project, Sun was probably put in the awkward position of agreeing to support a proposed standard for which its rivals had already developed technologies. Soon after, IBM open sourced its Java code for connecting to UDDI directories.

Likewise, IBM open sourced its Java code for SOAP (SOAP4J) just after the version 1.1 specification (co-developed by IBM and Microsoft) was submitted to the World Wide Web Consortium for consideration.

Sun, like IBM and Microsoft, understands the risks of interoperability standards. In addition to the noble cause of interoperability that customers rightfully demand, these standards level the playing field and make it easier for customers to consider competing solutions. The risks are compounded, however, when some players give themselves a head start, like IBM and Microsoft did with UDDI.

Charging Sun with a bad attitude, IBM's Director for eBusiness Standards Strategy Bob Sutor says, "If it wasn't invented at Sun, they won't get behind it." Sun officials admit they are wary of anything that poses significant risk to Java, Solaris or SPARC (the RISC processor technology in Sun's servers). UDDI, SOAP and WSDL pose that threat--not only to Sun, but to all vendors.

Interoperability technologies were introduced by Sun's competition. What company in Sun's position wouldn't want time to make sure that the playing field was indeed level and that the proposed standard was a two-way street? What may have been caution and diligence on Sun's behalf (especially on the heels of an attempted mutiny by J2EE licensees) appears to have been characterized as lack of Web services leadership by IBM's Sutor and Microsoft's .Net Platforms Strategy group director Neil Charney. That alleged lack of leadership has kept Sun off the WS-I board.

Meanwhile, for two companies that claim to be doing what's right in the name of open standards, interoperability and customer requirements, there's a bit of hypocrisy in the fact that both IBM and Microsoft are displaying a lack of enthusiasm for Project Liberty; an authentication specification effort started by none other than Sun. Microsoft has a competing specification called Passport, and IBM is once again stuck in the middle. IBM regards Passport as a proprietary, closed system that needs to be opened up--see my interview with IBM's Steve Mills. However, Big Blue is taking great care not to upset a Web services relationship with Microsoft that's been two years in the making and that could position it for an even bigger power play--finishing off Sun and taking over Java.

Was IBM and Microsoft's decision to exclude Sun from the WS-I the final chapter in a strategic interoperability power play to marginalize Sun, or a justifiable effort to keep Sun from slowing down the evolution of interoperability standards?

You decide.

Write to me at david.berlind@cnet.com, share your thoughts in TalkBack, and come back for the next installment, when I explore whether IBM sees Sun as nothing more than a stepping-stone to something bigger. Much bigger.