Web Services – .Net, Web Services, and the End of the Vendor Era

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 magazine 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; almost 60 percent 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 any 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: Realizing 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 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 Center, 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 modeling 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: Operationalize 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 operationalized 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 is 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 realize the savings that were deferred by the initial investment, says Goldsmith. But today those savings are beginning to be realized.

“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 operationalization, 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 of Microsoft’s control: CIOs’ need to rein in out-of-control, heterogeneous environments in a low-cost way, the development of XML outside of 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.”