/

How Microsoft controls the future of networking

By Barb Cole and Kevin Fogarty
Network World, 9/12/94

Redmond, Wash. - If standards are the key to interoperability, Microsoft Corp. may have more control over your distributed computing environment than any other organization.

By dint of its hold over millions of desktops, Microsoft has established itself as an arbiter of key network and applications standards. In this client/server world, the company now wields more power than such traditional standards-setting bodies as the International Standards Organization (ISO), according to many observers.

Users, vendors and others agree that Microsoft's power to create de facto standards loom large over the industry. But they are ambivalent about that power.

Some believe Microsoft has too much control over customers' desktop networks and they complain that Microsoft's standards are too Windows-centric. Others don't care about the company's influence; they're happy to have solutions to interoperability problems that standards organizations often take agonizing years to resolve.

Among the company's de facto standards supported in Microsoft's own products and thousands of offerings from independent software vendors (ISV) are the Open Database Connectivity (ODBC) protocol for heterogeneous database access, the Messaging Application Programming Interface (MAPI), and Object Linking and Embedding (OLE), a mechanism for linking applications.

Microsoft isn't stopping there. The company is working with Intel Corp. to develop specifications for computer-telephony integration and with Texas Instruments, Inc. to build an object repository that will let users share objects among front-end development tools.

In many ways, Microsoft is like the IBM of old, spelling out the rules by which users and vendors will play the networking game. To its disadvantage, IBM couldn't carry that power into the client/server world.

But as IBM's influence fades, Microsoft is showing greater strength in establishing its specifications. It has sprinted ahead of plodding standards groups, as well as trade consortia, and used its market share to push its specifications so far into the market that even its biggest rivals have to play along.

This three-part Reader Advocacy Force article will examine Microsoft's growing influence as a standards setter, the impact on users and what Microsoft's power means for other vendors. The series is based on wide-ranging interviews and a survey of 200 Network World readers.

Across the industry, there is little debate on Microsoft's standards-setting power. "Microsoft does have the power to specify standards on the desktop because Microsoft owns the desktop," said Ronni Marshak, analyst at Patricia Seybold Group, Inc. in Cambridge, Mass.

That's only natural, agreed Thomas Nolle, president of Voorhees, N.J.-based consulting company CIMI Corp. "Anything that Microsoft elects to support in Windows becomes automatically accessible on about 20 million desktops," he said. "Any [application program interface] that has an installed base of 20 million attracts third-party developers to support it."

Although standards such as OLE and ODBC give it huge market power, Microsoft uses its APIs mainly to enhance its operating systems, said John Rymer, an analyst at Patricia Seybold Group.

"OLE, ODBC, all the other APIs that Microsoft comes up with are there strictly to make the Windows environment more stable, more usable to developers," Rymer said. "It's a matter of building on the incredible domination they have."

Most analysts also agree that Microsoft has gained a major competitive advantage because its APIs are tailored to Microsoft products. Microsoft gains by being an early adopter of its own specifications.

"As developers of OLE, Microsoft has the best level of application integration. Lotus [Development Corp.], on the other hand, dragged its feet on Windows, and paid the price by being two generations behind Excel," said Bobby Cameron, senior analyst at Forrester Research, Inc. in Cambridge, Mass.

Microsoft has taken different approaches to es-tablishing control over key interoperability standards.

In some cases, the company started out as a member of a standards group and then took charge. Case in point: ODBC. ODBC's roots are in work begun by the SQl Access Group (SAG), a consortium of vendors of which Microsoft is a member. The group set out to develop a call level interface (CLI) for accessing SQL databases, but Microsoft, convinced the process was taking too long, decided to establish its own database access protocol. "We decided to work independent of the group because things were moving slowly," said Dennis Comfort, group program manager for data access and retrieval technologies at Microsoft. "We felt it was better to get something in the works and shipping. Since the release of ODBC, we've been working to converge ODBC with the CLI.

"Microsoft took on the task of driving the standard, but it wasn't done in a vacuum. I view Microsoft as a catalyst to making sure it happened," Comfort said.

Richard Holcomb, vice president of corporate development at Intersolv, Inc., which markets more than 30 ODBC drivers, said Microsoft did the user community a service by taking charge of ODBC. "If Microsoft hadn't done it, we'd still be waiting for a standard," he said.

Since the release of ODBC, however, SAG CLI has virtually disappeared, according to Rymer. While acceptance of SAG CLI was proceeding slowly, Microsoft and its partners were able to swamp the market with ODBC-compliant applications.

The dominance of ODBC doesn't limit the choices users and ISVs can make in developing applications, Rymer said. Developers can use database-specific APIs to access data, or can go the shallower, more generic route of using ODBC. "There's a choice about whether you go generic or product-specific, which gives users a range of options in terms of performance and functionality, and that's what they want," Rymer said.

Vendors have found that it can be bad for business to offer a standard that competes with Microsoft's Borland International, Inc.'s integrated database application programming interface (IDAPI), despite its billing as an alternative to ODBC, gained little acceptance. Later, the company conceded victory to Microsoft by announcing it would develop software that lets IDAPI drivers work through ODBC.

OLE, on the other hand, began as a multivendor collaboration between Microsoft and such partners as Aldus Corp., Micrografx, Inc. and Lotus. In late 1989, Microsoft began talking to other vendors about ways to extend Dynamic Data Exchange a Windows feature that lets users copy information between applications.

The company took the lead in object-based interconnectivity at a Microsoft-hosted gathering in December 19 90 at which it described OLE and proposed that it become the mechanism for application integration. Two years later, OLE 1.0 was made available in Windows 3.1.

The Microsoft view

Microsoft said it tries to keep the development of ODBC, OLE and MAPI as open as possible by holding developer conferences, providing specs early on to other software developers, soliciting feedback from developers on CompuServe and heavily beta-testing new versions.

But even Microsoft acknowledges the process of rolling out standards isn't democratic: Microsoft has the final say on what goes in. "We are clearly in the control seat when we're developing these APIs, but we want input from ISVs" said Doug Henrich, director of Microsoft's Developer Relations Group.

Henrich said Microsoft gets ISVs including direct competitors involved early in the process of developing new APIs and has made major changes based on their input. Criticism from Lotus, for example, pushed Microsoft to change the Common Mail Call protocol in the first version of MAPI so Lotus could build links between Microsoft Mail and cc:Mail, he said.

"They're open to vendors who can help them. If you're some small software company, they won't pay attention to you, but what large corporation would?" said Intersolv's Holcomb. "Still, I've never seen any evil empire actions from Microsoft."

"Standards should be set in the marketplace and accredited as they're proven. That's been our approach," said Dave Seres, group product manager for OLE at Microsoft. "We know that standards don't succeed unless they have widespread support from vendors."

But while vendors may have some say, users are concerned that Microsoft isn't working closely enough with other organizations that are developing the standards used in their multivendor networks. Some 42% of the readers surveyed by Network World said Microsoft has too much control in setting network specifications, and only 29% believe Microsoft works closely enough with standards organizations.

"Sure, Microsoft is big, but you can't ignore the other standards that are out there," said Kurt Haldeman, senior systems analyst for US WEST, Inc. in Englewood, Colo. "[Microsoft] is not following any other standards groups. You've got international groups out there that US WEST has to comply with, and if you're not mapping to their standards, forget it."

Perhaps a bigger concern is that Microsoft's standards are limited to the Windows environment a concern voiced by nearly two-thirds of survey respondents. Users worry about having to implement one set of standards for Windows and another set for the rest of the enterprise.

"One of the biggest problems we have is with TCP/IP; Windows supports it, but it doesn't really like to," Haldeman said. "If you're going to do anything client/server, you want to go to any Unix box or Macintosh and work with them. The only way to get out there is to use something like TCP/IP. And Windows makes it harder for you to do that."

Microsoft is still too Windows-centric in its products, raising a wall between Windows and all other operating systems, said Bob Halloran, network engineer, of AT&T Universal Card Services in Jacksonville, Fla. That just makes life more difficult for information systems departments that have to support multiplatform networks.

Microsoft said there is nothing in the architecture of ODBC or OLE that limits them to Windows, and it plans to port both to other platforms. "The only thing that makes OdBC Windows-centric are Dynamic Link Libraries. There's no reason you can't put that on another platform, and we will soon," Comfort said. An ODBC development kit for Apple Computer, Inc.'s Macintosh is reportedly due soon.

OLE is already available for Macintosh and Microsoft's goal is to develop a common object model that runs on a number of platforms, Seres added.

But another thing that troubles users is that Microsoft's standards, while often first out of the gate, are not always up to snuff. ODBC was initially used almost exclusively for decision-support applications be-cause it proved too slow for on-line transaction processing.

OLE has been criticized by users and analysts as a bandwidth hog when employed across the network.

Microsoft has said future versions of OLE will function better in distributed environments, but current versions automatically download whole applications across the network to launch embedded objects.

While Microsoft's power to set standards may seem threatening and anticompetitive, some contend that it also pushes the whole computer market to develop more quickly than it would otherwise.

"The benefits of this seeming tyranny outweigh the drawbacks," Nolle said. "When somebody establishes a proprietary API, they're not bound by the petty politics and proceduralism of the standards process. They can make something happen; there are no delays while a consensus is hammered out. You've got a dictatorship, but it's efficient."

An efficient tyranny led to the development of IBM's Systems Network Architecture in 1974. Compare what it has provided users over the last 20 years with the ISO's vaunted Open Systems Interconnection technology, which was launched in 1976 but was slow to develop and gained little ground in the market.

A vendor with a large financial stake in a technology will work hard to develop it and get it into wide use, both by users and by ISVs, Nolle said. By comparison, vendor consortia and standards bodies can be hamstrung by politics and produce least common denominator specs that aren't as robust.

Some users applaud Microsoft's muscle in the standards-setting process, agreeing that is better to have a Microsoft standard today than wait three to five years for something sanctioned by a standards body.

"If there's a de facto standard that works, I couldn't care less whether it comes from Microsoft," said Frank Greene, a systems integrator in Knoxville, Tenn., who uses an Oracle Corp. ODBC driver to connect Microsoft Access to Oracle databases.

Frank Caratozzolo, senior information specialist at Johnson & Johnson in Raritan, N.J., also prefers a working proprietary API now to one developed by a trade group in the future.

US WEST's Haldeman concedes that it may be alright for Microsoft to break new ground with its standards. But once an independent standard is established, Microsoft should work harder to make its APIs compatible.

Today, Microsoft is a member of most of the industry's standards-setting bodies but does little to push the development of multivendor standards unless they are based on, or can coexist with, existing Microsoft technology, said Michael Goulde, an analyst at the Patricia Seybold Group.

Last month, for example, rather than change OLE to be more compatible with the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) specification, Microsoft teamed with Digital Equipment Corp. and Candle Corp. in a proposal to an OMG technical committee for server-based software that would essentially translate OLE object requests into CORBA requests, and vice versa.

Microsoft maintains that its standards-creating activity moves the market forward technologically and does not lock users into Microsoft products.

"OLE is a good example of that," Henrich said. "Everybody agrees there's some value to it. The whole idea behind it is to bring in non-Microsoft applications, just as 1-2-3 can work with Excel.

"It's easy to paint Microsoft as a monolithic company, but unless we continue to build better, more manageable products, our place is not guaranteed in [large user] accounts."