Columns

Two cheers for standards

Multivendor standards are a great thing, and our world would be a much poorer place without them. Yet I frequently run across an excessively simple-minded view of how useful this kind of standard can be. In particular, I find people who believe universally accepted multivendor standards are equally desirable in all areas. With a little thought, it's easy to see why this isn't true.

A simple way to think about standards is to view them in two dimensions: horizontal and vertical. Horizontal standards provide interoperability, allowing different kinds of systems to communicate. TCP/IP and HTTP are good examples of horizontal standards. Vertical standards, by contrast, provide portability, allowing code written for one system to be easily moved to another. Unix and J2EE are examples of this kind of vertical standard.

Horizontal standards are essential. Without them, we can't build effective networks. Furthermore, the agreement among vendors must be total or the standard is without value. My TCP must behave exactly like your TCP or we can't communicate. After years of struggle, every vendor has accepted the need for at least a core set of standard protocols, which has made the task of creating interoperable multivendor environments much easier.

Vertical standards are less essential. Perhaps as a result, they're also harder to create. With horizontal standards, you know when you're done because real interoperability is binary -- you're either perfect or you're broken. Portability, the goal of vertical standards, is much more forgiving. Think of Unix and J2EE: Neither provides perfect portability across systems, but both make moving code easier. This can be a good thing, but it's not essential in the same way as horizontal standards. After all, without horizontal standards, the Internet wouldn't exist. Yet in a world with no vertical standards whatsoever, the Internet would still work just fine.

In fact, universally accepted vertical standards often aren't even desirable. Think of J2EE, which defines common programming APIs and more. Java promoters frequently trumpet the great value of this vertical standard, suggesting that the world would be a better place if all vendors, including Microsoft, adopted it. But suppose Microsoft did choose to junk Windows and .NET, and decided to wholeheartedly adopt J2EE (a fanciful idea, certainly, but bear with me). Or imagine the reverse, with the entire industry adopting .NET. Would either of these outcomes make you happy? I hope not.

Believing that any one camp has all the smart people and all the good ideas is folly. The pressure of competition is what makes progress happen. Consider the cross-pollination that's happened between Java and .NET -- each has borrowed from the other, and each has improved on the other's innovations. (For a slightly more detailed look at this, go to www.davidchappell.com/HTML_email/Opinari_No1_4_02.html .)

Universally supported standards are great things for protocols, and having all vendors adopt the same few choices is wonderful. True, the lack of competition probably does slow protocol innovation, but the benefits of interoperability far outweigh the negatives. Universal standards are much less necessary in application development environments, however, because diversity is both more tolerable and more beneficial. Vertical standards like J2EE are clearly useful, since being able to easily move code across different vendor products has value. But to argue that the world would be a better place if everyone adopted these standards is to misunderstand both where standards are critical and the way in which technological progress happens.

Universal multivendor standards are great, and sometimes they are essential. Yet we should restrain our enthusiasm -- let's give two cheers, not three -- because they are not the solution to every problem.

About the Author

David Chappell is principal at Chappell & Associates, an education and consulting firm focused on enterprise software technologies. He can be reached via E-mail at [email protected].