Unlike IBM, Microsoft falls short when it comes to helping customers use standards in a productive, cost-effective way. Even as the two companies stood side-by-side talking about interoperable Web services, something was clearly lacking from the Microsoft camp.
Get Up to Speed on...
Get the latest headlines and
company-specific news in our
expanded GUTS section.
Redmond's approach to Web services is a dead-end of closed, Windows-only systems that lock customers into a single computing model. Customers don't have the freedom to choose the best hardware or operating system. Where does that leave the millions of users who rely on non-Microsoft platforms such as mainframes, Unix or Linux?
Contrary to Microsoft's claims, open standards does not necessarily mean open environments. Microsoft's Steve Ballmer has said that .Net delivers benefits as a Web services platform through XML (Extensible Markup Language) connectivity extended across clients and servers. The problem with that simplistic view is that while XML and Web services break down barriers when used with open standards, .Net creates insidious new barriers by promoting vendor lock-in for customers.
Ultimately, .Net defeats the purpose of open standards because Microsoft products are open only as long as you develop applications on the Windows platform. To me, this doesn't say open, it says welcome to yet another Microsoft environment that is anything but open.
Proprietary environments deny businesses the flexibility to chose best-of-breed solutions that are fine-tuned to their industry's unique environment. Consider financial services companies that need Web services to link disparate systems in a secure environment. Given Microsoft's checkered past with security flaws, I'd hate to think that my local bank is even thinking about standardizing on .Net.
Unlike J2EE middleware, .Net doesn't do much beyond connecting information to the Windows desktop. Companies have moved beyond merely connecting applications but now also require software that manages high-volume transactions and all kinds of customer data. They need to integrate complex business processes and centrally automate the management of IT environments. These are all areas where Microsoft continues to fall short.
Contrary to Microsoft's claims, open standards does not necessarily mean open environments.
Building your company's Web services platform on .Net is fine if you don't mind throwing away decades of investment in existing applications. For instance, on any given day, businesses use CICS systems to process about 30 billion transactions, to the tune of $1 trillion. They can't afford to rip out that kind of processing power. Instead, they're looking for ways to exploit it within other applications. But if they were to buy into .Net, they'd better be prepared to stack it on the shelf because Microsoft's Host Integration Server provides limited access to CICS on mainframes.
There are even more reasons why .Net hits the wall as a Web services development and deployment platform. Customers must deal with .Net's limited scalability, the ever-fluctuating .Net product road map and the five- to six-year migration path, just to name a few.
But Microsoft doesn't seem to realize that being open takes more than merely participating in standards organizations or positioning themselves alongside IBM. Redmond continues to use Web services standards to develop--and encourage their partners to develop--Windows-only applications. They continue to pass off .Net as the best platform for "interoperable" Web services, even though they're not really open.
Windows dominates the desktop and many of us will continue to use it to run our PCs. I suppose that's why IBM wanted to show interoperability with Microsoft at the demo in New York. But Microsoft won't necessarily transfer its dominance to Web services, since there are better alternatives out there.
Customers looking to adopt a truly interoperable Web services platform should think twice before leaping into .Net's not-so-open arms.