Paul Liptrot, Partner – UK Government & Public Sector at Kyndryl
Any organisation embarking on a digital transformation project will know that there are significant challenges to overcome. While the benefits at the end are impossible to ignore, the barriers to success are complex and wide ranging. Add in legacy public sector applications to the process, and you open up a whole new layer of complexity.
Whether it’s cost-cutting pressures or competing interests holding back the process, product development and delivery can be significantly harder than it is in the private sector. Not just that, but across Whitehall it is broadly recognised that there’s a significant amount of technical debt to deal with too, meaning many Departments are typically starting from a place far behind that of their commercial counterparts.
Technical debt has been acquired in the public sector over several years (even decades), and for many reasons. Predominantly, ongoing budget constraints and loss of resources mean it has been easy to put off long-term, labour-intensive maintenance and modernisation projects, in favour of feel-good ‘quick wins’ that can be delivered quickly and the impact felt fast.
Furthermore, legacy, proprietary platforms that many public sector systems are developed and operating on, have undergone significant customisation and bespoke development over many years. Not only do these support mission-critical processes, making it hard to get downtime for improvements approved, but they are notoriously tricky (read: time-consuming) to unpick and migrate to newer, more modern platforms and infrastructures.
Too often, both public and private sector organisations have had a superficial opinion of what it takes to address tech debt, focusing on dealing with the often out-of-support components rather than the underlying problems. As a result, tech debt is only getting worse, reducing workforce productivity, inhibiting innovation and keeping public services stagnant through a lack of agility.
For public sector organisations looking to address the problem, the first step must be to assess and understand which services are going to be needed to deliver current policy and customer outcome objectives. With this clarity organisations can then design their Target Operate Model (TOM) to not only support these but also put in place processes and technologies that will be agile enough to adopt and adapt for the future. Understanding the TOM will then allow CXOs and their teams to make informed decisions on which approaches to take, which technologies to retain, which to replace and which to adopt public and private cloud services for in an overall hybrid environment.
With a TOM in place, priorities can be established, required investments can be understood and organisation teams and squad structures can be established within a governed program to remove tech debt. Informed decisions can be taken per business service or application with options typically including:
Retire and start new
Evaluate whether it is even worth modernising the underlying technologies. Would it be easier or more beneficial to instead migrate the business processes and data to something else? This could be a modern SaaS platform or a lighter-weight, micro-service-based replacement application. Where suitable SaaS products exist, moving legacy services to these transfers the risks and costs of developing and maintaining underlying application software and infrastructure to the SaaS provider.
Re-platform
Where SaaS isn’t an option, building products on PaaS can reduce the risk of tech debt by moving the responsibilities for maintaining, patching and updating the underlying infrastructure, operating systems and middleware to the cloud provider. As PaaS migrations involve refactoring legacy applications to fit the platform offered by a service provider, it can be time consuming. However, once it’s complete, it takes the maintenance time away from programmers, freeing them up to deploy new applications faster.
“Lift and shift”
One of the easier and least expensive ways to migrate an existing workload to the cloud is an IaaS migration, sometimes called a “lift and shift”. That’s because you move it in its current form, with minimal changes, and run it on cloud-native resources instead. This is particularly useful where the technical debt resides in hosting locations and physical hardware, but typically isn’t the answer where the debt relates to applications or software. In these cases, a lift and shift can be useful as part of a longer term program, by buying more time to modernise the applications once into Public Cloud and freed from the immediate risks associated with ageing hardware or building closures.
Modernise in-situ
You could choose to slowly migrate a legacy system by replacing specific components over a period of time. There are many variants to this approach but one of the most common is the “Strangler Fig” pattern which involves creating a parallel new landing zone and slowly redirecting from the existing application components to the new ones as replacement functionality and services are implemented. Eventually, the legacy is retired completely.
Whichever methods are adopted, once tech debt has been eliminated, that’s not the end of the road. Maintaining the TOM is an ongoing monitoring exercise to ensure that it doesn’t begin to accumulate again. Here are six top tips to avoid it recuring:
- Run teams that maintain and constantly update products rather than big periodic projects. The ongoing level of investment may seem high but the TCO will be lower, with the product itself remaining evergreen, supporting innovation and avoiding build-up of tech debt.
- Maintain tech roadmaps and review regularly, with tech refresh built into investment cases up front.
- Implement modern DevSecOps and Infrastructure as Code methodologies to ensure that services can be updated and re-deployed easily.
- Consider options like Low-code/No-code and RPA for building applications and workflows where these are suitable, avoiding the need to write and maintain code.
- Design for micro-services over monoliths. This allows parts of applications to be updated and modernised in isolation from the rest of the service. Principles of abstraction help here, as well as designing for components/services to be joined up using APIs and loose-coupling.
- Feeling overwhelmed? Engage a partner you trust that can help advise, build and, if required, operate your technology transformation.
