Architecture-led portfolio migration and modernization

Good morning, everyone. Uh my name is Sibu. I'm the worldwide tech leader for migrations and modernization of AWS. Welcome to the 12th annual re:Invent. I'm glad you're here. Uh it's kind of a full crowd. Um I was hoping to do some show of hans paul. Hopefully, I can still see you guys. Um but yeah, welcome.

Um today, I'm gonna be joined by uh two customers um AJ from Petronas and Daniel from Adidas in a little bit. Um we're gonna talk about architecture uh led portfolio and migrations in my role. Um I work pretty closely with the mig AWS leadership team launching new programs. Uh for example, the Migration Acceleration Program, I wrote the tech specs for the MAP tro uh program. Uh I work closely with the services leadership to launch new partners, new tools um and stuff that helps customers accelerate migrations and modern in the play.

Um that's a little bit about of me um this session. So what, what can you expect and what you cannot expect? Uh this is about. Um, in my role in, in my past life, I've done several projects with so a esb enterprise architecture um cto s office, things like that. So if you're familiar with the e sbs and so a and things of that nature. Um some of the, some of the keywords would resonate.

Um so we're trying to see how the traditional practice of enterprise architecture can apply uh when it comes to migrating to the cloud and using those uh well-established mechanisms uh into the cloud journey, right? Uh that's sort of the talk track.

Um what you cannot expect is uh don't expect a brand new framework or anything like that, right? We are going to use established frameworks and processes and workflows. So when you zoom out a little bit, when you look at those diagrams and stuff like that, you will see that um you'll see the uh the pictures are very, very similar to some of the well-established or very familiar uh migration practices that you've probably seen the six r methodology or the business capability mapping, things like that.

Um so I don't know if you have heard of the term um astronaut architect, if you zoom out at a sufficient level of abstraction, everything looks the same. Uh we are trying to get into the diagrams a little bit and I'll call out subtle differences on on when you take an architectural approach. Why is this different from, let's say a technology, a pure tech approach or a pure financial based approach? So that's sort of the the mental model here. That's sort of the talk track.

Um hope you're expecting that um in, in this, in the next hour or so for the 1st 20 minutes, it's gonna be me talking through that, that, that framework. Uh and then about 15 minutes each for AJ and Daniel uh talking about their journey uh diving into very specific things from their own ex um experiences.

Um and at the end of the time and at the end of the hour, we'll have about 5, 10 minutes for q and a uh if time permits. Um if things go cool.

Um so what is architecture? Uh so by show of hands, how many of you are enterprise architects? All right, I think I can wrap up my talk now and then. Uh glad, so many of you are here. I think in words of the same f um this is um enterprise architecture is a well-established practice, well, somewhat well established, right?

Uh because there's always pros and cons, there's always um people who claim to be enterprise architects, people who are technical architects who don't think about enterprise architect fully. Uh in my mind, it boils down to about five key elements, you know, uh business applications, data, technology and people, people is very, very important in this, in this journey too, right?

Uh so these five elements and all these five are changing on day to day basis. So business is changing, becoming more digital, the definition of application is changing. It is not, not, not, not um one cohesive unit. Sometimes it's a collection of api s uh data is changing, it is being generated at the edge as well as in the cloud in, in a multitude of ways.

Um you have to kind of keep in mind the data ingress and egress. I heard that the egress costs are high. I don't know about that. But um um so you're kind of keep in mind all those aspects of data. Uh there is uh the people part is changing both sides, like your stakeholders who are business leaders have very, very high expectations on it.

Um they think that just because you have an it department, you can be the next amazon or next netflix sort of thing. Uh at the same time, your your employees or your developers and builders also have very expectations on it. Uh they say like i want to work on, you know, gen a i like i don't want to work on java anymore, right? They also always want to work on.

So the as an enterprise architect, you want to kind of straddle the expectation between people on both sides of the spectrum. And so that's the people aspect. So all the five key elements of architectures are changing on a on a day to day basis, thinking how the practices can help evolve or how um these mechanisms can help uh make you think better or make you deliver uh the cloud journey, better sort of thing.

So that's sort of the context of why architecture or what architecture is important. Now, if you take a typical enterprise, it landscape, it can be quite complex, it can have anything from cobalt assembler mainframe, all the way to sas applications which is running on some other, some other um um sas provider sort of thing and integrations and um collaborations between all these two as well.

Now, how do you make sense of an enterprise um landscape as an enterprise architect. How do you kind of think about it? What is the mental model that you use? I can give you two two frameworks to think about one. I call it uh a generalized generalist versus specialist sort of approach.

Um enterprise architects tend to be generalist for those of you who have been the been an architect for years, there is always a common point of connection that you can form with an application owner or with a tech owner or with uh a database owner. Oh, i have used that store before. Oh, you're doing this in bland c++, come on, i started my carrier there or you're doing this in ruby on rails framework, that framework is so similar to the j two ee framework sort of thing.

So if you think about some common connections that you as a generalist, you have um that usually helps establish this relationship with the application owners or the business owners much better. Um so that's one mechanism that i typically use from a generalist versus specialist connection.

Uh the other i want to point out is really a pitfall. Um um how many of you have heard of this concept called the gel gelman amnesia? Anybody? Ok. It kind of goes like this, right? Um you, you open a newspaper, you read an article, let's say it's about cloud computing. That's a topic that i'm very, very familiar with. I know exactly what cloud computing is.

Then i read through the article, i know the journalist is wrong that the story is so wrong that it is presented almost backwards, you shrug your head and then you turn the page, you find the next story is about ja i, then you think that it is correct because you forget that the the part you have selected. So that's kind of what we call, you know that the concept is called gem gelman amnesia.

So you can apply here. So you go to one application group or one infrastructure group, understand their problems. And then you just because it is familiar to your own personal background, you may understand it better and then you go to the next group you want to assume um or you don't want to assume that it is going to be exactly the same. So you figure out.

Um so that's a pitfall that you want to keep in mind when you think about the enterprise landscape. Now, when you as architects, as practitioners, you have running into challenges with respect to, you know, data governance, security, standards, compliance, application delivery capabilities. So you kind of run through all these mechanisms, you run, you know, day to day job, you have a mental model of your, of your landscape, you somehow formed your mind, you have a concept of your mind.

Now, how do you transform it with architecture? Right? The question really comes in what is, what is the why sort of thing? Um the a lot of people will come up to you at this point, including vendors saying that you could do this, hey, i could just move this into a container or hey, i could just upgrade this code into the next version and they'll be all right.

Um or uh i could just move everything off of this and run it on a um i don't need code anymore. Um or you'll also get financial um beating saying that why is it so expensive? Right? So why can't you like take it down by 30%? I've read this report that by moving everything to the cloud, everything is goes down by 30%. Uh why can't you do that?

Uh so there's a lift and shift concept and all of these approaches to the cloud that people will push it push you or people will pitch, you will have biases, right. There will be a technology bias, there will be financial bias, there will be personality bias. Uh, there will be an aws bias too.

Um, and as an architect, it's your job to kind of think through all this and then figure out what is the, what is it that you should do rather than what is it that you can't do? Typically when we uh if you are familiar with the aws migration services, when you do discovery, when you do assessments for migrations, we can run through the entire portfolio of applications uh and tell you what is possible.

We categorize the applications into six categories, right? The reho repla refactor we can, that is the what is it that you can do? But it doesn't mean you should do that, right? We love to that if you do that. But as an architect, it's also about what you should do from a business capability perspective. What is it that going to give you the most value for, for your transformation journey?

So that's kind of where or the why the architecture is important. Like i said in the beginning, there are five concepts like, you know, business applications, data people. Uh and if i could this one more. Um right. Technology, thanks.

Um so there's five things that's important. So you're always kind of think about it in five different lenses, most of the biases that you see will be in one of those. Um as long as you kind of keep that holistic approach in place, architecture will lead you to the right outcome, so to speak.

Um but i kind of touch upon a few points here. The business capability maps is extremely important. Uh we sometimes we tend to push um when we do assessment for migrations, we tend to ignore it sometimes. Um because it's hard, hard, hard to understand what capability persist.

Um it's also a topic where you can get really, really boiled down uh really fast, you can get into the into the weights quite fast. So i would say recommend uh do the business capability mapping at the first level or the second level of detail. Don't try to boil the ocean and get into the extent. Like don't build a spreadsheet with 48 tabs and 2, 2000 rows in every sh sheet, right? That's not gonna work.

So you can keep that capability map at that particular level of granularity and that helps drive the complexity. Um and that helps drive you the decision making process, so to speak. Uh from an application perspective, what are the key applications that matter? Uh uh what capabilities matter, what are those revenue generating applications? Uh where do you bring in agility sort of thing?

Again, this is not new, you probably as an enterprise architect do these things on a day to day basis. So if you look at business capability mapping. If you look at application portfolio, if you look at technology risk mapping, if you look at shared services identification, uh if you look at architecture standards or technology standards, these are things that you should do as an architect, regardless of the cloud and these are exactly the same things that would apply when you come to the cloud too.

And this is why i'm saying take the architecture based approaches, it's really sort of cohesive or it's almost the same thing. I'm almost question like why you wouldn't do that and better? A lot of the successful cloud migrations or modernization that i've seen um is led by architects is led by enterprise architect, it is led by cto sort of thing who takes this holistic approach into interaction and that's kind of why uh why would need it.

Um so the key advantage again is focusing on what you should do rather than what you um what you can do, right? So it's proven because enterprise architects anyway, do this on a day to day basis. It is comprehensive. It is not looking at just technology or just solution architecture or just database engines or just licenses or just security. It's kind of taking the entire thing into, into consideration.

Um it is also very strategic uh because your communication up and down is very, very strategic, it can help you drive um transformations in your business. Um to tell you two stories from my personal experience. One is for a big uh telecom company in the midwest.

We had, they had about six or seven data centers. Il 35 ielt 36. Il 5556. They had to shut down. Ilt 55 and 56. Ill stands for illinois, the data center for illinois

Um, I was there physically doing this, doing the work and they had to, they were running, you know, and docs, they were running it, shared services. They were running a bunch of common products across the portfolio. They had a huge amount of storage. They used to sell this big installations of uh towers um of high end communication equipment to provide us all across the world and all the paint, all the blueprints and drawings for all those towers were kept in storage there um in case somebody calls up from germany one night and then say, hey, i got a problem, i can troubleshoot it, they can go back and look at it. So all of them are kept in active storage, so to speak, so huge amount of storage as well.

Um i was able to work because of, you know, the generality or because of the skills that i was able to establish and some of the programs there was actually running in c++ um i started my career in c++ so it's very easy for me to establish that wrapper with the application owners uh as an architect understand port portfolio. I was able to migrate i 55 completely over to the cloud to aws. And then a part of the applications were which we could not do because of some severe hardware restrictions. We were able to move to i 35 that is 35 and 36 together. And i had to kind of work with the data center owners and the application owners to get this, get this going.

They also had a, had a compelling need uh because iel 55 was uh getting shut down because of some contraction issue that we had the provider. So they had to kind of move out. So there was a compelling driver there. Uh but at the same time, um without the architecture, uh without putting together the political plot, without putting the diagrams, i don't think it would have been a possible journey.

Uh the second story is very similar um based on the success of migrations. I'm like, hey, this, this is really cool. Uh i went to my next client. It was a big bank out of the midwest again. Uh they were one of the largest, uh they had the largest market share in uh commercial, small business lending. Um so uh loans are from 25,000 to let's say $250,000 loans for small businesses. They were, they kind of had the market share for that and their primary loan processing and loan originating originating applications were in legacy technologies. Some of them are in mainframe. Some of them are in this thing. Uh some old java applications, they are not scaling.

Um, so i kind of put together a very, very technology friendly proposal to them. Here is how i migrate this mainframe using this tool. Here is how i upgrade this java using that tool. It is a very technical approach. It also had some people components on how i will retrain your employees on from java to whatever. Uh but it did not have any business outcome impact. So i kind of press into the proposal and then the customer said all good and good but nothing is broken. I'm not right. I'm not going to fix it.

Um, so they were um ok with the technology approach, they were not questioning that this is possible or not, but they were not. Um they did not get the business value proposition for me at that time. It took um it took about three months to four months after that proposal. Um a start up company launched out of i think california uh who were an online small business lending. They were saying, and the average time to close a loan for that bank was 42 days. So if anybody as a small business, if you're running a bakery or if you're running a, a bike repair shop or if you're running a motorcycle apparel shop, uh and if you want to start something there. Right. If you go to the bank and ask for a loan, on average, it will take about 42 days to get the money. Um, uh, even if it is $25,000.

Um, so the online start up company was providing their, uh, their catch line was $15,000 in 15 minutes or less. Up to $15,000. That was their sort of the big entry. So when i saw the news, like six months after my proposal was shut down by this company, uh i went back to the cio and said, look, here is a competition, here is a value proportion. If you don't reduce your 42 days to 15 minutes, they are gonna come up pretty soon. It took a few iterations first hidden degree.

Um they said, yeah, $25,000 is not a sweet spot. Our sweet spot is $85,000 and up. So I'm not going to worry about that market. Um and you know, guess what, three months later, that company uh said $25,000 in 15 minutes or 15 minutes or less. So they kind of automated the whole entire loan or generation process. And when they went up to $50,000 light bulbs started growing up. And then that's when the business outcome drove that particular transformation journey.

So regardless of what i had in technology, um architecture, uh solution mapping, how you would change the code. I kind of went down to the, the details of how the code would be changed, what database would be used, where would we host the databases? Uh what channels would we provide that project didn't go anywhere? Uh it went only when the business outcome was, was identified at that particular point.

Um so that's kind of saying that, you know, you need to kind of look at the architecture from a holistic perspective. Um so how does this work? Uh like i said again, um look at look at business capability mapping. It's really important um identify your key outcomes. Uh major capabilities is identifying the major capabilities are really, really important. Uh don't boil the ocean, just, just drill down on a couple of key important ones. Uh look at it from a portfolio level, you may have a cards application running on a four note cluster somewhere uh on windows 2008 service pack two on top of v ms uh vsphere six window with some, you know, net backup as a backup storage and that is one cluster and there is some other cluster who is running and um python and i can run anywhere on containers. Uh so your portfolio you make and you have to kind of take a portfolio approach. And then if you change one text stack, you can think about how it applies or how it impacts some of the other, other parts of the of your portfolio.

Uh cause again, technical um executive sponsorship is really, really important. Whatever you do, you have to kind of make sure that your business leaders and your builders and developers are in line with your uh with your thing, right?

How does this map into the aws framework? We have a framework if you're familiar with this is the, the traditional, the asset uh mobilize and migrate framework. Uh and this particular framework uh is I'm gonna kind of horn into a couple of things here zoom into, let's say on the side, we usually use the process, the six hour process for categorizing the applications on the mobilized side. I'm going to zoom in on the people part. Everybody says mobilized is landing zone which is indeed it is. But for me as an architect, as an enterprise architect, i also looking and mobilize as mobilizing of people because you need to kind of make sure your people are familiar with the skills, you are making sure they are upskilled or they are excited about that particular journey, so to speak.

Uh and the migrate and modernize the execution part is all about technology, like you use tools to automate and you kind of get going um the key, the key activities for these, like i said, it looked very similar to your traditional uh migration framework, but the key activities is focus on the critical business capabilities and business kpis and engage your people. Um uh this is really, really important when it comes to architecture.

Um so i kind of said the, the the words again and again that you kind of focus on the process, you focus on the people and you also focus on, on the technology as another dimension to look at the problem. I looked at the five things in the beginning of the architectural element. Another way to look at it from uh to kind of look at it from uh architecture, from a different lens perspective is about the people process technology.

Um so people process and technology, I'm gonna take the easy part, the technology part. I'm gonna talk about what technologies we provide from aws to kind of help in your execution journey.

Um the hard, the harder part, the process part, I'm gonna invite daniel to come on stage for talk about uh the process part and then aj to come and talk about the people part. Of course, they will talk about their own cloud journey as well.

Uh before i jump, invite them technology, we provide a lot of technologies uh from aws to help you with the migrations. Uh mgn application migration service. Uh we launched a new feature uh a couple of weeks ago. I think that helps you modernize your applications post migration. So you can containerize using app to container using mgn. So it is not a simple lift and shift, you can lift and shift and at the same time, launch something to containers right after that.

Um so ngn um that is modernization pathways. So we launched something early this year. Uh it helps you, we kind of figured out that 80% of modernization falls into six of the familiar paths. So we have launched the pathways. Uh it's a framework available for customers and partners to use.

Um that's kind of two examples of solutions that we have. We also have a ton of partners uh that come in with migration, tooling, um automation and ex expertise there. That's the easy part of the people process and technology.

Uh to talk about process uh in detail. Uh and to talk about their own cloud journey. Uh welcome daniel to the state from the s.

My name is Ahmad Jamal Khan. I'm Head of Enterprise Architecture, Technology and also Head of Cloud for Petronas Malaysia. Of course, those who know Malaysia is such a vibrant and beautiful country with a lot to offer in terms of human capital and resource. And of course, Petronas being at the center stage of Malaysia, not just carries the large objective of being an energy transition player, but also invest a lot in human capital.

We believe Petronas' core that when Petronas moves digitally the nation moves and hence given our portfolio, we operate over 50 countries with 50,000 people and growing. We offer our core services in the areas of upstream, downstream gas and business. And of course sustainability. At the heart of Petronas, we have now an offshoot called Gintare, which is all about renewable sustainability space. So if you are interested in knowing more about this place, please tune in.

I think as an enterprise architect, it is always good to define things and how we understand. And I think once somebody told me once was architecture is all about how we shape the complexity into pillars of why, what and how and I think this is how I'm going to be talking about why.

And of course, when the world was recovering from pandemic, we realized and Petronas that we have to change, we have to adapt to new ways of working and to adapt to modern IT. And while the world is still struggling with that phase of, although the joke is that should I be five days a week or four days a week in office, we are still battling that. But predominantly we have changed the way we operate today and our north star remains true to us that we need to find a way to have an energy transition in a sustainable way.

Now, of course, this creates an uncertainty in business. How do we achieve it? And of course, Petronas tried to answer this with this strategic ambition of MFT 5030 0, which is that we want to operate in a new world with reduction of our capital cost by 50%. We want to organically grow in new ventures through innovation of 30% of our revenue. And we need to be carbon net zero by 2050 a very ambitious goal.

The question is this is all enterprise, this is business goals based digital in all of it, right? And hence at group digital where I'm from, we charted our few digital initiatives and I said, look, we need to do things differently and cloud being the main focus of it, let's do it. And of course, cloud is not a new space for us. We've been experimenting in cloud at scale since 2016. But I think the shift has been in our strategy. We have adopted cloud first as our strategy and I think sooner is gonna be cloud only strategy.

So we have embarked on a multi cloud cloud first strategy. The goal was by end of 2022 we want to achieve over 90% of our workloads which spans over hundreds and thousands of applications in the cloud. And of course, why is it important? Why cloud, why now maybe you can ask why AWS, for example, we want to achieve we as I said we want to reduce our IT spend or cloud spend spend by 50% right? So let's try cloud. I mean, every brochure you read promise you cloud saving.

And if I ask everyone here to show the hands off, show the hands like who thinks cloud is expensive? How many of you will agree with me that it is cheap or expense? Ok. So that means I'm in with the right audience. So I mean, we have to make things way that that was a promise done, right?

So there were some tangible outcomes we wanted to draw from this digital transformation that we want to grow in cloud. Do you want to reduce the cost? We want to be sustainable because sustainability is heart of everything and on top of everything, we need to have a talent pool, a reskilling group because as I said, it's not about a company, it's about a nation development. And of course, then we have some indirect outcomes of resiliency, scalability, automation and so on and so forth. So that was why we were we embarked on this journey comes to what?

So we thought let's have an architectural approach of how we do things. Of course, it's not gonna be practical that we can modernize everything. So we said, ok, let's look at the legacy monolith application tag which consists of application, database host environment in infrastructure and see how much we can optimal move it to cloud, which is pretty much known as lift and shift method today. And while we were doing it, we got so better and expert in it that we said, maybe it's time to push a boundary a little further and say, can we modernize at the same time?

Of course, modernization among you and me is a very smart word to say. But when you're talking about business, business, ask you the question like is the application working? Are there any bugs? Is it 24 7? Yes. Then I don't want to take a risk of modernizing it. Why? And of course, this is where I think sibu and daniel were showing that we as an enterprise architecture have to find a way to chart a way to bring that confidence to business. That don't worry, we know what we're doing. There will be some tangible outcomes of this modernization that we can have a better resilience architecture, we can decrease your cost by further.

So that was a test case we opted on and we said, let's look at we have partners operate across multiple data centers. So, so for some of the data centers, we just migrated through re host and relat. But when it comes to a certain smaller size uh uh platform, we said, let's look at the modern and that's what we did as a case study. That's, that's the how part of things.

So I've talked about why i talked about what and how we're going to execute this. So we took this challenge that we need to exit the d dc by 2023 end of 2023 this year, apparently there were approximately 35 applications that we found which were ideal candidates for modernization. And we said, let's let's continue with it. And let's see what we can come up. I mean, it's just an open test scenario, right?

And of course, aws being our strategic partner help us through this journey of understanding of discovery analysis of it. What can or cannot be done? Ultimately, the promise to business was we want to reduce the cost. We wanna create a better microservice architecture. And of course, i i come from the background of start ups and i am a firm believer of open source. Again, i know it's a very difficult to explain sometimes to enterprises that should be always use open source versus not. I think there is a case for everything. But at my heart, i believe if i can move it reliably reliability with to open source, why not?

So that was my, my challenge, we looked into the solution. Of course, we saw anchor on the open source. While we were doing through this 37 application, we found another 87 applications from our old landing zone. And we said, you know what, let's give it a try.

So the the the thing the how part worked is we bucketed into three containers, we said, ok, let's see an application that can be modernized today. What can be done modernized tomorrow because this space is continuously changing, evolving, the tools, the support that you have from vendors may not be available today, but it will be in the road map. So let's keep an eye on it. And third, we know that perhaps it won't move for various reasons or it will take a lot more uh from efforts and time and cost. That's why.

So we look into it and towards the end of it, we had multiple successful po cs conducted and we shown business that not only we can do it, not only we can promise, bring the promises that about cost saving and reliability, but we can actually do so comes to the end of this year, which is almost, we are ending it. We almost completed 35 application of 87 application.

We have shown business that tangible saving of almost 4.2 million us d over tco of five years. And remember this is i'm just talking about a simple size of 87 application where we have hundreds and thousands of applications. Now that brings this muscle that we have now grown, that we can do this and we should do this because we remain true to our north star that we want to bring the cost down. We want to innovate and we want to find a better way to do things because ultimately it's no point for us to keep running cloud has been there for the last 2025 years. We need to be better at things.

So not everything can be surve, not everything can be functional. But if there is an opportunity, why not take it now while we do this, i don't want to talk about technology and processor. Daniel has already laid a perfect foundation for it. I think at the heart of it, i strongly believe that we achieve what we did is because of human capital, the the what we have invested because at the end of the day, once the application is in the cloud, it's my job to run.

And of course, i have a super amazing team of enterprise architects and uh and cloud team who day in day are believe in this vision, believe in this self. And we have now trying to create this community of practice so that we can at malaysia, we are not only embarking on this, we were also advocating to the other businesses and saying guys, we have found a pattern, we can share with you, we can learn from it and we can grow together.

And with this, of course, i know back in times we had operations, we had development, we coined a term called devops. Today, we have enterprise, we have cloud for the lack of better term. We have devised our own e a cool. So i hope this e a cool will remain with you guys. I think the whole idea is we want to create this fraternity of architecture discipline, software engineering cloud, coming together, understanding the concept of how, why we should do it, what should be done and how it should be done to bring those values and value realization back to the business that they have been working on.

And of course, change management adoption always remains a challenge. And of course, our digital group at patronage consists of inclusive diversity. We have people from uk us australia, canada, india, you name it. And of course, we have been promoting this because we have a large offshore and offshore operations. So we not everyone can be centralized. So we go back to each station and we demonstrate the capability of digital cloud, why the case of change and why e matters most. Because at the end of the day, we want to do things from the architecture way that makes more sense to the business.

And of course, in doing so, we've been quite successful, we have gone uh got quite a few awards for it and i think it's a joint effort by amazing group of talent that we have at pateras. I hope uh that was the last slide for myself. Sorry.

Um so from what next, I will ask uh perhaps uh sibu and daniel to come and show we want the next one. So you see the slide before there's a small addition to the end, the enterprise landscape is already complex. Now, it's getting even more complex. There is sas and other stuff keeping, keep getting added to the right. So you need to kind of deal with that overarching complexity. Like i said, in the beginning, the expectations on it is high and it's getting higher.

Um so from a people perspective, from a change perspective, i want to kind of ask my uh my customers a couple of questions. Uh and then we have, we can wrap it up. Uh the key questions is no, it is given that the the complexity, the integrations and the expectation is increasing. So how do you keep your people, both your stakeholders and your developers and the builders and operators and architects engaged and excited uh and how can architecture help sort of tackle these challenges?

Yeah, maybe i can go first. I go first. People part is always interesting. I i think one thing i've learned in my time in this, it world is technology shifts and people are inclined to move with technology. We should allow them that room, that innovation space and we should take the cultural aspect of it because if you have the right culture, people do innovate and do progress. And i think that the the bigger the challenge is and better it is communicated better, it is retained by the employees. I mean, that's my view of things to keep them, keep them engaged. Daniel.

Thank you. Yeah, i, i think like at adidas, we really don't have the challenge to people. Uh everyone is super engaged and has, has a lot of energy and, and i, i think like we were talking about it earlier, there is not a single day that i don't receive an email saying, hey, i wanna do something with abc. I wanna do something with ja, i just to drop the ball here.

Um and, and i think like engagement is not, it's not one of our issues but, but then um steering them in the right direction. This is i think like specifically where enterprise architecture can help uh helping to um um to untangle a couple of situations. So, in fact, we were having um uh uh a good handful of, of very, very high level info sessions now on the topic of, of gen a i. Uh but we're doing that, we're doing that and planning that as well for other topics um uh and working together with our strategy offices.

Um uh very, very, very, very deeply to, to show what is possible, what is the aim and, and, and bring, bring together people, ideas and technology. I think like that would be my answer.

Yeah, i think we have about uh one more slide. So we obviously have done thousands of migration as a company. Uh i personally have shut down about 10 data centers. I say about 10 because two of them are still running in half capacity. I need to go plug them out.

Um so in almost all of my personal experiences, and i've seen from your experiences having that executive uh sponsorship. Now, when i say executive sponsorship, i kind of emphasize, it's not just convincing our bosses, it's also convincing our teams to kind of do the right things and get, get mobilized with us. It's very, very important.

Uh setting business outcomes is very important. Like i said in my old story, uh when i had the right technology patterns, it didn't sell. But when the loan, when there was a competition on the market, uh the the business bank had to had to kind of sell. So there was compelling use cases uh build a momentum, take a portfolio approach and these are like best practice that we've seen across.

Um yeah, i think that's kind of all we had. Uh we have about four minutes left if you have any questions, we can take it otherwise you'll be out in the hallways. You can always uh feel free to come and gonna chat up to us. Thank you. Thank you.