The Digital Lighthouse: How Anthony Nolan modernised its legacy infrastructure

Modernizing legacy software and infrastructure is hard. Really hard.

Nobody wants to be lumbered in a clunky inefficient system. But “slaying the monolith” is easier said than done. 

Just ask Anthony Nolan. Increasingly hampered by its existing technology, the stem cell transplant charity was struggling to iterate and facing increasingly high levels of friction.

So what do you do? Build a totally new piece of technology? Or rewire the existing system? Turns out, it’s a bit of both. 

In our latest episode, Softwire’s Ben Below details how the organisation successfully embarked on a modernisation journey:

In this episode, Monal explains how:

• Changing technical strategy with a system in production 
• Key considerations when moving towards microservices 
• How the “strangler pattern” approach can help balance modernisation efforts

Check out the illuminating discussion below:

About our guest

Transcript

[Zoe Cunningham] Hello and welcome to the Digital Lighthouse. I’m Zoe Cunningham. On the Digital Lighthouse, we get inspiration from tech leaders to help us to shine a light through turbulent times.We believe that if you have a lighthouse, you can harness the power of the storm. Today, I’m delighted to welcome Ben Below, who is a Tech Principal at Softwire. Ben, can I ask you to introduce yourself, tell us a bit about your role at Softwire, and maybe add in an interesting fact about yourself?

[Ben Below] Absolutely. As Zoe says, I’m Ben. I’m a tech principal at Softwire. That means I look after the tech side of a bunch of different projects. I’ve worked on various different things over the years, such as working on internal processes at the BBC to work out which devices, which TVs are suitable to host iPlayer, for example. I’ve done some work in large financial banks, and I’ve done some work in the charity sector as well. 

In terms of an interesting fact about myself, I recently got very into escape rooms. When I get into things, I tend to get really into them. It’s culminated in I’m now travelling to Athens by train later this year to play 24 of them with a large group of friends.

[Zoe] Wow, that’s amazing. Are you saying there are 24 escape rooms in Athens?

[Ben] There are way more than 24. There are 24 world-class, top-of-the-world escape rooms in Athens, or close to that number.

[Zoe] There you go. I love asking that question because I just always learned something that I didn’t know before. Tell us a bit about the kind of projects you’ve been involved with at Softwire, maybe the differences between them or the similarities between them.

[Ben] Every project I find is a bit different. The differences may be easier to zoom in on than the similarities. The similarities are methodologies and technologies you’re using or languages you’re using. I think what makes projects interesting is the domains and the problems you’re solving for the ultimate client. That differs from project to project. People care about really different things. If you’re working for, say, a retail bank, they really care about that huge reach. They have all of their customers and they care about the regulation that they’re really subject to. Whereas when you’re working for more internal tooling for smaller companies, they’re suddenly much more focused on making those specific tools as efficient as possible. They’re not subject to that wide reach and that optimization of making sure it’s the best it can be for a huge amount of people, but suddenly zooming in on a much smaller set and a much more nuanced use case. 

[Zoe] Yeah, fantastic. Well, I want to chat about one specific project that you worked on. The client was an organisation called Anthony Nolan. For people who haven’t heard of Anthony Nolan, who are they? 

[Ben] They are a charity based in London. They are a donor stem cell register and they were in fact the first such register formed in the 1970s. What donor stem cell registers do is essentially keep a list of all people who would potentially be willing to be a donor of stem cells. Much like when people give blood, you need to have a matching blood type to the person you’re donating to for that blood transfusion to be accepted by the body and not rejected for that to actually go through and save a life. 

The same is true for stem cell transplants, which are used to resolve diseases of the blood like leukemia, but the requirements are a lot more stringent. We’ve got a match, a set of genes in our DNA, which are a lot more varied than blood. So there’s a number of blood types that is quite small single digits, whereas for matching of the genes we care about for stem cell transplants, there’s thousands and thousands of different options for each of these genes. 

And so it’s much harder to find an exact match. And that’s what Anthony Nolan and similar registries are set up to do. They have this huge database and they run searches on those DNA and work out which ones might be a match and from there facilitate transplants.

[Zoe] Okay, cool. So I can see that there’s probably quite a wide range of the different tech that could

help Anthony Nolan. So what did we specifically do with them? 

[Ben] So we got brought in primarily to help them modernize. A lot of the work that underpinned their business was written in a kind of legacy monolith, mostly kind of visual basic and oracle database. And they were finding that this was getting a bit clunky and hard to kind of iterate and modernize with. And they were finding that they had fewer and fewer people able to make changes and that the application was so sprawling that making those changes was just coming with a lot of friction and a lot of time.  And so we worked with them initially to kind of come up with a more modern architecture, help them migrate to cloud computing and split out that monolith into a lot of smaller pieces of functionality that could be developed independently and rapidly. 

[Zoe] So essentially, because there are some projects that we do as an organization where we’re coming in and building a totally new piece of technology, but in this case, they already had a system and we were coming in to help them change it. Is that right? 

[Ben] A bit of both actually. So they did already have a system and this did a lot of things. They had this desktop application that would run searches against this bank of DNA that would let them follow up with those searches that would let them track their testing internally. But there were some features that it didn’t do and they wanted new features. So to some extent, the new applications we built were just a rewrite of what they already had. But to another extent, the modern approach we used and the fact that it was this rebuild in a kind of more modular, modern stack meant that we could also add those new features that they needed as they needed them rather than just focusing on feature parity. 

[Zoe] See, that sounds like quite a complex process. Is it more difficult to change

technical strategy once you already have a system in production? 

[Ben] I would say absolutely. I think when we’re specifically talking about not just a change in strategy, but a change in strategy that turns into a change in technology or a rewrite or a rebuild, however you want to phrase it, which is what we ended up doing at Anthony Nolan and we did rebuild a lot of this legacy functionality into new services, then there’s really two different problems you can approach depending on how you tackle that. 

The first is you can try to rewrite everything at once and say, right, we finished this rebuild, it’s going live, the old one’s going turned off. And the problem you have there is that you’ve got to not only work out exactly what the old system does, you’ve got to rewrite it in its entirety, but you’ve also got to invest all your time and effort of everyone working on that rebuild until you’re completely 100% there. And so you’re not getting any actual delivered value for a very long time. 

[Ben] And I guess you have to keep paying to maintain the old system as well. You do through all of it. Well, in the other approach where you try and gradually replace the old system, you end up having to pay to maintain that old system for even longer because you leave it around not quite in perpetuity, but you gradually identify the key parts of the old application and modernize them and release individual chunks of value bit by bit. And that allows you to get the value out faster and start replacing it one part at a time. But yeah, as you say, you then have to keep the application on potentially even longer as those lower priority things take a long time to trickle through into the pipeline of work you’re doing. But secondly, I think it comes with an even bigger problem, which is you’ve suddenly got to keep these two systems running at the same time, which can be a real challenge. 

[Zoe] So the kind of modular approach you’re talking about, it’s almost like the old story about the axe where you replace the head of an axe and you replace the handle of the axe and you can replace them both separately and then, is it the same axe or is it a new axe? It’s that kind of… 

[Ben] The axe of Theseus. Yeah, I’ve heard that as the ship metaphor previously, but it’s the same thought experiment really. But yeah, it’s replacing it bit by bit, but you still need to worry about the other parts of the axe doing their job even though they haven’t been replaced yet. 

[Zoe] Yeah, okay, super. So I mean, one of the things that I think is really challenging is that because I think that going from no system to building a system, it’s very easy to kind of map out the benefit and you say, well, it will cost this much to build a system and we’ll get this benefit. But I can see that it might be quite hard if you have a system that already does the job or already does part of the job, what’s the kind of benefit to a business to invest in this kind of, I mean, almost upgrade or transformation project?

[Ben] So there’s a few different angles you can look at it from and really it will depend on the business and what their pain points are. So it’s worth evaluating that upfront. The key one for legacy systems particularly and for things that were written a long time ago and now quite outdated technology is going to be quite consistent across the board though, which is that the expertise and the ability to find people that can work on that is just going to get harder and harder and you’ll find that getting experts who work in the tech that was written in the 80s is suddenly incredibly expensive and you’re not going to be able to find full teams of developers to work on it. You’re going to find a handful of specialists here and there. 

So that key one is just the ability to make change becomes harder and harder over time. But there’s other aspects that are worth looking at as well, depending on the business. And as I say, if you evaluate your own pain points, you might find that the old system is working perfectly fine, but it’s a bit too slow and that performance might be an aspect you need to work on or it could be that the old system, everyone hates it, the users don’t want to use it and part of the challenge is getting more users to engage with your system by improving the UX, for example. So it’ll be a different challenge for every organization, I think. 

For Anthony Nolan, you know, and some of the key challenges were that they did need new functionality that they just couldn’t add, particularly in the concept of the search that underpins all of their work that matches these DNA. There had been scientific breakthroughs in the tens of years since they’d initially implemented such an algorithm. And so previously, it was only searching for three of the genes that matter for transplantation. But nowadays, we’ve learned from more recent breakthroughs that there’s six genes that matter. And adding those three extra genes was going to be a lot more complicated and very difficult, whereas breaking out that module and being able to work on it more rapidly and with more tools that were easy to find the skill set for meant that they could add that new functionality that was vital to keep their business as up to date as it could be with the scientific research possible. 

[Zoe] Yeah. So again, you’re kind of like breaking out that part of the system so that you can kind of recode it and then wire it back in again. Was that over simplistic? 

[Ben] Yeah. Exactly. And to clarify, I don’t know if we talked about the two methods of replacing the legacy earlier. To clarify, Anthony and I, we went with what’s often called the strangler pattern, the second method of replacing bit by bit. So as you say, ripping something up and rewiring it back in, despite having spent years kind of modernizing and taking out these important chunks, there are still aspects of that legacy that are still running, but those were just the areas that weren’t highlighted as the kind of the key value we could deliver straight away. But there’s plenty of areas where the new stack is in place and has been running for years and years, improving the lives of the people who use it and allowing those new features to get out much more quickly. 

[Zoe] Well, it’s like any kind of investment or improvement process, right? The other parallel that occurs to me is like upgrading a hotel and actually maybe you need to upgrade the bathrooms because they’re really dated, but you don’t need to replace the kitchen or you need to give it a paint job, but actually everything’s functional. You know, it’s that kind of, like you say, getting the most value for the investment that you’re putting in and actually throwing everything away and starting again, if you were to take that same amount of investment and target it, then you presumably should be left with the bits that were working fine already and then the new bits that deliver substantial improvements.

[Ben] Yeah, I think that’s a really good analogy. And to build on what we’ve talked about already in terms of in this hotel analogy, the bits that the guests of the hotel aren’t happy with is one reason they might want to rebuild it, but another is worth considering something that’s not noticed by the guests, something like the structural integrity of that hotel that might be at risk and is something that needs to be prioritized alongside the things that the users are seeing

[Zoe] So it sounds like an intricate and complex job. How did we go about this? Like how did we at Softwire go about it and start thinking about it and planning it? You know, how did we approach it? 

[Ben] So, having decided upon this kind of broken down service-oriented approach, we really just took the concept of breaking out where we could deliver value, what we could split out of this old legacy system and start delivering from. And we began with the kind of highest value to the client at the time. And so I believe the first thing we worked on was a new kind of React microsite for tracking. 

So when you sign up to the Anthony Nolan register, you get sent a swab in the post and you swab your cheeks. These swabs will collect DNA from the inside of your cheek. You send them off to Antonin Allen and they run some tests in their laboratories to work out what DNA you have to be able to run those searches against you. And they needed an upgrade to this tracking system because I think some of it was being used in spreadsheets that were orthogonal to the old system because it wasn’t all integrated. And so that was the area we worked on.  First, we put together this microsite that allowed them to track those samples from individuals joining the register from when they were sent to the individual all the way through to the results coming through. 

[Zoe] Which again is something where kind of modern practices have probably moved on from, you know, if I think back like 10, 20 years and the kind of tracking that was available when you ordered something, it was kind of non-existent. And now we kind of expect to be able to see on a map where the driver is with something that’s being delivered. So it’s an example of that as well, that you’re bringing something in line with what would be available if you built it new. 

[Ben] Yeah, essentially, I think that’s something they were tracking before, but again, just kind of manually by hand in spreadsheets. So in your analogy, it would be like ringing up the driver every few minutes saying, okay, where are you now? And then from there, we kind of, we saw the success of this first kind of broken out piece of the system. And we just kind of kept identifying now where else are the value points we’re going to be able to hit for Anthony Nolan. So having broken out this microsite for sample tracking and with it, a few different services tracking some of the core pieces of domain that Anthony Nolan have. So tracking their patients, tracking their donors, tracking the genetic data itself, we then identified right now it’s the search team who are running these searches to actually find donors who have a greater pain point. So we pivoted and worked on a different microsite using some of the same backend services that were shared for those core domain objects, donors, patients, DNA to allow them to get a new system to run their searches, look at their results, select ones for transplantation. And from there moved on to actually rewriting the algorithm itself that matches donor and patient DNA. So as an iterative, find the value, deliver the value, where is the next most large pain point? 

[Zoe]On that note, that kind of approach, it feels like, is there an end point or is it something that just carries on now forever for the whole life cycle of the software or the whole lifetime of the software, right? It just keeps being upgraded and upgraded or will the strategy change in the future?

[Ben] So the strategy could mean one of a few things here, I think. Are we talking about replacing the legacy and continuing to get things out of there? Are we talking about the new way of working of getting kind of rapid iterations into smaller chunks? Or are we talking about kind of the technologies we’ve chosen and the kind of the cloud hosting of the new system? 

[Zoe] Well, I think it’s kind of all of it, isn’t it? Because there’s got more I want to talk about on this as well, that I think that technology strategy can sometimes be seen as something quite limited. And actually, the question is just what technology will we use and then everything else is standard. I actually think like everything you’ve been discussing is all part of the strategy, right? And it’s you need to be on top of or aware of what your plans are in all areas. 

[Ben] Yeah. And I think in terms of the strategy to migrate to a service-oriented architecture from the old monolith is one where it’s a case of just continually evaluating the value you can get out of it. Because while the overall guiding star may be we’re going to decommission this, we’re going to replace it all with shiny new features and then turn it off, it may be that at some point we look at that and say, right, we do have to keep this on and it’s costing us very little now because we scaled it down because all of the heavy lifting has been removed. And the journeys that it’s serving are either infrequently used or just working perfectly fine and don’t need iterating. It could be that the strategy changes from we’re decommissioning the legacy to we’ve extracted all the value from that legacy, putting it into the new way of working. And maybe our focus should be elsewhere. Maybe we should be focusing on new features within the new world we’ve built rather than hitting that fairly arbitrary milestone of we’re going to turn off a server.

[Zoe] Yeah, yeah. Good point. Good point. And of course, the other truism about technology strategy, right, is that it has to be intimately linked to the business strategy. And just as in business, we don’t know exactly what’s coming in the future. We can’t plan our technology strategy without having that input from, you know, what are the changing business circumstances?

[Ben] Absolutely. If we had a technology strategy with no business driver, we’d just end up with a bunch of developers constantly changing things to the shiniest new tech stack for the sake of it. 

[Zoe] And no value at all. 

[Ben] Yeah, which might be valuable, but might not be. And it’s the case of working out whether it is before we embark on it. 

[Zoe] Awesome. So the other part of this puzzle or this kind of technology strategy approach is thinking about who are the people you have available to work on the project. Because again, I think sometimes people think, oh, you know, you get a software developer and it’s the same as another software developer and you just buy as many as you need. And I think that’s definitely not been my experience working in the software industry. So what expertise was there within Anthony Nolan when we started the project? What kind of skills did they have to tackle these challenges on their own.

[Ben] So yeah, this comes back to one of the first points we were making as well about the need to migrate and the fact that one of those drivers was the availability of that expertise. And so yeah, when we joined Anthony Nolan’s kind of tech capability was founded in that legacy system in those old technologies and they had people and still have people who are kind of experts in and available to work on it. But there were not many of them. There wasn’t a very scalable team and going out and trying to find people who are experts in kind of all the versions of Visual Basic and Oracle was going to be very tricky for them, much trickier than it would be to find experts in Azure and React, which are very popular technologies these days. So they had a small pocket of people experienced in their old system, but they didn’t have the internal capability for the new way of doing things.

[Zoe] And so how I kind of, I know what the answer is. So I almost feel I’m going to give the answer away with my question. But how much did upskilling this team and kind of changing that form part of the technical strategy that we put together with Anthony Nolan?

[Ben] So it was definitely a huge part of it. There was never a decision to just say we’re going to bring in Softwire as a technology partner to build all of this and then leave us with it. The idea was that we worked together with them to build their future rather than to build any specific application. And so rather than working independently on this, we kind of worked within embedded teams with Anthony Nolan. So we had Anthony Nolan developers working alongside Softwire developers, Softwire tech leads Anthony Nolan manages all interspersed. And as part of that, we were kind of making sure that the Anthony Nolan developers who were ramping up on these technologies were given as much support as we would give our own developers for sure. 

And not just that, but we were also helping support them through an apprenticeship training scheme. If you recall a few years ago, there was the apprenticeship levy issued by the government that was set out to encourage businesses to kind of train an upskill from within themselves to make sure they had the tech capability they needed in the ever more digital world. And so we kind of made sure that the developers we were working with at Anthony Nolan were given that experience, were being put through that training program and had all the kind of case studies and support and evidence they needed to work through that apprenticeship as well. And so these were for context, largely people who either had experience in that old technology at Anthony Nolan and were being trained up in the new kind of cloud first approach. 

But there were also some people who just started out at Anthony Nolan as clinical scientists and decided to pivot into tech. And so very much making the most of that apprenticeship levy for what it’s there for, which is to pivot from a non-technical role into a technical role without having to leave your organization and go and retrain somewhere completely different.

[Zoe] Very exciting. Thank you so much, Ben. I feel like there are so many different aspects just to looking at this one engagement that we had with Anthony Nolan. So yeah, thanks for coming on and sharing all those details with us. And thank you for listening.