Taming Complexity with Empathetic Design - Vasanth Sumanth

This talk focuses on the art of taming complexity through empathetic design, particularly in the context of Tesco's supplier invoicing platform. The speaker illustrates how the scalability of Tesco impacts millions of customers and suppliers, emphasizing the importance of understanding user experiences. The discussion highlights the need for empathetic design not only for frontend systems but also for backend architectures, as it influences the ease of system maintenance and user satisfaction. Key approaches such as the strangler design pattern and event-driven architecture are presented as solutions to manage modernization challenges effectively. By incorporating design patterns and externalizing configuration, the speaker argues that organizations can turn complexity into clarity, leading to more sustainable systems that cater to both user needs and technical scalability.

So, today's topic is art of taming complexity with empathetic design. So, let's start with a quick glimpse of Tesco. So, how many of you here knows about Tesco? Great. So, Tesco is a number one retailer in UK with over 100 years of legacy. It spans across Central Europe. And do you know it has its presence in India too through a joint venture? Any guess on the brand

name? It's a Star Bazaar. Yeah. So, you these are the key numbers which we have at Tesco. So, one of key somethings with respect to the scalability which I want to focus is Tesco holds 28% of UK food supply shares and more than 70 million shopping shopping trips every week. Speaks about the scale at which we operate. And at Tesco Tech Tesco Technology, we have over 6,000

technologists working on improving the experience of our millions of customers and colleagues by by solving real world problems using cross-cutting technology. So, at this scale, we are not just building software. We are part of people's everyday life. If you are confused, let me explain that explain that with a simple story. Meet Bob, a small farmer in UK who grows tomatoes and supplies it to Tesco. And Sarah,

a common citizen like anyone of us who is planning for a weekend get-together with her family and using Tesco app, she places an order with Tesco with an expectation everything will be delivered on time. And on the other side at Tesco, there's a lot happening. Based upon the demand forecast, Tesco raises purchase orders with suppliers like Bob. Bob receives the purchase order, harvests the tomatoes, and supplies

it to Tesco stores, and also creates an invoice with Tesco. And Tesco processes invoice, pays Bob. This cycle helps ensure our Tesco stores are stocked and ready to meet our customer demand. And on the other side, as we get close to Sarah's scheduled slot, the store uses using her order as reference, picks up the goods, packs them, and delivers it to Sarah. There is a lot of

systems working behind the scene to make this cycle look seamless. And how well this cycle works defines whether Bob gets paid on time, or Sarah had a great weekend with her family. And if something breaks, it can impact Bob's income, or can delay Sarah's order, which in turn can delay her weekend plans. Now, to this, if you add Tesco scale, like it holds 28% of UK food

supply chain, the impact is not just on Bob and Sarah. It has the potential to impact millions of people like Bob and Sarah. That's when you realize we are not just building softwares, we are part of people's everyday life. And there is a purpose behind what we design and build. I hope that clarifies when I mentioned we are we are part of people's everyday lives. Yes. They

don't like the one-to-one new orders. No, it's not a one-to-one. So, it's a it's a parallel activity. See, it's one of the parameter defining our demand forecast, right? Similarly, we'll have multiple orders, multiple sales happening. All that will define the demand forecast at Tesco. So, now uh coming back to it. we all engineers, right? Design and develop on a day-to-day basis. But, when you are designing a

system, it's not just sufficient we think as engineers, it's important we think as the people using it. That's where empathy comes in. So, empathetic design is not something new to our industry, but it's there, but it's widely used in our front-end design. But, according to me, it's equally important in the back-end design, too. Because when we speak about users, it's not just the business or it's not

us just our end users, the users could be our business users, the product team, the QA team, the upstream and downstream systems, the engineers your fellow engineers, and you yourself. Because the system that you are designing today, you might be maintaining it tomorrow. So, how easy or difficult it's to maintain depends on what you do today. So, at the scale of Tesco, empathy is not an option,

it's a responsibility of every colleagues. So, with that, let's look into a real example in Tesco of modernizing supplier invoicing platform and how empathy when combined with architecture and design principles became a very powerful tool. So, when we we saw about supplier invoicing platform in the example, it falls under Bob Bob's side of the journey. That explains how critical it is and what impact it can have

something goes wrong. So, invoicing itself is not a simple entity. It's a complex entity that is made out of multiple different entities like suppliers, deliveries, tax, cost, products. And on that, when we add Tesco scale, that's where the real complexity Like, multi-country, multi-domain, multi-format, 10,000 plus active suppliers, 30 million invoices processed annually, and billions of amount paid to the suppliers. And all these different dimensions bring bring

in an additional complexity, which we call it as rule explosion. We will look into it in detail in the upcoming slides, but for now, the question may come, with all this complexity, is it really required for us to do this modernization? Yes, the existing systems have done a great job in taking us where we are, but they have their own challenges. Like too many systems doing the

same similar things. No unified invoicing model. Rules are buried deep inside the code. And all this makes the systems hard to evolve and easy to break. So, it makes it clear yes, we need to do this modernization. And today we will see how empathy played a key role in this. But considering the time we may not be able to go through each and every design phases. So,

I picked up three key design phases and how people centric design made in a difference. Let us approach, architecture, and code. Let's start with our approach level. So, one of the first question which we asked ourselves as a team is what makes modernization hard at the scale? So, based on our discussion with business and our own engineering experience, four challenges clearly stood out, which is business anxiety,

reputation risk, unknown unknowns, and adoption resistance. So, one interesting thing if you notice is these are all is these are all technical problems. These are all actually business or organizational concerns. So, that's where the approach which we took it's important the approach should be here should be able to mitigate these challenges and not amplify them. So, what's the approach we have in hand? One of the approach

we can think of is big bang rewrite. what big bang rewrite says we rewrite the application all at once and replace it. But it might look easy and uh that or more efficient to start with, but there is a problem. There are three key challenges uh which it which it uh pops up for me according to me. So, first challenge is the system what we are replacing

is not a simple system. It's being there for 30 years and it's a mammoth in itself. So, rewriting it, we are going to drain our engineers effort in that. By that, you are not giving we are just completely taking away the place of innovation. So, there is no innovation coming in. So, doing such a modernization with no innovation is not a good place to be in. And

second, by this, you will bring in business at the end of the journey. Now, business feels they are not part of So, that bring that actually amplifies one of the challenge here. Any guess on which challenge it amplifies? Is it a technical? Yeah, business anxiety and adoption resistance. So, now since you're bringing at the end, they may not be ready to accept what we what we are

saying to them because they feel they were not part of it. And actually, yes. Indirectly, it impacts our business anxiety, too. So, this is not an option which you can go for. So, what is the option which we have in hand? I gave a hint before. So, it's the strangler design pattern. So, what strangler design pattern says? Instead of we replacing the system all at once, we

start building building our strategic systems around our existing systems. And over the time, we will slowly move the features out of our existing systems one by one into our strategic system. And thereby, we will be able to move all the features over the time and make the existing systems ready to be decommissioned. So, that's what strangler patterns offers us. And because of this approach, I do The

clicker is very sensitive. Yeah. So, because of this approach, what we can see here is since now we are going feature by feature, now we can perform parallel runs in production. Gain the confidence of business, show those results, compare it with your existing systems, show the results to business, and show them what benefit we bring in as part of this modernization. Then my now business starts feeling

they are part of this journey. Now, no more we are working in two different as two different teams. Now we are working as one team towards the modernization. So that's the best place to be in. And second, now since we are continuously interacting with our business, business might not be always able to every problem they have as their requirement. But now with our engagement with them, we

based upon their day-to-day process and what we are seeing it, we can see what problem they really have. So that's where it gives scope of innovation. So it's not just something has been asked to do as a requirement or be to be done as a requirement and we are doing it. Instead, now we are trying to understand the real problem of business and bringing in a change.

And the third, this is going to completely eradicate all the challenges. Is it true? If I'm saying so, don't believe it. It's not. Even with this, these challenges are there. But now they will come in a very controlled way. So by this, we can able to perform this mitigate these challenges in isolations and that's what strangler pattern provides us. It gives us more control. So one is

about using the design and the other one is it is about how efficiently we use them. So one of the key concept of strangler design pattern is its anti-corruption layer. So how many of you have done a modernization of replacing an existing system? Many of us, right? So what is the challenge? So there will be always a conversation which comes in, okay, because of my existing system,

something is not working in my existing in my strategic world. So do the change. That change has to be done in the existing system. Technically, yes, we can have a debate on it. But if you put an empathy factor into it, there is a reason why we are decommissioning this existing systems. So on that, now if you are giving more load to it, it's not the right

thing to do. So that's where this anti-corruption layer comes in and it's important we place them on the strategic side, what we are saying is the anti-corruption injection layer will help in ensure our strategic side of the systems are not getting influenced or not getting corrupted because of the assumptions and the inconsistencies what we have in the And at the egress side of it, now it helps

ensure the data's are fed into our existing systems in the way they understand. So, thereby allowing both the systems to coexist. That's where we say safe evolution through strangler pattern is an empathy towards our organization and our business. And safety stability preserved through anti-corruption layer is an empathy towards existing systems. Okay, can you give an example of this anti-corruption layer like what happened here? So, let me

say so as like we have the existing systems, they are working well. And now there is a specific attribute which you want to introduce as part of the strategic system. That attribute is not available in your existing systems, but they are working good because that is an enhancement you are bringing in or very well actual example is the tax rate as an example, they may not be

they were not present at the header level. They were present at the line Now, we want it at the header level. So, instead of forcing them to say, "Okay, you do you change your format and start giving the tax at the header level too." the anti-corruption layer will say will do like it'll aggregate the line level informations and it can bring in the header level information because

if we are not introducing something new, we are just playing with the data what is already present. Right? Because the existing systems are working. So, they don't want it at the header level, but now we are bringing in the standardization as part of it I want it at the header level too. So, there's no point in we overloading the existing systems because they are not going to

exist. Now, with this let's get into the architecture level. Just conscious on time also, yeah. Please. Look, why? But but it would Are you going to cover it thick? So, what we are saying is now, if you'd have done it the big bang, what would have happened? We are not taking So, you're you're putting your organization at risk if you do something wrong. Right? The big bang

approach what we said, it's going to amplify those Sorry. It's going to amplify those uh challenges what we spoke, right? That's not a good place to be in. But now it's triangular pattern, now we are mitigating them. So, that is an empathy which you are showing towards the Right? You are taking them along with their journey rather than saying you are at the end. Now we are

having a continuous conversation with them, understanding their needs. So, what empathy says, it's about being on the other person's foot and try to understand what they want and try helping in achieving that, right? Bringing in that. That's what empathy. And that's what strangler pattern Okay. At approach level So, now at the Sorry, at archi- architecture level. At approach level now we have taken a decision that it's

going to be an incremental evolution. underlying architecture also should be able to support it rather than forcing us to deploy all at once. So, we should be able to build capabilities independently and deploy them independently into production. That made us to lean toward the microservice architecture because with microservice architecture we can build the capabilities as services and deploy them in our own or based on how we

wanted it. So, even with microservice architecture because of the model is modernization scale, we have challenges like legacy and modern system coexisting, batch versus real-time processing because most of your existing applications will perform their operations in batch mode. And different phase of evolution because now you are building a strategic systems, every system is going to evolve in their own pace. Now, if all these challenges are not

handled properly, it can lead to problems like tight coupling, failure propagation, scaling bottleneck, and pace mismatch. So, we wanted to have a communication pattern a communication model that will mitigating these approaches out of the box. So, instead of we focusing on the cross-cutting concerns, we can start focusing on the business value. So, that's where we are looking for a communication channel a model which can help addressing

these challenges. Any any any guess on this communication channel? What could be the communication model that can help address these challenges? It's the event-driven architecture. So, what event-driven architecture gives us? Event-driven architecture naturally provides us the asynchronous communication. So, because of which now your systems are decoupled automatically. And also one of the resiliency what event-driven architecture provides us is its is its capability to handle back pressure

out of the box. So, now it since it can handle back pressure, now your services can scale independently and the characteristics of one service is not influenced by your upstream or downstream systems. What I mean by characteristics is the NFR. So, that's what Venkat mentioned in this discussion, right? Instead of calling it as an NFR, we can call it as a characteristics because non-functional use a very

negative meaning there. So, that's what it provides us. And with event-driven architecture, these are the advantages we get like loose coupling, improved resilience, better resource management, and pace alignment. Because what I mean by pace alignment, now every system can work at their own pace because the back pressure is handled by your event your the eventing pipeline. So, by this your systems are not influenced, like if you

are inbound says that it can process the transaction at 10,000 TPS, it doesn't mean that the the system that is consuming also should perform at the same pace, wherein my business requirement says it's sufficient I do it in 500 TPS. Right? So that's what event-driven architecture provides us, and that's where we call event-driven architecture is an empathy towards upstream and downstream systems. Because we are not forcing

your upstream or downstream system to change because of how my the surrounding systems are working. So now let's go look into the next one, which is at code level. And this is where the real shift happens. Because whatever we have designed so far, this is where it gets turned into everyday experience. Because the code what we write is what is going to directly decide whether it is

easy or difficult to understand, evolve, and maintain your application. Right? So this is this empathy has a special place in in me at least, because this is an empathy that you're showing to yourself it's about the engineers who has to debug the system at 2:00 a.m. Or it's about the developer who has to extend our solution after 6 months. Or it's about the team who has to

understand what we have done today. So all these if you're not considering in our design or simplifying it in giving a clarity in our design, it's it's equivalent to we are making our own life harder tomorrow. So one of the key problem what we had with code level is rule explosion. And today we will see like how what what is the approach we have taken to bring

in an empathy and what benefits it provided us when we when we made it more people-centric. So what is rule explosion? So we have invoices, and there are about 110 rules that has to be applied on every invoice to ensure the invoice is in the right state before it could be matched and paid to the supplier. But now when you add dimensions to it like country, invoice

type, invoice domain, invoice category, the behavior of the rules changes. Now suddenly the combination which starts as 110, now it becomes 4,000 plus. That's what we call And this complexity reflects our business reality. So we do instead of so if you don't if you don't do it with care, it can lead to cyclonic coding. So by this now we are forcing the engineers to remember everything instead

of reasoning things. So we don't want our engineers right? Tomorrow if someone wants to get into the code, they should not be trying to understand the if statements, for loops. It should not be very cognitive. It should not be heavily cognitive. It should be less cognitive as possible. So that's where instead of we fighting the complexity, we want to bring in structure to the complexity and for

that we heavily dependent on design patterns. So we didn't use design patterns because they exist, we use design patterns to bring in structure, extendibility, and also maintain the complex to manage this complexity. So one of three design key design patterns what we used this state, strategy, and factory. So but there are many other design patterns. So considering the time I'll not be able to get into the

details of this, but these are the patterns really helped us. But just using the patterns was not sufficient. Because one thing that was constant with this modernization is the changes. So we spoke about those 4,000 plus configurations or the ways, the rules, the the behavior of the rules. With business and product understanding the system, understanding of the system gets improved over the days, the changes that they

will ask us to do will be more. So for every each and every simple change, we don't want to touch our code. That's where we want to a further more enhancement to it. So, we thoughtfully took a decision to say my configurations will define the behavior and code will just interpret it. So, that's where we moved all our rule configurations, our rule behaviors as configurations outside. So,

I'll explain this with a simple example to get into it like how it would have looked at three different stages of us. So, before that is this configurations clear like you're able to see it? Are you able to see any hidden design patterns here? In addition to what I spoke before like strategy, factory. In addition to it, are you able to see any design patterns? So, if

you see you have the composite in our team we discussed the design patterns never come in isolations. They come as a team. We just speak about the team leads. But the delivery is done by the people who are working under it. So, it's the group of design patterns that gives a structure to our code. It's not just one design pattern that gives a structure. So, let's look

into a real example. So, we all know about the receipts like we have went to a store, bought a bought a bought some products and we get a receipts for it. So, receipts has the product what you purchased, the quantity of the product, the unit price and the total amount that you need to pay for the product. So, it's important we ensure the quantity times unit price

is the total amount. Else, we should we should reject that invoice. So, this is one of the rule. So, let's see if we have implemented that rule using those three stages like not following any patterns, following a pattern and pattern with external configurations, how our things would have looked. So, we also know the rules because of different dimensions what we spoke, we may need to do it

18 times because 18 different categories. So, if I if I do it without any structure to it, I might end up having 360 lines of code and And logic getting repeated in 18 different places. And tomorrow a small change like changing my rounding tolerance, I may need to do it in 18 different places and it becomes really unmanageable because of the complexity what we are seeing here.

And now when you look into the design pattern side of it, we brought in structure. Now we will have rule as an interface and this particular rule as an implementation of this interface like line amount mismatch. And now we will have all those configurations as strategy beans. Now these beans are Java classes wherein you will have the different rules that needs to be executed with the parameters.

And and these strategy patterns will be fed into your uh universally fed into your validation pipeline. But even with this, if I have to do the same sort of tolerance change, I need to different I need to touch it in 18 So that's what we wanted to avoid and that's where we move towards the configuration. With respect to the configuration, it's all the same but the only

difference is now all these strategy beans now as as become our configurations. So now these configurations at run time will be read by our factory factory class, create functional beans and these functional beans will be ingested into our validation pipeline based upon the invoice that we are acting upon. So that's the benefit it gives us. Now by this, if I have to do a change, the bis

our our engineers has to just come and change the configurations with no code change. What benefits it gives us? Since I'm not touching my code, no TD is required. Just with the behavioral driven test, we would be able to promote this code with more confidence and quicker. That's what it gives. And this is how our overall estate look like because of the changes what we have done

or because of that approach. So now from 100K lines of code, now actually we are having only 12K lines. So this 100K lines is more from based upon what AI because using AI we just asked it to write without giving a structure if you are doing it how it would be. Right? Because we have actually approached that level. From a duplication, it got reduced from 95 to

zero. From adding a feature, previously, every feature takes the same time. It's about 3 to 4 weeks. And according to me, it's even more. As we add in more features, the time it's going to take is going to be actually Now, if you go to stage three, initially the feature the first feature what we developed took 2x time because now we need to understand what is that

we are trying to solve, use the right design use the right design patterns, bring in the structure, ensure the team is aligned to it because that's where the resiliency is required. So, when you're using design patterns, the initial phase the engineering resiliency is required because sometimes people feel overwhelmed and they just lose the track. So, it's important as an engineers or engineering leaders to ensure our teams

understand it and follow the process. But once after that initial phase, we are able to bring in this feature which is very faster because now I have to just change my ML configuration or add a new ML configuration. I'm not touching my code. And that brought a lot of challenges and now our improvements. And also now we had time to bring in business values. So, though now

I say it made manage it made adaptable for my business or for my engineers, still for my business and product managers, it's a black box. They are still dependent on the engineers. So, for even for every decision like how a particular invoice works, why certain things happen, they are dependent on the engineers. So, we want to bring in an innovation there and change that behavior. one of

the very powerful and cool emergent feature that came out of our design is the transparency. Now, since our configurations are externalized and configurations defines my behavior, now what we decided is we want to serve these configurations as tree structure into our UI and with tool tips which explains what those each rules does. Now we are able to we are able to make bringing the clarity. Now by

this now business looking into this configuration or looking into the UI understands how their system works. So no more they are dependent on the engineering team. So they are able to take decisions faster and that indirectly enable the engineers. So what is one thing we all as developers feel is a is an blocker for us. Or we see what is the concern we all as have as

a developer. A normal concern would be focused coding time. And why we don't get focused coding time? Because if you're not giving the clarity to the business, they are always dependent on us. There is a lot of questions comes to the developer because that's where the detail is and that's how things are being done. And if you're not bringing the clarity, they are dependent on us. So

you have to spend time. Now since we brought in the clarity, we have got a lot of time and we were able to bring in a lot of other advantages, but considering the time, I'll not be able to go through it. With that, what I have to say is pattern made the systems extendable, configurations made the system adoptable, and transparency made the systems empathetic. So when systems

are empathetic, they don't just scale technically, they scale organizationally. So key takeaways is design for people, not for systems. Empathy turns complexity into clarity. So that's what we saw like the by just bringing in the UI, it made it brought in a lot of clarity for our business. Speed matters, but sustainability matters more. Because in the era of AI, we can do things faster, but if they

are not maintainable, it's not going to help us as an engineers. So that's where empathetic design is matters more than any time before. So with that if I have to design if I have to define empathetic designing systems by placing ourselves in the position of people who will use, operate, and maintain them tomorrow. Thank you. So, if you are interested in a career in Tesco or you

want to know more about Tesco, you can use this scan this QR code. considering the time, I'm not be able to take the Q&A, but you can reach me out in LinkedIn, open for a discussion over there. Thank you. Thank you all. >> [music]