Leave My Legacy Alone 

“Don’t fix what’s not broken. The local software, and the logic are fine. It’s the connection and execution between the departments that's broken - fix that”

I was recently told that my stance (see above) on legacy systems was ‘Brave’. I might not disagree, given that pretty much everyone in the digital transformation space is affected by ‘shiny new toy’ syndrome and professing the exact opposite. However, thinking differently has gotten me this far in life and it’s not as if I don’t have my reasons.

Every enterprise over a certain age has a complicated skeleton of legacy systems that function quite literally as that - a skeleton. Carefully grown and shaped, often over decades to function exactly how each organisation needs. So why the panic?

To be blunt, they’re old, reliant on human manual intelligence and obsolete in their ability to keep pace with modern systems designed for fast and smooth digital interactions and automation. The extensive manpower needed for initial input, checks that things are on-track, identification and fixing of errors etc… does lead most to the seemingly obvious conclusion that these legacy systems need ripped out and replaced. Indeed, we see this line of thinking as the common dogma. Tata Consultancy Services found that “70% of CEO’s believe modernizing legacy applications is a top strategic priority."

The big problem though, is that digital transformations based on this belief are failing, and they’re failing badly. According to McKinsey and Bain & Company, the risk of failure sits between 70% and 95%! I don’t think anyone ever goes into one of these projects thinking that regrowing a skeleton will be easy; even Harry Potter knows it’s not. Still, more often than not the project fails and the legacy persists. I’m not going to sit here and blame and slander new tech, (a lot of them are bloody marvellous) but it’s not the new shiny tech that’s the issue. It’s people, people are the problem and an executive-wide oversight in factoring human nature into these decisions needs to stop.

People don’t like change. You’re asking your entire organisation to do something new, new is scary, and people don’t like to feel like they don’t understand what they’re doing. It doesn’t matter how ‘intuitive’ the new system is, unless you’re prepared to consistently educate across the board it will be rejected. If you don’t have majority support, the first incident will be taken as proof that the new way is broken and will never work.

Then there’s the cost of this approach. The Society for Information Management "found that replacing legacy applications was one of the top 10 largest IT investments for organizations".

It ain’t cheap! Plus the numerous years of effort, the system-down time for ‘updates’, the education, lack of control of external vendors, sparse IT ‘wizard’ talent on the ground, etc… and the bill will continue to stack up for something that’s probably not going to work? I don’t know about you but I wouldn’t be surprised if all the Heads of Transformation out there feel like Sisyphus. The man, who for his trickery, was punished by Zeus to roll a boulder up a hill only for it to roll back down near the top, over and over again.

The outcome is we find ourselves in a cycle of micromanagement. CTO’s find and bring in shiny new toys built and designed to solve specific problems, sometimes they have a well thought out plan and align well with business outcomes. Sometimes they don’t. They can be quick wins or fail but the relative risk is comparatively small. Ironically, instead of one new futuristic system like everyone wanted we see legacy systems with a Jenga-esque assembly of programs on top.

So how is what I’m proposing different? I’d liken it to the difference between a Muller Corner yoghurt and Frubes. The first holds onto the assumption that yoghurts need to come in pots, whereas Frubes recognise the goal is to get the yoghurt into your mouth; so why not make it a tube to squeeze the yoghurt directly into your mouth? The assumption here is that legacy systems are not fit for function when that is simply not true. If you talk to any local team, what they do and how they operate runs like clockwork. The problems are routinely due to the friction when data/tasks are passed between these operationally separate entities (OE’s). Fixing the lack of automation and verification between OE’s does not mean the legacy has to go. We have the technology now to add a connectivity layer underneath them, that will take care of end-to-end process choreography, orchestration and execution. Instead of Jenga on top, there is one supportive layer, a table that holds everything up.

The assumption is that new is best and it’s a race to get there. When really the goal everyone actually wants is measurable improvements in outcomes. After going live, distributed connectivity with smart contract execution has already proven a 90% reduction in operational costs, 85% reduction in processing time, >90% reduction in outstanding trade balance, and 10-15X ROI. The best part is, getting to live takes only weeks or months not years.

The assumption is that everyone likes and will embrace the new because of logic! Humans are and will always be emotional creatures first. On paper, starting from scratch, simplifying, designing and automating a new perfect system sounds like the superior choice. In practice, it just isn’t feasible. Not only is it astronomically expensive and time intensive, but as previously mentioned, new = scary. For everyone. I like to think of myself as a highly logical person but when I bought my first house, coming from a lifetime in flats, I refused to use my dishwasher because I’d never had one before. I continued to wash my dishes by hand in the sink for MONTHS for no logical reason, only that I was hesitant to try out the dishwasher. Sacred people will keep doors closed or actively sabotage the project.

‘My way’ of connection and automation first over complete process and software overhaul means that functionally, what your people are doing does not change. There’s great reassurance in the familiar workflows and the continued existence of the legacy as ‘backup’ if the new connection falters; keeping the human element of transformations happy, relaxed, and crucially, engaged with the project. Not just for the ultimate users. It’s a lot easier to keep executives engaged when you can easily calculate and tell the financial story of savings and delay costs. The story is much less of a guess when it’s: this is what it costs us to do it now minus the time between here & here, the extra checks here to ensure things keep moving, the compliance checks, the time we spend chasing and fixing errors, the duplication of effort here, the cost in fines/bad customer service because of this common error or time-lag here etc… In a few months, for a small cost with minimal disruption.

Finally, ‘my way’ actually does bring simplicity in its own way. One single platform (the ‘table’) holding the skeleton up, is the same table of development across the whole organisation to improve more end-to-end processes, or design completely new ones using the table as the base. There’s no Jenga, no this team has X but no one else is aware of it. Just one place for the entire organisation to develop and grow. It’s not a one-trick pony designed to tackle one problem. It’s a tool of opportunity where the only limit on what's possible is your imagination.

Automate your existing complex processes first. Then use it for real-time GDPR compliant clean data-gathering, statistics and report generation; make a single view of customer database, detect fraud, connect external partners, integrate digital asset & DeFI networks, connect to industry networks, create a modular low-code environment, composable banking etc…

In summary, what I’m saying is, leave my legacy alone! One day it might eventually be replaced, but I’ll settle for 90% better in the meantime and a new way of thinking about digital transformation.