Hi Graeme, thanks for making the time to catch up with me. Thanks, George for the opportunity as well to talk about this.
Graeme, so an example we’ve come across is a solution that maybe provides a dashboard in your business that you’ve developed over time. And maybe brings different systems together such as your MIS system or MRP system, or ERP system, perhaps it also hooks into your finance system.
You’ve developed this over a long period of time. The knowledge of how to take an order and pass it to the MIS system. And how to get it invoiced and how to process all of that is all built into that software, if you were to decide to replace that, it would be a significant undertaking.
Graeme, so, the idea of rescuing the orphan software makes sense to you where you might come in, and say well what’s the migration path for this application. What are the benefits of maybe looking at extracting from it the business logic, that’s actually embedded in there. So that we can actually look at how we can replace this safely and economically is that generally speaking the approach that you would be considering.
George, look I think what you’ve described is the best approach. You can look at this from the other side of where you don’t want to be in one of those aha moments, where all of a sudden this critical warfare piece of software is in the spotlight because it’s stopping something.
It’s stopping an update. It’s preventing a broader enterprise direction or change. Or it just needs to adapt to a change in business process or circumstance. Because if you haven’t done those steps, you described if you aren’t prepared for that suddenly you’re in a situation, where you need to react quickly. You don’t have that time to understand precisely all those impacts and implications.
Then you’re also in that situation, where those risks have a potentially bigger impact of just replacing, or saying okay let’s wipe that off the desk and look for something new. Because your business will be impacted. So, I think that’s a very sensible approach what you’ve described.
I think anyone who looks around their place to say well actually we can’t stop ignoring that you know bob over there uses this piece of software in his fancy excel macro, but if Bob wasn’t here no one would know how to use it or to run it. I think you need to have that transparency to recognise those pieces and do that evaluation of what would you do, if they stopped working tomorrow and once you’ve done that you can also then prioritise it.
Hey, this is important we need to have a better plan of how we take this forward, and that approach that Softlogic has would be a good aid to have that because it opens up your options, and it gives you a view of what those risks are, but also that IP that you don’t want to throw in the bin.
You want to get a value out of that and that as you described is the basis of any business case you need to then look at how you take that forward.
Graeme, Excellent advice, so you can see that the service we provide where we investigate that orphan software is important. A lot of people are in a sense of calm and a steady-state environment where things are working. But they’re sitting on these time bombs. I think they need to take some action to locate those things. Bring Softlogic in so we can assess those particular solutions and find ways to maintain them and to look after them properly and keep them running reliably for the client.
Watch/Podcast full series for Software Maintenance
Meet Graeme to chat about Software Maintenance Help