Proprietary to Open: Middleware Evolves
But in another sense, Prebon is on the cutting edge. Its technology group uses sophisticated middleware from Sonic Software to ensure that its customers and brokers get almost immediate electronic trade confirmation; previously, they would have waited hours or even days for fax notification that the deal had gone through.
Since Prebon is a voice brokerage, the capability to send online, near-real-time confirmation of clients’ trade details boosts customer service. "This is a revenue exercise. We’re aiming to retain our customers by giving them greater efficiency in dealing with us," says Geoffrey Sanderson, CEO of Prebon Technology Group, the IT arm of the $434 million brokerage.
The software Prebon uses—SonicMQ—is an enterprise message server. And it’s merely one example of the variety of modern products that expand on middleware’s traditional role as "glue" to tie together disparate applications. With a generous push from XML and Web services, middleware has moved away from proprietary schemes toward flexible, open standards. And new vendors such as Ascential Software and Sonic Software have joined traditional players such as Tibco and Information Builders in offering cost-effective applications that target specific pieces of the integration puzzle.
Rather than going away, traditional middleware has branched out into subtypes including service-oriented architecture (SOA), enterprise service bus (ESB), business process management (BPM) and Web services. The diversification results from an increasing need for CIOs to find ways to integrate evermore disparate systems, from ancient mainframe applications to the latest Java servers. Integration, and therefore middleware, is today’s cost of doing business.
Early Days
Middleware first appeared in the mid-1980s (though the term itself didn’t take firm hold until the 1990s and has morphed in meaning over the years). Even at the dawn of the client/server revolution, large companies were grappling with how to extract data from mainframe systems and serve it to other platforms. Middleware provided that connection. Unfortunately, these products used proprietary frameworks for communication, and they often required hand-coding for each system. The result was costly software and long-term projects that focused on making the IT function more efficient rather than delivering and retaining customers or igniting sales.
"Traditional middleware was too expensive, too hard, took too long and required too much training. It was very IT-centric," says Eric Austvold, research director for enterprise applications and technology strategies at AMR Research.



