This is part of a new mini-series looking at Legacy software - the term "legacy" is often seen as a positive - yet within computing it is a negative term generally uses to indicate the need to replace hardware or software. A few weeks ago, I introduced three methods to address legacy software: In this episode, I take a deeper dive into Outsourcing
Or listen at:
Published: Wed, 31 Aug 2022 16:01:29 GMT
Transcript
Hello and welcome back to The Better ROI from Software Development Podcast.
I'm currently in the middle of a mini-series looking at legacy software - what it is, how it occurs, and various strategies to deal with it.
Over the last few episodes, I've introduced it and I've talked about all software being on a sliding scale rather than an absolute of legacy or not.
I've talked about the impact based on how much effort the software development industry puts in to try to explain it - the technical debt analogy, the broken windows theory, the messy campground example - these are all shared warnings that seemingly small problems mount up over time until the system is no longer viable - which is leading to an expensive replacement work for something you've already invested in.
I've taken a look at some of the causes of how we get legacy software.
And in episode 144, I looked at three approaches to addressing legacy software:
- Evolution - the continuous improvement of the existing system to bring it out of its legacy state
- Revolution - the wholesale replacement of the system with something new
- And Outsourcing using a third party to either maintain or replace the legacy system.
In Episode 145, I took a deeper dive into that Evolution option. And in the last episode I took a deeper dive into the Revolution option.
In this episode, I want to take a deeper dive and look at the outsourcing option.
It's fair to say that I'm not the biggest fan of Outsourcing.
I've lived through the upheaval caused by Outsourcing when it was fashionable. A period of time where it was believed that the work was unskilled and as such, it didn't matter who carried out that work. It was believed to be commodity work, and as such it could be done by the cheapest resource.
Personally, I've yet to find a compelling example of where that worked - which thankfully, is why the approach has largely fallen out of fashion.
And with software being so critical to the success of an organisation, I find it rare that outsourcing the software makes sense. In Episode 144, where I compared evolution, revolution and outsourcing, I suggested two reasons why it may be practical:
- One - you're unable to recruit or retain technically knowledgeable staff
- Two - you're effectively buying a product.
If you're effectively buying a commodity product, something that can be sold to many other organisations, then it definitely makes sense to outsource that. For example, if you've previously internally built a timesheet application, then it is almost certain you can find a commodity product that performs the same action.
I'd never suggest that you build commodity software. You definitely wouldn't write your own version of Microsoft Word. It just wouldn't make commercial sense.
The one piece of advice I would offer on this, though, is to watch when the product becomes something non commodity.
Many software applications provide an ability to customise them. And the minute you start down that road, you should be tracking how much customisation you make.
I've seen projects take a commodity application and modify it well beyond its original intent. So much so that making upgrades or moving away from the product became almost impossible - there was simply too much complex investment in it.
For me, if you think you're buying a commodity product, ask yourself what would happen if the vendor suddenly went out of business tomorrow?
If there isn't an obvious "we'd move to product X from vender y", then I suggest that you're not buying a commodity product.
The Outsourcing of an existing internal software product brings with it different considerations.
Let's assume that you have a legacy software built in a technology that it's no longer viable to recruit or retain knowledgeable staff for. You are approach by an Outsourcer that has a history with that technology and the necessary staff to build and maintain it. They offer to take over the ownership of that product for you.
Now, beyond the basics of proving they're capable, there are a number of factors that you should consider:
- Who will own the code for the legacy website?
- What is the exit strategy?
- What if the outsourcer goes out of business?
These are questions you need to think about early when setting up the relationship. These will influence any contract.
Let's look at each.
Who will own the code for the legacy website?
If this website was originally yours, and probably more importantly, you want to avoid the outsourcers selling it to your competitor, then you want to make sure that you retain ownership of the code.
You'll also want to include any changes made by the outsourcer. Different countries have a tendency to treat the ownership of that change code differently. Many countries will treat it as owned by the outsourcer as they have created it. This is definitely one worth checking and ensuring that all rights are assigned to your organisation. The same should be true of any other created asset such as documentation, training, material or support guides.
What is the exit strategy?
You should always ensure there is a clear plan for exiting the relationship and the outsourcing service.
Ideally this exit will occur because you have either replaced the legacy system in question or simply no longer need it.
But the exit could be because one or both parties simply do not want to continue the relationship. In that situation, how do you ensure a clean exit? How do you ensure that you receive all the code, data, documentation and any other asset held by the outsourcer? How do you ensure that they cease to hold any of your intellectual property or confidential information?
Rarely does anyone want to talk about an exit strategy at the start of the relationship. But this is a business relationship, it is not expected to last forever. Obviously having a clear understanding of the ownership helps to make this exit easier.
What if the outsourcer goes out of business?
If during the relationship the outsourcer goes out of business or is sold, what protections do you have over your assets?
With modern software development, it is relatively easy to ensure that source code, data, documentation, etc. are in a shared environment that can be accessed by both parties. But you need to ensure that will continue to be available if the outsourcer goes out of business.
Where it cannot be shared, then you may need to look at an escrow agreement where all relevant assets are held by a third party such as solicitor. But this is unlikely to be needed as much as it once was.
Most of the time by having the relevant system for sharing, it will continue to be available as long as you, as the organisation, own any underlying account and are paying for the service. Don't fall into the trap of the outsourcer owning and paying for the sharing service. It may seem easier from a setup and billing perspective, but if the service is lost due to the inability of the outsourcer to pay, it could be challenging, if not impossible, for your organisation to recover it.
With these three questions in mind, I would also add one more additional comment related to the outsourcing contract. Both parties must work together for this to be a win-win. Normal procurement procedures should be left at the door. You need a partnership on equal footing, not a commodity procurement knock down to the lowest cost.
In this episode, I've taken a deeper dive into Outsourcing as an option for dealing with legacy systems.
Of the three options, Evolution, Revolution and Outsourcing, it is by far my least favoured. And for any system that is critical to the success of your organisation, you need to retain that internal capability.
While many leaders will consider that software development is something they can use strategic partners for, after all, they aren't in the "software development business", I would suggest they've missed the point.
Business used to be about moving atoms, physical items. It's moved on. It's now about moving bytes, digital data.
So regardless of what type of business you think you're in, you're in a technology business. And software development is no less critical part of your capabilities than accounting, sales or marketing. And more often than not, you'll find that software is a differentiator in the market. And if it isn't yet, then that's great, because it will be - use this opportunity to get ahead of the market.
Thank you for taking the time to listen to this podcast and look forward to speaking to you again next week.