By Tim Landgrave

This article originally appeared on our sister site, TechRepublic.

Over the last two weeks, I’ve spent several hours talking with senior development managers and architects about their upcoming training and consulting needs. As I’ve summarized these conversations, I’ve uncovered some interesting trends that all CIOs should be aware of regarding employees’ attitudes and opinions about how their organizations approach the adoption of new development technologies. In this article, we’ll look at some of the prevailing opinions about how new development technologies are selected and deployed and what that means for adoption of .NET and Java in the enterprise.

A simple case of economics
The senior leaders in their respective companies all recognize that pure economics are driving most enterprise decisions now more than ever before. They’ve seen budgets slashed and projects delayed or cancelled. Most recognize that their ability to stay employed depends on whether they can deliver cost savings in the near term. But they’re all very concerned about what the company will look like coming out of the tough economic times. For example, most report that training budgets for new technologies have been eliminated. And most projects that were designed to improve or replace aging infrastructure have been pushed off until later in the year or early 2004. Many don’t believe that their companies will be in a position to handle the demands placed upon them by the time they start emerging from the recession because they’ll have poorly trained people working on a poorly maintained infrastructure. The likely end result is that the recession will be extended not because of the lack of demand, but the inability for companies to satisfy it. Economic issues are also at the center of these companies’ evaluations of competing development platforms.

The Java argument
As companies downsize their development teams, they begin to focus on delivering necessary services with existing infrastructure wherever possible. When the existing infrastructure can’t support their needs, they have to turn to packaged solutions first because they don’t have the resources to extend the existing solution or to develop a new one internally. This is one area where the Java community has a significant advantage over .NET. As companies look for enterprise-class solutions that can be implemented quickly, they are finding a handful of Java-based solutions and very few .NET-based solutions.

For example, one company to which I spoke was in dire need of a new stand-alone human resources management system to integrate with their home-grown accounting system. The architect in charge of the selection process found several enterprise class systems based on J2EE, but only two Microsoft-technology offerings, and both of them were COM-based, not based on .NET. Because of their heavy investment in Microsoft infrastructure, they chose one of the COM-based systems to purchase. But when it was time to sign the contract, they asked the software vendor when they could expect a .NET version of the system. The vendor replied that this was its last version of a package based on Microsoft technology—the vendor was converting it to Java!

When pressed for the reasons for converting to Java, the vendor gave two answers. First, the vendor felt the conversion would ultimately provide the ability to run on more platforms with less work. The vendor admitted that the first version was very WebSphere centric, and that it wasn’t really thinking about targeting multiple platforms now because its focus was on converting quickly. The second reason for the conversion was because the vendor felt it could charge more money—almost two and a half times as much—for a product based on J2EE rather than one based on Microsoft technology. The vendor also recognized that companies would hire it to install and deploy the J2EE version of the system, but almost always insisted on installing the Microsoft system themselves. In their opinion, there was no black magic associated with the Microsoft technology, but there was with the J2EE implementation.

Most of the development managers agreed. They found that when their companies deployed a large, enterprise system based on J2EE, the implementation was almost always done by the vendor or by a consulting firm selected by the vendor rather than employees of the company. They also cited this phenomenon as the reason their companies wouldn’t pay for training on the J2EE platform; i.e., they were in a catch-22 with regard to trained J2EE resources. If they paid to train employees, the employees would leave to work for consulting firms where they made more money. If they didn’t have trained employees, they would have to pay consulting firms to install and maintain their J2EE-based systems.

The .NET paradox
This training catch-22 is not unique to companies with significant investments in J2EE-based systems. Every company that I spoke with over the last two weeks had delayed or eliminated their .NET training initiatives. They emphasized that this wasn’t because they didn’t believe they would be developing .NET systems. On the contrary, because of their existing investments in Microsoft technology, they all had plans to build and implement a common set of tools, practices, and standards from which they would first run pilots and then move into larger-scale deployments of .NET-based systems. But these plans were continually being delayed for economic reasons, and most now see the summer of 2003 as their planning period and the fall of 2003 as their pilot period. That makes 2004 the year they begin rolling out .NET systems en masse.

Given this timing, the companies are reluctant to begin training their developers on the .NET platform. Most believe that if they give their developers the training, they’ll want to use it immediately. Since they’re not providing the opportunity, the developers are likely to leave and go to a company that lets them use their newfound skills right away. This is the real irony: These senior developers realize that once a developer learns about the .NET platform and recognizes the huge gains in productivity for developing both Windows and Web applications, they won’t want to go back to using their old tools. But since their management has cut off funding for all new projects, they are forcing their development teams to use older, less productive tools to maintain the systems they already have in place.

Breaking the impasse
So how should senior leaders in these companies—or others in their position—respond? First, CIOs should recognize that training technical employees is a critical element of retention. Technical employees who don’t feel like they’re increasing their knowledge will find ways to gain the knowledge themselves and then look for a job that allows them to leverage it. If you’re concerned about losing your training investment, have employees who take training classes sign a contract that requires them to pay back the cost of training if they leave within a year or 18 months. Then, even if the employees leave, you can use the money to train someone else.

Second, the companies that will make money in 2004 and 2005 will be the ones that come out of the recession with an infrastructure that’s built and staffed to handle new opportunities. If you keep whittling away your systems or handing them over to outside consulting firms to manage, you won’t be able to respond quickly to the increase in the demand for your services. Make sure your key developers and managers know that you’ll fight for funding for any new projects as long as they’ll take the initiative to demonstrate how the new technology can save money or at least break even in the short term and make money over the long haul.