Mick Bell
22 February

There is no doubt that in these stringent times any costs saving ideas have to be looked at seriously. There is a compelling case for building new systems using Open Source software, but what can we do with existing systems? Looking at the existing software base, and the associated costs, can be very enlightening. If you have perpetual software licences for a specific project, the maintenance and support costs are low, and there is no compelling need to change - the best course of action may be to stay exactly where you are.

If there is a driver for change (any change) then there can often be a case made for changing to an Open Source solution. This is often driven by new versions of middleware making the current implementation unsupportable; if so, there can be a strong case made for changing proprietary middleware to an Open Source solution. A straightforward case for Open Source can be made if a new licence is needed, as these are usually expensive items.

Case Study

Here is a real world example from one of our managed systems, it's grown over the years and is a complex mix of package/bespoke, Java/.Net sub-systems integrated using proprietary middleware; not untypical of many systems in many organisations. The Workflow middleware licence was expiring and we had already used up all extended-support available. Some rework for the next version of the workflow software was needed. We had an extended licence renegotiation (reducing the proposed new licence cost from £3M to £600k), but as this new licence was also for another 3 year fixed term were still attracted to a licence-free OSS solution.


So In-Year we had a circa £½M TCO saving, and each subsequent year a further £½M saving - meaning £2.5M reduction in TCO over the lifetime of the contract. To paraphrase 1066 and all that, very much a "Good Thing".

So What Next?

On the back of this introduction of Open Source middleware we also examined the rest of the estate and found that the remaining Integration Broker and Application Server middleware could also be replaced by Open Source software as upgrades were similarly needed. This time there were no licence renewals and the justification was based on cost of the changes and ongoing support costs alone. This business case to change to Open Source was marginal - the ongoing savings to support costs was the only real factor and the software changes had to happen either way.  We still decided to go ahead for the following reasons:

- Risk profile was neutral - change had to happen anyway.  We were confident that quality would not be an issue because of the initial OSS migration. There were a few doubters in the first OSS change, but they melted away after it went live without any dramas.

- There were ongoing minor savings in annual support and maintenance costs.

-         We would be removing proprietary Java frameworks and switching Open Standards - giving us more flexibility and allowed us to use (lower cost) generic support skills.

- We would have one single supplier of middleware, as opposed to 3 prior to any change - meaning our own support staff skills could be leveraged. If we didn't like that supplier we could choose another or do it ourselves - the effect of this is liberating - no more lock-in! As always YMMV (as they say on the internet), so work out your own TCO and cost-of-change equations.  The example above is from a real-world system, with the names removed to protect the innocent. Given the numbers, the decision to go with OSS should have been easy, there was a healthy risk aversion from the business users of the system, we did have to do a quick Proof of Concept to demonstrate that the volumes could be handled, but the economic argument won through in the end.

So yes, the business case can stack up, but there may be other emotional arguments that are harder to overcome.



TrackBack URL for this entry:

0 responses to 'Open Source migration - can the business case stack up?'

The comments to this entry are closed.