Menu
In anticipation of Rob Horn's session, "Patterns of Legacy Displacement", Richard Wallintin and Lukas Zühl (WPS - Workplace Solutions) asked him a few questions, e.g., "Is it the inevitable fate of any software system to be subject of a legacy displacement effort?" or "If you had to give just one advice to a company striving to replace a legacy system, what would it be?"
You state that even six-month-old startups have legacy systems. Could you provide an example and clarify how that happened at such an early stage in development?
A lot of people, when thinking about legacy systems, are thinking about room-filling mainframes, Cobol, unsupported SOA middleware, and other technologies that the organisation acquired decades ago. And in many cases, these technologies will be included in how James, Ian, and I are thinking about legacy systems - but not always. We define legacy systems as those systems that are holding the business back. In many cases, older technologies might be holding a business back due to spiraling support costs or ever-increasing time/costs for making changes. They may have an increasing risk profile or be unable to scale. Meaning they cannot evolve services or create new revenue streams for example. In this case, a business will act and look to displace that legacy system with a new solution and take advantage of the opportunity to update processes and ways of working.
In the case of startups - when the race is on to find a product-market fit, the architectural trade-offs will tend to favour reduced time to market, rapid prototyping, and incorporation of feedback over long-term supportability, scalability, and maintainability. And rightly so - if they don’t get to market first and find that market fit, then there is no long term.
So, it is not uncommon to see startups reach inflection points in their product development where the architecture is just not fit for purpose anymore. Without doing something about it, the solution will not enable them to meet their business goals - it is holding them back. And so they will act and displace those legacy parts of the system with a new solution. As Google says, “design for 10x rebuild for 100x”.
Is it the inevitable fate of any software system to be subject to a legacy displacement effort? What is the alternative lifecycle?
Great question, and it feels like this would take writing a book (and drinking many beers) to answer. But no, I don’t think so - but we may be straying into the “Ship of Theseus” territory here, though.
The Ship of Theseus is a thought experiment along the lines of “if over time, through years and years of maintenance, you have replaced, piece by piece, every part of a ship - is it still the same ship?”
So, if you are able to maintain a system over years and years such that it continues to be relevant, solves business problems, provides a positive ROI, and is easy and low-risk to change when the next problem comes along, then it never becomes legacy. But is it the “same system” that has avoided becoming legacy, or is it just the current state of an ever-evolving system? Or more likely system of systems.
The need for change comes from many directions: Business changes - new requirements to drive revenue protection and revenue generation, operational efficiency and process improvements; the world and time moving on - upgrades and product maintenance, infosec vulnerability patching, usage - storage, backups, costs, talent and skills. To name a few.
The factors that enable this alternative lifecycle are system characteristics like: a business capability-aligned modular design; change as a first class citizen; clean code and low technical debt; fast running comprehensive automated test suites; continuous delivery, etc.
With these characteristics, change is easy and low -risk, and so a system can evolve. And as long as a system can continue to change and evolve, it need never become legacy. But there are pressures on the investment needed to maintain these system characteristics...
Have you observed “typical” behaviours (ways of working) that lead to the creation of systems that become “legacy” (in the negative sense)? And which behavioural changes have proven to be beneficial to building sustainable systems?
I think the short answer to this is those behaviours and decisions that put pressure on maintaining the characteristics that enable a system to evolve and change in a low-risk way.
I have seen firsthand how “feature pressure” can lead to technical debt being mismanaged or not managed, resulting in the cost of change starting to rise. I have seen systems where an “Invasive Critical Aggregator” (a Management Information system/data warehouse) has been implemented such that it is highly coupled and changes to an application break report - again meaning changes become higher stakes and so harder and slower to implement. I have seen applications that have become the magic porridge pot of features; their context becomes unbounded, and they become a massive tangled ball of mud. I have seen cases where release failures lead to more manual controls, making it harder to release, and so releases get bigger, and the risk of failure increases. We are also seeing pressure, post-COVID, to move away from flow efficiency (effectiveness?) and back towards cost efficiency - making advocating for maintaining these characteristics even harder.
We have all probably seen one or more of these cases - but the tendency for a system to become legacy can be very slow. Like the classic “boiling frog” metaphor (I hope it has only ever been a metaphor) the micro-decisions made today, in good faith with good intentions, may be just a minor temperature increase to the pot we are sat in, and it may take years for increases to compound to a point where we realise we are in very hot water!
Software Engineering/Development education (training and tutorials) is very often focused on the idea of building something new (the “green field”). Do you think that is a mistake?
No, but I think more could be done to make the challenges of integrating with, and/or displacing legacy systems more “sexy”. What makes these systems and displacing them so interesting, to me, is the social and technical complexity, the scale, and the impact. The fact that many legacy systems have survived as long as they have is because they continue to be critical to the delivery of significant value for a business. The challenge of how to unlock new potential by incrementally displacing them without negatively impacting the services they provide can be some of the toughest challenges out there.
If you had to give just one piece of advice to a company striving to replace a legacy system, what would it be?
On the assumption that “hire Thoughtworks” might not make it through the editorial process, my advice would be - don’t be seduced by the promise of switching modes to continuous small releases of value after the big bang migration goes in 12 months' time. You have to start as you mean to continue and learn by doing it. Break the problem down, and incrementally deliver the pieces. The organisation will learn how to do continuous delivery, and the new system will be better architected to enable change as a first class citizen.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
