Replacing a well-loved legacy application

We should all have in our minds some examples of software products that for a combination of reasons are not only successful but feeling for them runs deeper. They have an emotional connection with users and administrators. It is a rare thing but from time to time a software product is a good fit, arrives at the right time for the organisation, suits the organisations culture and unassumingly time after time delivers with no histrionics. It becomes a loved and cherished "member of the family".

It is a sad time when moving technology makes this a harder to maintain environment. Eventually with advancing Operating Systems old technology reaches a point where it becomes a struggle to maintain. The costs of this maintenance go up and it can start to become a burden. How do you deal with a situation like this. Any replacement will almost inevitably be compared to an iconic memory. Will it be doomed to fail ? Perhaps.

The purpose of this blog is not to judge the success or failure of the work we have done on a recent much loved legacy system replacement but instead to look at the significant challenges and the incredible achievements that we tackled to propose a viable, fully supported and affordable alternative. Here is a bit more detail on the existing application and what we offered as a possible solution.

The existing application

So what did this existing application do and what was our objective ? The existing application was a highly flexible user driven drilldown system that could alert to issues and apply a cost to any particular scenario. This allowed a very quick view of the key process/profit constraints at any given time in a prioritised view. These views could be broken down by areas with different owners/editors for each area. If you imagine a much more fluid and flexible OEE solution that could roll up or be drilled down into for more detail with user custom measureables. User defined calculations could be typed into the system freely with no fixed template design.

Our aim was to minimise the need to change any of our existing product offerings but equally to make sure that the end user experience was as close as possible to the one they were used to. All user defined calculations needed to be in the same syntax so that no involved user training was necessary. The legacy application configuration would be loaded into one of our applications and start to produce the same results. We were fortunate that we had a highly flexible product in KPI Navigator but it still would create a challenge.

"Configuring" KPI Navigator

We wanted to be in a position where the product we proposed was the same "off the shelf" offering with no customization from the core product. We did not want to start to create difficult deployment situations in the future and it was important that this solution could be covered by our existing support team. We started by defining the calculation parameters for each branch of the legacy application retaining the field names and terminology of the existing application. Our KPI Navigator already started to look very different. We introduced the language syntax for the calculations and it looked even closer to the original application. We needed to remember though that we were not trying to build a cheap copy or imitation here. The user experience is important and needs to change as little as possible but the core technology could not be more different. We are using our existing technologies in gathering data on change from the real-time historian minimising the need to re-perform the same calculations for no good reason. The snappy responsive actions and screen updates are KPI Navigator and not the legacy system. The challenge for us was to prove it was possible. We are not attempting to create a fake Rolex here but we are showing our understanding and respect of how important the existing culture of this application is. 

Success or Failure - How did it go ?

We had considered delaying the writing of this blog until the project had progressed further and some of the longer term questions like "Was it successfully adopted by the users ?" had been answered and we decided that while that is not unimportant to us it was not the objective. We aimed to challenge ourselves and prove that this could be done. Are we proud of our teams for being able to achieve this incredible feat in a short time frame without incurring a big internal expense ? That is the key question that matters to us at this point and the answer is a resounding yes. What an achievement, well done guys. It is a wonderful testament to the product and the people involved.