Microsoft's FUD-filled .Net strategy confuses customers

By James Kobielus
Network World, 08/13/01

Life's tough enough without vendors needlessly contributing more fear, uncertainty and doubt (FUD). Let's single out Microsoft as the industry's FUD slinger-in-chief. The company has engaged in a lot of conceptual legerdemain in its .Net initiative. In many ways, .Net represents a marketing-oriented renaming and repackaging of products, technologies and directions Microsoft has been committed to since the mid- to late '90s.

To no one's great surprise, existing Microsoft products that heretofore have been outside the scope of .Net are starting to fall into this vortex. For example, recently Microsoft has begun to de-emphasize the future role of the Web Storage System (WSS), an object-oriented, Web-accessible data repository and development environment introduced in the Exchange 2000 messaging/groupware product. Instead, Microsoft increasingly will integrate future .Net versions of Exchange with the universal data repository in future .Net versions of SQL Server. However, Microsoft has stopped short of saying it will discontinue WSS altogether in future versions of Exchange, though that bit of uncertainty still hangs in the air.

This is such a big deal because Microsoft had previously announced a very expansive role for WSS in Exchange 2000, discussing the possibility of integrating WSS features into other server products. And because the vendor has now effectively orphaned WSS technology in its evolving .Net architecture. Microsoft has even hinted that it may not support the full set of WSS APIs in future .Net versions of Exchange that integrate tightly with SQL Server's data repository.

The poor customer can get whiplash trying to follow these zigzag maneuvers. If some current WSS APIs bite the dust, then customers currently writing sophisticated applications for Exchange 2000 may have to rewrite or junk them in order to migrate to future versions of the groupware environment.

However, companies should realize that beneath this layer of FUD there is little cause for serious alarm. Microsoft's renewed emphasis on SQL Server as its core data repository will not greatly affect most Exchange users. And Microsoft is moving in the right direction because SQL Server is the more appropriate platform and repository for Web services. Indeed, many current Exchange implementations are configured with SQL Server to support e-forms, workflow and other data-driven public-folder applications.

Microsoft needs to proactively address the following key questions:

? Will the company continue in future Exchange versions to support the full API set of the current WSS environment, especially the Collaborative Data Objects (CDO) 3.0 APIs that were introduced with Exchange 2000?

Currently Microsoft is evaluating its future support for these APIs in the context of its .Net framework. Chances are that rather than alienate customers, Microsoft will continue to support backward compatibility in future Exchange versions to these legacy CDO APIs, even as it innovates newer APIs for Web-centric collaborative commerce.

??Will this possible future lack of full support for all current CDO APIs require Exchange users to rewrite applications they've written to the platform? Even if Microsoft were to backpedal in API support, customers would have little to worry about. And that's because Microsoft has largely failed to position Exchange 2000 or its predecessor as a popular application development platform.

Few applications have been written to Exchange 5.5's API set (CDO 1.2), and few Exchange users have migrated to Exchange 2000. And few of the companies that deployed Exchange 2000 have built applications that leverage the rich programming features in WSS and CDO 3.0. So any backsliding from current CDO 3.0 APIs in future Exchange .Net products will have minimal impact on real-world enterprise Exchange-based applications.

??Will Microsoft help current Exchange users cost-effectively migrate current Exchange apps to the .Net development environment? You better believe the folks in Redmond won't slack off in this regard. They will almost certainly blitz customers with a full suite of migration tools, technical guidelines and professional services to help customers deal with migration issues on the road to a SQL Server-based data repository and development environment.

Freedom to innovate is a great thing and must be preserved. But why do vendors such as Microsoft feel they must periodically invent new buzzwords, position statements and architectural frameworks to keep us off balance? They think they're doing us a service by bringing us closer to their true vision, when in fact they're just blinding us with more FUD.