Categories Programming

Continued from Who spends? Who saves?

In the mid 1990s, it seemed as if a new determination swept through the software development community: a collective will to make the reality of software components live up to the promise.

Electronic hardware, it has long been observed, is built from parts that eliminate the need to understand how internal functions are performed. A circuit designer can lay out a radio, for example, by choosing transistors (or multitransistor integrated circuits) from data sheets without needing a knowledge of how a part's behaviors are achieved. Many theorists have urged that software should hold itself up to this standard.

The Internet and the World Wide Web made the goal of standard components seem much less abstract. Suddenly, there actually was an information-processing environment in which it was useful to generate information, or to describe an information-transforming process, in a format that could be understood and used on many different platforms.

The culture of the Web, initially a somewhat academic and communal set of ideals, migrated quickly into commercial settings. Corporate IT buyers, often guided by Webmasters of somewhat libertarian leanings, demanded that vendors deliver platform- neutral solutions. Buyers sought enterprise software that made effective use of commodity-priced processing power on standards-based networks.

The advent of the Web, and its rapid rise to corporate credibility, created a favorable environment for talking in practical terms about software component technologies. There were strong motives for finding ways to let the different parts of an application do their jobs in the most convenient places. It was genuinely useful and no longer merely elegant to place functions close to related data--to have the smallest possible number of bits crossing costly long-distance connections.

When people actually tried to get work done with early versions of software component technology, many gaps emerged between promise and practice. A multivendor specification, such as the Common Object Request Broker Architecture, might define a basic framework for building an object request broker (an ORB) that would let one node on a network seek data or services from another. In all too many cases, however, buyers found that each vendor had made its ORB "better" in some key way than its competitors' products. This differentiation had predictable results: Only the most rudimentary functions were actually vendor-neutral, and cross-vendor operation lacked the performance and scalability demanded for enterprise applications.

The Visigenic implementation of the CORBA specification served as something of a kernel for consolidation of the market. When Novell and Oracle licensed the company's VisiBroker, they crowned the product with the status of a reference implementation. Iona Technologies' Orbix implementation achieved a similar role, much as PC compatibility was once defined by the Texas Trio of Tandy, Dell, and Compaq.

IBM, Inprise (which acquired Visigenic), and Symantec all put their weight behind an enterprise software model based on CORBA. Regardless of their internal technologies, software components in a CORBA-based space would communicate with each other to cooperate in performing high-level tasks. No component would need to know the platform on which another component was doing its part of the job.

No one who knows the enterprise software marketplace will be surprised by what happened next.

Next: Promises vs. Products

Published as Enterprise Computing in the 4/20/99 issue of PC Magazine.