How to effectively manage legacy technology in government
Focusing on technology problems is the wrong place to start. We need to hone in on the problems that users have and the benefits they are looking for.
Technology enables superior digital public services. Problems occur when we forget to include the users, processes and many other external factors which influence the use and adoption of it. This is not a failure of the technology itself.
We should always remember this when we’re thinking about issues with legacy technology in particular.
Legacy technology
Admittedly, it’s very easy to fall into the trap of making legacy technology the chief culprit of all our woes. We blame it for being unreliable. We get frustrated because there is only one person in the team who knows how it works. It feels like it breaks whenever they’re not available. All these factors make everything harder to do.
I recently had a moment of realisation that made me rethink these criticisms when I received some feedback from a member of a government department team. They had spent years working on a legacy system. My comments about how awful the system was, felt as if I was dismissing all of their hard work.
I listened to their feedback and asked myself, “have I been fair, or has my thinking been lazy?”
I concluded that it was my lazy thinking. The key challenges with legacy systems (and indeed non-legacy systems) is the lack of continuous investment to keep them up to date and the absence of documentation. The dearth of skills to maintain them is caused by failures in how we all manage our technology. It’s not the fault of the technology.
I’d like to share with you a strategy I have created for understanding and appropriately managing legacy technology. It also covers how to manage processes around the technology that might replace it going forward. The aim is to make sure that (a) we make the most of legacy technology where it’s right to do so. and (b) that the technology we might develop to replace it doesn’t become the legacy problem of the future.
Understand what you have
Often with legacy technology, you’ll have very little documentation and only a vague notion of how it fits together with the rest of the architecture. So my strategy starts with mapping and documenting what the architecture looks like now – not just from a technical perspective, but also from a business perspective.
I do this by asking: what business process does the architecture support, and what operational value does that deliver? (Events Storming is a good methodology for this). The outcome of this exercise is a comprehensive understanding of what everything does. And more importantly why it does it.
You also need to define what success looks like and ensure all stakeholders understand it. This is crucial. It’s your chance to unpick all those assumptions you have made about how the processes are working and what the users are doing which adds confusion later on.
Decide what needs replacing
When you know what the legacy technology is doing and why, you canwork out if it’s fit for purpose or needs replacing. This is unlikely to be simple. For example, if you have an Oracle transactional database that underpins online products, that might be fine and you can leave it alone.
But if there is lots of customised Oracle code on top of that, and the system has become cumbersome and expensive to maintain, you probably need to replace it.
The mindset throughout needs to be geared towards stopping thinking old is bad by default. Sometimes things that work just need to be left to do the job and aren’t worth the opportunity cost of fixing.
READ: User-centred design at Zaizi: Putting users first
Replace by putting users and not technology first
You should only think about a replacement programme when you know you have sound business reasons for doing so.
If that’s the case, kick off with discoveries before you do anything else by following the GDS discovery process.
At this stage, you should also use your newfound knowledge of the business processes that the system supports to work with all the key business stakeholders and reimagine the process. This helps to ensure the tech you build delivers value because it solves a validated user need in the most efficient way.
This is critical. All replacement work should align with a user-centric perspective, even if your users are other internal technology teams. To make sure this happens, follow the processes set out in the GDS Service standards and ensure users are at the heart of all delivery.
Finally, I recommend you work on the programme incrementally, usually starting with the highest value piece of work defined by the product teams to ensure you release value to users quickly. Sometimes though it’s better to start small, especially if you have very complex interdependencies and you aren’t completely sure what will happen if you change something.
Concluding thoughts on legacy technology
The problems with legacy technology are undoubtedly a frustration. What they also highlight though is the importance of some key principles that should inform all replacement work and future technology development.
Organisations need to document what their systems do and the business needs and processes they support. They need to prevent a single point of failure by building multiple disciplinary teams. They must also avoid creating more technical debt by developing products that are hard to change just because it’s faster or cheaper. This means understanding the whole life cost of a system and not just the build cost.
Above all, organisations must build everything new against validated end-user needs to ensure they deliver value.
It’s time to stop blaming legacy technology for everything. Instead, we need to recognise it is often not fit for purpose because it was built against a flawed methodology that can’t be allowed to resurface in the future.
Our Transformation Day workshop can help you rapidly figure out how to manage legacy tech issues. We’ll help you quickly gain consensus and develop a business case to solve your complex digital challenges. Please get in touch to find out more.
-
How Zaizi’s user-centred approach won the trust of border officers
-
Does the state need to be more like a start up?
-
How to kickstart AI projects in government — lessons from Border Force, HMRC and GIAA
-
My first Regional Scrum Gathering in Stockholm – key takeaways
-
Transformation Day – How do you fit a square peg in a round hole?
-
How product management improves public sector digital services