Open Source Cooperation Helps Competitors: openadaptor as an Example

December 2001


Investment bankers are among of the most competitive beasts in the business jungle, yet some of them know when it is in their best interests to be cooperative, even with their biggest competitors. Not all of them, of course…just the smartest ones.

The Problem

Dresdner Kleinwort Wasserstein (DrKW), an investment banking arm of Dresdner Bank, was looking for a way to speed up trading transactions by pulling together information from different computer systems and passing it on to others so that it could be used easily across the organization. The situation is not uncommon in businesses that have multiple computer systems as a result either of acquiring other companies or from a long process of installing newer systems without fully shutting down the older systems. Most businesses face this problem to some degree.

The difference in the DrKW case is that they did not want to adopt a middleware solution and thus become locked into one more vendor. And while a middleware solution can provide a common backbone for all the systems, simplifying their linkage, each system depends on individual programming to link it to the backbone.

The First Solution

The work began in 1997, and was based on based on Publish/Subscribe paradigm implemented by the TIBCO products Enterprise Transaction Express (ETX) and Rendezvous. These formed the infrastructure on top of which the cross-platform framework (called Dealbus) was built. The purpose of this framework was to make it possible to avoid writing programs to integrate the applications, but instead to write configuration files to perform the linking among standard connector pieces. Dealbus was thus an integration toolkit.

This initial solution was developed internally and aimed to take advantage of open standards to build a set of standard connectors that could be used to link the various systems; furthermore, the idea was to automate as much of the connecting programming as possible. The program was written in Java to take advantage of its portability, and uses such standards as Java Message Service (JMS) and Java Database Connectivity (JDBC). There are many utility packages that contain abstractions of the connection protocols for the various systems, or that provide services such as filtering and data exchange based on standards such as XML.

The resulting abstraction layer on top of the applications makes for a more uniform user interface, and the performing of data operations such as compression on a system-wide basis increases the speed and smoothness of the entire resulting system. The details can be found in the White Paper at

The Solution Evolves

The system worked so well inside DrKW that someone had the great idea of sharing the technology with the customers to facilitate their interaction with the bank. This is a not uncommon practice among businesses: the easier customers find it to do business with you the more business they will do with you. The practice also reflects the growing integration of individual businesses within a business domain--the automobile manufacturers that operate on the Japanese Just-in-Time (Kanban) model of close integration with their suppliers are early examples of this integration over a common information system.

The real innovation was to take this thinking a big step further: if the transparent technology made it easier for customers to deal with DrKW and thus increase the business, wouldn't it increase the investment banking market as a whole if other investment banks (and their customers) were using the software? Nor would this be the only benefit to DrKW (and to DrKW's competitors): no single bank would have the whole burden of maintaining the code, and every user would benefit from improvements and innovations developed by the others. IT department users and developers readily understand these arguments from the technical point of view, and also understand that there is a positive incentive for each user to pass on the changes that he has made: if these changes are adopted as part of the main code, then the individual who made the changes no longer has to make them again each time a new version of the code appears.

The business-based decision is harder to make. Every highly competitive business fears that any internal information may be useful to competitors, and the idea of releasing source code for some of the company's software horrifies management. Good managers rightly fear surrendering any competitive advantage they now hold, particularly if that advantage were to pass over into the hands of competitors. In this case the key question is: Does the technology in question provide a competitive advantage to the company--is it a key strength of our business?

In the case of the openadaptor technology, DrKW decided that the answer was no. After all, technology was not the business of Dresdner Kleinwort Wasserstein. The technology itself was not a banking application, and performed no banking calculations. It was plumbing to facilitate the flow of bank information. The technology brought no income to the bank, and was instead a cost center. DrKW competed on other factors than its internal software. Because it faced no potential loss of income, but rather a potential savings in upgrade and maintenance costs, management agreed to try a cooperative development program with competing investment banks.

DrKW approached the three largest investment banks with a proposal to cooperate in using and improving the Dealbus software already in use or under development. Two of the three candidates accepted the proposal, and the openadaptor project was organized. To reassure all parties that the source code would always be available, the rights to it were vested in a new foundation called the Software Conservancy.

Everyone Wins

From this point forward the cooperating banks--and anyone else who wants to download the software from share in the benefits of the project. Besides the benefits mentioned above, DrKW also intended to win favorable publicity from the project as a promoter of innovative software development, and knew that bright young software developers would be attracted to a company that was prominently involved in Open Source projects.

The software is not banking or financial-services software, and could be used by any organization with complex internal systems that wanted to communicate more easily across divisions, or with a new acquisition. Any user can extend the software to fit company needs and operations, and then share the code with others in order to gain the benefits of others' improvements and bug-fixing. Recently the project reckoned that it was in use in 70 applications around the world, handling some 500,000 messages per day.

Already improvements are coming into the project from beyond DrKW, such as the Java Management Extensions (JMX) and advanced memory and performance testing techniques. A Chinese version of the project is also underway, and a porting of the code to C# is planned. SOAPsink, a Web Service, was recently contributed.

The Growing Power of Collaborative Development

None of the project is dependent upon Linux, although some Linux may be a part of the project. But the project does arise out of the ferment which gave birth to Linux: the discovery and working out of the ways that widely separated software developers can contribute together to projects of mutual benefit, and that this distributed development can save duplication of effort and consequently money. There are many projects like openadaptor your company might be able to take advantage of, and there may be software within your company which would be useful to others and even more useful to you…if it were shared.

Copyright © 2001 by Donald K. Rosenberg, Stromian Technologies (

Return to Rosenberg's Corner -- Topics