Menu

webMethods IPO Highlights Benefits Of Interoperability

February 16, 2000

Edd Dumbill

Over the last week you would have had to work quite hard at ignoring the IPO of webMethods. Its stock soared over 500% since trading started Friday, even after a hike of well over 100% in its starting price on Thursday. However, in the crazy alphabet soup of market hype it would seem that "B2B" had a bigger part to play in this success than "XML."

Well maybe that's true for analysts. But the future of business-to-business communication is intimately linked with the use of XML. Let's take a deeper look at what makes webMethods tick. Essentially they are in the business of allowing their customers to interface diverse e-commerce systems with each other. In other words, making those systems interoperate. The powerhouse behind that technology? XML.

The success of webMethods demonstrates the vital role XML plays in the business communications arena. webMethods software allows the integration of pre-XML systems into the XML-based world. It has been so successful because it brings interoperability where previously there was none.

At least as far as the market is concerned, this blend of XML with point-to-point communication is a clear winner. Cool as they are, other XML-related activities (such as document management) have not yet caused an equivalent stir. Why should this be? Simply because communication is an eternal, vital need for human existence.

With communication comes the need to be able to understand others. This means interoperability is vital. The out-and-out killer application for the Internet is still e-mail. Why is this? It provides a basic level of effective communication with a high level of interoperability. No other application so far has come near it. The sheer pressure to communicate drove Internet e-mail compatibility into the heart of even the most proprietary e-mail systems.

This same requirement to communicate is emerging in the world of XML application-to-application communication. It's one that webMethods' "translation" approach meets now. But in the future this requirement will need to be met at a deeper level, through the adoption of interoperable approaches by XML product vendors, and the crafting of standards in a way that encourages interoperability. Vendors take note: communication matters far more than feature-richness.

However it's not only vendors that ought to be concerned about interoperability. "How will I communicate with my suppliers and customers?" is a question that ought to be asked about any B2B product purchase. Users must exert pressure on vendors to support interoperability with other vendors' products as a vital feature. Rich feature-sets (that encourage vendor lock-in) are meaningless if communication with business partners becomes costly.

It is interesting to observe that the interoperability argument doesn't just apply to extra-organization communication. XML is driving a revolution in the intranet too, enabling interoperability among diverse systems. This gives more power to the users as the pressure to buy all their systems from the same vendor in order to preserve interoperability recedes.

If users don't push for interoperability, they will have only themselves to blame. This is illustrated by a recent article from Microsoft, in which their product unit manager for Internet Explorer suggests that their support for standards is subordinate to their users' feature requests. In other words, they'll support feature X of a standard if enough people ask for it.

Standards bodies have a market too

Before we all throw our hands up in horror, let's realize that there are commercial realities for vendors. Support for standards is a two-way street. It is right that vendors should be under every pressure to support standards, and the consumer is the ultimate beneficiary of this. Yet vendors can also be seen as consumers of standards. Standards bodies have a market too, which they can't ignore if they don't want their standards to be cherry-picked for features.

So called "Internet-time" is catching up with the creators of XML standards. The clamor for XML schema and query language specifications is pushing the W3C to the limit of its resources. Unfortunately, at the end of the process, not everyone is always happy with the result. There has been criticism from some quarters about the complexity of the XML Schemas specification. The requirements from different parties are so diverse that it is almost inevitable that the result of the consensus development process will be too bloated for any one person's taste.

There is a risk that such specifications, although politically acceptable to the working group concerned, could fall by the wayside if they cannot be implemented by the vendors in a manner consistent with their users' requirements. Perversely, the ultimate losers will be the users themselves as proprietary mechanisms assert dominance.

The reality is that there are, and always will be, different constituencies that the same technology is trying to address. The beauty of XML is that it bridges these constituencies in a way no technology has ever done before. But it would be a mistake to think that every technology we could layer on top of XML would also suit every constituency.

If we cannot have 100% implementation of every standard, then we need a reliable way for products to indicate exactly which standard is supported, and at what level. Through such mechanisms our hard-won interoperability can be preserved. I am not sanctioning cherry-picking of standards here, rather urging that standards be created where possible to encourage adoption and interoperability, if necessary by a layered approach. The W3C last year announced the intention of an XML Packaging activity, which would help meet this need, but since then we have heard little of it.

It is important to learn the lessons of history. The technically inferior but simple HTML worked on the Web where full-blown SGML did not. Similarly, a readily implementable approach to an XML technology may win out too if the alternatives are too obscure. These lessons apply to both vendors and standards-makers: vendors should note again the triumph of communication over feature-set, and standards bodies the importance of implementability.

In summary, responsibility lies with all three parties—users, vendors and standards bodies—to encourage the adoption of standards and the preservation of interoperability. If this issue is handled correctly, all three benefit: users become more productive and drive down costs, vendors are able to compete on the quality of their product, and standards bodies gain increased confidence and respect.