The real deal on .Net

Ignite/400 founder Bob Cancilla says there is a contradiction between professions of interoperability and a Web services platform based on a Windows-only systems that locks customers into a single computing model.

4 min read
IBM and Microsoft made news last week touting advances they've made on the Web services front. The two companies even went so far as to bring together Microsoft's Bill Gates and IBM's Steve Mills for a joint press conference in New York to ballyhoo their efforts. IBM and Microsoft on the same stage? They strike me as a rather odd couple.

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...
Web services
Get the latest headlines and
company-specific news in our
expanded GUTS section.

Sure, both companies have worked closely to develop and promote a sizable number of important industry standards that will continue to have a big impact on the way business is conducted in the foreseeable future. But cool specs are meaningless to the IT people who must actually assemble all those standards into real business solutions. That's where the rubber meets the road for Web services.

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.
Additionally, Microsoft's claim that .Net's Web services platform saves customers money is misleading. Sure, the initial investment is enticing, but how much will it cost when the hard work begins? A recent Gartner report said companies planning to move their old programs to .Net can expect to pay 40 percent to 60 percent of the cost of developing the programs in the first place.

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.