.Net Gets Real

What .Net eventually came to mean (and to be) was a set of development tools and an environment or framework in which to use those tools. While .Net's marketing floundered, Microsoft's technical team was busy building those tools and the framework that would, in fact, foster a revolution in how Microsoft developers built applications. Microsoft just marketed the revolution before it had the tools.

And the new tools were turning out to be superior to Microsoft's older Win32 development platform and associated tools. Arcane technical advances aside, what Microsoft did with .Net was to allow programmers to use many languages - C++, VB, VB.net, C# and so forth - and run them in one environment, making it easier to recruit affordable talent to develop in the Windows environment. In addition, the tools were accessible in a way that made them easy to learn, accelerating training and development. CIOs give .Net high marks on other fronts too. "It really facilitates rapid development, particularly on the front-end GUI area," says A J Sutera, director of application services at JetBlue, which has used .Net since the airline launched in February 2000. Two reasons for this: .Net development uses automated memory management, which means developers don't have to spend time worrying about how applications grab and give back memory to the computers running the programs. And .Net allows for managed, reusable code. Proc esses don't have to be written every time, but rather can be grabbed from a repository and plugged into the application being built.

By 2004, standards for Web services, such as XML, SOAP, UDDI and WSDL, had been hashed out well enough (with the unlikely cooperation of Microsoft and IBM keeping the standards moving forward), and Microsoft and its competitors adopted them in their development frameworks. That helped CIOs start to take Web services more seriously. "Right now, we're seeing the advances in the technology, much more than a couple of years ago," says MCI executive vice president and CIO Elizabeth Hackenson. "We've got through the bad times and now we can put this stuff into our strategic plans."

The robustness of the .Net development framework allowed CIOs to ignore its marketing. "It's a development environment," says Berk of Brown Brothers Harriman. "You either develop with it or you don't. It's that simple."

Free at Last

For Microsoft, binding .Net to Web services represents a profound shift in the company's strategy. Microsoft has pried open a space between its development tools and its technology architecture. What has been created is not the technology independence that Java makes possible (you're still developing Windows applications), but Windows applications can now easily talk to other applications through the Web services layer. Rick Roy, CTO of CUNA Mutual Group, calls it a "loosely coupled application environment".

Microsoft admits that this is a big change. "Customers have existing large investments in terms of staff, hardware and software for back-end systems," says Microsoft's John Montgomery, director of the .Net Developer Product Marketing Group. "It could be an OS/390, AS/400, WebSphere, SAIP, Siebel, whatever. And the larger the company, the more likely that software is running on Big Iron. Historically, a Microsoft salesperson would have said: 'Rip all that out and put in the Microsoft technology stack.' With .Net, our intention was to overcome the either/or and get to a point where customers can choose what they want where it's appropriate, instead of having a religious conversation about the technology stack."

So, as profound as this change is for Microsoft, .Net and its link to Web services represent a more profound change for CIOs, who finally can choose the development tools that are best for the service an application will provide, rather than having to use the tools that are determined by a preselected technology architecture. Plus, the fungibility of Web services means technology risks are diminished. If one development environment doesn't work out, it can be changed, and that failure won't ripple through the entire technology architecture. CIOs can not only tolerate heterogeneity, they can embrace it, inside their companies and out, with partners and customers.

"The age-old IT question was: 'What do we do about standardizing on a platform?'" says JetBlue's Sutera. "That question's not so important with Web services. It gives you a freedom you didn't have before that is exceedingly attractive. Just use the right tool for the right job."

It is a great unburdening. The weight of technology decisions - the very decisions that used to be at the core of the CIO job - have been lifted from CIOs' shoulders. Instead of thinking about the technology, they can focus on the business - what services to expose to whom, what business processes to improve. And because they don't have to match up different technologies, they don't have to spend all that time on integration.

"We can look at process instead of code," says H&R Block's West, who credits Web services and .Net for getting his client acquisition system up and running much faster than it could have been in the old days. "We have the opportunity to do more-valuable work. We used to spend a lot of time on .Net versus Java. That's so much less relevant now."

"I couldn't care less what developers use," says Scott Osgood, CTO of Noel-Levitz, a subsidiary of Sallie Mae. "I've been freed up to worry about what we're trying to accomplish rather than technical interfaces."

At supercomputing research organization Cornell Theory Centre, David Lifka, who is director of computing and information sciences, recalls a great example of how Web services provides leading-edge interoperability. "We had this collaboration with several universities; they're all rocket scientists doing materials modelling at the atomic level. But they all have their own platforms. It's a three-year grant, so we said: 'We can spend three years porting all the data to one platform, after we argue forever about which one will be best, or we use the Web services glue.' Obviously, we did the latter and it took less time and worked out great."

"It's just so completely logical that this is how we should develop," says Mortgage Bankers' Fennell. "It's surprising we haven't always done it this way. Then again, we didn't have the tools from the vendors."