Standards & Technology

A Look Behind the Scenes

Creating and Implementing Database Standards

If users don't articulate what they need in database standards, they may find themselves with standards that don't solve their problems.

By Carl Cargill

The idea of standardization within the database arena is not new to the IT industry. All sorts of standardization activities have been focused on this arena, probably the best-known of which is the Structured Query Language (SQL) standard produced by the Accredited Standards Committee (ASC) X3 H2 (the database standardization committee of ASC X3). It has been estimated that the successful standardization of SQL was one of the reasons for the success of relational database management systems (RDBMSs) a decade ago. (The standard used was the Standard Query Language from IBM.) While not actually achieving much in the way of true interoperability, the SQL standard provided the market with the assurance that there would be a second source for any relational database. The success of the standard as an implementable piece of technology can be traced to the efforts of the SQL Access Group (SAG), which took the standard, cleaned it up and provided implementation details for companies that would use it.

The standardization effort played an important role in this process. It did not serve as a technical guide to open systems, standardizing the way the databases achieve interoperability. Although this was its original purpose, standardization rarely achieves such results. More often, the standard serves a business function rather than a technical one. In the case of relational databases, the function of the standard was to assure potential purchasers that there were other vendors who could provide a similar capability to the one being bought. This--not the standardized technology--helped move the market to relational databases. (This analysis, of course, ignores the technology and the market need for relational databases in the first place.)

However, I believe that if the standardization had not been in place, one of two things would have happened: either a single major vendor would be providing the technology now (in the manner of Microsoft) or there would be multiple smaller vendors, each with a unique system of doing something, resulting in a fragmented market for relational databases. Another possibility might have been that a different technology would have appeared, around which the majority of vendors would have coalesced. In any case, the success of the market would have depended upon the ability of the vendors and suppliers to work together to solve a business problem.

The proof of this concept will be, of course, whether the same tactic can be duplicated by the market. There is currently a move under way to standardize object-oriented databases. The leading activity in this area has been undertaken by the Object Database Management Group (ODMG), which created a standard for object-oriented databases in 1993. ODMG-93 was published for use and implementation by the industry, with commitments from seven object-oriented database vendors to implement the standard in 1995. The consortium is now beginning to work with other consortia (primarily the Object Management Group) and with X3 J16 (C++), and X3 H2 to ensure that the work on ODMG-93 is made available to a larger audience for study, review and implementation. The test of the theory will be if the market for the object DBMS expands and both users and providers begin to accept the activities of the ODMG. (For a further description of the activities of the ODMG, see Rick Cattell's account in "Experience with the ODMG Standard," StandardView, Sept. 1995, pp. 90-95. It is available from ACM at 800/342-6626.)

DRDA and The Open Group

At the same time as this work, there is a database interface protocol standardization effort occurring in The Open Group, that amalgam of the Open Software Foundation and X/Open Co. In 1995, in a move that surprised X/Open and many independent software vendors (ISVs), IBM announced that it was giving its proprietary distributed relational database architecture (DRDA) specification to X/Open for standardization. The activity kicked around for a while, because X/Open wasn't used to having its technical program driven by single-vendor press announcements. After a while, DRDA activity ended up in the Open Group marketing committee, where I chaired the DRDA task force.

The problem with DRDA was complicated. The RDA standardization effort in ISO and X3 had not been successful, and the earlier effort in X/Open had been largely abandoned. The market demand for these earlier standardization efforts never manifested itself in user demands--the market seemed to be coping with the problem of disparate database interface protocols. The task that faced X/Open was threefold. The first question was to determine if X/Open was the proper forum for this type of standardization; that is, a proprietary specification with a large installed base. The second question was whether or not the market needed a database interface protocol. The third question to be considered was whether DRDA was the right one.

The first answer was an easy yes; X/Open had, after all, accepted the Unix specification for standardization. On the next question, there was substantial disagreement on such topics as gateway, user demand and market size. As this was to be a marketing/business issue, the primary consideration was to be given for a marketing case. The real problem here was not so much the technology standardization--that is, the actual modification of the IBM DRDA specification to make it more open--as the issue of the need for the activity at all.

The major database vendors (Informix, Oracle and Sybase) pointed out that their customers were happy with the current situation. IBM and Starware pointed out that the gateway process was inefficient and costly. The retort was that the database vendors and the market have been seeking the "silver bullet" for interface standardization for years and never managed to find one. The discussion became heated, and ultimately the task force voted to reject the submission. The rationale for rejection was simple: There wasn't enough consensus on the proposal to succeed.

Whose Problems Get Solved?

Two real issues implicit in standardization surfaced in this discussion. The first lay with the nature of the question being solved. The solution provided by IBM was exactly that; a solution proposed before the users were asked if there was a problem or if the IBM answer was correct. The question that came to haunt the discussions was What is the problem? IBM and Starware posited the problem as one that DRDA could solve; the other vendors posited the problem as one that was being solved by gateways. Neither side looked at the issue of user needs; one was going to change the market because they had the answer, and the other was content to let the market react and let the users pay a price in inefficiency. The real question that should have been answered was What is the problem that the users want solved, and how would my solution help them be more (or less) ________ (enter any one of many user requirements here)?

The second issue derived from the fact that there was no consensus possible in this case. The two sides started from installed-base positions; IBM with its proprietary DRDA base and Informix, Oracle and Sybase with their own solutions. Essentially, IBM put the DRDA issue into X/Open and hoped that the organization would bless it; the ISVs objected, and a "standards war" almost began. Consensus--while not necessarily indicating unanimity--indicates that a majority of the market accepts the standard and will not fight against it. This wasn't the case.

Database interface protocol efforts seem to have ground to a halt within most standardization organizations. The problem is that users have not clearly elucidated their needs in a way that providers can hear. While this may be changing, it still remains a major problem for all standardization groups. What users should do--especially those in UniForum, who are, after all, most concerned with open systems--is to state functional requirements collectively and clearly. Part of the response depends on how much you're willing to pay and when you want it, as well as whether you want a "silver bullet" or would be content with a solution that, like SQL, is "good enough." The important thing to remember is that users validate standardization and ultimately cause it to happen or not. By not participating, users give away their ability to structure the future direction of the market to either the government or the providers.

Carl Cargill is standards strategist at SunSoft in Mountain View, CA. He can be reached at carl.cargill@eng.sun.com.