Strategy for migrating to new messaging middlware

I was chatting to an old accomplice the other day who headed up FX architecture for a tier 1 in the US about my new position with 29West - apart from saying they were a great company with great tech, he said they has decided not to use the LBM product because of the pain of migration from the existing Tibco RV middleware. So part of my new role will be to create a migration path which is as pain free for our customers.

This is exactly the problem we had to solve in my current assignment (I don't start with 29West until late July btw) - how do we integrate Wombat (which runs over LBM) into an organisation which relies on another product successfully? The strategy we adopted was to use a straightforward design pattern to implement a piece of throw-away middleware combined with a touch of perception management - always important.

Project Evangelism Framework


As important as the technical feasibility and superiority of a candidate solution is the management of the change process. I've amalgamated some techniques which are based on open source tools, allowing debate and development of a community of interest around the solution. The idea is not new and was inspired by reading the Cluetrain Manifesto as a younger man.

Basically we have several chat channels - one for the project where the public can ask questions and get expert answers, one for the technology, so that we can fight our technollectual battles. A blog for a record of meetings, decision, vendor liaison and general project karma and lastly a wiki where we can disseminate project documents and build a support knowledgebase. I'll blog again about this as I have some theories about the roles people play which I'll elaborate.

Using this setup has surprising effects and advantages - meetings are now a matter of record for public consumption which modifies people behaviour towards cooperation and congeniality. Vendors are treated fairly and openly, decisions vindicated or challenged thereby using the wisdom of crowds. Project documentation is completed and of a higher standard. People behave more professionally. Business customers can see the real state of the project.

Technological Framework

First thing is to get the new infrastructure up to near production level on dev hardware with the minimum of fuss and footprint. Then productionise it so that there's autostart/stop, logfile monitoring and maintenance etc. Next you need to develop some examples or tailor the ones supplied to assist with onboarding.

It helps if you can develop the code to fill patterns of use within the organisation - this way the developers need minimum effort to integrate. Be ready to answer support from developers and sort out issues quickly. This way the community will begin to trust you because if you lose people early through poor infra, support of lousy code, it's going to be all the harder to get your new solution adopted.

You need to run the two infrastructures in parallel but new development needs to use the new infrastructure and existing code phased over to the new infrastructure once it has been proven.

To help here, I implemented daemon process which implemented a Facade/Proxy/Adaptor pattern. This can be written in whatever language you like, but I'd recommend C because it just so happens that it's the lowest common denominator. This allows you to take data from any source (databases, flat files, memory maps, MQ, Tibco RV, Emma, Vhayu, FAME etc). and provide it to the existing and new clients. In time, the new clients bypass the adaptor. This allows you to maintain the client functionality whilst developing new interfaces.