The Dawn of a Post-Legacy World
It’s easy to be fatalistic when you work in enterprise technology.
Of course the great big programme will go wrong: great big programmes always go wrong. Of course the infrastructure will fail: infrastructure always fails. And of course we will always have legacy technology: technology becomes legacy the moment it is deployed.
Sometimes this fatalism is cynical: it is the world weary shrug of people who have lived through many failures. Fortunately, though, this fatalism is more often realistic, practical and active, and prompts us to create mechanisms to deal with inevitable failure.
Great big programmes always go wrong: that’s why we break them up into smaller pieces, manage our work through backlogs, and adjust our plans after each iteration.
Infrastructure always fails: that’s why we design reliability and resilience into our solutions, and treat infrastructure failure as an expected operating condition.
Except for legacy.
For some reason, we seem to accept that legacy technology will always be with us, and that it is a debilitating condition to be managed rather than something from which we can be cured.
(Note that, I deliberately use the term ‘legacy’ in the pejorative sense: all those software and hardware components which have drifted out of support, and those code bases which are hard to understand and maintain. I know that life is more complicated than that, and that our attitude towards legacy technology should not be extended to the teams that run it. But for the purposes of this article, we’ll regard legacy as something to regret.)
I do not believe that it does not have to be this way. It is not inevitably true that legacy is always with us. Moreover, I believe that we already know what we need to do: we just have to do it.
领英推荐
The first step is to recognise that we have legacy infrastructure and legacy applications, that these arise from different causes, create different problems, and need different responses. Infrastructure becomes legacy when we don’t manage it effectively: we skip patches and upgrades, and we don’t put mechanisms in place to make those patches and upgrades automatic. Applications become legacy when we don’t give priority to code quality, readability, maintainability and testing.
I don’t even think that we should blame ourselves (too much) for creating both of these forms of legacy. The scale, breadth and complexity of enterprise technology for an organisation of any size can become overwhelming, especially as the demands and expectations of technology grow every day. How can we find time to do patching, when the new system is already six months late, and our sponsors don’t understand the support levels of our infrastructure - and wouldn’t understand if they did? How can we get a business stakeholder to care about code readability when they’re never going to see the code?
As well as creating legacy, though, this overwhelming pressure gives us some indication of how we should tackle it. The complexity is so great, and the pressure is so overwhelming that sporadic, periodic interventions will never work. We cannot ‘remediate’ our way to where we need to be: that is like bailing with a sieve. Instead, we must make profound changes in the way we work.
Firstly, I believe that the best way to manage infrastructure is to stop managing infrastructure - or rather, by getting someone else to do it for you. We are fortunate enough to live in a world which has a growing market in managed service, software defined infrastructure platforms known, of course, as public cloud. It is often said that you don’t fix legacy just by moving to the cloud, but a good move to the cloud, and wholehearted adoption of managed services, fixes a great deal of legacy.
Second, delegating the management of infrastructure creates the bandwidth to focus on what we should be doing: building great software. And building great software does not just mean building software which is functionally rich and innovative: it means building software which is reliable, secure, readable and maintainable. Indeed, those latter things (reliability, security, readability and maintainability) are often more fundamental than the former things (functions and innovation), because you can enhance and innovate on top of high quality software, whereas it is virtually impossible to squeeze quality back into a code base that has gotten away from you.
Technology leaders face the challenge of explaining to their stakeholders why they should spend lots of money on legacy remediation for no discernible benefit. This is a tough conversation, especially if the answer is that we will do no more than make the world incrementally better for a short period of time: we are selling the brief moment when the water in the boat has got a little bit lower, and it has not yet run out of the sieve.
Instead, I think that our answer should be that any investment in addressing legacy is part of the transition to a post-legacy world. We should say that continuous legacy remediation is not a necessary evil: it is an unnecessary evil, and we aim to get rid of it. Our investments will move our infrastructure to a managed service, and give priority to good practice in software development. Not all sponsors will understand these strategies, but they will understand the outcomes: we will never talk about legacy remediation again, your software will do what you need it to do, and your end users will be able to rely on it. Rather than bailing out the boat with a sieve, let’s fix the boat, rev up the engine, and take it where we want to go.
This is, of course, much easier to say than to do. But we build enterprise technology because it holds out the hope of making the world better. A post-legacy world would be even better.
(Views in this article are my own.)
Servant Leader, DevOps and SRE evangelist
1 年As always, very insightful article. Thank you David Knott. I wish there is a way to put $$ value on the potential operational risks due to technical debt. We can plot a graph of increasing risk $$ value without investment and then few scenarios of plotting investment over say next 5 years and showing impact to risk profile. Business owns the budget so they own the decision of investment. The best language they understand is $$. I know, it is simple to say but tough to implement.
Founder, Director and Investor | Turn HR and Recruitment into your business’ biggest revenue driver | Passionate about helping CEOs and leaders to thrive in every aspect of life |
1 年Absolutely David Knott ?? Embracing the challenge of transitioning to a post-legacy world is where true innovation and progress lie.
Co-Founder & CIO
1 年Leaning into the problem of addressing legacy (thinking, infra, code, behaviours etc) fearlessly but with compassion is for me, a critical aspect of our role as technologists. Agree with your point on directing focus and energy towards areas we can deliver the greatest results and not trying to push on all fronts (which simply diminishes overall impacts and can be exhausting) Great call to arms David! ??
Chief Technologist AWS UK Public Sector
1 年System owners who adopt managed services also need to think (and act) to enable the benefit from the patching/maintenance that the managed service provider offers. If systems need to be pinned to a specific version of a database because your process doesn't enable a patch to be deployed due to testing requirements for example, they wont get the benefit. Cloud providers can do a lot of the the heavy lifting of patching the database for example, but depending on your process and technology choices, you could get yourself into a position where you can't capitalise on that benefit. This leads on to designing products, projects and teams to support this ever-green approach.
Delivering the secure Cloud, Defence and Security Solutions that Secure Government, Defence and Defence Primes need.
1 年David, working with the right Partners in the right way will result in the right solutions being found. Therefore the challenge is finding that right Partner and the challenge there is that the net never really gets cast very far and so the same old "Partners" are chosen and the status quo remains.