 Hi, Lauren. So quickly, I won't take a lot of time, I'm from a Western company and we are supporting our customer around digital transformation and I've been working there for ten years now. I've been working on the M&A Topic, the United Transformation in Europe, US, Mexico and now in Singapore, since six months for a large scale company. We start this speech by giving you a bit of feedback of the 2023 DevOps market. So in a nutshell, what I have seen so far is that my customers are saying it's a chaotic environment with a huge workload where the teams are always late and over budgets and the releases are lacking quality and cybersecurity. In fact, when we're looking in depth, there are several topics that are emerging. So the delivery pace is an issue, meaning that the business wants to release a lot of releases on digital products, releasing new features and the IT teams have some issue to follow that pace. The second part is regarding global consistency and we can see that there are sometimes there are operation and quality of services that are not at the right level and same for the quality of the run, there are regression issues between the releases, etc. Regarding the target operating model and the delivery operating model, we can see that there are sourcing inconsistency between the delivery team. There are some sizing errors in terms of strategic workforce planning that you will see, okay, I want to have 10 front-end developers, I want to have two back-end developers and sometimes the capacity planning between the team and the right ones. There are some poor separation inefficiency due to the legacy of IT organization created in the 90s. And finally, there are some budget management principles and currents between the development team and the operation one. Regarding the sourcing strategy quickly, I have seen there are some inconsistency between the contracts and there are some issues by asking your outsource developer, for instance, to deliver faster because they have waterfall contracts. And here it's the most common issue that I've seen and also the service level agreement part. Finally, there are the human resources and psycho-social hazards that we can face on your organization, on which that you have overload, turnover, and most common stuff that are coming now and mostly on the Singaporean market, it's to keep and retain your talents in the company. In West Storm, we consider that there are five maturity levels that pave your way on the road to agile endeavors. So I will go quickly on that one because I think the DevOps part will be the next slide, it must be focused on. So first level is the tailored one on which everything is manually. So it's the one that you face, like between the 90s and the 20s. Yeah, 2000, sorry. The second one is the agile project. So some of the application you started to develop it on an agile way. Then there were the agile application on which you started to push the dev and the ops working together. The Allias, it's a bundle of application working all together in the agile mode. And finally, innovation first, it's to let the bees work near the dev and the ops. But when we present that, the most common mistake that I can see is, sorry, is that when we are talking about DevOps, most of my, my customer are thinking about this first part. DevOps for most of our customer in Western is only agile organization and collaboration culture. But in fact, DevOps is much more than that. It's for CICD pipeline infrastructure as code and application architecture are the cornerstones of the DevOps methodology. So everyone knows the agile organization and the collaboration culture because they've been brainwashed. And most common advisory consulting team are doing that. But the three other pillars are very interesting because you need to consider that to be able to have fast delivery, you must consider the infrastructure as code as part of it. Meaning that you need to be to become an infrastructure called broker for your application in order to reduce at most as possible the time to market, the time to deliver any underlying platform and services from an Edison point. I will give you an example, for instance, how long do you wait to have a new virtual machine, a new VLAN to be created if you are working on the legacy services and on infrastructure as code services. You need to ask a ticket on your ITSM, you need to wait for the team to be reassigned, and then you need to receive the service. With infrastructure as code, you end to reduce as a service, meaning that it's click and you got the service rate right away. Regarding the CICD pipeline, it's the way to automate your code delivery from code repository toward your production in the fastest automated industrialized way. If we talk about DevSecOps, it's including also the security part on your CICD pipeline. Finally, the last pillar is the cloud native and modular application. So it's good to have the tooling, it's good to have the infrastructure as code. But if you have only one big jar file, so one monolithic application, it's like asking an elephant to break your eggs in the morning. It's very efficient, but not accurate. So my point here regarding cloud native and modular application is the goal here is to work with the architect, to work with the business to redesign your modular and microservices architecture in order to be scalable, in order to enhance the fact to push small features into your CICD pipeline, triggering infrastructure as code as much as you can, and finally integrate cybersecurity on small pieces. So at the end of the day, microservices and modular application is having the same application that breaking into pieces that leave opportunity for the IT organization to push it faster, easier and in an industrialized automated way. You can see on the bottom part of the slide that the market trends are the cloud offer. So the main cloud editor on the market follows the DevOps principles and you can see for instance if we can AWS, we can take AWS for instance, they propose DevOps with the CICD pipeline infrastructure as code. So all of the cloud provider now on the data and the line on the DevOps principles. So meaning that they are fully APIs to ease automation and visualization. They have services enabling modern architecture for application. They do propose transversal services for the run of your platform from monitoring standpoint, security, cost monitoring, etc. So it's open the door for FinOps for instance. And finally there is integration with best of rates DevOps tooling. So from the infrastructure as code, SCCM, build engine, etc. Now why a showcase journey is relevant for any IT organization. So I will go in detail so how to scope it just after, but now why it's relevant. You will create a seamless, team-involved business, technical cybersecurity profile. You will focus the team on long-time product but with short-term milestones to achieve and thus you will limit the relative efforts to be done. And you will take credit for the showcase and you will promote the showcase results and the people involved in it in order to create your new DevOps hero or champion. And finally, and this one is very important, you will find more easily the relative budget for developing it. So now in order to scope your showcase, how to select the right project to be launched. So yeah, there are four steps and the first one is which projects. So you need to consider that on your application landscape, there are the project considering complexity and the needs of instability to be considered. Now we give you an example, if you are working in the banking sector, everyone knows the mainframe. The mainframe does not need to change every day, so it does not need to be unstable. So you need to have it the most easy as possible so it's not a good candidate for DevOps. Regarding the project complexity here, it's to consider that is it something difficult to develop? Is it highly linked to any other application or I'm working on a very standard technology with a standard application. So here the goal is to take the more unstable application like a mobile application for instance and the less complex one in order to ensure you have the best array in there. Then which application to be considered. So there is a technical compatibility to be considered in order to have the best application compatible to go on the DevOps path to provide the best compatibility on it. Now I really talked about it, it's how to prioritize. So here it's to have the best ratio between the benefits and the investment. And finally there is a priority model to be discussed in order to decide what do you want to do on development and production between internal and external. There are several assignments and topics to be launched in priority. So showcasing several application. The one relevant to the business. Creating a series for CICD infrastructure as code could be a good opportunity for you because it's something that will be relevant in the incoming future. The more often you will have you will use your CICD pipeline, the more often you will use the infrastructure as code. And finally, to transform the application technically incompatible into compatible ones to grow your ecosystem. Quickly on this one, because I discussed several topics, we can differ two main applications. So the one that are devosizable and the one that are not. So the one that are devosizable are the evolutive one. The one that have some front end. So a lot of interface manual with customer, either internal or end user. The one that have low flows meaning standalone. The one technically compatible. And the one that are visible to the management and to the business. And on the control. The one that are not devosizable. It's totally the, the, the malware here. So the legacy one, a lot of backend for a lot of multi flows, a lot of technical incompatibility. And that are not known for the business and the top management. Now how to create your DevOps team for this showcase. So the goal here is not leaving the way people are doing DevOps right now. The goal here is to bring the tech guy working with the dev and the ops. And when I said tech guys is the people working on the platform and the underlying platform, working on infrastructure as code, working on the CI CD pipeline. In order to start and use the change with the team. And the important part of this showcase agility must be in tip independence in order to avoid to be influenced by the management or any legacy organization. Then you can compete this team with ACMEs expert that came from outside the company, either from outsourcing or recruitment. Then you want to build your team on the showcase that you would like to launch and promote on one or several facets of DevOps. Meaning that you can take an application and say, okay, one is monolithic. I want to transform it. First, the monolithic application toward microservices. And I want to use only a part of the CI CD pipeline. You do not have everything complex at the beginning. For instance, and after three months, you increase the complexity. Then you could do other project DevOps if you have launched several ones at the same time with other teams. And you might need to rush for the team at some point from HR career point of view or from skills point of view. Finally, the last part is to increase the audit, the cybersecurity, the IT standards and the viability of the environments. And then you repeat again, again. So in a nutshell, your showcase could be like C4 working in banking, for instance, a B2C application for customer on which that you'd like to promote this mobile application for your business with a bunch of features that require several interface with the end user. Then you want to develop it or replatform it, for instance, with microservices using a CI CD pipeline and having new fast sector Ascot in order to reach, I don't know, one release a day to push new features or to push new rush on every day. Here, the showcase you can say to your management, I'd like to have three to four months showcase on which I will have this application totally replatform from monolithic to microservices and having the KPIs, the following KPIs that you can define with them. And then after the three, four months, you can share the results having the most tasks completed. And if you need an extra time, you can ask to develop something extra to have any other features promoted there. So after the showcase, what's next? So, as you know, because it's a very ongoing transformation develops, it's an iterative approach by making DevOps a subject of adoption and skill development. So this one, everyone knows it. Then the second one is a bit tricky because you must dedicate teams, architecture and environments for the showcase. And this one, no to no company are doing it. I think it's a mistake because by doing it, you are able to get big for working like as a startup by creating a dedicated environment for that. Then you must facilitate the team adoption as they will do processes and tools they have tried to implement and test. And by considering the IT agile net transformation to be allowed in the beginning, meaning that most of the company here in Singapore market have launched years ago, this DevOps transformation, their cloud transformation. However, when I'm talking with my customer here, I can see that they are lacking some industrialization within the CI CD pipeline. They are lacking some standardization on the CI CD, CI CD tooling, for instance. And finally, there are some lead time to create a CI CD pipeline to support a new application team to be developed. So here you can see it's because they worked only on the dev and on the ops part and not on the tooling. So the IT agile part. So my point here is that the IT organization, so the geek people in the organization must work as a team with the DevOps team. And finally, so applying the DevOps principle on eligible application, this one is important because a lot of the application landscape in the Singaporean customer here, but I can see a lot of it are on the cloud, certainly, but on, yes, application. So very legacy way of working as you had the application in data center or data. So my point here is not to jeopardize everything. It's to take benefit of what you have, but start on one application to application through application. And maybe think it was the good way of doing it. And you can start it again, for instance, with a compatible standard application that will fit for showcase and on some environments, meaning on your dev environment, on your state environment, your player. And then you can you will be able to spread through DevOps culture within your company. The showcase. By improving it using the showcase post mortem and in this way using it is a sustainable approach. Again, the sustainable approach is clear in the company here. I don't know what one that I've seen because they are new to know tooling from CICD pipeline or infrastructure point of view. Then I think the last part of it, you can extend the showcase to all target environment and defining that deployment pattern and principles. Here I can tell you what I've seen and what I've done in the U.S. in Europe is that we create a dedicated environment in order to have an end to end DevOps environment from business to development to operation to the IT, so the underlying platform and services. And we moved the different application monolithic to a platform one on the new environment with a dedicated operating model that brought value to the business. I will conclude here that it develops in a agile way to quickly deliver value and share results to the business, but also to mitigate the risk. So DevOps is agile, so is implementing DevOps at scale. I have found it now with you guys in order to answer any questions that you can have and have a bunch of appendices also if you need to go further in detail. Thank you. So when you are talking about dependency, you are talking about dependency within the application or with other applications. So within the application, there are several approaches for the units. So there is the code retro or reverse engineering in order to define the three main areas, which is UI, UX, front-end, back-end. Then there are common features on the front-end and the back-end that you can rely on. So there are several patterns of standard monolithic application in order to match as possible what would be the microservices one. So my point here is that you can have 20 Mondays to reverse engineering the application and then map as much as possible the current features in it to what could be a continuous application in the target. Okay. Now it's architecture is design. It's just design. You need to have this document in order to start creating a low-level target because if not, it's like creating front-end application. Any other question? So if I understood the question, you are asking the leader of the market to work on that kind of development activities. Leader in the company. Okay. Okay. The middle management. Okay. So it's an incentive question. Okay. So regarding incentive, there are three ways that I was handling that topic. The first one is from the HR standpoint. So you must talk to the leader of the company in order to review the goals and the objectives of the middle management. Here, you can incentive the middle management to work on the showcase or to support the showcase by putting it under their goals. Because at the end of the day, if they are not supportive, no bonus, no money. So yeah. The second topic is to promote the HR career path from the middle management regarding DevOps in order to be fully ensure that they are working to develop their skills also on that. And finally, the last topic is to create an incentive around. It's what I called, it's like, promote the success. So you put in front some of people of the middle management in order to take benefit of what is done for that. So it's free way of answering it, really related to HR. Okay. When I see a front end, I always want to do an A-B test, right? Yeah. A-B testing is something that takes time and is not trivially DevOps-izable. And so for me, things are much easier to put into a proper C-I-T-C-D DevOps process on the backend side instead on the front-end side. What is your standard? So I was talking about the showcase. So it was very showcase oriented. You're right. I was very showcase oriented, meaning that it's easier for front-end application like a CRM, for instance, compared to say, okay, let's go for an A-B. So no, at the end of the day, yeah, you will have some backend application that bring a lot of money that will be very relevant to be on the Microsoft services application to use your C-I-T-C-D pipeline. Thanks a lot.