Phone 0403 398 807  |  About  |  Contact   |   Blogs  |  Case Studies

2. Graeme Perrins – Examples of Orphaned In-House Software

2. Graeme Perrins - Examples of Orphaned In-House Software

Hi Graeme, thanks for taking the time to catch up with me.

Thanks George, for the opportunity as well to talk about this.

So, Graeme as you know Softlogic Solutions is in the business of Rescuing Orphan Software, I am wondering if you could tell us about some examples of orphan software you might have come across in the past?

Sure and I like that term Orphan Software because it does resonate with different circumstances I’ve seen at different organisations through my career. So you know in my mind when I’ve seen software end up as an orphan it follows a typical pattern, where a business unit or someone within a part of the business, requires a very specific bespoke solution to a particular need they have. A lot of organisations are structured from a centralised IT function, that means they end up having to have a set of barriers or entry criteria to get a new solution built. So someone working in the business that has a very particular problem they would like to solve, and if it’s not going to solve an enterprise-wide problem, then it’s something in there their particular patch of the business. A lot of those IT structures make it hard for them to get a solution to their problem because they had to engage the IT function that was centralised. That means they had an overhead of needing a project, and a business case, which forms a barrier of entry. 

So, what people do and have done is, because they still have this problem to solve, they’ll go out and find out a way to solve it. When they do that it typically ends up something very bespoke that they might create under the radar, or invisible to their IT department and the management across it. It could be a solution that we would have seen in the late 90s where it’s 4GL or Visual Basic or even doing programming within excel. So they’ll get a unique piece of software created it, and it may not be or typically wouldn’t be managed centrally by their IT function. When they’ve created it, they end up having that default ownership rest with them as well, so what happens is after a few years the person who created it or the business person who sponsored that little bit of creation, move on. It is possible a person may have come in and created it and gone if they were a contractor. Then all of a sudden, you got this little piece of software that ended up doing something innocent but becomes quite depended upon by that business domain, and the organisation’s IT function doesn’t know about it. So patching it, maintaining it, keeping it current with technology as it needs to be upgraded, just doesn’t happen. One day you look back, and suddenly you’ve got this key piece of software that no one knows about because it’s become orphaned. You’ve got to have that ownership of something you create, and when you don’t, it becomes an orphan.

Graeme, it is clear that 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.


Watch/Podcast full series

Meet Graeme 

Leave a Comment

Your email address will not be published. Required fields are marked *

    Your Cart
    Your cart is emptyReturn to Shop
    Softlogic Solutions