 Kai Schefner, who is a Customer Success Manager at Lean IX. Kai is going to talk about cloud transformation, how to succeed when transforming your IT landscape. He's responsible for making the customer journey of modernization of their IT infrastructure with Lean IX successful. Great title, Customer Success Manager, Kai, I like that a lot. This presentation offers insights into major transformations of IT landscapes like cloud transformations, global ERP transformations, modernizing monoliths, et cetera, and shows how architects can help to drive transformation in budget, time, and quality. A warm virtual welcome from the open group to Kai Stehtner of Lean IX. Welcome, Kai. As you join us, I should say, thank you once again for Lean IX being our premier sponsor for this event. I appreciate it and won't take up any more of your time, Kai, and I'll see you for questions afterwards. I would like to present you now within the next 15 to 20 minutes, something about cloud transformation and how we think you can succeed when transforming your IT landscape. If you have any questions, please feel free to use the Q&A session or just send me an email. You can find my email on the last slide of my presentation. Okay, so let's get started. I would like to begin with some photos, and which shows quite nicely my opinion. Yeah, what's a huge transformation can be, and you can see on the left-hand side, the cockpit of the Apollo in 1970, and you can see on the right-hand side, the cockpit of the SpaceX Dragon Version 2 in 2020. So this might be a nice picture, what a transformation can be within 50 years. You could also apply this to software, and you could see on the left-hand side, some huge transformation in ERP systems. You can see the first version of the SAP software in the console, and you can see on the left-hand side in the bottom, like your proper UI of an ERP system. Same on the right-hand side, you can see like a normal server, and then on the bottom, you can see the cloud. So there's like huge transformations going on, as well in the software industry, but as well in other industries. But like 70% of these transformations fail, and why is that? That's why, because there's like missing preparation, when starting the transformation, there's also a lack of monitoring in the phase from ideation to implementation, and it happens quite often that there's light... You were in there one. There's light identification. ...drains and risks during the transformation. At the moment, there are like many transformations going on, so there's a high need to manage these transformations properly. And here you can see some examples for equations which are going on at the moment. For example, you want to migrate your on-premise world to the cloud, so you want to switch from your own data center to the cloud. As I said regarding ERP systems, you want to roll out global ERP systems. For example, you want to change to the new SAP S for HANA. You want to modernize your monolithic IT landscape, so you want to switch to a cloud-native world to microservices. Your organization is changing, so you want to merge business units or you want to carve out business units, or in terms of COVID, you have to change your entire operating model. So all these transformations are going on, and there's a high need to manage these transformations more right now. I would like to show you now in the next slides how VNIX as a tool can be leveraged to plan and execute your cloud transformation. So I focus on the use case of the cloud transformation. Just a short overview of our LinaX. We are a SaaS company for EA and cloud governance tooling. We have founded 2012 in Germany. At the moment, we do have more than 300 global customers. Approximately 250 employees globally are working for LinaX. We do have 120 million funding, for example, by Goldman Sachs. Gartner reviewed us as a visionary, and we have a really good way to take the Gartner peer insights. And what's really important to us is the usability. So we try to build our software that's really intuitive, and we do, like, every year now, buy 100%. Okay, let me explain to you why we think you need a proper EA tool to manage your complexity. Due to cloud transformation, complexity is really noisy. And this increased complexity and this increased required speed cannot be handled by Excel, Visio, or other modeling tools anymore. So you do have more processes, more applications, more technologies and companies. And there's a need for, like, an EA tool with a transparent overview of your whole IT landscape. And you can see here on the right-hand side our application landscape showing your whole IT infrastructure with a view on the life cycle of your applications. So is it like in plan, is it end of life? Large enterprises are already using LinaX, as for example, Adidas or Vosh, or even high-tech company as Dropbox and Lesson are using LinaX. And they're using it for, yeah, for fast and intuitive analyzers of your applications with regards to your business context and to leverage easy and fast decision-taking. So you don't need to, like, have, like, long plans, but you want to have, like, fast data-driven decisions based on your EA infrastructure. LinaX is also, for us, it's like a GitHub for a G-Rotner planning. As you know, GitHub is, like, one of the leading software versioning applications. And we think you can compare your assets, architecture to the main branch of GitHub, for example. And with LinaX, it's possible to also model and simulate plans of your existing active architecture. So for example, you could have the plan to migrate finance systems to the cloud, which would be, yeah, like, in the future, a different architecture. But there could be also scenarios for the plan. So you want to migrate finance systems to the cloud, but there could be the alternative if you, for example, buy the HR system workday or you just do it on your own. So it's like a make-or-build decision. And all these plans and the scenarios would have some impact on your current architecture. So you would, there's a need to model the impacts on this architecture. And there's a need, if you execute the plan or the alternate scenarios one or two, to execute these impacts. And this is possible using LinaX. So you can model and simulate and plan the scenarios. But then after executing these plans or these scenarios, you can, like in GitHub, you can merge some, you can merge the scenarios to the main branch. It's also possible to lose, to use workflows as a gyro to trigger the execution of the impacts. So it's possible that you can use some external workflow to trigger the execution and, yeah, to trigger the merge to the main branch. To sum this up, it's LinaX using, it's like GitHub and some sort of time machine. So it's a time machine, I mean, you have your SS. As you can see here, like you have your business capabilities and marketing, including Salesforce, your own CRM, Finance with S for HANA, SAP R3, and some HR system. But you can go and then you can go back and forth in the future and in the past. And you could say now, for example, this is the SS. But in Q4 2020, this SS would change. So depending on your scenarios, you can, for example, have now Salesforce marketing, you can have like another billing application within finance, but you can have a workday or HR system in the HR business capability. Okay. Getting back to the use case of cloud transformation. As you know, cloud transformation is happening. So it doesn't depend on the hyperscalers, AWS, Azure, GCP, the migration to the cloud is happening. And, yeah, and you have to manage the cloud migration, but you also have to manage after the migration, the governance of your cloud components. And if we talk about the cloud migration, there are, it's called the 6R, so six strategies of how to model your cloud migration. And the 6R would be in the rehosting. So you just lift and shift. So you just, yeah, take your on-premise world and shift the infrastructure to the cloud. You can re-platform as you lift your on-premise, you tinker a little bit, so you change, for example, the infrastructure, and then you shift it to cloud. You just re-purchase. So you move it to some, you move your on-premise world to some star solution. And refactoring, and this is, yeah, the best way for cloud native transformation. So you re-write your application code that is compatible for microservices. Or you can just retire your application or you retain, so you do nothing. So these are like the main migration strategies from on-premise to cloud. And after you have migrated to the cloud, you have to govern your cloud. And if you want to govern your cloud, we have experienced these clusters, which our customers discover at the moment or complain about. They do have like a missing visibility. For example, they're like hundreds of AWS accounts discovered that they didn't know about. Or they do have some uncontrolled cluster whisk. For example, they're using like some VMs or they bought some VMs, which they're not in use. So they have, for example, like 25K every month, which they shouldn't have to pay. Or they have slow response times because they just don't know the owner of the cloud account. So for example, there's like a ticket and they have to fix an issue. And it took them like five days to find the responsible for the specific microservice or the cloud account. And I want to show you now how you can use Linux for your end-to-end cloud transformation and your governance. So you can start to assess your cloud awareness. You can then plan, execute your migration. And then after the migration, you can establish your cloud governance. Now I want to jump now in every of these eight bullets in the following. Okay, so let's start with, let's start in the Lena eggs enterprise architecture suite and how you can prepare your migration. So first of all, you should build your image railway and collect your data, for example, through surveys. So you could conduct a survey for each of your applications. And then get your application owner, get the business criticality and get them equation strategy and considered here. I included in the survey, the business owner, the business criticality and the migration strategy. And you can do this for all of your application infrastructure within Linux. Second step would be to analyze my equation strategy by application. And after the survey, you can see here now, we do have some nice reporting where you can see the migration strategy of every application group by business capabilities, which you can see here. And then in the third step, you could also model your impacts. As I told you beforehand, so you can say, for example, for the migration strategy, we hosting, we do have the application LS law plus, we want to we host them to Azure. And we've, if we do this, that would impact our infrastructure, because we wouldn't need the, the HP application hosting anymore. But we would need Azure VM and Azure function, if we want to migrate them to the cloud. So we can model the or simulate the impact to migrate some some on premise components to the cloud. And we can do this for every application. So we can model for every fact sheet application impacts of a possible migration transformation. And now we want to plan and execute our equation. So we want to see the dependencies to other projects and epics. And then we could use our transformation world map. So we could see, depending on the initiatives on the project phases, how are they dependent on each other, how are they aligned. We can group them by business capability and objectives. You can see here the different work packages or transformation world map. Next step would be, you can now project or simulate the future state of your landscape. So you can select a possible scenario or transformation plan, for example, your scenario be cloud transformation. And then you can jump to a specific time stamp. For example, here's June 21. And you could see the changes in the heat map. You could also jump, for example, now to November 21 or 22. Or you could go back to the past. And then you would see nicely the changes of your heat map based on a specific transformation plan scenario. Okay, now it's step six. We have migrated to the clouds. And now we want to see, yeah, you want to see, you want to gather the clouds. So you want to have some KPIs for the clouds. And we could use our cloud network suite. We could get some nice KPIs on our use on a managed cloud infrastructure. So you could see the ratio of use type of scalars like the ratio of AWS, GCP, Azure. We could use our, we could see our use cloud components based on the business context. As we can see here, security storage. We could see our cloud spend over time. And we could also get warnings. For example, the security warnings for criticality or availability warnings for criticality. And then, so this is like our main dashboard. We could also jump into the details. So for example, we could jump into the AWS Lambda function and then get details on instance level technology life cycle, tax, hosted region, your business context, some classification or violations of this used IT component. So you can have both like a sort of management dashboard, but also jumping to the details of every cloud component. And then the last step would be to mitigate these issues in your architecture. So you can have a connection from the technical view of your cloud to the business view of your applications. In that case, I'm showing the application gain side. Gain side is using some AWS Lambda function. So some infrastructure as a service component. And you can see here by clicking on this icon, this is end of life. So there's a technology risk, which was identified based on automatically based on cloud native suite. And now we should try to set up some mitigation, because otherwise the usage and of the application gain side is at risk, because we're using some Lambda function, which is still using node JS, which is deprecated. Okay, to sum this up. We think that a successful transformation requires pragmatic planning and automatic tracking. So first step is you need a transparency on your assets. So it's, you need, yeah, it's really essential to start the transformation. You need transparency of your assets infrastructure. You should only model brings you added value. So don't model too much just model just enough to take good decisions. You also should apply aggregations and simplifications. So if you want to keep an overview about your use cloud providers, you have tons of details, but you should aggregate them. In for example, as I shown to you the dashboard to apply them and get a clear overview of what is needed to keep control of your cloud infrastructure. And you should focus on automation. So use integrations, use automation to track your technology, but also the impacts of your technology on your business and your coast on your security. Hopefully you're still around for for a quick question where we're sort of out of time, but Yes, I am. I can hear you, but I can't see you. Okay, that's good. That's a good start. So the question came in and talking about trans transitioning to the cloud, the process of transitioning. And I know you had some slides that showed some steps, but for me, the key part of the question is that how have you seen the process that with your customers take? How have you, how do they go about deciding what goes in the cloud and what doesn't? And normally, normally they, they first of all, they, they try to assess their components. So they try to set up a migration strategy. So as I said, like the six hours, so they set up a migration strategy, they assess for some using surveys of the technical fit and the business fit of the application. So first they want to assess like whether or not they want to invest in the application or not. If they want to invest in the clouds, they set up like a migration strategy. If it's like a long trip application. They want to like apply the equation strategy for and they V a ask the application owner about the it components of the application and the application owner says, yes, this this application could be suited to be to get my credit into the clouds or not. And depending on that decision, they can, for example, just lift and shift. They just just put like, they just shift to the cloud using some infrastructure service or they do like a total refactoring to the cloud native world, for example, like changing the application and infrastructure and setting up a micro service. So it's really depending on the in my opinion, depending on the assessment of the of the application owner and the entire migration strategy of the company. Thank you. Well, Kai, we're out of time. I know you've been answering it looks like you've been answering some questions in the. So if anyone else has any questions for Kai, then please do please do go through the channel in the meantime. Thank you once again to you personally for your for your presentation and to be nice for being our premier sponsors for this event. Thank you for your support. Thank you. Thank you.