Mercedes-Benz Aftersales: A cloud-first transformation

Good afternoon, everyone.

A very well welcome from our side to this breakout session here today. We are, we came all the way from Germany and we are very excited to be here and even more excited to share the experience that we have made and gain throughout the cloud first transformation of Mercedes Benz after sales.

Hence, thank you so much for showing up in such large numbers and sparing your time to listen to our experience. And as far as we know, there are quite some people who couldn't make it here physically today and have to join us virtually through our content app right now. Therefore, thank you so much for listening in. We hope you enjoy it as much as we do down here having that said.

Now, before I just jump right into the outline, please give us a chance to introduce ourselves really briefly starting with the most important person on stage here today if I thank you for that.

So, hi, everyone also from my side. Um my name is Eva. I'm working for Recedes since approximately 10 years now. Um my responsibility in the after sales platform is mainly the overall architecture and the program management. I'm doing this approximately 2.5 years now. Um before that, um I was responsible for several applications and products within the after sales area. And even before that, I was working in the on premise data center in Europe with Mercedes overall, I have a background in computer science and with that being said, uh let me head over to Michael.

Yeah. Hello, everyone. Also from my side, it's truly an honor to be here today. It really is. We've been excited for weeks and um I'm Michael. I'm a manager here at Deloitte and the lead AWS architecture of the Mercedes Benz after sales platform, I also have a traditional computer science background. So started out as a system administrator. So really administrating Cisco routers center is linux and active directory controllers. Then didn't like that anymore. I switched to full development and now six years ago, found a new home at Deloitte and been doing yeah. AWS ever since and AWS exclusively ever since.

Thank you, Michael.

Hi, from my side as well. My name is Food Muji and I've joined Deloitte around about four years ago as a cloud architect and manager and have had the chance and pleasure to work alongside Michael and the team within the cloud transformation and cloud development practice in Germany. Ever since before that, my journey started quite young as a developer and a systems engineer in linux and have had the luck to gain experience in platform engineering and cloud application development ever since throughout multiple different consultancies and industries. And definitely one of the major ones being the industry here today. Automotive and the project that we are going to talk about now enough about myself.

Now let's get to the bread and butter of this session and what you can expect from us here today. We will kick it off with the Mercedes Benz after say its strategy and vision and explain the reasons why they started this to invite this cloud transformation journey. After that, we will delve into the key aspects of the technology and structure transformation and display, you know how we overcame certain challenges and how we made certain decisions and at the end to round everything up, um we will share the lessons learned we made along the way and give you the chance to ask questions or dive into short discussions with us at the end of the session.

So once again, thank you so much for being here. And without further ado, I'm handing it over to E a to kick it off with Mercedes Benz after sales strategy and vision. Thank you.

Thank you for that. Then uh let me give you an overview about the Mercedes Benz after sales it version strategy. Um I will do this with two concrete examples. One is service contract management systems where I used to work before I joined the after sales platform team. And we will make a small x curse into e sports with league of legends. We are not only Mercedes is one of the main sponsors. AWS is one as well. Um also the quick shout out to the colleagues from riot. They have a session tomorrow and I think they would be happy if you joined there as well. Yeah, so overall, the Mercedes Benz after sales, it strategy is is an essential part of the digital customer experience journey. Overall, how do e-sports and service contract management systems do anyhow match here? Let me explain you that um league of legends world championships were some weeks ago hosted in south korea. And uh there was uh in addition to this, the so called worlds. In addition, there was a, a watch party event in berlin, which was also sponsored and organized by mercedes. Um the one of the major topics there from me was they have organized a paper chase and doing this paper chase. You were able to win a test drive as one of the prices there. And now I imagine you are on a watch party, watching uh watching world and you win the test drive, you register yourself and after that, you decide that you want to purchase this car and then you go ahead, you have purchase this beautiful car and then drive around having fun with your car and then very warm welcome to the after sales customer experience journey. Um so one rule of thumb, which is an essential part of our strategy is never asked the same question twice. And um yeah, just imagine with upcoming worlds in next year, um we already know that you love league of legends and imagine your mbux screen will directly appear during the world's event in the league of legend skin. How amazing would be that? And if if you have bought for your shiny new car, a service contract, then you are part of service contract management systems.

Yeah. Uh staying with the service contract management systems. How did this look like approximately two years ago? So let's do a little time travel and travel back to 2021. Um I was working for service contract management systems during that time. How does it look like? Did it look like? So we had super close silos and we had something which we call a little bit like real end to end perspective. What does that mean? You are responsible for everything? Starting with the deep infrastructure, be it framework, architecture, uh guidelines, uh etcetera. So um one of the small advantages is like you can take independent decisions, you just have to go to your hierarchy and say, hey, I want to go this way or I want to go that way and if it's approved, you can do whatever you like. So um of course, this has also disadvantages um this overall results into solving the same problems several times. Be it in middleware, be it infrastructure, be it compliance? Um yeah, additionally, um things that happened. Um so imagine before, before the covid crisis you went into the office, grab some coffee, have a quick coffee chit chat with your colleagues. It's like, so hey, i implemented this and that last week. What are you doing? What are you doing currently? And the answer? Like so, oh, i have implemented the very same, a little bit different, but it's the same in the end. Ok, nice. Thank you. Have a nice day.

Um so to summarize it up high redundancy all over, but not only from a technical point of view, we observed this high redundancy. Um also if you look into processes and administration, the tasks and efforts, they were super individual, super specialized designed for each, for each closed silo for each app. And it's not only applying for service contract management systems, you could observe this behavior in the complete after sales it area. There was so much potential for shared services. We will come to this uh later as well. Um but they are not used with simply individual uh a decision, close silo implementations all over, but how to solve the 2021 issues.

First of all, for me, it's crucial that you understand that implementation of new technology as such is absolutely insufficient. So if you have seen the holistic customer journey point of view, the same applies here, you have to create a holistic, holistic change. So not only technology, so Michael will get um we will guide you through that our presentation in a way that we will first show you our technology transformation, which Michael do and then we will continue with the structural transformation, which will take over so that you can get a holistic view of what we changed beyond technical implementations. And we will finish up with our lessons learned, but um let's travel back in the here and now uh let me spoil you a little bit what we have achieved so far.

So um I think we are in a very good way that we are. Uh we have done a holistic transformation. Um of course, we had outstanding management support from all companies involved and we managed to go live with our after sales platform in less than six months. And this is really amazing. Um I think we are on a very good way of breaking the silos. We have one platform, we have one stack, we have one something which was really, really amazing to, to observe from my side was um the community based, know how sharing. So we have a lot of colleagues without further involvement, they meet up once per week, twice per week, sitting together and sharing their experiences with our platform like, hey, what have you done and so on and so forth and they are, they are self organized user groups. And this gives me always like a little bit of feeling. This is more than a platform, this is almost a movement and it feels like you're a little part of a digital revolution.

So let me take the time as well to give a quick shout out to my former colleagues from service contract management systems because they migrated everything into the after sales platform and they went live with all markets in less than three months, which is really amazing, Michael. Do you want to tell us a little bit more what we have achieved from a technical point of view?

Sure, thank you so much, Eva. So when we were tasked to design the architecture, one of the requirements was also zero overhead, which is almost as easy as zero redundancy, right? I mean, it's incredibly hard, it's almost impossible, but we can very very close. So we provide to the applications, a stable platform, we provide shared services and that doesn't mean that the teams cannot make decisions themselves anymore. They are supposed to innovate, right? But it just means that the feature teams, they can fail faster, right? So they can try out different approaches in a stable environment with stable sheds services and find their best approach. And of course, we still have in service contract management systems, we have different configurations because it works very differently in China compared to Western Europe, for example. So we have configuration based rollouts which allow for these customizations while still maintaining one stack.

Now, now let's really dig deep into the technology. So this is a 300 level session. So we're gonna go deep on technology today's safety verus azure. So if you get confused at any point, raise your hands, yell out azure or whatever it's called. Now, we'll fix that for you. All right.

So I promise technology and now I bring you a consulting slide. I'm really sorry about that. Nevertheless, no worries. Thank you. So please bear with me. We really believe this is very important. So if we would apply, if us and real end to end responsibility to the cloud stack, that would mean you would have a cloud team for your application. And there will be one person discussing subnetting, a second person will be discussing s versus ecs far. And the third person would actually argue which model we're going to use in bedrock. And if those three people are in the same meeting, it's going to be a very, very long call. So this is why it is our opinion and also that's best practice by AWS to actually slice the cloud a little bit in multiple layers of responsibility.

So we start at the bottom with our cloud service provider, which is AWS. That's kind of the point why we're here and AWS gives us a lot of cool things, gives us data centers, gives us the electricity and cooling for it. And all of these amazing services that we've been hearing the last two days already about. And now if we imagine the account provisioning in AWS like a conveyor belt. So from AWS, we get an empty AWS account and they say you can do whatever you want with this. And now we have a foundation team that provision services into this account. So the foundation provide services that add the application every use case needs. So that's really networking, dns that security services, this is also where AWS organizations and security hub comes in and we get a lot of stuff here already on this base layer and then the responsibility here ends. So these services are configured for your account and then the account is handed over to a domain specific platform layer.

So domain specific means there can be more of more than one of these platforms. So why would we do it like that? Because I think every company that you work for in here has domains that have very specific requirements

Just imagine in Mercedes research and development doesn't really have to care about GDPR compliance because they rarely use like personalized data. But in after say that's very important and or if you have like a industry 4.0 platform, they probably need centrally configured io core. We really don't need that in the office. So even though you have multiple of those platforms where you provide additional services to the application teams, you can still strive for serious redundancies.

Now our fictional account where we, for example, provide a central cos cluster is configured and then we hand it over to the application teams and we grant the applications a lot of freedom when picking their services. So we try on every layer to enforce as much security as necessary, but give them as much freedom as anyhow possible.

Now, if we go one step further, finally, some aws service symbols. So ok, we're getting deeper into the text. So finally, we're getting into the technology, this is what the after sales platform looks like. Um so we started at the bottom again, cloud service provider still aws then comes our foundation layer and i already said, so the foundation layers maybe in your companies, they could look different, right? So there are still different requirements for different companies when it comes to foundation, for example, we have centrally managed kms keys for a bunch of reasons we can discuss later, but you might not have that for your particular use case.

Then we become 11 layer above we have the platform layer. So this is actually what we've been mostly been working on. So we have a centrally managed co cluster which we're gonna dig deep into in just a little bit. And then we also provide terra farm templates and also get up template repost for the teams to actually set up their own es target environments, for example, or other modules for different use cases.

And then if there are some people in here working for old companies, let's say probably all of you have to deal at some point with legacy file transfer, right? which is always a huge pain, which is why we provide it centrally on our platform. And then on top, we have the applications and you already see there's just some examples of of a of services that do platforms or the application teams can actually provision themselves.

So that also supports the def shift left approach because yeah, you build it, you run it right. So whoever sets up the service is responsible for it, but you can see we have the central cerni cluster in the platform layer. But if we have larger teams or very experienced certis in aws teams, they can also get their own cluster. That's not a problem.

So um it's just a different offering also already mentioned, even though we actually do have multiple platforms here, we can still strive for zero redundancy. So we have for all of our platforms, we have our central data dog, we have central kafka. And of course, of course, a lot of inner sourcing when it comes to terraform, like nobody needs to develop their own s3 module anymore in terraform like this has been solved quite a bit now. So this is shared responsibility on the high level.

Now, let's go one story deeper. Now we are in our shared coded cluster. So we are applying a concept called name space as a service. That means we have a central account with that is provisioned by the aws by the platform team. And we actually set up aws eks there for the teams. And when the applications get on boarded there, they already get a lot of stuff in there.

So we have an ex controller that they don't have to worry about. We have calico caver for the policies to isolate the applications also from each other. We have open tele preconfigured and the applications get their own name space. So hence name space as a service and there are roads are really scoped to the name space. So they are administrator within their name space.

So they cannot have any cluster wide permissions with some very small exceptions. But here is where the a w aws concepts and co concepts clash a little bit because we have the issue that for a w the border of a tenant is kind of the account, right? So it's multi tenancy within an account. I see a couple of smiling faces. Yeah, probably everybody has experience with that. You really don't want to do that. But on the other hand, co it is, is really it's a central component, right? It's container orchestration and you have multiple of these name spaces within one account.

So how do we solve this and using aws ram? So the resource access manager, we can use the secondary ciders here, that's where our ports live and we can share those subnets with a dedicated application team account. So these teams here on the right hand side, these this account, sorry, on the right hand side, they are actually owned by the application teams and we're simply sharing the subnets with them.

The cool thing about that is that you can then see in those application accounts, you can see the subnets, you can deploy your aurora services in there or you can use your amazon mq etc, you're in the same networking space, but you are protected from other teams influencing your resources and you can do pretty much whatever you want in those accounts within our guard grades, of course, but you can use almost any service which again supports the strive for innovation for our applications.

The other cool thing that's just kind of a side effect of name space as a service, our nodes are very well utilized. So if you've seen approaches for deployment cluster as a service, so that also works and it's also a good approach, but you have a lot of stuff running multiple times, right? You still need in every cluster english controllers and kno so you always have like a base load and we don't have to deal with that here because we only have a couple of clusters, but those are huge clusters, right?

So there's always a trade off now. I already spoiled open telemetry. We're really excited that we get to use it. And eva tells us now a little bit why we can use it. Yeah, let me be your captain obvious. So besides the it i say strategy, of course, we do have an overall it strategy, right? And one essential part of that is open source is the future of software development. And I couldn't agree more to that.

Maybe, you know, it, mercedes is also a member of cncf and was just recently awarded as a top end user. So the decision for open telemetry was basically a no brainer. What was really jamming on top is the vendor vendor neutrality. So we have a compatible so open to me is compatible with a wide range of tools. So we can reduce our vendor lock in.

Um but not only from a strategic point of view, the benefits of open to the mery are really amazing. So as you can see in the slides, we have a super good features, not only for performance but as well for the behavior of our workloads overall. And of course, we have a super seamless integration. We have a lot of aws services.

Um we heard a lot about ek about eks from michael, but we have also ec2 workloads uh and uh they are seamlessly integration as well. So, um the scalability of course, is something with his merch merch mentioning. And of course, what is charming as well um is the possibility to create or to observe cost savings and improve our resource utilization? Yeah, michael, do you want to show us a little deep dive into that?

So this slide and the next one, our deaths are extremely excited that we get to show this here. We know that looks complicated. That's kind of the point because it's it's a technical session but and we're really happy that we can share this here. So um maybe show of hands who here in the room is using data dog also quite a few and who is using open telemetry.

So a lot less people using open telemetry. That's also why if i had to fight really hard for us that we get to use it. And we are using the open source implementation of open telemetry for eks here. And I'm not gonna lie. It is more work than using the data dog agent out of the box. It just is.

Um but now we're really happy with the results because we get a lot of goodies out of it. So we're still at shared responsibility by the way. So that hasn't changed. We're just going one level deeper and we have a central coordinators name space. That is where we setting up our hotel collectors. And we are setting up two of those, we are planning more in the future, but we use setting one up for metrics and the other one for locks and we're collecting the logs and metrics centrally and then we do some enrichment, some compression buffering and the metrics we sent to data right away.

And with the logs, if the teams are logging to standard out or to standard error, we are actually sending them back to the team name space where we have a, let's say open telemetry gateway, we do this so the teams can use their own api to send the logs. All right. And this is blazing fast and scales really well. Of course, you don't have to do dns or some kind of network traffic because everything is happening within your cluster.

Of course, no, this is how we deploy this. So we're using operator patterns in copan is and this is truly awesome. We're not allowed to say so much of awesome, but i already said it's hard to implement, but now that it works, it works really well. So it's indeed awesome.

So yeah, so we, we have to operate a pattern and we can have a simple feature flag that actually influences the deployment pattern. So we have for the metric scraping, we have a state full set because we still want to do some buffering on the notes, right? But we really don't need it on every note. And for the apps, that's really cool because if they are exposing a slash health c or slash metrics, end point, they have the metrics automatically in dated already without doing anything. They just have to provide the end points and the second thing is for the actual log gateway or for the log collector, we are deploying that as a demon set because if you are logging to standard out or to standard error that lands on the notes and the teams really don't have access to the notes because they only care about their name spaces.

So we are scraping those logs for them. And this is only a simple feature for the operator deployment. And the third or the deployment pattern is the teams also have, as i already mentioned this hotel gateway. So they can use their own a p key to send their logs. They can use the same operator and just use the side car deployment. And they're done also, if they are following our best practices and logging to files, then they don't need our gateway. They can, they can just run inside car.

So this works really well in coins and now we are coming to two. So shared responsibility once again applied. So we have the central platform team baking custom a s we do some hardening but we also install the hotel, the hotel agent on the twos or into the am. That thing is very, very flexible. So we actually send some metrics from the ec two instances to data do but also to cloud watch. So we can do some custom auto scaling here.

And yeah, so as i said, even down into the co classes or into the a ms, we can apply the shared responsibility model model. And now that being said, there was a lot of technical stuff and now as if i said technical is not enough or technology is not enough food will guide us through the structural transformation.

Yes, thank you, michael. So before i jump into the next slides, it's very important to highlight once more that the shared responsibility model as it was introduced by michael was not only being applied on the technical side down to the deepest level where the code is, but also on the organizational side where the people are. All of a sudden, these people within the organization were facing new collaboration and communication effort or new responsibilities in places where it hasn't been before.

And in order to enable the shared responsibility model effectively, to help with these mentioned challenges and to break out of the silos, as they were mentioned by i a, we were looking out for a framework that helped us doing that and now coming to the structure and transformation, the framework of our choice being safe.

Um save one of the more known agile frameworks out there and probably being applied to dozens of organizations of people sitting here today really in its essence, provided the principles and tools and the overall landscape that we needed to overcome. these mentioned challenges to enable the shared responsibility model successfully. And yeah, foster the collaboration in places where it hasn't been before.

And as you can see by the slide alone, the safe framework in itself is quite complex and i'm not going to talk about it. Otherwise we spend hours here. Um as you can see, it's quite complex. And in order to ease the complexity of yet another of yet another um framework towards the organization, we decided to take it a little slower and implement it in a step by step manner.

What does that mean? We as the platform team and us three being part of it uh decided, you know, to cherry pick some of those principles out of the framework. So we started with prints with dailies with other simple ceremonies and established quite some supporting functions and roles as well like a system architect who guides us along the technology transformation or released an engineer who helps us understand the safe framework along the way.

And you know, when we, when we started getting used to these principles, we adopted more and more of these and one of the major ones being the p i planning, uh the p i planning for those who don't know what it is. It is basically one of the major cadences within the safe framework where you plan the product increment for the next three months and related teams that have or should work together, come together and discuss dependencies, discuss risk and plan objectives together.

And yeah, when we started using this and we started doing the p planning. It actually happened during the, during the time of crisis, during covid. So we had to do that all of that online instead of meeting up and just to share some experience of it maybe back to michael. And if, uh how was it for you guys?

So that's actually our real board back from two years ago. And that was, it was just weird because none of the deaths had met in person i hadn't met for in person yet

So nobody really knew what was going on. But it was, yeah, it was a start and then we just started planning our objective. So yeah, let's try what we're gonna do the next six weeks. And when we started discussing, we came up, we need xyz. Where do we get that from? I don't know, we have but I have a dependency. Ok, let's raise it as a risk. Ok? And that actually happened a lot during the first p planning. Everything that we didn't know was a risk pretty much.

And then we planned the first three sprints. So it was like a mini p and then handed over those, those risks and dependencies to e and said help, please. Where do we get this in mercedes? Yeah, basically you can summarize it with, deal with it. So um there were only two possibilities like accepted or own it. Um basically we had no idea how, but we accepted that we accepted the risks. Uh yeah.

Um in addition, no one would have ever thought that we would go live in six months. So there were a lot of doubts and so we were sitting there like so, ok, um let's deal with it. Uh surprising uh was really uh the confidence vote. Uh so we used the confidence vote uh from a scale from one which is very bad up to five, which is nice. Uh and it was totally confusing that we got a confidence vote result uh almost around four. And I could not even imagine why, where does this come from? So we were all a little bit confused. Why is this confidence so high?

So we were so confused that we decided to adopt a red panda for all the for all the colleagues. Just to describe our level of confusion and then we discussed it if we can maybe hand the red panda over to the management to get a little bit more support. But luckily it was not needed, right? It was, it was. But even, you know, the safer were being quite new to us and uh quite, you know, stepping into the unknown, um we were starting to get used to it, you know, cadence. After cadence, you start adopting more and more principles and you start getting used it. And after some time, we reached the level of maturity of the platform where we started on boarding applications on the onto the platform. Technically and instead of just on boarding them technically onto the platform, we decided to take a leap and teach them about the safe framework and guide them into our release train into the our safe framework as well.

And yeah, as it is with uh successful frameworks within organizations, more and more teams joined our, our framework and we had an additional release train uh joining us with their own set of applications and their own set of supporting functions and roles and et cetera. And that's more or less where we are today and just to reflect on how we changed over time when we get back to michael and if a to show you what you see here.

So that's our last board while it was still empty. Um this is now awesome. Um also for all the development team. So it's now p i planning is 2.5 days and the day before the actual planning, we have a developer system demo and every team gets like 20 minutes or something, 20 minutes, 20 minutes and where we really present the results of the last three months down to the telephone code or down to the lambda code or whatever. So it's actually just a presentation for the depths from des and they really like it because they are usually really in the trenches and working for three months and every few months, they are coming up and get to present the cool stuff. They've been doing and that actually worked so well. We were just doing it for ourselves. And then people were just asking can we join and also management? Like, can we, can we see this? Is it ok? And then last year, we had hundreds and hundreds of people just watching because they really like actually seeing the technology evolving that we're building and then the actual planning.

So you see a lot of team boards there where you define your objectives and also try and estimate your your iteration slash sprints. And to be honest that it's a lot of work actually preparing this. So it's a lot of work before the p planning. But if you do that well, then you can really dig deep into the objectives and define dependencies and ready plan very well ahead. But now that we have to release trains, we still have a lot of dependencies and risks that we have to hand over to e then at the end of the day.

Yeah, nice. Let me, let me share my very personal experience with the dependency board. So the first huge dependency board i have seen with all the sticky notes and all the errors and all the complexity. I really hated it. So it was hate on first sight, so to say, but now it's one of my best friends, to be honest, almost open it daily. Um and um yeah, so it really changed because the dependency board, it works at least in our, in our approach, it really works.

Um what was interestingly also evolving was the risk management or let's call it like the risk roaming. And we had now problem solving workshops and we had some managers across different levels included there as well. And lessons learned, there are more than two states in risk management, not only accepted and owned and we were also able to solve issues and problems. I talk that was really an amazing experience.

Um basically, it just showed also up in the in the confidence vote. The last one was almost five, which is really amazing. Um it would be super interesting to have like a graph, the evolving of the confidence vote in the last two years. I don't know why we do not have this any idea, we can take care of it later. Yeah, let's put it in the next.

So and yeah, just highlight once more. Um we did that with hundreds of different developers physically um because we are out of co we now out of the crisis and uh we had quite some management showing up as well. And you know, to basically now building up on top of this success and building up on top of this uh management commitment that we receive for this framework. Our vision is not to only apply additional principles like a portfolio layer to align the objectives between those different release trains, but also to spread this framework and to adopt more and more release trains across the organization and maybe even go beyond the misuse plans after sales.

Yeah, there being enough now um about the safer in itself now, um you know, we took care of the organization gaps, we took care of the technology gaps, but we were still having some gaps on the people domain and the change management domain and you know, applying these frameworks. Um we still were facing quite some challenges with it. And in particular two major challenges, one being that central teams, just like our platform team where a lot of application teams or a lot of other teams have dependencies to are getting really exposed by this framework. And all of a sudden, you had our platform developers facing hundreds of different questions and requests across different domains along the end and customer journey and they couldn't really focus more on platform enhancement or actually platform development.

And the other one being that, you know, we had the collaboration foster, we had those cadences. Um but whenever we left the safe framework and we left those cadences, the application teams and our customers still had to take care of their journey to the cloud and throughout the cloud from development to production by themselves. And in order to shield our developers, so they can actually focus on platform development. And in order to guide um our customers even further, we decided to group these different questions and requests into different domains. And the very first one being the application on boarding.

And um we the first, this was also the very first team that we established around these domains. And yeah, questions like how do i get onto the platform? What type of compliance do i have to take care of? And all these different initial interviews and conversations being taken care of by the application on boarding team to get them on board on top of the platform.

Now, when those applications were on our platform, they were still had, they still had to take care of all these technical challenges. And that's where we started implementing the application enablement team. A team which scales with the amount of applications on the platform and really brings those applications from development to production. You know, questions like how do i code my lambda function? Can you maybe do some pair programming with me to code it together or do i go for ecs? Far do i deploy it on the two instances or do i go for s and all of these technical questions then being taken care of by the enablement team to enable those applications?

An additional team that we established was the cross functions team. Don't get confused by the name. It's just a name that was given by the organization. Uh but a team that was basically bridging the gap on both ends first on an application. And you know, maybe those applications had to do or had to perform severe changes to the application to basically, you know, get on board to the platform. So they got resources from that specific team to help them or i'm bridging the gap on our platform side where and taking care of services that we may be deprioritizing because of yeah mentioned planning as well.

And last but not least, uh the aws learning path team in collaboration with aws, definitely a game changer. Um a team that helped the organization and the cloud practitioners to learn about the services and technologies that we use on the platform.

Yeah. And when we did all of that, not only could our platform developers take care of platform development and platform enhancements, but our customers and stakeholders were happy as well.

Yeah, and that being it about the structural change and structural transformation. Now let's jump into the lessons learned that we take from here. And um the very first one being a quite obvious one. Yes, remote p i plannings are possible especially during a time of crisis but coming together physically definitely enhances team spirit and general efficiency. And you have all of a sudden you have different developers, hundreds of different developers coming together, discussing objectives or risks or whatever within coffee breaks or you know, changing rooms to discuss and plan objectives together and don't forget about the fun.

Yeah, exactly. The second one, lesson learn being is that especially with such complex framework be it saved or be it another framework or the shared responsibility in itself, you know, implementing in a step by step approach can really ease the disruption and help those people with the change that they are expecting.

Next one. Ok. It's the last time today, i'm gonna say shared responsibility model promised. Thank you. But it just works if you apply it on all levels from the get go. So even though who had mentioned that we had in the beginning one platform team, but we still the terra form code was still divided between foundation and platform code. And that really helps us now that we have sister platforms and other use cases being on board that we had this separation from the beginning. So this really helps. And also if i mentioned it end to end responsibility, it's really hard for people to actually follow that path and be aware that at some point, your responsibility now ends. So you don't have to take care of everything. You don't have to decide between ethernet and token ring anymore. It's fine, somebody did it for you. And by defining clear interfaces between the layers, you can really ease the transition. But it's also important to have on the top application. There are still a lot of freedoms because the application developers know best. It's just a fact, one thing that we didn't really touch on because it's a different top or like a complete talk in itself is we really treated compliance processes as a virtue from the get go. So that means from the start, we were every week in discussion with our isos and isos and we're trying to improve the trying and succeeded in improving the, the platform, security capabilities and the overall architecture. And we were doing pretty much for 2.5 years. We've been doing continuous well architected reviews. So that's maybe not always the case, but we are not that scared of corporate audits because not that scared of corporate audits, but because we've been auditing ourselves with our iso and is a teams for 2.5 years.

Yeah. Last but not least, i think the most important lessons learned is developers, developers, developers, and of course customers. But listen to your developers, please and adapt your framework accordingly.

Um yeah. Um let me quickly take the chance. Uh if not now, then when i want to give a quick shout out again, a shout out to all our amazing colleagues, to our desks, to our operations team, to our architects, manager and all the colleagues um especially for those who cannot be here on site uh this week. So thank you for your dedication, for your commitment and for your outstanding work. You are missed here and we really love you. So. Ok, that was enough for the fields. I, i hope it's fine.

Yeah. Uh guys, uh folks, do you have any questions?