Many Digital solutions are not an alternative or replacement to existing systems, or I would argue that if they were meant to be, the speed required to bring them to market might have compromised functional maturity and resulted in a need to retain the (now) legacy system.  This is not a new phenomenon of course,  we have all witnessed large transformational projects which have underestimated, deliberately or otherwise the complexity of replacing systems which have had decades of custom development behind them.  The mantra of ‘change the business process’ rather than customise the solution however well intended would not accommodate all of the use cases, and some invariably would be business critical and have to be supported by legacy applications.

“We replaced our monolith with microservices so that every outage could be more like a murder mystery.” @honest_update, 2016

I read an article recently on Legacy Application Strangulation, based on an original piece by Martin Fowler in 2004.  He reasoned (and I’m paraphrasing here) that one should replace legacy systems by building around them until the system is superseded.  In more recent times, I think we can see this kind of approach playing out in Service Orientated Architecture (SOA), where organisations have been re-aligning their systems into loosely coupled services.  This has been a massive architectural overhaul, predating but still relevant to Digital ways of working.  However, I think SOA only helps with the legacy issue in part.  While interdependencies and web services have been broken out, there is still so much inextricable business logic within legacy systems.

This might be a bit patronising – particularly if you’re bearing the battle scars of having to prop up these systems for yet another year, but plainly speaking, spend and focus has typically been elsewhere.  It’s been impossible to make a business case for replacing legacy applications, and now your get out of jail card of re-platforming has been taken off the table as the application’s age has become incompatible with modern Operating System and Infrastructure stacks.

Corporates have been in ‘Keeping the lights on’ mode, dipping into the eBay spares market and counting down the clock for when these systems can be retired.

The good news is that this gap isn’t getting any wider.  Continuous Integration practices at least mean you are not getting the opportunity to “sit out this upgrade” (do you remember optional quarterly upgrades!) and fall behind on supported software versions.  CI has forced us to do not just continually develop, but to continually plan.  We might have escape plans to keep the CI train moving forward, but no-one gets left behind.  Does this mean the eventual end of legacy?  Probably not, but I would hope the gap will get smaller – if we have a plan to stop it from getting deeper!

Also, there is more encouraging news in that there are several technology-based solutions at our disposal to reduce this legacy gap.  We are working with several clients embracing the likes of Kafka to create an event layer above legacy systems on which they are building new digital applications on top.  This seems to further help with the business logic issue relating to SOA that I mentioned above, as these solutions can delve into the mainframes of old and be more than just a broker.I’m also talking to some vendors about their containerisation technology, where one applicable use case is to ‘wrap’ legacy systems into a modern infrastructure and O/S stack.  This still feels like a retirement home for ageing applications, but this will surely help address the infrastructure and (some of the) ageing OS issues, meaning you can at least put away your soldering iron!

If you would like to talk to us about how Ntegra can support you to manage your legacy systems lifespan span and reduce “the gap” then please get in touch here