On December 29, 2004, Oracle assumed control of PeopleSoft, the software vendor that merged with J.D. Edwards in 2003. Industry analysts see this as one more example of Larry Ellison's crass and crafty abduction of IBM territory. Yet, beyond the media circus that surrounded the Department of Justice's failed antitrust action against Oracle and beyond the posturing of PeopleSoft executives in the hostile takeover battle, there is something poignant about this ultimate outcome. One might say that the outcome was almost ironic.

After all, IBM never knew what to do with the fruits of its own technology model of the relational database--the model that made J.D. Edwards and PeopleSoft application software so productive. And history has a way of repeating itself again and again with IBM. Ellison saw that IBM was missing an opportunity, just as he did 20 years ago with Structured Query Language (SQL).

Against the Odds

You may be surprised to learn that IBM's feud with Oracle extends all the way back to the 1970s. The source of the feud? Oracle's basic database technology and its subsequent success is the direct result of IBM's failure to embrace its own basic research.

Today, the entire sector of financial software is based upon the relational database model. Oracle didn't invent this technology and, technically, neither did IBM. But it was an IBM employee named Edgar F. (Ted) Codd who came up with the idea of creating a database whose structure defined how a person could retrieve information from within it. In a series of reports in 1970, Codd laid out a novel idea called a "relational model" that relied upon two unique attributes of a revolutionary database technology: First, the model provided a means of describing data contained within the database with its own natural structure. Second, the model provided a basis for a high-level data language that could separate the way in which a user accessed the data from the machine upon which the data was stored. This would lead to the development of SQL as a language for database access.

Before Relational Databases

From a 21st century perspective, it's hard to imagine a modern database today that doesn't provide these features, yet back in 1970, database technology was advancing along a completely different avenue.

IBM's mainframe database product at that time was called IMS, and its technology was based upon work done for the National Aeronautics and Space Administration (NASA) Apollo project. The structure of the IMS database was dependent upon the computing hardware and physical disk drive itself. IMS required a database administrator to specifically define the location, size, and configuration of every field of data, down to track and sector level. To access an individual field, one had to know the disk volume name, the file name, the track location, the sector location, the record number within the file, and the number of bytes offset from the beginning of the record to the field's location. One also had to know precisely how many bytes of data were contained within the field as well as a litany of other information about the format of the data that was retrieved.

A simple change to the database definition--like adding a field or changing the characteristic of a field--represented a significant undertaking for the database administrator because there were no implicit definitions of field or file characteristics. A change to a field impacted not only the associated data that was logically related to the change, but also the actual physical location of every field and file contained on the volume of the disk drive itself.

An IMS database administrator's primary function was to record and control the means by which data was defined, manage proposed changes to the database structure, and--when necessary--reorganize the disk to make new space available or reallocate the resources.

IBM's Critique of the Relational Database Model

IBM had invested so heavily in the IMS database technology that the thought of bringing out a competitive database product (based upon an unproven theory of technology) seemed out of the question. Consequently, Codd published his original theoretical paper describing the relational model in the public literature because no one at IBM could conceive of the model's eventual impact.

The response to Codd's work from the outside technical community, however, soon showed IBM that the idea of a relational database might actually have some commercial potential, particularly in the financial software sector. Unfortunately, within IBM, Codd's model was severely criticized as counter to the company's goals for IMS. In an amazing move that is difficult for us to comprehend today, IBM declared that IMS would be its sole strategic database product.

The Impact of the Relational Model

Today, trying to imagine an ERP system without a relational database is a little like trying to imagine the iSeries without DB2. And that's the point that IBM missed: The relational database model wasn't about "product and profits," but about "function and efficiency."

By 1978, the professional community of database developers rapidly began embracing the relational database model. Ingres, Oracle, Sybase, and others could see the potential of a database that was self-describing, and each began piecing together the architecture needed. Even within IBM, the relational model was causing enough interest that it became an integrated part of the design of the System/38 minicomputer, much to the chagrin of the IBM IMS salespeople.

Structured Query Languages

Yet, the real value of the relational model was made even more compelling when the industry started implementing Codd's idea of a high-level access language that was separated from the hardware. The Structured Query Language (SQL) seems to have occurred in spite of IBM's best efforts to suppress it, and this is where the real feud between Oracle and IBM began.

Oracle, founded by Larry Ellison, developed and began selling an SQL-compatible product before IBM even had an SQL product out of research. Instead, IBM's SQL was still in the lab project called System R.

How's that?

Ellison had learned of SQL through publications by IBM's System R project team, a group of IBM San Jose employees who designed and built a prototype system to demonstrate the value of Codd's relational database ideas. The System R prototype was intended to provide a high-level, non-navigational, data-independent interface for simultaneous access by many users. This research developed into the Structured Query Language (SQL) that ended up being the current international standard.

Yet, at that time, corporate IBM was trying hard to suppress SQL. Why? Because SQL could not work with the IMS database. Consequently, IBM had no intention of releasing an SQL product. It was only compelled to do so after Oracle released its own product and began winning over the financial sector.

The Rise of DB2

Many of us remember when, with the marketing failure of IBM's grand Systems Application Architecture (SAA), IBM finally acknowledged that IMS was no longer its sole strategic database offering. It announced that it was going to begin selling a new relational database called DB2 to its customers. IMS was to be used only by IBM's largest mainframes. DB2 was to be the future database of IBM's financial applications efforts. From these efforts, J.D. Edwards, PeopleSoft, and SAP would begin to rise as important vendors, delivering Enterprise Resource Planning (ERP) packages as well as a host of other services that drove the software industry through the 1980s and 1990s.

Of course, on the AS/400, the integrated relational database that had been on the machine since the days of the System/38 became the template from which IBM would fashion DB2. It even started marketing the AS/400 as the integrated solution "with DB2 built in." DB2 became a completely new product line for IBM's software business. For a while, IBM even proclaimed that it had "invented" the relational database model with Codd's research. Today, DB2 is one of IBM's most profitable brands.

Final Irony

So the irony of the Oracle takeover of PeopleSoft is that 30 years after IBM tried to suppress the development of the relational database model and 20 years after IBM tried to suppressed the development of SQL, IBM was forced to rebuild its financial applications portfolios through J.D. Edwards, PeopleSoft, and SAP partnerships, using its own suppressed technology. Then, as the market became saturated with these expensive applications, IBM has had to preside over the consolidation of the industry sector, only to now watch Larry Ellison reap the spoils once again.

And what will happen to Oracle?

Analysts believe Oracle will emerge within these next five years with new financial applications for the enterprise at precisely the time when companies will need to reinvest. Oracle will also emerge with fewer competitors and on stronger financial footing, too. Instead of a refreshed playing field of competition, driving software prices down, Oracle will arise on the field as a stronger competitor to IBM, with a near monopoly of former IBM customers.

Who'd have guessed this would ever happen? Perhaps that's why we've always needed an Oracle to see the future.

Thomas M. Stockwell is Editor in Chief of MC Press Online, LP.