Closing in on open standards

Open standards have been said to be the panacea for problems faced by designers, manufacturers, and consumers. From the designer’s point of view, they provide coherent design or architectural models allowing for integration and evolution, and in general support interoperability and provide application independence, platform independence, long-term access to data, and open marketplace. Today hardly anyone prefers closed, proprietary technology to open standards-based designs.

However, designers should see the open standard from various angles, now that they have almost 20 years of perspective available since the 1980s when problems in interfacing data and communications between computers because of highly proprietary designs in computing technology, both hardware and software, made open standards a burning issue.

CORBA DILEMMA
I think open standards are not the kind of panacea they were thought to be. Take, for instance, CORBA. It is an open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on perhaps any computer, programming language, OS, and network, can interoperate with a CORBA-based program from any other vendor, on almost any other computer, programming language, OS, and network. CORBA has been around since 1991. However, hardly 10 percent of software programmers are said to use CORBA. OMG may not agree, but most software designers would agree that CORBA is a failure.

For one thing, open standards are not as simple as projected. Once basic standards have been developed, designers build extensions on them to differentiate their products. For instance, few use SQL-92 and SQL-99 standard features in their databases, but take advantage of the increasingly large numbers of extended features manufacturers provide. Extended capabilities take away some of the advantages of open standards. Consumers using extended features are less capable of moving on to other vendors. OMG has tried to define how vendors should design ORBs so that interoperability can be maintained. But business considerations always propel vendors to differentiate in their own way, even competing with ORB implementations. In other words, open standards have not been as open as they were thought to be, and new and great products should go beyond open standards.

CORBA failed because of the complexities that grew over it. J2EE, a platform-independent, Java-centric environment from Sun for developing, building, and deploying Web-based enterprise applications online, failed for the same reason. I believe that web services standards such as SOAP, WSDL, and UDDI are now getting very complex. It is too early to say what impact complexity will have on these standards, but CORBA and J2EE should be reminders. As web services are comparatively a new segment, many standards are emerging. I envisage growing standards war between various open standards, and the standard most likely to succeed will be the one that can offer openness with a calculated balance between complexity and differentiation.

DOMINANT STANDARD
Incidentally, I am surprised at the number of standards the industry can come out and support. Look at the PC industry during its infancy. Commodore, Sinclair, Acorn, Apple, Sirius, and many others, all with different standards, competed for market share. The advent of IBM PC and Apple as dominant standards established the platforms for safe investments. E-learning industry faces AICC, IEEE, ADL ARIADNE, IMS, ISSS, LRN, SCORM, etc. Wireless industry has seen such a cacophonic growth of standards that it is difficult to keep their count!
I would venture to say that some of the open-standards bodies are bureaucratic, slow-moving, and intrigue-ridden, and do not quite meet the needs of a fast moving market with fast changing user preferences.

An emerging view is that mandating open standards to ensure interoperability is a flawed approach, and a new “matrix approach” is required that will view openness not in its absoluteness but as a function of business, cultural, and resource needs.