Solving the Legacy Dilemma

Podcast Transcript

Sam: Welcome to pragmatism in practice, a podcast from Thoughtworks where we share stories of practical approaches to becoming a modern digital business. I'm Sam Massey, and I'm here with Ashok Subramanian, Head of Technology for Thoughtworks UK. We'll be discussing the hidden legacies that hold organizations back, and how to overcome the challenges of legacy modernization to enable innovation and competitiveness.

Thank you, Ashok for joining us today on the podcast, and why don't you just explain a little bit about what you do at Thoughtworks?

Ashok: Thank you for having me Sam. At Thoughtworks, my role right now is head of technology for Thoughtworks in the UK. What that means is I help clients with the technology, strategy, architecture, and more generally approaches to how to deal with complex IT estates there.

Most of our clients are going through, the entire industry in many sectors, going through troubling times, trying to figure out how to navigate through these complex times is something I try and help our clients do.

Sam: Let's talk about those complex times and what it means for a client, and today we're going to be talking about legacy modernization. Help us understand a bit about that. What does that mean when we say that? When we go into a client or when a client is facing that problem, what does that mean to you, and how do you start approaching modernizing a client's legacy?

Ashok: The term legacy modernization is now going around the industry quite a bit. Let's try and maybe unpack that a bit first to try and understand what it might be. What does legacy actually mean?

Right, so nowadays the connotation of that word seems to be fairly negative, but I think we have to almost remind ourselves that it's actually these systems, these technologies, and processes that have made organizations successful. That's probably the first thing to actually see, now step back and look at it and say, "It's not all bad." Sometimes I have even heard people refer to it as a heritage system so I think, just seems to have a better connotation to it rather than legacy.

Ashok: People are really talking about legacy. I think this is sometimes about what people can experience, right? It's much more about the challenges that it could possibly be posing. I think it's quite common for people to be frustrated with the systems that they have, with the systems that their customers have. It could be due to ageing systems. That could be one part of it what defines legacy. It could be the tools, and frameworks, and the process people use.

On the other end of the spectrum, it could even be organizational structures. You might have the most newest shiny tech available to people and there's no constraints over that, but how the organization has grown, and now it's sort of evolved to a stage where it can't really take advantage of those things. It could be any one of these things or a combination or many of these things as well.

Sam: It's not as simple as just looking at the public facing piece of what a client might produce, and say, "Oh, that's the legacy." It's also to do with the teams, and how they're structured, and how they've become the business who they are today.

Ashok: Absolutely. I think this, it's a very interesting point that you highlight there. Sometimes we can get carried away by the customer facing touch points or just the interfaces that we sort of interact with. Actually, in the world we live today, the customer experience is much more beyond just that user interface. It could be the expectation of a customer when they use your website online. It could then be, they want to speak to you because they have a query, and the expectation that you know who they are, and the answers to their questions will be easily available and addressed. I think we're all very familiar with where you have to go through this, repeating the same thing seven times to seven different people before you might get to an answer. I think that's a common problem that many organizations deal with.

Sam: How do we approach that problem, and how do you approach that problem when you speak with clients? How do you begin the work where you can see that, "Yep. This is a business which has legacy, the business knows that, They want to make a change.", but it sounds like from not just the public facing user interface and the shiny thing, but deep within the company, you essentially have to transform from the inside out.

Ashok: Yeah. I think the dilemma that most organizations face nowadays, and I think in the retail industry it's quite common. I think the term for it now is the Amazon effect. The challenge that people are trying to solve is, how do you innovate? How do you keep up with competition, but also respond to changing consumer needs and behaviors at a rapid pace? Now, in order to that, there are two ways to do it. You can either have platforms, and tools, and process that allow you to build upon and innovate very quickly, and sometimes you don't really have the ideas coming from within the organization, they might be from outside the organization as well. The expectation that you might even be able to be a fast follower, like catch up with ideas that maybe your competitors have introduced.

In order to do that, one of the challenges ends up being the systems that the enterprise has grown up with. One of the common themes or patterns that we see was across enterprises. Our organizations and businesses were designed to be vertically integrated. You have a bank that was mainly meant to do banking, how a retailer was expected to mainly only sell stuff, insurance company will need to do to manage risk and sell you insurance. Nowadays, you have messaging applications where you could do payments. You have a retailer selling you everything where you would only expect to buy like physical goods, but you could buy music online.

In those sorts of circumstances where organizations have had to respond to the fact that, as they try and pivot from a vertically integrated enterprise to more horizontal one where it's not even necessary that they provide all the services, but they might have to play in an ecosystem of other players providing services that you need to sort of integrate with.

I think it's quite common in the startup space right now, especially if you look at some of the fintechs like Monzo for example. They understand that, while they might, to start with, be able to provide the entire suite of services. They work with other startups like TransferWise in order to be able to do cross border payments. It doesn't mean that in the future, they might not build it or they might not be able to have that capability in house. But to start with, they want to make sure there's nothing in their existing estate that's actually constraining them from going ahead and building these things.

Sam: Easy for the startup. Easy for the company that was born post .com. Someone gave me an example this week where they said, "It's fine if you're a big online retailer that was born as that, but if you were a high street brand that was maybe founded a hundred years, or even longer than that, ago, it's a challenging thing to then go head to head with that very new, very sort of seamless customer experience facing site or business.

I think what I find really interesting about that is you have these conversations with these clients, and I suppose it's really interesting to hear for others, where you meet resistance sometimes, or why do we see resistance initially sometimes from clients? What is the reason behind that, or what do you find is the most common reason why people might find it difficult to go on this sort of transformation?

Ashok: I think that's a really good point. It reminded me of a recent conversation I was having with a client of ours, and actually they're doing all of these things. They're trying to introduce new technology. They have the intention to build a platform. They are now trying to organize teams to have daily stand-ups as an example. They're trying to break teams to work into squads.

Then, I think this is possibly a good lesson even for myself that of not making any assumptions. Then, we directly went into some of the approaches they could be using to try and decouple some of the systems, architectural patterns they could be using to either reduce the footprint of all applications, how they could look at analyzing usage patterns before designing, whether they can find ways to integrate newer tech into their estate.

For every thing that I would suggest, they would be like, "Well, yes, we've tried that, we've tried that." For a second I had to take a step back and pause and think about, "Well, actually, if had been trying all of these things, what is the real challenge?" Then I told Austin, "Well, is everyone in the organization, do they actually see, does the organization actually feel the pain of what they're calling legacy?"

They were like, "Well, actually no, not everyone is. There are some people who are quite happy with some of the systems. They talk about some of the 5% productivity increases they can have by doing something else, some changes to manual processes." That was the thing where we had to almost go back to the step one before you even think of starting on the journey is, is everyone up and down the organization actually bought into the fact that something needs to change?

Do they really understand the pain that is felt, maybe not necessarily in their department or division, but in other departments and divisions? Then understand the challenge that might be there for the end customers because of the fact that they're not able to deliver a more compelling experience. While customers might be satisfied today, there's nothing stopping the next startup coming up with and launching the next bright idea. While this was a client in the insurance sector, and they don't necessarily see that sector being disrupted at the moment because of all the legislation, and the pace of change that is very common or slow in the insurance sector. It's still something that you can't avoid. Maybe they can avoid it for now, maybe for the next five years, but I think you never know when you're getting disrupted, until you have got disrupted, and you're out of business.

Sam: We've seen that, right? We can give all the examples that we all know about from Uber, Airbnb, to others where you don't realize until it's done. The customer, the thing I love about being a customer sometimes is that someone would just come up with a better solution for you because someone's faced the same problem, and loyalty doesn't really count for much when the user experience is so good and so valuable to the customer. In your answer, you actually answered my next question, which was how do we begin and how do businesses begin?

Ashok: Actually, on the previous one when you were talking about some of the challenges. I think one of the challenges, actually a colleague of mine who has a lot of experience working in the public sector and they call some of the challenges blockers and describe it as the triangle of despair. Where, you have on one side of the triangle, you have your IT departments who might just believe that they are well equipped and have the technology that that is necessary in order to service business.

You might have procurement, which makes getting a launch contract just as onerous as procuring some post-its, and you might have governance that is focused more on how stuff is done, rather than what needs to be done. I think these are all not necessarily anything to do with the technology, but to do with the organization structures and processes that are in place.

By the time he left, they had added a fourth dimension to it and evolved the legacy challenge to include security and married the square of despair, but the problem necessarily didn't go away.

Sam: Well, I'm hearing you. What we're hearing is that the problems that you face, and your title says Head of Technology, but actually the solutions and the ways that we figure out how to work through this with clients, is not necessarily technology per se. It's people. It's how an organization is structured. It's communication. It's delivering a story to the whole business to explain, we are going on this journey together, and ultimately that's going to benefit the end user, the customer. We're going to have to find new ways of doing things as we go along as well.

Ashok: I think, coming back to the start when we said not all legacy is, is bad. For a lot of enterprises, when you start in the journey, I think one of the first steps we said was acknowledgement of the fact that something needs to be done. The second step in this, is that, it is a journey which the end destination isn't necessarily known. There's a temptation to perhaps create a plan which might be with milestones just fixed in there, but this is the change in mindset where you have to look at that as initial plan or guideline of where you want to go, and probably the first few steps of where you need to start.

Then, as part of creating the plan or the roadmap, there are three things for an enterprise to try and understand.

What are the kinds of things that you are going to forget? This could be technology. It could be processes. It could be tools. What are the things that we're going to borrow from, because there is still some strength in the organization. There is existing capabilities, whether these are technology capabilities or business capabilities that should be leveraged, and what are the things that you have to learn? This is where you've got to try and figure out new ways of working, perhaps, or even adopting new technology and trying to figure out how to integrate that back into the rest of the estate. Maybe, how to share information across the old and the new.

When coming up with the roadmap, having these three and keeping those as guiding principles. Every time you make a decision, trying to say, "Well, which one of these buckets does it actually fall into?", and then making sure that you're moving forward keeping those in mind.

Sam: I was with a client yesterday, and it was really interesting hearing about the journey that they've gone on since they modernized their platform as such. The interesting thing was, it wasn't a huge time spend on our part, and it was actually just a team of four people to go in and kind of figure out what the problems were. The client said that, "You would think that going on such a big scaling transformation would require hiring new teams, new people." They haven't hired anyone new. They've got exactly the same team of people because the core skills they had as a company and they're a technology company, but they had the core skills already, and it was just about giving people room and the time to learn new ways of doing things.

I think sometimes when we think about the legacy organization problem, if it is a problem, is that businesses might be thinking, "I haven't got the budget to hire a bunch of new people, or bring on new developers, and people who know how to do this already.", but actually, it's not about that, right? It's about giving teams room and allowing them to get on the change, as well.

Ashok: I think the people, and this is a common trap to fall into, where you overestimate the challenge that competitors have or startup startups have because you look at that in terms of how much does it cost you right now to provide the service with the systems and the processes that you have. Forgetting, the fact that actually if you were completely redesigning the offering and looking at some of the newer tools and tech available, especially from the cloud vendors, you could actually build a similar sort of capability for end customers to use for far cheaper. Actually, that cost can then trickle back to the customer for a service that's not only better, but actually cheaper to use as well.

On the other hand, you underestimate how much effort it is actually going to be to make the shift or change in some cases because the underestimation of the effort is more around keeping in mind the existing tools and processes, and like I said, you don't really give people the space to move and change the way that you really need to be delivering these services or making the changes in a new way. As you know, it's quite the bias that you might have, is very much rooted in the reality of what people are living in today, and it's like trying to almost lift yourself from that, and then understand the art of the possible. Sometimes do need somebody to help, so I think like in the example that you're saying, it might not need a lot of time and effort, but you need to be open minded, and if you don't know how to learn to build these things yourself, just make sure you reach out for help somewhere, even through other peers in the industry who are going through similar journeys because I find organizations are quite open nowadays to be able to share.

Sam: I mentioned the Ubers and the Airbnbs. There was a period of time, I think about four or five years ago, when I was in the U.S., and the term unicorn kept on being used all the time. I think there was almost a fear factor within a lot of these traditional companies that we're going to have to become that or we have to try and beat these. It's actually like, no, that's not what you have to do. As you say, not all legacy is bad.

Some legacy is fantastic because there's a history to the company and there's a trusted relationship with an existing customer that those new companies can't yet buy. It's invaluable. Really interesting you said this morning, was about in some sectors, and you gave the example of the insurance sector, and we don't want to give any bad press to the insurance sector, but it's about saying there is a change coming, and it's accepting that change is inevitable no matter what.

When we don't accept that change, when we've seen companies that have folded, where you would never have seen it coming if you were within that company, but it happened because there was just so much resistance to change. It's actually quite sad to see big companies fold when there was a fantastic customer base, there was a brilliant product, or a valued brand that people look towards, and it's just not there anymore. That's unfortunate, but it was because there was no acceptance of, "We must change our business."

Ashok: I was reading this thing about how retailers in the U.S. are responding to Amazon now, and how they're now realizing or even looking at what their strengths are. Target and Walmart realizes that their large stores are a great places to have their distribution centers, but they can quite easily, if they had to sell with online orders, they can quite easily do that. They need the systems and capabilities to extend to allow them to do that. Once they have realized that, they can take on Amazon on their terms rather than trying to fight Amazon. What is Amazon's actual strength? I think realizing that there's a certain value, this certain power that comes from understanding your strength and capability in the legacy, but figuring out the best way to actually leverage that is where the differentiation. In the end one day, journey comes through.

Sam: Any type of transformation requires just a little bit of help, sometimes. The example I have, I don't know why I'm thinking it in my head, maybe it's because I had a personal trainer, and I don't anymore, but that example of, if you want to make some sort of personal transformation, you're going to have to hire someone to probably just assist you in at least the first steps to becoming slightly different than we are today.

Ashok: I think it's the breaking of those habits is where someone like a personal trainer can come in and help you, or even help you to introspect and realize where you might be going because if you've been doing something, that can become part of muscle memory of the person or the organization.

Sam: We're quite resistant to change as a species, but once we know that we want to go on that change, whatever that might be, it becomes a lot easier. Of course, all of this is very useful information, but where are we going with this? What's the end goal in in sight for companies?

Ashok: I think the end goal, really, in this is about making sure that not just the technology is changed, but the tools, and systems, and process that are designed for evolution. That isn't really an end point because I think we're very, very used to the fact, over the last 30, 40 years of enterprise IT to be doing large projects and systems, and once that's done, everyone heaves a sigh of relief. Then, you sort of go away and you feel that you don't really have really anything much rather other than just keep keeping the lights on and then find the next big thing to do.

In Thoughtworks, we've been talking a lot about evolutionary architecture and this really has to form the basis of any technology, strategy, an estate for an organization going forward. You've got to embrace the fact that change is there. Changes is inevitable. In fact, it's not even new. Fred Brooks wrote a paper in 1987 that sort of described the fact that change is something that software systems really struggle to deal with, and it's something that we know of. I think as industry, we're now coming up with some tools and decrease in approaches that allow us to better manage the change. I think if organizations adopt a more evolutionary approach to building systems, I'm sure it'll help them adapt to whatever comes next.

Sam: Yeah. Transformation is not one and done, it's all the time. Ashok, Thank you so much for joining us and sharing such insightful stories with us this morning.

Ashok: Thank you, Sam.