This article will explore the negative impact legacy systems have on your organisation, help you find root causes and start to develop a strategy for taking back control of your software.
Legacy burdens business agility
Legacy systems are the main contributor to a loss in business agility. A typical example that many organisations face is around reporting. When there are a number of legacy systems around different business units, there is usually a lag time in getting the appropriate data collected and subsequent reports to management. Sometimes the lag time can be weeks or months, depending on the size of the organisation. This has a negative effect on the organisation as the leaders cannot get access to the right information at the right time, hence decreasing business agility.
Further problems occur when developers within your organisation use “quick fixes” in an attempt to force your legacy systems to fit their needs. This technical debt increases as the legacy system gets older, and the ability to maintain or improve gets harder. If you don’t invest the appropriate budget towards maintaining software, which is on average 70% of the software system’s total cost, your system will rapidly decay. Eventually the legacy system will become such a burden on your organisation that you will be forced to replace it, and the cycle begins again.
Before we can start to develop a strategy to break the legacy cycle, it is important to understand the root causes of your legacy burdens.
The root cause of your legacy problems
A new lead developer is demanding that an existing software application needs replacing because it is hard to maintain. The developer who maintained it left the business because they were frustrated with the application’s poor documentation.
Your CTO is insisting that your learning management system needs replacing. It’s a monolithic application that cannot be customised because it was built around processes that are no longer relevant to your business after recent changes in response to the market.
A business analyst wants to replace your Access database. It doesn’t do what they need it to do, it’s not in the cloud, and it is a local database that was built when there were 20 people in the company who could collaborate in person.
Legacy systems become entangled within your organisation. They become tightly coupled with other software systems, and create their own versions of “normal” for how people use them, possibly ending up in scenarios in which people have to manually copy and paste data between applications to stitch up business process.
The root causes of legacy systems comes down either a lack of knowledge, or a lack of control of software systems, sometimes both. The current organisational practice for managing legacy burdens is usually to either rewrite the application, or replace it with something off-the-shelf.
Rewriting vs Replacing
Evolutionary pressure on software systems means maintenance is a never ending activity. When legacy becomes too much of an organisational burden, organisations are forced to take action. Many choose to replace legacy systems with new off-the-shelf software, but this simply resets the legacy cycle.
Off-the-shelf systems can be brilliant, if you can find the right fit. Development cycles are significantly shorter, and bugs are the responsibility of the vendor. If the licence model is favourable, the total cost of ownership can also be significantly better. Unfortunately, for competitive organisations, off-the-shelf solutions are simply not good enough. Development cycles can become significantly longer if any customisations do not fit neatly into the off-the-shelf application, and the total cost of ownership can blow out as circumstances change. Off-the-shelf vendors also tend to lock users in, meaning they have to start from scratch if they want to move to a new system.
Rewriting the application is another option. Writing a new application is fun, and working on a greenfield application can be extremely enjoyable for your software team. However, if you ask a software team about rewriting, they will likely want to use the latest and greatest technology that all other companies are using, and if you don’t, you’re at risk of not matching up to your competitors. Plus, once you rewrite an application, it immediately becomes legacy again.
Breaking the cycle with continuous modernisation
So how can we keep our software systems up to date and break the legacy cycle?
Gartner recommends seven options for modernising: encapsulate, rehost, replatform, refactor, rearchitect, rebuild or replace. Cognizant recommend a smaller set of five options: total transformation, gradual replacement, duct tape approach, improve existing, or no system change.
Through trial and experimentation, we’ve discovered the most effective method for breaking the cycle is to first embrace legacy systems and then move into a mode of continuous modernisation. Our hypothesis, as presented in Bots that Code, is that continuous modernisation can positively impact business agility by allowing you to find and mitigate root causes, then build them into the solution for your legacy system.
Continuous modernisation recognises that the moment you start using new software in an organisation is the moment it is legacy. In highly complex and dynamic ecosystems, continuous modernisation is the application of strategies and tactics to minimise risks and play to our strengths to tip the odds in our favour for a successful outcome. Bots that Code is your playbook for creating your own set of strategies and tactics.
There is no valid reason to continue maintaining old legacy systems, but we understand that legacy migration can seem daunting. Daunting or not, legacy migration is necessary. Get started now with our 6 easy steps to legacy cloud migration.
Written by Shannon England
Branding, Communications and Marketing
Shannon is our branding and marketing go-to. When she isn’t working on our communications and marketing campaigns, she is typically drinking coffee or at the local plant shop.
