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 in terms of when you’ve come across Orphaned Software in the past, what techniques have you used to manage that software and utilise it into the future, and what value did the software have that you could draw on.
Sure George, and again this is probably taking a few learnings from different organisations. I think the pattern is somewhat common, systematic or symptomatic of this the little piece of orphan software that is doing its job fine every day, and it then becomes pretty much a black box to that part of the organisation using it. For the team that may have created or spawned it, everything’s working well until it doesn’t. Then it suddenly becomes that that squeaky hinge and they would typically turn to the IT department to say “hey look I’ve come in today and this little piece of software that we’ve had for the last two years suddenly stopped working can you help us”. The IT organisation are shocked, and it’s like what is this? No, we can’t help you. We have no documentation on it, and we don’t know where it’s broken, there’s no vendor for us to reach out to engage.
It could be something as innocent as you know, the organisation’s updated the version of their desktop environment, or their operating systems, or a network, or a piece of software that needs to be updated and this has an impact on the orphan. It can’t work with that new piece of software, so it becomes a critical moment and what happens is this innocent little piece of orphan software can then suddenly become quite a hold up to a more significant project in a company.
So you know they might need to do security patching or vulnerability patching to their environment, and they can’t compete for this business area, because they need this piece of software. The software isn’t legitimate in terms of the organisation because they haven’t had an owner for it or having someone to maintain or understand it, and suddenly this piece of software becomes a critical roadblock to a broader program. That’s usually when the orphan software gets all the attention because now people know about it. Now the unofficial shadow IT environment gets that light cast upon it, and it becomes quite essential. You have people say, well guys what is this thing, and you need to get rid of it. That usually is the trigger for the “oh what” moment of okay what are we going to do now, you know we don’t even understand, or we don’t even have a vendor for this. Our technology team don’t want to go near it because it doesn’t fit within in their remit, and it’s holding something strategic up, or something important up, so what do we do. Suddenly that becomes the critical moment, and usually, it becomes a lot of stress and pressure because you’ve got to do something quickly. You then have peeled back the band-aid enough that you also need a longer-term solution to this as well.
Graeme, so you can see that the service we provide where we investigate that orphan software is essential. 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.