 OK. Thank you, and welcome back. I will start with a presentation on how to use IT for IT to become more ready for DevOps world, let's say. We are in the middle of an unfolding era of digital transformation, and a lot of disruption is coming to us, which challenges how the IT function is organized today. And you see more and more demand for more flexible agile IT organization, and it's expected that the organization will be much smaller, leaner, agile, brokering, and integrating services from a lot of different vendors. And more and more organizations, they realize that the current IT operating models, they do not survive anymore. We need to reinvent the IT organization, and that's what IT for IT can provide. And this presentation will help you and guide you to how can you get started with IT for IT in your own IT organization. Now, a little warning up front. I typically talk a little bit too fast, have too many slides, but we have a small audience here, so we can at least, if there's any questions, if it's not clear, you can interrupt me. So what I want to do is go through the key challenges that the IT organization has in the sense of, how did we run IT in the past? What do we really need to do? And what kind of capabilities do you need to run a new and agile IT organization? And how can IT deliver that in a sort of roadmap? So, first let me start with providing an overview. I mean, this is probably known, right? But there's a lot of things coming to the IT organization nowadays, or the IT function, I must say. And on one side, you see the demands from the business to enable digital transformation, becoming more responsive to business demand, enable new business models, provide more transparency and traceability, also protect the traditional business from new entrances in the business that are more lean and agile like new startups. And at the same time, it's asked to lower the cost of IT, reduce the risks, rationalize the current portfolio, because a lot of IT organizations, the portfolio is very big, a lot of legacy applications, and often the organization doesn't even know what kind of application service they all provide. So, and at the same time, the IT organization is asked, yeah, do use cloud computing, mobile, big data, software defined, internet of things. We talk about API economy using containers. There's all the things that will come to this IT organization. And then we have different new IT management paradigms, such as containers delivery, dev ops, agile, lean, B-modal, multi-speed IT, more self-service, automation, infrastructure as code, right? There's all these things coming together at this moment. And I think it's very unique that in the last 20 years, there's never been so many changes and demands for the IT function. So there's really a change happening in the IT industry. So in the middle, you see, how does the IT function need to respond to that? Is there a sort of new IT management engine needed to manage this new IT reality? I hope this is complete. If you miss anything, just let me know. But this is the reality where most IT organizations are dealing with. Now, so the question you could ask yourself, what is the impact of the digital enterprise on IT management? Because IT management needs to be more responsive to business demand, for example, and be able to manage more in an agile way in new services, and not just introduce a new service, but then continuously update and maintain it and decommission when you don't need it anymore. Just an example, how do we manage the cloud? In the cloud, the infrastructure services are managed differently. Think about infrastructure as a service. You could have patterns and policies that automatically spin up a new server, like in a cluster. You have a web load balancer and web servers. If you need more capacity or resources, it will spin up automatically. If it's not needed anymore in the weekend, we turn it off. How can you maintain the CMDB in that kind of situations? Service will be up and down all the time. So the way we manage IT in the past will change as well. And the same is for servers. We're not going to upgrade servers anymore. We're just going to remove them and replace it by a new virtual machine, and then the application will be provisioned on top of that. So the way we manage in the cloud and automation will change. Another concept that you have is like the containers. And the question becomes, how do you manage containers? And the way we deploy a new application service to the business. Maybe you've seen the program on TV container wars that people have no clue what's in a container. I need to bid on it and see what's in there. Before you know it, we have the same situation. We don't know what's in the container, what version it is, and et cetera. So those kind of topics pop up. Another example is, how do we manage the explosion of the number of apps, infrastructure services, APIs that we need to manage? Because at one end, we say we want to rationalize our application portfolio, reduce the number of applications. And at the same time, we get smaller applications, APIs out there, microservices. So we've got more and more components to manage, which all need to be updated and maintained. And then we look in the IT organizations, ask, OK, what kind of practices in the market can we use to really manage this new IT ecosystem? And here you see a few examples. But we've got so many standards, and frameworks, and practices in the world from IT. And they're typically focused, like we have Toga for enterprise architecture, PMBOK and PRINCE for project management. We've got ITEL for covering a lot of the service management processes, ISO, and Baabok for business analytics. So you can continue doing that. There's so many practices out there. But in reality, you only use a few of them and only partially. Now, IT for IT is bringing, it doesn't replace this concept. But it's bringing the glue and bringing it all together. I hope we'll discuss that later as well. Now, IT management is complex. And this picture is a picture that is the management landscape within Shell for the IT management estate. I'm working at Shell as an IT management architect. And this is what you need to run an IT organization. And of course, there are possibilities to rationalize. But in reality, you need to have your portfolio management system where you maintain your portfolio services. You have your projects management. You've got your development and testing tool deployment. You've got a portable, people can request services. We get an IT financial management system. So we have insight in the IT costs. We've got intelligence and reporting environments. We have for risk management systems. We manage the risk of IT services. And of course, monitoring tools to monitor the different kind of environments we have. And security management. And I can continue with that. But these capabilities, you do need to run your IT organization. Unfortunately, it is just complex. There's so many components and so many moving elements in there. Now, if you think about what do you need to run an IT organization? This is basically what it is. It has a list of activities you need to perform, like instant management or business continuity management, managing the cost, do development, test management, manage contracts, do supplier management. There are more than over 30 processes you need or activities you need to perform in your IT organization. And there's nothing what you can say, I'm going to skip it. There's all you need. You can do it lightweight. But you need to manage your contracts. You need to do monitoring. You need to have test management. The same with the data. If you look at how much data you manage in your IT organization, it's overwhelming. And it's more than 100 different data entities that you manage. And that ranges, again, from requirements, projects, costs, budgets, events, incidents. It could be monitoring data, your source codes, and so on. There's nothing that you can remove from this picture. There's all the data you need to manage. The problem is today we don't have insight in that data because it's scattered around across a lot of tools and processes. And then we have our call it the information system, so the tools you need to run IT. These are all the things you need. There's over 50 type of management tooling that you need. And of course, you can buy a sort of framework tool that supports multiple capabilities, but it's still complex. You have a risk management system for managing your risk, your project management, your monitoring tool, deployment tool, self-service portal, CMDB, financial management, all these capabilities and systems you need. Now, IT5T is bringing this together to get a more structure of how to manage this complexity. Now, if you look at your own organization and you think about what does it take to get from a demand and get it into production. So we get a demand from the business, develop the service, and then deploy it, and then maintain it. It's not uncommon that this is more than 100 different tools that you use to get this demand into production. And what is the problem is that most people in the organization, they don't have the visibility. What happens from a demand to get something into production and get the value realized? If you ask people in your own organization, how does that work flow? There's a demand coming in, who does the approval, who get the portfolio, we do an investment analysis, we're gonna do the build and the development or we source it and so on. There's probably no one in your IT organization that can really draw this entire end-to-end value chain out, understand the data that is needed, understand the tools that you need to do it. And that is a challenge, because if you don't know it, this is just an example of the solutions you need. This is what we need to engineer. We need to automate, simplify the end-to-end process. But if you don't know how you run it today, it will be challenging to improve. And here you see what kind of components you need from a demand to get it to something in production. And that ranges between developers' tools like having a source code or do code checks like security or vulnerability testing. It also includes email and collaboration tools so that the developers can discuss items with, for example, other people in the business side, license management, monitoring, and so on. So, one of the messages here is we need to understand that end-to-end flow and how we support this by automation and tools and data and processes. Now, what happens if you have the key stakeholders on the left and they need to find information in your IT organization? Like, you are the product owner or a service owner. What as a service owner do you want to have information need? So you need to understand what are my services, how well is it performing, what are the risks, what is the cost, when is a new release coming, how does my backlog look like, and are there maybe audit findings I need to act on when is a contract end of life? All those information, the product owner need. Well, today they don't have that information. It takes them a lot of time to find all the information they need to really work on their responsibility area. And the same for a project manager, risk analyst, and so on. So you can imagine the complexity that IT organization is handling today. It's not having the insight and there's a lot of lost productivity for people to find information, creating spreadsheets, maintaining that. And this is due to the fact that in most cases, almost in any case, this whole information systems or the collection of data have never been designed upfront. It's just historically grown with new tools, new solutions. So it's never been engineered or designed from an architecture perspective. And that's what IT 5T will try to resolve and say, let's design this and work on the target state. Now this slide make itself clear, right? We never really designed the IT function within the IT organization. So we have fragmented tools, data, repositories, many handovers, and a lot of spreadsheets as well. And some people believe that we don't want to automate this because they said, if I have a spreadsheet, I may have the ability to modify the process and tweak the data. So some people really like that. So somehow we got away with this. In the past, the IT organization got away with it. And I was thinking, maybe I should write a book on how to manage IT badly and still get away with it. I didn't publish it yet, but this is what happens, right? We really got away with it. We managed IT badly today, I could say that, but we get away with it. So what do I mean badly? We don't know what services we provide to our customers. We don't know how well they're performing, what does it cost? We have no, the seem to be is not up to date. It's all, we don't know where it's running and which service or databases. A lot of manual activities, a lot of technology depth. We got no monitoring. So the end users need to call the service desk. And of course we do have monitoring in some cases, but if you think across all your services, it is not that good. The administration of IT is not that well defined. And how did we get away with it in the past is because we got people solving it and we got a lot of flexibility. So in most of the cases, the application perform okay, right? They do perform, but maybe the high cost. But because the flexibility of people, we got away with it. But now this is changing. So what will happen in the future is we got away with it in the past, but I can assure you that in the coming years we will not get away with it anymore because there's a lot of things changing. First of all, we get more service providers where we need to work with. You know, we're gonna source that to other vendors and we need to work with them. We got more applications and services. They'll be maybe smaller, but we have to have them more. We have more releases and changes. We do continuous delivery. We don't wanna wait six months for a new release. We have it more continuous. Maybe not for all applications, but a lot of them. So you've got more releases, more changes, more security events, more incidents, increasing consumption of IT. We got more storage usage, more IT data, more interfaces, and more devices connected. So we have to do more. So the IT organization is really stretched beyond its limits. So, and at the same time, of course, the risk needs to go down, the cost needs to go down, and the time to market needs to go down. If we do operate the IT organization as we did in the past, it will fail, yeah? So the new IT organization needs to focus on how can we make this end-to-end flow work? How can we automate end-to-end workflows? How can we make IT data transparent and support the business of IT? And that is what IT-to-IT can provide to you. Now, I got a short video. I promised you that small video about how IT-to-IT turns the world upside down. It's a palindrome. You watch it from one direction, and then we turn it back, and I hope you enjoy it. End-to-end IT management is an illusion. I would lie if I said this is about to change. And I believe that it's impossible to manage the new digital enterprise. We should never think to gain control over a complex IT ecosystem. It is possible through modern IT management tools can no longer be said. It is just the way it is. IT specialists need to adapt to tools from different technology vendors. That is the new way of working. Having one integrated IT management system is way too difficult. To log in to many different portals and systems, having different processes and data models is the only solution to manage the complexity of the IT landscape. Simplifying things for IT specialists, that is unnecessary. The IT organization is out of control. But IT-to-IT turns the world upside down. The IT organization is out of control. That is unnecessary. Simplifying things for IT specialists to manage the complexity of the IT landscape is the only solution. Having different processes and data models to log in to many different portals and systems is way too difficult. Having one integrated IT management system, that is the new way of working. Tools from different technology vendors need to adapt to IT specialists. It is just the way it is can no longer be said. It is possible through modern IT management tools to gain control over a complex IT ecosystem. We should never think that it's impossible to manage the new digital enterprise. And I believe this is about to change. I would lie if I said, end-to-end IT management is an illusion. So that is basically the message, right? We believe it's impossible, but I think it would be possible with IT-to-IT. Now, this is the IT-to-IT reference architecture. You've probably seen it before. And I will not go through all the details, but what typically happens if you talk with larger IT organizations and talk about IT management, I show these pictures and I show, okay, what do we need to do to improve the IT function? Now, there are a few challenges, but I will show them later. So we would like to explain to the IT function to say, let's make IT flow end-to-end. So it's from strategy portfolio where the new demands come in, what portfolio decision need to take. Then you're gonna develop and test your service. People can request and subscribe to services and then you need to monitor and act on incidents and security related issues. So we got the dev and the ops that's covered by IT for IT. And this is what people still understand, right? And then have the continuous feedback loops from production and we wanna focus on the value, eliminate the waste, automate things, optimize and get more transparency. So that looks all fine, but then if you look at it, people said, well, and that's most of the comments I get from IT, the CIOs or other executives, they say, well, it's really nice that IT for IT, but for me, that's much too big. We cannot bowl the ocean and this is too complex, too big for us. And also, we have no budget. We have no budget to implement this, so there's no go. Also, it's not a greenfield in most cases. We have a shop to run. So if it was a greenfield, it's fine, but we have a running shop, so there's no way we can implement IT for IT. And other people, they say, well, I'm already doing this. I'm working on it, so I've solved it next year. So don't worry, I don't need this. Or they say, I don't have any time at all. Now, I will show you that all these reasons why not to do IT for IT, they're all not correct. We'll go through each of them. So let's go through what you already do today. So I ask them, what do you do to improve your IT function and make a list of all the things you're doing to improve the IT capability itself? And we try to plot them on the IT for IT value change. Now, typically what most large IT organizations have are many different initiatives to improve the IT function and they will not stop them. They're already doing it. So there are people working on improving the self-service portal, or they wanna introduce scrum and agile development. So they're implementing solutions and work practices for that. Or the business asks for application performance monitoring. They'll be more inside of how an application is performing for the business and the ability to diagnose performance issues. So they have a project to do the continuous delivery pipeline and implement that with all the development and continuous integration tools and deployment automation. There's a project for software asset management because there's an issue with the licenses. The CIO likes to have a dashboard. There are log analytics. We got security monitoring, of course, test automation. We need to implement the test automation capability. And cloud infrastructure provisioning. And we move to the cloud. Cost transparency, of course. The CMDB is not up today. So let's put a project and do some discovery and we will solve it. We do project portfolio management because we need to replace the current system and we wanna be more agile on portfolio planning so we need a new project portfolio management solution and manage the ideas on the road maps. We need service catalog. Identity and access management is a key one. We need to work on federated identity and access management maintain who has access to which application when they're moving end of life and so on the knowledge base, predictive analytics, big data and DevOps. Now, I said, so you're doing all this and you say you don't have money and time for IT for IT because they do this, right? The only problem is you're wasting a lot of effort here and a lot of money because you're all fragmented initiatives and there's a waste of money to invest in this at the same time without having a vision of how things integrate. So you're actually wasting money. So you have the budget. You are having the time because apparently you do these projects via four or five, six times and it fails. So you have, so basically what IT for IT messages, you're doing this anyway. You need to do it anyway. So there's no excuse that it's too complex or that you don't have budget or you don't have time for this because you're doing it already, only fragmented and not from an end to end vision. So if you understand that this is already working in your organization, only it's fragmented anywhere and on different places. That at least let's build a vision or where you wanna go to. So that we say, okay, current way of working is fragmented and we build a picture of how do we foresee the new IT organization to look like? Focusing on value streams, integrated systems, more automation, be able to flow demand through production that you can follow that and have the ability to support continuous delivery and DevOps. So that is basically what IT organization typically said, yeah, that's what I would like to achieve. And then how to achieve it. Now this slide shows you briefly what the approach could be on implementing IT for IT and there are different ways of doing it. This is more like to get started. So IT for IT is a good reference architecture today to get a quick start and analyze how you're doing it today, where can you get improvements and then have a sort of roadmap to continue to improve. But first of all, you need to understand as one, the IT for IT reference architecture itself. Now there are trainings programs to do about that. Andrew will talk about later on this topic. And then we need a good understanding of the current IT management landscape because typically what most businesses do not have if an understanding how do they run and operate IT function today? They have no clue what tools they have, how they're integrated to data. So you need to get a good understanding of how do I run it today. And that could be per line of business or maybe if SAP is run differently than more Java development lines, then you need to understand that. It's really, it's good to start with that because there you learn how it's run today and you see the issues immediately if you have that picture. Then we need to create a common vision because you need to have a common vision of what is the future IT organization gonna look like. And for example, we wanna use the DevOps, more agile self-service portal, more automation and how do we position a new IT organization with the plans that the business have to become more digital. You need to have that vision and document that and share that with the business. Then it's also important to discuss the IT for IT governance model. Who owns the tools, the processes, the data and maybe we can organize that around the value streams. I will come to that later. So they have clear ownership and people working on the value chain instead of loosely coupled tools. Then we have the portfolio backlog and define a target architecture. So important activity there is work with the different lines that are using IT for IT related capabilities to building a target state. So what are the real capabilities I need? So if we talk about a more lean and agile IT organization, we should think about, okay, are the tools that we have and the process is also lean and agile. If we have a change approval that we need every time when we wanna deploy in a continuous basis and we need to change the processes there. We also might need different solutions that fit into this more agile and lean working, simpler tools, easier to use. So we really need to build that picture of, okay, how is my target landscape gonna look like? And then I can build a sort of roadmap, a portfolio backlog of, okay, I cannot implement it all at the same time but it can come with an approach to work on items that I need to start first. So if, for example, test management is important or maybe monitoring, we can build a roadmap on that. And then we need to develop end-to-end scenarios. So there is a, we need to explain in a new way of working, how does a requirement come in and is it developed and tested and deployed? How does that workflow looks like? And what is, as a service owner or product owner, how can I see the data and how can I follow that process? Or if I'm a developer, what can I do and what does it benefit, does it give me? So the end user scenarios and epics are a key one that you need to define for the key personas in your IT organization. And then we start to implement the pipeline gradually and it's a continuous implementation, right? The IT for IT is not something that you implement at once. It's a continuous updating of the architecture. It's reviewing it, tuning it and modifying it. And a key mechanism that we need to do is to explain to the business how we will be working in the future is creating a model office. I will come to that later. Now, there's a lot of lean people in the IT organization typically, so they like this approach. So we call it value stream analysis. We try to understand the entire value chain or value streams that could be coming in requirements come in and how will that be fulfilled? Or there's an incident or an exception detected how is that resolved? Could be a security related event and how does that release corrected end to end? Or where's a new demand from the business? How do we get that into a production environment? So you need to start with the end to end flow. Now, as I said before, this flow is so complex that most people don't even have that picture on one wall, but we need to build that picture. So my experience is if you work with a number of people from the portfolio side, for the development and for operations, you need to define how does that flow work in reality and understand the data that is used in the systems. So you look at, you need to go see that. You really need to understand how did he actually doing it? Because one of the risks is that people tell you, this is how we're actually doing it today, and reality is something different. Typically we'll say, well, this is how it works, these are the systems that we use, but if you go see, there are many more tools they use, there are many more activities they perform that they will not think of if you'd ask them. So we need to get those, how is the work managed? Ad hoc work, plant work, where are the queues, where are people waiting, what are the key lead time? So you have an understanding of what's going on in my IT organization. Now, and as I said, you also need to understand the tools and the spreadsheets that they use, of course, because Excel is still the most important management tool out there today. So, but then we need to understand, in this picture is the IT for IT, a simplified picture I would say, is understanding where if my work, so you have different queues in your IT organization. You have a portfolio backlog queue, you've got a product backlog where the agile teams are working on, there's a problem queue and an instant queue with service question changes. This is where all the work is managed in IT organization. And if you're moving to DevOps, you would like to understand all that work, how can I prioritize that better? Because in the DevOps, you might work on an incident and then work on a new requirement or you need to fix something or you need to fulfill something. So this is important to understand how is work distributed in your organization? How many queues do I have? And typically different solutions for that. Now, one of the challenges is that if you, the next step would be is to identify the waste and issues. Well, that can be easily done because you work through the process. Typically you can easily identify all those issues across the entire life cycle. So you try to plot them like this. For example, we don't have a good funnel of managing the demands or there's no requirement traceability or it takes a long time to infrastructure, to deploy infrastructure resources for testing. So we have an agile delivery street but we cannot easily get a new test environment up and running. So testing just by itself takes too long because it's manual testing potentially or people are not available or the approval of my changes takes too long. There is the seem to be end up to date. We don't have self-service. We don't have monitoring, utilization data not available and the contract with the vendors are blocking innovation. So even if I want to deliver faster, the vendor says, well, we have an SLA with you and it takes three weeks. But the challenge becomes because once we have identified these, what they call nicely impediments, the issue is that people think, oh, let's solve them. Let's remove the impediments and then it will start working. And typically that's not what you should do because if you have the impediments here and try to improve them, it doesn't really add that much value entwined because what we forgot is but what is my new process gonna look like? I'm not gonna fix all these things. I first need to think about what is the most optimal way to deliver an entwined value and that's probably not the way we currently work. So often businesses will start with this and say, okay, we need to update the C and B, it's not up to date, we buy a discovery tool and that fixes our problem. And I say, no, it will not fix your problem, it only makes it worse, you've got more data to manage and not more insight. So we need to tell them, don't go try to fix all these individual components but first do a step back, right? And that's what IT5T tries to tell you as well. Look at the entwined flow first and now try to plot how you would like to work in a new environment and how does value flow through the, from a demand to production, for example. So, and then it's more the architectural work. Is there a common data model people can agree on? What are the key roles in the organization because it will probably need, we need to change roles, we need to combine roles or changing what are the metrics we're gonna measure because if you don't have clear defined metrics, how are you gonna improve? And of course the idea is to automate more activities in the entwined chain. So we're gonna think about what are the automation opportunities out there? But we have to design this first before we starting to resolve all those impediments and issues and bottlenecks. Now, this is maybe a difficult slide but you can imagine, you're working with the business to say, okay, how does my new architecture look like? There's a value chain, what kind of capabilities do I need? What is the data and so on. So you work with the business or the business of IT on what is my data model? Where is it mastered? Who owns data? If contracts, where are the contract managed or the licenses? Or where do we manage the catalog items or the patterns for infrastructure provisioning or the licenses and so on? That's already challenging. Now, of course, people typically come back and say, okay, now I need to select what tools that we're gonna use in the IT for IT landscape. And we have to be careful with that because we're not talking about tools per se, we wanna focus on value chains but the discussion is relevant. So there's so many vendors out there providing IT management tool capabilities that you can imagine if you wanna integrate that all in your own landscape, it's challenging. So you have to be carefully select those vendors and tools that you could say, I'm able to integrate. So if you have Microsoft, for example, for your development and testing, can you integrate for your development? Can you integrate with HPLM for test management, for example, or integrated with deployment tools and so on. Because it's a very complex landscape out there with a lot of vendors and they're continuously changing their offerings. So one of the things we need to do is really select the building blocks in our IT organization, what are the solutions we're gonna use, what data will be mastered there, who will own this, but try to do it from a value chain or value stream perspective. Don't try to say I'm gonna implement test management. That probably doesn't work. We need to think about the whole chain from a requirement to deployment and test is one of those capabilities you need. And typically it doesn't make sense to implement the test management system, spend a lot of money because it probably takes you two, three years before all the projects will actually use that system. So you need to come a different way of introducing new capabilities. Now, IT, this looks simple maybe, but it's complex, but it's even more complex because if you look at, this is the pipeline end to end. So DevOps typically only covers the subset of the pipeline, but we need to extend entire pipeline of IT by IT. So it covers portfolio management, investment planning and then the backend, the costing and charging. But typically you have different pipelines. For example, you have application you develop yourself like on java.net. You will realize that a number of those components and workflows you need to do that are different than from a past application or a SaaS or package based, but you also need to develop your own infrastructure service or source them in. So you can imagine different pipelines you need to maintain depending on the characteristic of the technology. Now hopefully a number of technologies are the same. So portfolio management typically you can do for all these pipelines the same way because it's technology independent. But deploying java and deploying potentially a package based application might be slightly different or you need different components for that. So you need to build that model as well. Yeah, just this is more like a slide that I should not forget to mention because we typically started to talk about tools, information, system and data, but it's also it's not just about the tools. It's about the mindset in the IT organization. And the mindset is about let's create that end to end value. So if you are a developer, for example, developers typically have a mindset to say I select the tools that I like to work with and a tester may do the same or somebody from security says I know a nice security management system and I select my own. And that's also part of the mindset. We said no, we don't want maybe the best security monitoring tool because most security monitoring tools they come up with events and then what then? We need to say, okay, what does the server is linked into? That's what a security monitoring tool can do. But after that, those tools don't have no clue what's running on that server which application is affected. Is it business critical or not? So the only value you get out of these tools if they can be integrated with the CMDB or to an instant management system. So we need to have a different mindset and say we select the components that integrate very well where we get the insight and we need to work together to define this tool set. And of course, in some areas you could have like a developer could have his own tool for coding because that may be less affected in the engine chain. So you give that flexibility. But if it's about source code management you could have debates about whether it's the best source code management system if we don't need five or six different source code management repositories if we can have two different vendors maybe that's sufficient. So you need to have that discussion about integration, getting the value out of these systems and tools. And that requires a different way of working together because in an IT organization and you will probably know that as well every team or every department thinks he knows better. They have looked at a performance monitoring tool in the market and say, ah, we're gonna need that. We're gonna do a proof of concept. And I said, no, we're not gonna do proof of concept all everybody by itself. But what we're gonna do is, that's what's the slides coming later and we're gonna create a model of us together. And a model of us is a kind of experimentation or sort of integration lab where we can say, okay, we have these core solutions and processes that we use end to end. And if we think that we need to extend that with a new monitoring tool, we bring it into the lab and say, okay, how does that integrate with other solutions we have? So instead of having a pilot again in different places in the organization we control it into our integration lab. People come with ideas. We have room for experimentation. We're gonna demonstrate to the IT and the business how the new flow will work. We can get their feedback. So we get people involved, but still controlled in an environment where you can show integration is important. So if we do a proof of concept, it will be done in this environment so we can demonstrate the value. Now, going back to roles and responsibility, that's also a key challenge. In a new IT organization, we need to define what are the new roles and skills and competences you need. Now, this is not complete, but you can imagine a new role like a service owner that you have that is really end to end responsible for both the development and operations and the cost and the risk. That is really a change in your IT organization where that's typically split. So we need to think about those new roles, what they're accountable for, what information do they need and how can we engage with them. The same for people responsible for consumption and cost management. There's some kind of new role. We didn't have persons that really looked at that or an IT data analyst, for example. Now, this slide shows you a bit about how do I govern IT for IT and you don't necessarily have to do it like this, but this is a typical way that you would like to do it from a portfolio perspective. You look at all the IT management capabilities you need and then you have, it's like a skilled agile framework approach that you have persons responsible for the different value streams. So somebody's responsible for strategy portfolio and that person looks at the portfolio of services we have for project management, for example, enterprise architecture and investment planning and they develop together with practitioners, how does that end-to-end process look like? What solution do I need? So you have four, in this case, four value streams plus the supporting activities and they develop the value stream epics. They think about basically the requirements in that sense, the data model, the integration strategy and that's all driven by an overall roadmap that's done on the portfolio level where you have people responsible for the IT for IT vision and portfolio as a whole. Now, typically what you have is a different and it's not different than software development we were used to have. We have different teams called agile teams working on the different IT management, we call it applications. So we have a team working on project management tooling and it's a team on test management or financial management or service monitoring and all those product owners of those solutions they need to work with the value chain owner to say what is the priority for this release if we're gonna change capabilities in our seem to be or our risk management system and so on and focus on the integration. So, and this is really challenging, I can assure you to get this up and running in your IT organization because typically what you see is that the project delivery is done by a different organizational team and maybe even spread around the same for development and testing and operations and financial management is even across all the functions so really challenging but setting up this government structure with really is essential because then you get a discussion going with all the users of your IT management capabilities getting the priorities set up, creating a roadmap, identify the user stories of how are we gonna work and as I said, building that integrated lab. So, and maybe to come back on that. So, most organizations already have all the tools and processes in place that we just discussed but they're not very well organized. So, how do we implement this? Now, one option is of course to say we start with a value chain like strategy portfolio we're gonna implement that first. That typically is an option to do but the other option is to say we just take a line of business end to end and we're gonna look at the end to end picture from portfolios, development, testing, deployment and we try to in the model office build that for that line of business for those set of applications we're gonna build the whole pipeline from a portfolio backlog down to the deployment and monitoring. So, it's a lightweight, very small for one specific set of applications. Once that is proven and shown to work we can then extend it to other blind and businesses, other application teams. So, and that seems to be working very well because then you can demonstrate it quickly because typically what happens if you talk about this most of the time people said, oh yeah but we're already doing it. We're working on a continuous delivery pipeline so don't worry, at the end of the year we have this kind of capability you're looking for and so, and they said no because you probably think you are doing the right thing but we need to work together to really build it in an integration lab demonstrate it to the business and the users and then you'll get that feedback. Now, so this picture shows you how most of the time also within Shell and other organizations that we say build that continuous pipeline of things and themes we need to do in IT organizations so it's like similar as normal development practices you use it also for the IT for IT portfolio build the backlog of items and then monitor once they're done whether they actually deliver the outcome. So, if we implement some monitoring capabilities and we prioritize them and we build them in a model office and in production we wanna make sure that we deliver the outcome and demonstrate to the business what the value is of IT for IT and how much what we invested but it's also bringing new value for the IT organization itself and the business. This is an example of a potential roadmap per value stream but let me not go into that in more detail but you can imagine you need to prioritize work that you're gonna do in different plot, let's say iterations or releases and typically what you see here also you're gonna work on all the value chains or value streams at the same time. So, you do something on portfolio management or you do something on monitoring as well so that's the challenge, right? You cannot say I'm only focusing this here on strategy to portfolio you're probably doing all the different things in parallel. Now, as you know most IT organizations they are thinking of moving to a digital enterprise and they like to become more innovative and more resolving the demands from the business in a quicker way. So, any organization is working on that, right? We're all working on getting to the digital enterprise rationalized portfolios, mobile, internet of things but typically what you will see is if you don't have the IT for IT architecture in place that there's a likelihood, very high likelihood that all these initiatives will fail. You need to be able to manage the new digital enterprise you need to be able to manage the cloud, the internet of things, the different kind of big data service that you're gonna develop, right? So, this is a screen that I also get a lot on my laptop nowadays but so when the boot is failed your IT organization has a number of options I'm not sure if you've seen this screen but so there's one option that you could say we do troubleshoot and you try to reinvent the wheel yourself that's what a lot of organizations are doing today they don't look at IT for IT and they try to solve it their own way and of course there's also an option just to turn off your IT organization but I hope you will choose for the top one and is to continue and accelerate your IT organization and then use IT for IT to do that, okay? Thank you.