.NET? Not Yet
Microsoft Corp. is positioning .NET as the enabler for next-generation Internet applications. As important as that sounds, I wonder if I’m somehow missing the enormity of the effort required for .NET to become successful. Some executives at Microsoft are positioning this as yet another “bet the business” technology shift for Microsoft, but from my perspective it appears to be an important evolutionary step --not a revolutionary step.
It may be easiest to explain what .NET is by explaining what .NET is not. First, .NET is not a new software licensing scheme where Microsoft rents or sells applications. There has been speculation that Microsoft will move to a rental model, and will discontinuing perpetual licensing schemes. While there are valid reasons for certain market sectors to embrace software rental, for now you don’t have to worry about not getting a perpetual license for Windows 2000 Professional, Office 2000, or any near-term products.
Another thing that Microsoft.NET is not is a single or a group of products that you can buy. It is better to think of this initiative as creating COM++ or COM#. The .NET technologies will be incorporated into virtually all of Microsoft’s operating system and infrastructure products, and will serve as an enabling layer that provides the services needed by next-generation applications. Given the proprietary nature of COM and the failure to get decent COM support aboard non-Microsoft platforms, the company is wise to use a different moniker for something that it hopes will be used as a multiplatform technology.
The most important elements to .NET are not, after all, foreign terms. Elements include XML -- a universal file format and data exchange mechanism -- and simple object access protocol (SOAP), a messaging mechanism that can kick off remote procedure calls or multiple processes on different target systems.
There are some interesting parallels between the .NET strategy and Microsoft’s 1995 effort to embrace the Internet. Like Microsoft’s Internet strategy from a half-decade ago, the .NET strategy affects nearly every product in Microsoft’s portfolio. The infrastructure pieces -- operating systems, servers, and middleware -- all need to be capable of understanding, handling, and processing .NET traffic. Tools need to generate applications that leverage the .NET infrastructure, and applications need to be written to exploit .NET capabilities.
Where the gee-whiz slope meets the can-do curve is where Microsoft is at today. The company had prepared to launch its server products last month. You will find native XML support included in products like SQL 2000. Visual Studio 6 already has extension toolkits available to generate SOAP objects, and is working to integrate .NET capabilities into the next release of Visual Studio. So Microsoft can state that .NET is falling into place.
But there’s one missing piece of the puzzle. No matter how good this new infrastructure is, and even if it’s installed at many customer sites, the applications are still missing. Applications tend to lag infrastructure technology because they are frequently written to least-common-denominator operating environments. This could have the effect of slowing down .NET-exploitive applications since we’re likely to have non-.NET platforms in the mix for a long time to come -- Windows NT, Unix, and Linux to name a few. The good news is that on the client side, it is likely browsers will abstract application needs away from the core operating system.
Finally, the .NET strategy is expected to enable mobile, embedded, and other next-generation clients to participate in a network, even if they are not running a --gasp -- Microsoft operating system. If this proves true, it could be the first time Microsoft has launched a technology initiative that doesn’t inherently favor Microsoft platforms. This sounds too good to be true, and most observers will not believe it until they see it for themselves.
What also requires a leap of faith is that Microsoft expects that its platforms will be successful because they offer compelling solutions, not because users are trapped due to proprietary lock ins. Sounds great, but it is not clear how non-Microsoft client and server systems can take a deep role in a .NET environment since they don’t natively support Active Directory and can’t run Visual Studio-generated applications or Microsoft infrastructure software. If the answer is through SOAP, the next question is will the competition enable SOAP on their platforms? Some industry heavyweights including IBM have lined up behind SOAP, but there are still important names missing from the list. Until it’s clear that there is universal interoperability, .NET will have a shadow of doubt hanging over it. The .NET initiative will be unsuccessful if it remains as proprietary as was COM and COM+.
Finally, how should an IT manager prepare for .NET? That’s easy to answer: As with other Microsoft technologies, as you upgrade the preparations are made for you, whether you need them or not. Of course, should you decide to exploit .NET, it may accelerate your upgrade and purchase process. But it’s still too early to start worrying about that problem. First, let’s see it work in the real world. --Al Gillen is research manager for system software at IDC (www.idc.com) and former editor in chief of ENT. Contact him at agillen@idc.com.