Four years ago, CIOs worried that .Net, which Microsoft was proclaiming a revolutionary new software architecture, was just another name for lock-in. "I'm not confident that Microsoft .Net will be compliant with open standards," Brett Kottman, then the e-commerce director for Excellence in Motivation, told CIO in 2001. He wasn't alone. In a CIO Research Report from that year, seven out of 10 CIOs said they wouldn't adopt .Net. Just one in four said Microsoft's motivation for launching .Net was technical; nearly 60% said the motivation was marketing.
Fast-forward to earlier this year when FedEx executive VP and CIO Rob Carter built a web service that allows his people to print to a nearby FedEx Kinko's from inside Windows Office applications. He used .Net to build it. But here's the surprising part: On the back end, the platform it connects to is not Windows and, says Carter, "It's really of no consequence that it's not."
But Windows has never connected easily to anything but Windows. Nor, for that matter, has vendor's software easily linked with anyone else's. Indeed, CIOs used to be defined by which technology architecture they bet on, and the software business used to be defined by which vendors got CIOs to bet on their stuff. As Rick Berk, the CIO of private bank Brown Brothers Harriman, puts it, "Vendors have always created things to pin us down."
So how can Carter be so casual about mixing architectures when that's always been excruciatingly complex and expensive and therefore ill-advised? What happened to lock-in?
Web services standards happened. If your native tongue is .Net or J2EE, C# or Java, WebLogic or WebSphere, Windows or Linux, or anything else, all countries are starting to communicate using the lingua franca of XML and associated specs like UDDI, WSDL and SOAP. And so far, software vendors have adhered to those standards in their products, including Microsoft with .Net.
After decades of holding customers captive inside the walls of proprietary software, Microsoft and its competitors are selling products such as .Net that help tear down those walls. Why?
The answer is, the market made them do it.
CIOs made them do it
"They didn't really have a choice," says Brandie Fennell, CIO of the Mortgage Bankers' Association of America. "We were going in this direction anyway," asserts Marc West, CIO of H&R Block.
That direction is a product of the profound change in IT brought on by web services. The CIO's entire solar system is tilting on its axis, away from technology and toward services. The religion of technology is giving way to the agnosticism of development. And the foundation of the IT industry is shifting from vendors to integrators and services companies. At the same time, the CIO's role is changing. Once judged by the efficiency of the technology architecture that he bet on, the CIO is now judged by the value of the services he provides to the company, to partners and to customers.
Nolan Jones, CIO of the Colorado State Department of Revenue, is using .Net, Avanade and other technologies to build the new Colorado State Titling and Registration System (CSTARS) for registering motor vehicles, but "the .Net aspect of this is just in the background," he says. "All of this is focused on business process, not tools. What's been nice is we haven't heard, 'Well, that's a system limitation, we don't do that'. It's more like, 'What's your process, how can we unify that process across counties?'"
"The real question is, Do individual vendors matter?" asks Hossein Moiin, VP of technical strategy at T-Mobile International. "And the answer more and more is, No, they do not."
For the software vendors, it's a cruel irony. In a world running on web services standards, technology platforms are fungible commodities. Once dreaded by CIOs as Microsoft's next big lock-in strategy, .Net is now applauded by CIOs as a nice development framework that fosters the technology neutrality they're learning to expect.
The shift from technology expert to process maven will not be easy for many CIOs. If they don't provide value now, it won't be the vendors' fault. It will be theirs.
The "bet the company thing"
Microsoft introduced the term ".Net" in June 2000, in a six-page white paper called Microsoft .Net: Realising the Next Generation Internet. A judge had just ordered the company split in two and, predictably, its stock price was suffering. In its white paper, Microsoft used the word "revolution" (in all its variations) nine times and the phrase "next generation" or "new generation" six times. Bill Gates said that it was a "bet the company thing".
.Net, it seemed, was supposed to brand Microsoft's software business under one umbrella term. But .Net was also supposed to be a product -- or products -- although what kind wasn't clear. The white paper spoke of "constellations of computers" and embedding products in an "electronic fabric", and promised "zero management" for end users and a "new era of dynamic trading relationships". The paper cited XML and web services heavily as some of what would make .Net go, but it wasn't clear how, or to what end.
Joel Spolsky, a software developer and now a frequent blogger on software development issues, summed up the attitude toward the .Net fanfare at the time: "I'm not saying there's nothing new in .Net," Spolsky wrote in 2000. "I'm saying there's nothing there at all."
For the next two years .Net came to describe nearly anything forged in the Redmond smithy. Microsoft's major products gained a .Net appendage: Windows Server.net, Office.net, Visual Studio.net, MSN.net, .Net Passport, .Net My Services. Vista, the company's next operating system (it was called Longhorn at the time), was advertised as something that would be built on top of several pillars of .Net -- even if it wasn't due out for years.
.Net was ubiquitous. And mystifying.
Mortgage Bankers' Fennell says that when .Net first hit, "It was a buzzword thing. People just didn't understand what it meant or what resources were available for it."
By late 2002, Microsoft was retreating. CEO Steve Ballmer conceded that "We probably made .Net a little harder to understand than we should have." Gates admitted to a "misstep" with the .Net launch, telling Wall Street that certain elements of the strategy were "premature".
Microsoft tacked the other way and lopped off the .Net appendage from many products, notably Windows. (A few kept the suffix, including the development tools Visual Studio and Visual Basic.) Eventually many of the .Net-based features promised in the Vista OS were eliminated. (Vista isn't due to ship until next year.)
In 2002, Gates offered a simpler definition of .Net: "Software to connect information, people, systems and services."
But that didn't really help; lots of software is supposed to do that.
.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. Processes 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 gotten 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 standardising 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 organisation Cornell Theory Centre, David Lifka, 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."
Some things never change
As CIOs start to put .Net and WebSphere (its archcompetitor from IBM) to work for web services, the old question of which technology architecture do you subscribe to may be gone, but there's a new question: Which tools are appropriate where?
Despite the fact that IBM and Microsoft have played nice on standards, they're still sniping when it comes to marketing their particular tools to CIOs. But what's interesting about this competition for CIOs' attention is that, for the most part, CIOs aren't paying much attention. CIOs aren't betting on either .Net or WebSphere. They're betting on web services. .Net and WebSphere happen to be means to that end. As Lifka says, "What you really care about is that .Net supports web services and managed code. That's what makes it attractive."
Many CIOs use both .Net and WebSphere and will continue to. There is no consensus on which tool is better. Many are choosing to operate with Microsoft on the client side and IBM technology in the back office; old habits are hard to break. But standards have made allegiance to any one vendor out of date, says Bob Laird, chief IT architect at MCI. "Look, if one person's cement deteriorates, or can't hold up, we can always put the other person's cement in."
The importance of standards
With web services, CIOs have a common language for easier integration, the capability to expose their companies and others to a whole new range of services, and less risk in choosing technology at the outset of projects. Vendors have to compete on merit, not by virtue of lock-in. It sounds like the dawn of a golden age for CIOs.
But there are risks. If vendors don't adhere to standards, CIOs could end up where they started, having to do tricky and expensive integrations of proprietary technologies -- and dealing with angry businesspeople wondering what happened. "Keeping to standards overshadows everything else," says Northrop Grumman vice-president and CIO Tom Shelman. "Like many CIOs, I've placed some pretty big bets [on web services]; we've sold this architecture and the promise of easier integration and lower costs to other executives. So the applications vendors have to play fair and keep it open. When they start getting outside the standards, they start putting CIOs like me at risk." As commodity development allows web services to take off, standards must be honed and further developed, and companies building web services need to discipline themselves to adhere to the standards while pressuring vendors to do the same.
To date, the MAD (mutually assured destruction) theory has held standards together. As West at H&R Block says, "We're not going to use anything that's hard to run in other environments". In other words, if a vendor doesn't hew to standards, West will walk away.
Meet the new CIO
No longer technology czars, CIOs need to be business experts who understand services. When decisions are dictated by the technology architecture, it's limiting but it's also a crutch. The limitations of the technology could explain a lot away. In a web services world, the CIO carries the weight.
A new job in a new landscape means different challenges, not fewer. Shadman Zafar, Verizon's VP of architecture and e-services, argues that the CIO's new central mission is simple: Operationalise web services.
By that, he means create an SLA-like model for the web services that programmers develop. It has to be clear to anyone who might want to develop or use a web service how it can scale, what its level of security is and so forth. And if others want to use that service, the group that developed it needs to be compensated for its work. If anything, Zafar says, a vendor such as Microsoft with .Net should focus on helping CIOs manage the tools and services rather than focus on the tools themselves.
Zafar has operationalised his development with "IT Workbench", a formal and standard procedure for application development. "As soon as you start a project, you go and search for parts, for code already developed [which is stored in a taxonomic, searchable repository] that can help, and you'll know what that code is capable of. You get what you can use and develop the rest" -- in .Net, WebSphere, whatever is most appropriate -- "and then all of it is thrown back on the shelf for others to use."
This takes time and money to get up and running. Web services are no free ride. Ian Goldsmith of SOA Software, which works with Verizon, compares the current environment to the challenges faced by auto manufacturers in the 1990s when they began revamping their assembly lines to build several models of cars on a single platform, using shared components. At the time, the changeover required a huge investment in time, money and training in order to realise the savings that were deferred by the initial investment, says Goldsmith. But today those savings are beginning to be realised.
"The complexity of the governance problem that you have to deal with in a services-oriented environment is big," says Keith Glennan, Northrop Grumman's CTO. "The CIO has to sink time and money into planning and operation," says Zafar. Otherwise, he says, web services is just a bunch of "toys" and "tricks" -- little pieces of code that do neat things but that can't help the business in any meaningful way. Without operationalisation, Zafar says, "Web services is just a little bit of magic -- and magic runs out."
A different revolution
Microsoft announced a revolution in 2000 and said .Net was it -- the biggest change to computing since the internet. But as it turned out, .Net was the result of a revolution, not the cause of it. What brought .Net to its current status -- a solid set of development tools among several solid sets of development tools -- were forces outside Microsoft's control: CIOs' need to rein in out-of-control, heterogeneous environments in a low-cost way, the development of XML outside any vendor's purview, the development of web services standards as a reaction to the development of XML. The internet.
"To me, the revolution occurred 10 years ago, when transactions moved to the internet," FedEx's Carter says. "If you look back, just 10 years ago, everything we did to connect mainframes, and Unix and Windows and VAXes, was proprietary network linkage. How we reached out to customers was with dedicated lines, dial-in services, SNA and DecNet and TTY dial-up, terminal emulation. In a mere decade, we've gone from all these expensive and private custom interfaces to an assumption that everyone can touch the interface layer. And now we've got this services orientation that lets us touch that interface layer in a much easier way still. It's making computing very horizontal. It's profound."
Carter gives credit to Microsoft for making .Net real. ".Net launched with a flourish and a lot of fanfare before there was a 'there' there," he says. "Now it's evolved to the point where it's useful, and it's time to put it to work.
"It's time to put points on the board."
Microsoft goes all in
Redmond is betting CIOs will have to connect their web services offerings to Office and Windows -- a bet Google is willing to call
By now, .Net was supposed to be the centrepiece of Redmond's empire. Yet when Microsoft met Wall Street analysts a few months ago, the company didn't focus on .Net. Instead, CEO Steve Ballmer concentrated on "anchor businesses" such as Windows and Office.
But the latest version of Windows was four years ago; the next isn't due for a year.
Microsoft is facing so much scepticism on Wall Street that in late September the company announced a huge reorganisation. The reorganisation is "part of driving software-based services in competition with anybody else who thinks they're going to use that strategy to get ahead in the marketplace", Ballmer said in a Wall Street Journal interview. "We're not the only guy who's going to try to deliver software that has a service-based component. We need to get there aggressively and quickly."
But Microsoft still has faith that your average businessperson weaned on Excel, Outlook and Word will continue to prefer those applications to anything web-based. Windows and Office, Microsoft argues, can simply do more than a browser -- better graphics, more complex applications, more immediacy than the click-and-wait world of the web. CIOs will want to develop web services for Windows and Office because of these "rich" features. And Microsoft is doing everything it can to encourage web services development on top of Windows and Office, including creating a development toolset specifically for Office. One product of that would be Mendocino, an effort to use Office as a front end for SAP's ERP software.
Microsoft is betting that if you try to take Windows and Office away from users, no matter how much sense it makes financially or from a development point of view, they'll revolt. The appeal of Mendocino is that it's something everyone is comfortable with – Office -- fronting something everyone is uncomfortable with, ERP. As FedEx executive VP and CIO Rob Carter says of his decision to integrate his .Net web service with Office, "The vast majority of the world finds the Microsoft desktop productive and standard. For people who want it, we could provide a browser interface. It just won't be the same."
But what if it became the same? Users are comfortable with browsers too. And technologies, such as Ajax, are being developed right now that make browsers quite rich, with the kind of immediate gratification and deep visual and complex transaction capabilities of a desktop application. Front and centre with these kinds of web applications is Google, Microsoft's new nemesis. (Many observers say it's this threat -- Google, its applications and the fact that it keeps taking Microsoft developers away -- that spurred the massive reorganisation in Redmond.) Google Earth and Google Suggest, among others, are just hints at what web-biased developers want to do with the web: Take it out of its click-and-wait heritage and take on Microsoft.
Definition of .Net please
Even today when most everyone considers .Net a development framework, Microsoft is trying to market it as more than that. A sample of definitions of .Net from Microsoft:
X ".Net is the Microsoft web services strategy to connect information, people, systems, and devices through software." -- Microsoft.com (www.microsoft.com/net/Basics.mspx)
X "When I say .Net, I am talking specifically about a chunk of technology that ships in Windows and Visual Studio. That's the framework. But in other places for non-developer audiences, the term .Net has an appeal because it speaks to the connected nature of applications." -- John Montgomery, director of the .Net Developer Product Marketing Group
X "I like to think about .Net as more than just one thing, depending on who you are. One, it's about web services. It's about XML and it's about managed code in the .Net. framework. But it's true of all decent brands -- .Net, Java, WebSphere, the PC, what is it? They have flexible definitions depending on who you are." -- Sanjay Parthasarathy, corporate vice-president, Developer & Platform Evangelism Group
X "I define .Net in two ways. One, when .Net is used in the abstract, and two, when .Net refers to an actual physical software component (the .Net Framework). When we use .Net in the abstract, which folks are doing less and less of these days to help clear up any ambiguity, .Net communicates the notion of "connectedness". I know that is an awful word, but it does convey the notion we're trying to get across with regard to the ease of integration that .Net and the support of XML Web services are intended to drive. When discussing the physical manifestation of .Net, which is the .Net Framework (or, the .Net Compact Framework, for mobile devices), we're simply talking about a software component that is embedded in many of our key products, and that solution vendor partners can embed within their solutions, that will allow those products and solutions to share and consume XML data with other products and solutions." -- Tony Jacobs, global industry marketing manager - Financial Services
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.