Designing & migrating an AWS-native mobility solution in an M&A setup

Raja Rajat Sharma: Hey, hello everyone. My name is Raja Rajat Sharma. I lead the Platform Business and Growth at Zensar. With me, I have Tapa Samantha, who is the CEO of MSDs Stalls. We are going to talk about a very, very interesting case study today, primarily focused on building a cloud native enterprise and how the cloud native enterprise help seamlessly go through the motion of merger and acquisitions and divestitures. So I will invite Tapas to talk about the MSDs Stalls journey and we will take it on from there.

Tapa Samantha: Hi, thank you, Rajat. Uh good afternoon everyone. I'm Taus and I'm the CEO for MSD tolls, which is a portfolio company of Shell based out of the Netherlands. And today I have the distinct pleasure of talking to you and sharing our story about our digital transformation. And uh so we'll go through uh we'll, we'll talk about how we started the journey. So let's set the stage and let's give you some more context and the frame of reference of how it all started.

So MST tolls is a leading payments provider to the commercial road transport sector in Europe and, and we have for long for, for for a very long time, we have embraced digitalization and technology at the core of our DNA. However, we also have a very strong commitment to stay ahead of this technology evolution. And our decision to go into, you know, transforming our legacy application into cloud native development was rooted into this commitment.

So what i'm going to talk about what you see on the slide are some of our major milestone decisions. And one of that was finding in sio partnership with gens who supported us all throughout this journey. And the second important milestone was the business being acquired by shell in 2022 which kind of added a very different dimensions to our business and to our transformation journey.

So um if you look at what was the reason for us to do this? We were uh we were our legacy applications, which was before we, before we were cloud native, our legacy application which was pretty function rich, which was had a very great user experience, but it lacked when it came when it comes to scalability. And that was one of the reasons why we went into. We started looking at transforming our, our legacy applications into a cloud native application. Plus additionally, at the same time, when around the same time europe was warming up to gdpr. And if some of you have worked with implemented gdpr policies, you can, you can, you can really understand how challenging it was.

So um so yeah, a compliant data management with our own set standards of superior customer user experience, pushed us to take some bold technology decisions. And the other thing is that europe as we call it as one continent, but it's a very multicultural multilingual setup. And that also adds certain different dimensions to the soul equation.

Now, here you see the technology decisions that we take that we took, i will not dwell upon all of those points because most of them are kind of standard in terms of cloud native development today. But i'll draw your attention to the purple cloud. Well, at least it looks purple to me. So this is basically the dream that we are still pursuing in terms of building high velocity enterprise dimensions.

Now, my colleague rajat is going to talk a bit more in details when he, when he speaks about what we did. But for a plain business guy like me, it's all about being able to run fast and the ability to rise safely when we fall. So our transformation in the cloud native application actually really helped us in our speed to market.

Now, to pursue our objectives, we started defining our development principles. And one of the things that we really focused on at the outset was defining our domain, our microservices domain to replicate exactly the needs of our business and the operational model of our business. And and then to, to suit our business requirements, we chose the technology stack. And one of the things that we did, which was meticulously defining the inter domain relationships, which was really important for us to get the best out of this transformation journey.

So i'm very keen, uh actually, i'm very keen about talking you guys about some of the learnings that we had during this journey. Now, one of the things that we learned pretty soon into the development was our a p do not solve everything, for example, to serve our microservices domain microservice architecture, we started building a lot of a ps and at some point in time, it got pretty overwhelming for the for the development teams itself. And as development teams were working, you know, on on different domains parallel. So there was a lot of effort duplication which was happening.

So we realized that and then we started fixing the the api redundancy aspect as technical debts. But there were also other other issues that came across while we were while we were in this journey. And, and some of the things you see on the within the circles here on the slide. And then we took on to the native aws resources to solve some of these some of these challenges.

Now, while we leveraged on gen sar's ability of global delivery, we also leveraged on some of their frameworks and methodologies and i'll let rajat speak in more details about it over to you rajat.

Raja Rajat Sharma: Thank you. Thanks for taking us through the journey i must emphasize on one point with which we started. And that was the cornerstone of success of the whole program of forming a one team culture between msds stalls and zensar. And the vision of this one team was to follow the pod based model to build a cloud native enterprise.

If you look into the chart on your in front of you, it talks about the cloud life cycle management and we followed this particular methodology templates and processes right from discovery to strategy up to operate and optimize including your foundation and transform.

So unlike the other players who just focus on the technology aspect for msds stalls, we started with the business viability. And as tapas mentioned, we, tapas and team helped us work very closely with the business stakeholders to see what are their priorities in terms of independent device, agnostic payments, in terms of integrating with multiple third parties. It was hundreds of third parties because it was across europe and different standards for different countries and different governance mechanisms.

At the same time, we also wanted to specify the products which we are building so that the customer can consume these products on paper use kind of model. Also we built, took into consideration the human desirability aspect. And in that we looked into the consumer and how can we enhance the experience of the consumer to simplify the whole product. At the same time, look into the kind of flexibility they need to access the reporting and the analysis based on. And of course, in the technology aspect, I'm not going dwelling deeper. But of course, we looked into the technology currency, the legacy and the infrastructure to application dependencies and so on and so forth.

Looking into these three parameters, we defined the strategy and the strategy was very simple. We did not want to buy a product because there was no product suiting this. We went in and worked on building a cloud native enterprise primarily to create the whole environment which is built to change rather than a built for today. We built it for tomorrow. The things which basically we catered to in that is we did not just follow the basic principles of cloud native, which are primarily the seven factors api first or even things like your depth checkups. But we followed a creation of a composable enterprise.

What i might mean by composable enterprise is that where it is very, very easy and flexible to create new services, deploy new services, consume new services. And how we did it is not only just with infrastructure as a code which is traditional to cloud, but we basically created composable at every level. So composable everything right from application compos to data compos to security as a code to finally infrastructure as code.

So that's the concept which we followed through. If you look into that whole aspect that helped us build a, build a right foundation layer. And when we build that foundation, we actually looked into all the parameters of foundation. Be it the availability zones? Be it the network policies, be it the security policies beat the governance. And when we build the foundation that foundation we build, keeping in view that this foundation is going to take us to the transform and operate so that we can leverage the aspects of the foundation to actually create a seamless migration architecture or migration plan. That too at a scenario when we did not have any visibility on shells, governance, shells, technology standards or shells policy, right?

And this foundation then took us to operate and optimize. And the concept we followed in the operate is built to operate kind of concept. So from build to change, to build, to operate and the common theme was the foundation layer and i'm going to spend more and more time in the slides. follow up on the foundation side.

These are some of the templates and methodologies we followed and again, we had templates and followed templates strategy and all those components followed to also meet very stringent timelines of t sa. I'm going to talk about that also, let's first look into the migration approach, right.

So how we looked into migration approach is we did not just look into creating the migration waves or sequencing of migration right away. We went through a number of design thinking sessions with the client and the business stakeholders also. And since there were multiple stakeholders, one was coming from the devastating entity which was heavy in this case, then there were stakeholders from msds stalls and then there were stakeholders coming from shell.

So bringing all the stakeholders together to actually create a foolproof migration plan was one of the core charter which we followed along with as a combined team. And that also helped us in terms of creating the migration road map. But most importantly, we actually looked into defining the future state architecture. And one of the things which we followed in the future state architecture was the principle of building a very, very solid foundation.

Although we could not use the foundation which we built for msds because shell had a very very different foundation or landing zone. So we basically looked into three core tenets of building the foundation which is close replica of shell. The things which we followed was one is the processes. Second is the people and third was the tooling, the tool sets which we are going to take some of the tool sets and move it seamlessly to shell. And some of the tool sets we embrace from the shell point of view.

And of course, I don't want to get into the complexity of foundation, but it had all the core components right from security postures to cic pipeline to network policies and so on and so forth. And we followed all the aws well, architected framework standards to build that foundation.

Now, let's look into some of the challenges and this is very interesting because most of the times when you hear about a case study, you hear about all the great things we have done together. But I'm also going to talk about because we had our own share of challenges.

The first and foremost, as i mentioned, it was a very, very short time frame to migrate the workloads where the workloads were built using multiple databases. So we had oracle on one side, we have post grace, we have dynamo db. And at the same time, it had the experience piece on the front end side, on the portal and product side. On the back end, we still had a lot of transactions running which was basically, again, not easy to migrate of.

So what we basically, so two core challenges which we faced. One was as i mentioned, it was multiple stakeholders. So divest states are coming from, we pay so we pay had their own view on how this needs to be conducted. On the other side, mrs stalls had another way, our view about this and shell had another view and how to bring all the stakeholders together.

We used zensar mnd framework which had not only just templates and processes but also a methodology which was similar to your scrum teams or daily send up calls here, it was not daily, but of course, we try to do twice or thrice a week calls between the individual parties and then bringing all the parties together. And what worked out here was showing them the benefits of our approach and methodology. So everyone brought in in terms of the approach which can help them meet the timelines of t sa which was 3.5 months.

Normally these kind of migrations take almost 1 to 2 years and we crunched it out 2, 3.5 months of migration. The second challenge which we, you have a question. Yeah. So because in a typical amend environment, if you don't migrate, you end up paying the fees for the people who are managing the environment and it becomes very, very costly or expensive affair to you.

So the both sides for the private equity side also as well as for the shell side also. So from that point, so, so that was the timeline. The second challenge which we faced was primarily around what i've been talking about target state architecture. So how do we basically mimic the shell, target state architecture? And neither shell nor mst stall allowed us to do any automated discovery.

So we did not have any view of taking the snapshot of shells architecture and create a seamless foundation. So what we did is again, we used our templates processes and lot of manual work in terms of interviews to capture that information and built the complete foundation following all the stringent policies, the technology standards, the processes and above all the governance of shell because it was going to get integrated into. And of course, shell had a very, very different standards from security point of view.

They had a very, very different standards from the vendor management point of view. They had a pretty different standards from the network traffic prioritization point of view. So there were quite a lot of extensive standards which we work through along with the help of msds stalls. And as i said, this was a joint effort of one team.

So we classified this whole program as migration as a product, right? And we basically followed this whole, i would say best practices which we created around this migration, which helped us move seamlessly into a cut over in 3.5 months. So i'll hand it over to tapas to talk about the benefits we all gain from this.

Tapa Samantha: So as as you have heard through the entire presentation, so it it's a story of transformation which has its own challenges, a lot of challenges actually. But at the end of the day, when we were able to build our cloud native application, and then we were also able to migrate it from another enterprise location to the shell enterprise location within a short span of time. And i must say with zero disruption to business, i think that was one of the most gratifying gratifying thing of this whole thing.

So um you know, to conclude, i would say the entire journey of cloud transformation opened up a lot of business opportunities and possibilities for us. So, and i think we were really benefited with our own decision to go into this in this path. So thank you, thank you for your patience and thank you for spending the time to listen to our story.

We have got 1.5 minutes. If you have some more questions, we can take them. No, no, absolutely. Thanks tapa. And again, this whole case study is very close to my heart because most of the migrations, when we do, we try to bring more and more automation when we try to industrialize the migrations. But here, the scope of industrialization and automation was also not ample. Still, we met all the stringent timelines and brought in the automation from our methodology and frameworks. But any questions from anyone more than happy to answer here. Otherwise we have a booth at 576, feel free to come over to our booth and ask and we can probably dwell deeper into how we did it or any other questions specifically.