CIOs and corporate strategic planners need to regularly reevaluate strategies for every component of their enterprise architecture. Over the past couple of years, most of that time and effort has gone into investigating and implementing data center strategies. Server consolidation, application server platform choices, capacity and storage planning, Internet security, and other critical issues have been taking the majority of the focus. In large measure, decisions and issues around client platforms have been minimal.

This is partly due to an acceptance of the de facto standard—Windows. But many end users have noticed a pronounced shift away from applications that take advantage of Windows as a client platform and toward Web applications that are easier for IT departments to deploy and manage. And many end users are clamoring for their IT groups to support and provide more integration points for their mobile devices (Palm PCs, Pocket PCs, and mobile phones).

But much has changed in the technology and the vendor focus on client applications. Let’s take a look at the desktop applications and the technologies competing for the IT dollar.

The battle for the desktop
Given that some version of Windows runs on an estimated 90 percent of the world’s desktops, it may seem a little silly to even call this a battle. Hasn’t Microsoft already won the war? Not necessarily.

If you view the value of the desktop as the productivity gained by the applications used rather than the operating system installed, a different picture begins to emerge. Over the last five years, corporate IT departments have been on a steady march toward replacing native Windows applications with applications that use the browser.

One could argue that this has resulted in replacing one Microsoft technology (Windows) with another (Internet Explorer). And certainly the move to Internet Explorer has meant a massive move away from Netscape. But this has become a catch-22 for Microsoft. If organizations move all applications from native Windows applications to standards-based Web applications, they could ultimately choose to use a different browser host (Netscape, Opera, or some other upstart) and eliminate their dependency on Microsoft technology altogether.

Application models in play
That’s not likely to happen for a couple of reasons. First, browser-based applications have significant limitations. They have limited user interfaces, limited access to local hardware devices, and a strict programming interface that limits the usefulness of applications developed for them.

Sun recognized the need for a more advanced client-programming model when it released Java. Java was initially designed to be a client-side replacement for Windows that allowed an advanced windowing environment to run on multiple platforms. But Sun was unable to deliver a true “write once, run anywhere” environment that performed reasonably. And its lack of a versioning strategy meant that two Java licensees could require different versions of Java on the same device and could thereby render one of the applications inoperable. That’s why you don’t see many shrink-wrapped packages that use Java as their operating environment.

But a move back to Windows development could be just as problematic. The reasons that corporations embraced Web development in the first place were for reach and deployment issues. Applications based on HTML could be used on any machine with a browser. Moreover, they could be accessed by pointing the browser to a URL and didn’t require a setup process to run on the machine like their Windows counterparts.

Microsoft has solved these problems with the release of its .NET platform. Now developers can write applications that take advantage of the rich Windows GUI environment and of the thousands of prewritten objects in the .NET Framework, and these can be deployed automatically. Users access a URL just like they would for a Web site and a local copy of the .NET Framework can download, cache, and run the application automatically. Permissions for the local machine can be as restrictive as the browser (the default) or can be customized to allow access to local machine resources based on the permission of the user that’s logged into the system. But to take advantage of this functionality, the client machine must already have the .NET Framework installed.

Corporations that want to move toward rich client applications will have to make a corporate commitment to installing the .NET Framework. To do this, they’ll have to be running Windows 98 SE, Windows NT 4.0 Workstation, Windows 2000, or Windows XP.

Key decision points
Given the economic situation, most companies will be looking for clear economic value—and not just technical capabilities—before making an investment in new client technologies. If they can place a value on the productivity gained and deployment costs minimized by the adoption of .NET/Windows technologies, they’re likely to make the investment necessary to roll out the .NET Framework and train developers to take advantage of it. For many companies, this decision will be driven by existing server infrastructure.

If companies have made a huge investment in J2EE plumbing and JSP presentation technologies, they’ve already made a decision not to take advantage of the Windows platform. But if they’re moving toward an open, Web Services-based back end, using the rich Windows client with it may become an option.

In my next column, I’ll look at the other key client issue that CIOs need to consider: The mobile client is truly a technology “green field” and the fight for this turf will affect every IT planning decision made for the next decade.