Microsoft absent from open standards movement around SOA

Back when Web services standards were being devised and made part of an open standards approach to XML-based loosely coupled services interoperability, Microsoft was head of the pack. It was one of the main supporters of the WS-* family of specifications that found a home at the Organization for the Advancement of Structured Information Standards (OASIS). Microsoft was all for "open" on the Web interoperability level.

Now, a new series of SOA standards is headed to OASIS, ones that could create a whole market segment around SOA common programmatic principles, but Microsoft is nowhere in sight. The absence of Microsoft from the Service Component Architecture (SCA), and its sibling Service Data Objects (SDO), definitions process can mean one thing: Microsoft will pursue its proprietary approach of baking pseudo-SOA into its operating system stack as long as it can.

And as John Bell, enterprise architect at Marriott International, recently pointed out during a BriefingsDirect podcast I did with him and some other IT analysts, this is entirely consistent with Microsoft's history and strategy.

"... Microsoft tends to build those kinds of capabilities and as part of the operating system," said Bell. "Other vendors tend to create them as standalone products and infrastructure pieces. If you are a small company having it built into the operating system is a value to you, but in large, heterogeneous environments that can be costly to you. So that [strategy] has always been used by Microsoft -- if you look at CORBA versus COM and DCOM, it’s the same story."

My question, then, is this: Why is SOA interoperability any different than Web services interoperability when it comes to benefiting the businesses? At its most basic level, SOA aims to make heterogeneity in IT systems an asset, rather than a liability. If Microsoft sees interoperability at the Web services level as a productivity benefit, why is standardized interoperability at a programmatic level, embedded within widely accepted SOA open standards, any less beneficial?

Shouldn't Microsoft as an incumbent vendor in most enterprises be interested in helping those organizations make the best use of their applications, data, runtime components, and services? The SOA Consortium of large IT vendors -- including SAP, IBM, Oracle, BEA and Cisco -- seem to all think that such reuse and extension of heterogeneous IT assets is a good idea. Incidentally, the consortium today began a new blog. And one that won't put them out of business as large vendors due to cooperation, either. If IT organizations think such broad use of IT assets is a good move, too, they ought to be telling Microsoft about it now.

Microsoft will listen to its users, but the users must be forceful, vocal and committed. For example, you may recall that Microsoft last year reached an agreement with Novell to help make the interoperability, or at least the co-existence, of newer Windows servers and Novell's SUSE Linux server distribution, work better in the same environment. From an operations and cost perspective, Microsoft heard its customers. And those customers want to be able to better manage Linux and Windows platforms together at lower total cost.

Here, once again, Microsoft -- when prodded hard by its customers -- thinks that reduction in the complexity of managing Linux and Windows side-by-side is a productive venture. Well, then, again, why not the same drive to efficiency when it comes to SOA interoperability at a programmatic and meta data level for mixed environments?

One would think that Microsoft's customers are bound to, once again, cry for relief when dueling SOAs rear their complex heads inside the enterprise in coming months and years. If IT managers end up with two types of SOA implementations -- one based on open standards and supporting heterogeneity, and the other based on a Windows everywhere lock-down approach -- we may find ourselves back in 1998. By that I mean that that was when the Enterprise Java approach versus the Windows everywhere approach left developers and architects trying to work out how to make these things work better together. And that, with some level of irony, lead to the creation of the WS-* specifications.

Perhaps it would be better to avoid this whole break it-fix it cycle, which is seemingly based on Microsoft's desire to wager that its hegemony can be leveraged to take on yet another chapter in computing and somehow come out ahead, but at the cost of a lack of ready integration. I think SOA is different, and that SOA by definition is about avoiding another cycle of break it-fix it. It's just too expensive, and it gives IT a black eye as a perpetual cost center instead of a productivity and new capabilities center.

Indeed, the backers of SCA and SDO that are bringing it all to OASIS, see history repeating itself. They say that standards-based SOA via SCA/SDO may do for SOA what J2EE did for n-tier in distributing computing in the mid-1990s -- create a non-Microsoft way to assemble an architectural approach that supports a variety of standards-oriented infrastructure vendors, while appealing with common platform porting ease to a new generation of ISVs, partners, suppliers, integrators, and channels -- all of which helped spur a large Web, intranet, portal, and ecommerce ecology of applications and services via J2EE. And then, of course, Microsoft needed to respond, which it did, with .NET, Common Language Runtime, and C#. And enterprises had to buy all of that stuff, too.

The SCA/SDO backers invited Microsoft to join their efforts, they said, to adopt a programming-level of SOA standardization, rather than a Web services level of interoperability. But the members voiced little hope that Microsoft would have a sufficient motivation to move .NET to a programmatic open standards level. SCA/SDO is nonetheless expected to make interoperability between .NET- and non-.NET-based services a natural and rudimentary aspect of SOAs, but at a higher cost -- a tax, if you will -- due to Microsoft's separation from the pack.

Tell them now, if you feel this is a lack of innovation tax you'd rather not bear.