One of the systems engineering challenges that haunts the public sector is the legacy system: the systems which have been around for years and are integral to day-to-day operations but are now outdated, often with no-one knowing exactly how they work anymore. Relying on an old system can cause a range of problems such as difficulty sharing information, a poor user experience, performance issues, a lack of storage space and inadequate security to name a few.
In law enforcement legacy systems are even more common, with UK police forces holding their own budgets and procuring IT at a local level. The expense of off-the-shelf products plus the fact that a ‘one size fits all’ approach rarely fits anyone has resulted in many forces coming up with their own solutions to support their own specific ways of working. While these bespoke solutions have been tailored to local processes and niche requirements, this has led to a plethora of unique-but-similar systems existing across different forces. These local systems need to be upgraded to accommodate evolving national requirements and standards, resulting in a long tail of changes which were never anticipated when the system was first designed. However as legacy systems often have a relatively small number of users - a single department or even a single team in some cases, it can be tricky to make a business case for an overhaul.
Although replacing a legacy system will almost always be more expensive in the short term than simply adding more functionality to it, it is important to take a longer-term view. The ongoing cost of maintaining a legacy system and updating it to comply with security requirements and data privacy and protection regulation can very quickly begin to add up to more than the upfront cost of a new system. The knowledge of the legacy technologies used and how to unpick the business logic embedded in the code base is also often lost over time, making it harder to implement change quickly.
Add to this the fact that legacy systems can sometimes be a bit of a Frankenstein’s monster: a system initially developed in-house to meet one team’s needs is then adapted to accommodate other teams who see the benefit, but have slightly different requirements. Systems grow in an ad-hoc manner, almost becoming a set of tactical ‘point solutions’ in themselves, and the code base often becomes increasingly inefficient and repetitive - retro-fitting emerging security or data management requirements across a system like this can be both complex and costly. It is also common for all of this work to fall to the one member of staff who is an expert in the system; not only does this create a single point of failure, but leads to skilled front line officers being diverted from operational work to provide support. There is certainly a point at which just replacing the system is the most efficient, cost-effective and sustainable solution.
So how does Principle One approach updating legacy systems? Firstly, it is crucial to recognize that legacy systems typically fulfil mission-critical roles within a force. This is exactly why they are so hard to let go of – legacy systems may be a bit long in the tooth but they do what they were built to do very well. There is also a fear of change to tackle: day-to-day users may feel that having a sub-optimal legacy system is preferable to the disruption of adapting to a new one, particularly if that system is integral to their work. Therefore it is important to use the legacy system as a template for any ‘overhauls’ and replicate its value: the new system should inherit key aspects of the original system (such as supporting existing business processes) and offer improvements where needed. Effective business change needs to be considered alongside this: how can we make the smoothest possible transition and minimise the frustration for users of having to learn how to use a new system?
At Principle One we have developed design patterns for uplifting legacy case management systems, taking into account the need for compliance with national standards and requirements but tailored to support local teams and their established ways of working. At the heart of our approach is an understanding of what works well for users and what does not. We start by conducting user research and mapping out business processes along with a thorough technical review of the existing system in order to identify the key features to retain, and areas for improvement. This analysis allows us to plot out a system roadmap, prioritising the features or changes that will have the greatest impact and helping the client to determine their minimum viable product (MVP). This end user engagement helps us get beyond the ‘that’s how it’s always been done’ mindset and think more creatively about how they could work more efficiently. It’s typically not long before users begin to appreciate productivity benefits such as streamlined processes and reduced double keying.
We then use tried-and-tested design patterns for core or 'commodity' functionality but tailor the user experience to support local business processes and terminology, ensuring that the system continues to do exactly what it needs to do and feels bespoke. This is more efficient and cost-effective than creating an entirely bespoke solution, and more likely to meet local requirements than implementing an off-the-shelf package.
In the example of case management systems we see common requirements across teams, departments and organisations (often around hygiene, compliance and administration), and have developed a baseline set of services to deliver these. There are further benefits to taking a more repeatable approach here too: if case management systems follow a familiar, intuitive format this will reduce the learning curve for new users, allowing them to focus on getting to grips with new business and operational processes instead. Commonalities between systems also open up opportunities for better information sharing, with data stored in standardised structures and formats.
Despite the spectre of legacy systems looming over many forces, there is still significant resistance to change. No system is immortal, and although some simply refuse to die they are increasingly difficult to manage and maintain in old age. Using tried-and-tested design patterns can help remove the fear of the unknown, while a user-centric approach delivers a system that enables rather than constrains local ways of working.
Deciding when to give up the ghost is a difficult decision, but one that shouldn’t be faced with too much trepidation.
Comentarios