No standards movement in the history of the software industry has garnered as much attention or support as Web services. After the previous decade's failed attempts to reach unity, the industry has lauded the promise of more flexible, open, and interoperable software as a revolution and a breath of fresh air.

Corporations are applauding the possibility that the software industry is finally starting to standardize its offerings, thereby helping to eliminate the islands of information that exist within nearly every Global 2000 organization. It's perceived that Web services will go a long way toward eradicating the integration challenge that's the number-one cause of CIO headaches.

Despite many attempts, and some pockets of progress, the software industry remains essentially a craft business, relying on the individual knowledge and skills of highly trained, experienced developers to stitch together disparate operating systems, middleware systems, and development environments. The largest cost of IT projects is labor. The industry needs standards that allow rapid mass assembly of individual components into integrated business operations.

Many industries have gone through this process, for example, standard shipping containers in transportation, standardized parts in automobile and hard goods manufacturing, standardized components in PC manufacturing, and standardized media formats in CD and DVD entertainment systems. In each case, a tremendous shakeout occurred in which new companies gained market share by embracing the new standards and understanding their true business value.

Today we're at a crossroads. The core standards - SOAP, WSDL, and UDDI - have been universally adopted and implemented, but disagreements over next steps and industry fragmentation are emerging over the standardization of technologies at the upper layers of the stack. Recently, the industry has witnessed a controversy around orchestration, or choreography, with Oracle and Sun leading the WSCI (Web Service Choreography Interface) effort and Microsoft and IBM leading the BPEL (Business Process Execution Language) effort. We also have Oracle and Sun publishing WS-Reliability without involvement from IBM and Microsoft, citing intellectual property concerns. It's turning out to be much harder to gain agreement on significant next-level features, such as security, transactions, reliable messaging, management, and orchestration, than it was to gain widespread agreement on the core standards. Some software vendors base their entire businesses on these higher-level features and functions, while others fight strongly to differentiate themselves from the competition by delivering better implementations.

Standards are necessary to break the lock-in of proprietary systems. But they are most significant because they improve the speed of assembly, as they did in automobile and hard goods manufacturing. Or because they increase the efficiency and speed of operations, as standardized containers did for the shipping industry. And above all because they reduce the overall labor costs relative to the production and sale of the finished item, which in the case of software is the operational IT system or integration.

One issue preventing agreement is intellectual property rights. Microsoft and IBM appear to be holding out to maintain intellectual property rights on the specifications they create, while Oracle and Sun have gone on record in favor of unrestricted access to the specifications they create. Depending on how this issue is resolved, the software community will either be able to implement new Web services specifications for free, or be required to pay for the privilege.

It's a valid question: Do a specification's authors have the right to profit from its implementation by others, thereby recouping some of the value of their work? Another valid question arises when a specification defines technology that a company has previously implemented in a product and perhaps protected via patents. Should that company have the right to charge a license fee to permit other companies to implement the specification based upon it?

These questions get to the heart of some of the current disputes slowing progress on specifications such as choreography and reliability. (Choreography is significant because it represents the all-important reusability value of Web services by stitching individual services together into composite applications, by business analysts rather than skilled programmers; reliability is important because businesses need to know whether or not their requests were received.)

Rather than view Web services as an open, new, and large market opportunity in which everyone can compete, established vendors naturally try to maintain their positions of dominance by controlling the extent of standardization.

The level of standardization applies to features within a particular technology area, such as security, transactions, or management. If the standard specification doesn't include a sufficient level of features and functionality, proprietary technologies may still be required to create useful applications or technologies.

The extent of standardization applies to general technology areas viewed as appropriate for standardization. To use the automobile analogy, it's appropriate to standardize parts that need to be fitted together during mass assembly, but it's not appropriate to standardize parts related to the human interface - there is no standard size for a steering wheel, for example. In Web services, some might argue that choreography and reliability aren't appropriate areas for standardization, and thus remain a point of competition instead.

One could speculate further, given a broad historical view of how industries reach a sufficient level of standardization to reduce costs and improve efficiencies, as to whose interests are better served by delaying progress in standardization, or by confining standards to particular levels or areas. Services companies naturally do not want it to be too easy to integrate disparate systems, for example, as they have based their business model on the ongoing demand for high-priced labor. Operating system companies naturally do not want all areas of the operating system to be standardized, as their business model relies on the high margins involved in selling proprietary software products.

The software industry must now choose its path, and the chosen road will impact end users and developers differently. One road leads to a truly standardized world where corporations reap the economic benefits of Web services through the lower prices that open competition usually brings, drastically reducing IT costs. The second road leads to the world of proprietary systems, yielding massive vendor service and maintenance revenues, and killing end-user flexibility and future return on investment.

There are several reasons why the industry is in danger of veering down the wrong road. First, the business environment changes after standardization, and the software industry is having trouble coping with this reality.

Another reason is the impatience of vendors to profit on their Web services investments - the Web services market is not taking off as fast as everyone initially thought it would. It's ironic that some of the same people who promote Web services as the next revolution are impatient as they discover that the technology will become mainstream, which by definition means it will take time to become adopted by conservative IT shops.

The biggest reason for the industry's tendency to choose the wrong path is that the industry is having difficulty drawing the line between what is appropriate for standardization and what should remain as a basis for competition. At the basic level, such as agreeing on something fundamental like TCP, commercial interests don't override the universal needs of the computing industry. Thus the core specifications (SOAP, WSDL, and UDDI) were fairly quickly agreed upon and implemented. We're now beyond that level and are entering an arena where commercial interests are much stronger.

To accomplish software industry standardization, vendors have to shift focus from selling proprietary products with a "standards compliant" label on them to focus instead on cooperating to create a larger market based on truly standard products. In the CD or DVD industry, anyone's disc works with anyone's player because the electronics companies and entertainment content vendors were able to agree upon a common format for the entire product. We are still somewhat far away from the day when a program written on any computer will work on any other as seamlessly as a DVD will play in any hardware system supporting that format. Software vendors, unfortunately, continue to focus on differentiation and long-term relationships based on proprietary features rather than on creating a broad new market.

What's needed is agreement that the potential Web services market is bigger than all current software markets combined. Some vendors prefer to draw the standardization line where it currently sits, with SOAP, WSDL, and UDDI. But customers correctly say that this level of standardization isn't enough to realize the promise of Web services technology.

Many software vendors quite naturally portray Web services as merely another feature of existing products, since they often have millions of dollars of investments at stake in those products. However, Web services more correctly represent an XML layer on top of any and all existing software systems, programming languages, and packaged applications, and that layer has unique requirements that need to be recognized and standardized.

Market leaders often introduce new specifications under the guise of better industry-wide standardization, when in actuality they are more concerned about mapping the specifications to their own product sets. They try to agree on the minimum possible to call something a standard while still requiring customers to use proprietary features. The goal is to blur the line between their products and what is accepted as the standard, so that they can sell their software as "standards based." In essence, the customer is again buying proprietary software that facilitates the same level of vendor lock-in as the prestandard offerings, if not more. Not only does this not solve the integration challenge, it actually exacerbates the problem.

Established vendors naturally try to subjugate the greater good and customer benefit for their proprietary self-interests. They're afraid of industry changes that invalidate their investments in current products. If Web services standards are comprehensively adopted, not only at the basic level but also at the extended levels, it will change the economics of the software industry and make their investments in current products unsustainable.

Because Web services represents a revolution in the way software and systems are designed and interact, it threatens the existing franchises of major vendors in markets that include application servers, application development, and application integration. The choice for these vendors is to start over and risk losing market share or to try to control the revolution. Not surprisingly, these companies are choosing the latter. It took television years to gain widespread adoption, in part because of how strongly radio manufacturers opposed it.

Standardization of parts for the mass production of automobiles did not take off until Henry Ford insisted upon it by enforcing strict purchasing policies with his suppliers. It's very possible that the Web services standards effort will continue to flounder until businesses truly start using Web services to talk with each other as often and frequently as they use the fax and phone, and they start to put real purchasing pressure on the vendors.

The next year will be important and telling in the development of Web services. End users and independent software vendors need to demand that standards remain neutral and not map to a small handful of vendor specifications.

The promise and goal of Web services is to unlock the door to past IT investments, change the proprietary nature of new software offerings, and radically change the economics of the software industry. Without question, those ideals face tough obstacles over the next twelve months.