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

5. Graeme Perrins – Difficulties maintaining your own Orphaned Software

5. Graeme Perrins - Difficulties maintaining your own Orphaned Software
Hi Graeme, thanks for making the time to catch up with me. Thanks, George, for the opportunity as well to talk about this.

So Graeme, I believe you can see value in our approach where we identify developers who are looking for the opportunity to use the skills that they had and were expert at several years earlier, to help maintain these kinds of solutions. To extend their lifespan to allow time to extract the intellectual-property that’s in them and plan a proper strategy?

Oh, definitely George. I’d say that it’s really important and you know it’s somewhat independent of what they decide for that sort of target strategy as well because you’ve got that you know moment, you’ve got to deal with right there in the now. You need to be able to quickly get, as you said, that knowledgeable expert in a technology that may no longer be a commonplace capability so even finding that person in the market could be a hell of a challenge. You’ve got to find someone who understands that domain, who’s also willing to work in that domain with their skills as well, because the newer developers who’ve come through University since that technology was originally the in popular demand, are not willing to learn an older technology.

So having that capability of finding an organisation or someone who’s got that set of skills who can connect you with the developer will all that technology expert in that older technology is really important. One of the things independent of what the business decides to take forward is that intellectual property in the software, so it’s not necessarily about the technology stack it’s on, it’s the implicit business rules that are built within the software.

So no matter how you choose to go forward if you are going to replace it or if you’re going to move the businesses processing of that into some other application or another system you still need to be able to extract those business rules because no matter where you go to, whether it’s an update or a rewrite or a move to something else, you need to be able to validate those business rules and they become the requirements, so typically in those orphan software environments, you don’t get a lot of supporting material hanging around with it, you end up you know maybe just with the executable itself maybe with the source code hopefully but you’ll be a part of reverse engineering, typically where you need those experts in that technology domain to be able to document those business rules and no matter what path you go forward with that becomes really essential because ultimately no matter where you choose, you’re going to need to test what you replace it with and you need to test against those rules.

The other aspect, there is data as well if this piece of software has been sitting there in the business, doing something useful for a number of years, typically there’s a really important valuable set of data behind it as well, so functionality moves or can be rewritten. You then also have to look at the data and understand that data, so you don’t lose the inherent business value in that data when that itself needs to be migrated or taken into a newer solution.

Graeme, 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

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