It’s a common pattern – particularly in the enterprise – that as critical software systems grow organically over time, they also increase in complexity. This can lead to harmful levels of technical debt (which comes from balancing short-term feature and functionality requests with long-term maintainability) and make implementing improvements a challenging and risky process.
Organisations dealing with these kinds of legacy systems are often prevented from responding effectively to new needs and driving innovation to maintain competitive advantage – indeed, legacy software systems have been cited as the biggest barrier to creating an effective digital transformation strategy (source: CXO Today). At Box UK we’re seeing specific examples of this in the organisations we talk to, such as those B2B retailers looking to pivot to a D2C ecommerce offering (something we’ve written about previously on this blog), and large organisations looking to connect disparate systems to support streamlined journeys and an improved customer experience.
Any attempts to address these challenges can also be problematic, as the downtime required to overhaul a legacy system makes it a high-risk and potentially ineffective solution – particularly as many legacy IT systems underpin core business processes, and often involve myriad dependencies and integrations (which can often be revealed by an in-depth code review).
There is an alternative solution that has grown in popularity in recent years however, known as the ‘Strangler Pattern’. In this post I’ll explore how the strangler pattern works and the benefits it offers organisations of various sectors and sizes – along with the real-world results we’ve delivered for our clients – to help you understand how you can begin to tackle your own legacy systems, and unlock greater growth and success for your business.
What is the Strangler Pattern?
The Strangler Pattern is an approach to software development where new elements are developed around or on top of the existing legacy system, allowing both to be run in parallel before the old elements are eventually migrated/swapped out. (This is in contrast to more traditional software engineering approaches, where the new system is built from the ground up before replacing the legacy system in its entirety.)
The term comes from the idea of a ‘Strangler Fig Application’, coined by Martin Fowler in 2004 after he observed the behaviour patterns of ‘strangler fig’ plants in Australia, which seed in the upper branches of established trees and gradually work their way down until they reach the soil to take root – ‘strangling’ the host tree in the process.
Benefits of applying the strangler pattern to legacy software
Delivering increased flexibility and control, as well as higher levels of uptime and availability, the strangler pattern offers many advantages for businesses looking to minimise disruption and maximise gains from their software development activities:
Quicker return on investment
A key benefit of the strangler pattern is that initial value is delivered much more quickly than with traditional approaches, as upgraded components and new features can be deployed to live as soon as they are completed. Importantly, too, these new elements can continue to be used even if development is stopped before the new system is fully ‘strangled’.
By demonstrating value at an early stage in this way, the approach also helps secure senior buy-in for any investment, which can be further supported by prioritising core elements of the system or valuable new features when planning your development activities.
(Note though that if your team isn’t experienced with the strangler pattern you may instead want to begin with a more straightforward component, to test and prove the approach before committing further investment.)
In comparison, if replacing a legacy system in its entirety, the value can’t be realised – or even validated – until the new system is fully developed, which is late in the day to realise that your budget may not have been invested in the right way.
Reduced risk
The incremental nature of the strangler pattern will also help to significantly reduce risk, as the existing legacy elements of your software are run alongside newly-developed components until they are ready to be swapped out. This ensures that new elements can be thoroughly tested prior to rollout, and even enables work to be reversed if necessary.
This staggered approach can also support the migration process for users (whether these are end-consumers, or system administrators), for example by enabling new components to be trialled as a beta service before being rolled out fully.
The strangler pattern also helps reduce risk by allowing new components to be redesigned in a way that eliminates unnecessary complexity that may have accumulated over time – both reducing the likelihood of errors, and streamlining the process of diagnosing and addressing any issues that do occur.
Higher quality
By its nature, adopting the strangler pattern means you won’t be redeveloping a system from the ground up, delivering you the benefits discussed above. However, the new features, components, applications and services you build can be developed from scratch, freeing you from the existing code and underlying logic present in your legacy system and ensuring that quality can be built in from the very start, to safeguard the performance, security and maintainability of deliverables.
Depending on the age of your existing system, you may also be missing out on more modern development practices – such as test-driven development, continuous integration and continuous delivery – which you can take advantage of when building your new components. A refactoring of your legacy software additionally provides the perfect opportunity to review your initial technology and infrastructure choices, to confirm that they’re still the most appropriate for your needs. Key points to consider here include:
Software application architecture
The strangler pattern approach is ideal if you’re looking to overhaul your software architecture, for example supporting the migration from a ‘monolithic’ legacy system – where everything is managed in a single application – to one based on ‘microservices’, where the application is decoupled into individual components that can be grouped by service offering, and exposed through APIs.
As the individual elements of a microservices-based architecture can be redesigned, rewritten or swapped out without affecting the underlying infrastructure, it can help improve the maintainability of your system and support your ability to scale – and if you’re looking for more detail on monoliths, microservices and serverless architecture (the next step in this software engineering evolution), take a look at this fantastic guide by my colleague Nick Rowland.
More generally too, when working with the strangler pattern you can ensure your new services are built with integration in mind, and so more easily take advantage of pre-built features and functionality, which can be slotted into your wider technology ecosystem with the help of APIs and middleware solutions.
Hosting options
Offering near limitless flexibility, reduced upfront costs, and efficiency gains, cloud solutions such as Google Cloud Platform (GCP), Amazon Web Services (AWS) and Microsoft Azure dominate the hosting landscape today.
If you’re not already taking advantage of cloud hosting, using the strangler pattern to modernise your software components provides the perfect opportunity to move them over to a cloud-based platform and so safeguard the future scalability and growth of your systems – and if you want to learn more about migrating to the cloud and the benefits it can deliver for your business, we’ve produced a white paper and webinar on the subject, which you should definitely check out.
The strangler pattern at Box UK: ‘The Anfield Approach’
So we’ve been through the what and why of the strangler pattern, but how does it work in practice? This is something we know well at Box UK, with extensive experience of applying the model to help enterprise organisations modernise their legacy software systems.
It’s often referred to as the ‘Anfield approach’ by our teams, in reference to the expansion and modernisation of Liverpool FC’s football stadium, which saw the new stadium built around the old one before eventually replacing it – adding 8,500 seats without disrupting the experience for fans.
This inspiration came at an ideal time, as we were taking on the redevelopment of RS Components’ DesignSpark community platform, which had grown organically over several years, and was showing high levels of technical debt as a result. We decided to adopt the strangler pattern/anfield approach for the project, iteratively improving the quality of the underlying codebase to the point where it could support new feature development, all while maintaining service for DesignSpark members and retaining RS Components’ existing SEO value. The approach also enabled value to be demonstrated quickly – with all initiatives tied to clear, specific KPIs – aiding the client in getting budget sign-off from senior stakeholders.
Take a look at our webinar ‘Keeping the lights on’ to hear about the impressive results achieved through the DesignSpark redevelopment project from the client themselves, and if you’re after more detail about the technical approach taken, check out our session on ‘The Anfield approach’ – both of which are available to watch now on demand.
Time to transform your legacy software
The strangler pattern approach offers an innovative development model to transform your legacy software, but you’ll need more than a skilled development team to ensure the success of your initiative.
Business analysts, solution architects and software consultants will be required to define your overarching strategy (based on a detailed knowledge of your existing systems and future goals); product, project and account managers will support the rollout of your development roadmap and keep your project on track; and User Experience (UX) and User Interface (UI) designers should ensure the front-facing elements of your software are of the same high quality as the underlying code, and that they effectively serve the needs and expectations of stakeholders and users.
At Box UK we understand the complexity involved with addressing legacy software, and have built multidisciplinary teams to cover this end-to-end process – find out more about how we’ve helped organisations in the past, and contact us to discuss your specific legacy software requirements today.
