Has Microsoft missed the SOA bus?

While not an issue of omission, one of the telling aspects of last week's Professional Developer's Conference was Microsoft's treatment of services oriented architecture (SOA). Microsoft tended to uphold SOA as a progressive architectural development, but steered clear nonetheless from explaining how Windows-based tools and systems could be used to forge an enterprise-wide and fully heterogeneous SOA.

In fact, within the Windows Longhorn/.NET environment, Microsoft has eschewed the use of SOA for "Connected Systems." It's as if the rest of an enterprise's assets and resources are purely incidental -- and a bit annoying given all that complexity -- to whatever can be developed and deployed in Windows.
This is telling because Microsoft is taking a hands-off approach to general SOA, and refactoring how they describe composite applications made of reusable modules and services within their own environment. This ambivalence to enterprise-wide SOA comes at the same time that the other major software infrastructure vendors are making SOA an integral pillar of how they construct their own wares, and also how they expect their customers to broadly construct business processes and general composite applications for the foreseeable future.
The non-Microsoft infrastructure vendors see the next big IT growth market as one where the vendors provide the preferred way to assemble and manipulate business services as inclusively and as horizontally as possible. They want to become the tools and runtimes for the blossoming notion of business process orchestration and composite applications modeling and management. This will extend to B2B operations at some point, which makes inclusivity all the more valued.
Microsoft seems to want to relegate SOA as on-ramps and off-ramps to Windows Connected Systems, which use Web services standards, WS-* principally, to offer interoperability, but not broad integration to other IT assets. If you want to do B2B, Microsoft expects you'll use Windows/.NET-based services for that. For Microsoft, SOA is a means to Windows everywhere, and not an ends unto itself.
BEA and IBM have made process-level modeling and interface-independent assembly of SOA services the hallmarks of their future products and the expected path to future growth. And, sure, they expect that their runtimes will be the market leaders, but at least they seem to want their SOA implementations to be able to capture, extend, and manage any and all services that an enterprise might need or use.

IBM is now rolling out its WebSphere Message Broker Advanced ESB, which links just about everything but the kitchen sink. Oracle just this week has ratcheted up its SOA inclusivity with its Fusion announcement. Sun is filling in the holes of its SOA strategy, most recently with the SeeBeyond acquisition. And SAP at last spring's Sapphire event pretty much declared SOA the future for all business applications construction, customization, and refinement.
What chiefly separates BEA and IBM from Microsoft at this point is that they envision a future where the new productivity action is above the interfaces, runtimes, and discrete messaging protocols. By elevating process innovation above the older platforms and embracing open source tools and frameworks, IBM and BEA see SOA abstracting much of an enterprise's legacy assets and resources into standards-based services that can be modeled and deployed as general and easily tuned processes, regardless of their origins. Oracle, SAP, and Sun, I predict will follow suit, albeit with some hooks into their own respective incumbent and technical strengths.
There are also a slew of third-party providers of SOA solutions, from composite applications to open source ESBs, and they will fit into the grand SOA ecology in some fashion or go out of business. But as infrastructure components they are chiefly ecumenical to whatever services an enterprise may wish to use within their SOA. They don't have a larger agenda other than to make the enterprise buyer happy. This makes third-party vendors part of the general SOA value camp.
Microsoft, on the other hand, appears retro. They are remaining tied to the platform, and limiting the types of integration of outside resources at both the runtime and process orchestration levels. Does this leave Microsoft as the odd-man out when it comes to general SOA and highly inclusive ESBs? It could, unless Microsoft becomes a general SOA enabler and adds much more integration to its ESB, the Windows Communications Foundation (Indigo). At present, if Microsoft is successful in the enterprise market with currently defined Vista/Longhorn/Connected Systems, those enterprises who adopt Microsoft deeply will have to pay to support the entire Microsoft product universe, as well as some form of an enterprise-wide SOA capability, too. That's because Microsoft apparently won't provide both.

Enterprises, however, will probably want inclusive backward and forward compatibility, and the agility of a broad and adaptable SOA that plays well in B2B interactions. Maybe some small to medium businesses can go all Microsoft for all things, but the vast majority of enterprises will remain essentially heterogeneous. SOA by definition promotes and enables heterogeneity.
So a big question for enterprise IT strategists and architects over the next five years is whether they should pay for and maintain two versions of IT, or can they get away with spending only on one for an enterprise-wide heterogeneity support via SOA. They may be making the choice between SOA that encompasses multiple vendors, or Windows Connected Systems that offers WS-*-based interoperability but may also beg the need for additional broader integration with the rest of the IT universe.

One option that is bound to be considered as enterprises and hosting organizations evaluate Longhorn server is actually ending further new development in Windows, and using a general SOA approach and open tools to support whatever legacy Windows assets they may already have. That way they can focus on process innovation, and not legacy integration for the next 10 years.