 See, DevOps is a concept that is used a lot nowadays. If you look at annual reports today, and let me go one slide back, there's a lot of annual reports. If you look at that, you see that most organizations are thinking about this digital enterprise. And even in the annual reports day, they mentioned that they wanna rationalize their service portfolio, eliminate legacy, move to cloud, adopt new technologies to create this digital enterprise and enable new business models. And so now in the IT organization, you are basically challenged to deliver that promise. And this is the diagram that shows that a bit, is that the demands from the business is changing, the market is changing, the IT organization has to change, and also the way we manage IT needs to change. And a lot of organizations realize that, but there's still a lot of IT organizations that don't see the need to radically change their way of working. The organizations that do realize that, they use DevOps as an example of an approach and continuous delivery. And during this presentation, I would like to show you how DevOps and continuous delivery is basically, can be enabled by IT for IT. Now, looking at the digital transformation, there are a number of key changes that the IT landscape is going through that changes the way we need to manage IT. And one of them is of course cloud, and we talk about hybrid cloud, you have your clouds internally still, but also externally with many different SaaS paths and EOS vendors. And as a result, you have a lot of vendors to manage. So it's a multi-vendor sourcing network that you get, and you source services to multiple parties. Typically, the traditional outsourcing was like in Shell, that they source initiatives to three big vendors, and they have three big towers. And now they're thinking about changing the way we source items, smaller batches of works, our sourcing to different vendors, and cloud vendors as well. So you get more vendors to manage. Now, at the same time, you can see that yourself, that we look at new ways of delivering services using microservices. We have API economy, they talk about it now, have many different interfaces with different components. Everything needs to be service-defined, so you have infrastructure as code, and you define services as code, basically in a source code repository, and use new technologies like even blockchain, for example. So there's a lot of new technologies coming, but I think the key ones are the cloud and the multi-vendor sourcing model that impact the way we manage IT. Now, a large amount of IT organizations, and I'm currently engaged in a number of financial institutions, and they see DevOps as their primary change of the way of working to enable this digital transformation, to enable the digital journey. So they look at DevOps, continuous delivery, and agile development. And at the same time, they see the need to, for example, explore infrastructure as code. Can we make an application pattern and refer to standard infrastructure patterns and then deploy based on basically infrastructure and application as code? They use containers or serverless computing microservices. So they try to combine a lot of things at the same time, and at the same time, implement agile practices and DevOps. Now, before we go into the details of how ITVIT can help DevOps, I would like to first talk about DevOps in a little bit more detail. So we know that the business is working on a more agile way of working, so deliver faster, more secure, less risk, right? So it's the same as this diagram shows you, you would like to deliver in smaller chunks of work, release earlier, because that's what is delivered value to the business. If you have the software available or a solution and you deliver it earlier to the business, they can generate value, assuming that this software generates value. So you want to deliver earlier. The advantage of that as well is you get earlier feedback of this functionality and improve it with the new early adopters community and so on. So basically, by using this incremental approach, you deliver more value earlier and also reduce the risk because you don't have a big bang. Now, that is commonly known, of course, and people trying to implement this. Now, one of the key concept, and Gene Kim is one of those promoters of DevOps and the two of the books are shown here, the Phoenix Project, I'm not sure if you're familiar with that book, but it's really a nice story about the challenges an IT organization is going through. And DevOps is a key theme in this book. And DevOps is not the methodology, it's not about tools, it's about three key items that are shown here. So one is about really collaboration between the business and IT being development and operations together and creating cross-functional teams. So instead of having different silos, having teams that really have all the disciplines needed to deliver that value. But also it is key that Ops is included in development, so we think about the full lifecycle of a service. So we embed and instrument security, for example, during the development. We also think about operations, like automated provisioning and monitoring. So instead of just building functionality that the business need, we at the same time build functionality that you need throughout the entire lifecycle, like building resilience in an application. If it fills, then you can restore it by spinning up another component and it takes over that function. So that's one, it's a collaboration and the way we work together. The other one is also value streams and that's what IT for IT fits very well with DevOps. So within DevOps it's also about the value streams and creating value and it's about system thinking holistically. You're not focusing on individual component but make something work for the business and demonstrate end-to-end workflows and also visualize the work when something comes in like a demand before it's released in production. Can you visualize the end-to-end work stream through tools and methods to monitor that? And it's also about moving left. It's a similar as I just said about instrumentation. You want to prevent any defect resulting into production. So moving left is meaning you do everything upfront to prevent any rework later on. And it even is about investing in the right things. If you have an enhancement or a new user story, do we really need that? So it's about not doing the things that don't add value but also making sure that anything that can go wrong is resolved in the early stage. And then it's about all the continuous feedback loops. It's about continuously monitor, test, improve things and measure. In DevOps there's a lot about scientific measurements. We want to measure things and monitor things and it's similar in the lean manufacturing concept. Measure the right things and we can continuously improve. So it's a continuous improvement is a key item there. And of course you use methods like for lean manufacturing about smaller batch sizes and create a pool of work. Now, that is DevOps. But DevOps in reality doesn't tell you how to implement it. It doesn't tell you what you need to run a DevOps organization. So that's why it's interesting to look at how can IT for IT complement that. But let's first look at what DevOps needs from a information and system perspective. So although I have to stress DevOps is not about tools but I'm gonna talk about tools at this moment because one way or another, if you wanna implement a DevOps pipeline for example, you're gonna try to automate as much as possible, getting insight and data out of that. So we have solutions that people need for planning the IT work. Like having a backlog where all your user stories are stored, you have your analysis and design tools still needed. You've got your code tools where you do the code changing like an ID, development coding, having source code repository, do the code analysis. Then we have to build and continue delivery tools and artifact repository where we store those builds. Then we need to deploy it before we can test it. And we have orchestration, infrastructure provisioning, application release automation. And of course we have a bunch of different test components you need like automated testing but also security testing. We need performance and stress testing. So there's a lot of components that you need there and then we release it into production and hopefully the same topologies we have deployed for tests we can do the same to production and inform the users that something new has arrived. And of course then we're gonna monitor this environment and act upon the events. So, but there is actually more. So DevOps is typically focused on this but IT IT takes it a little bit further. It also looks at the portfolio side of things. DevOps teams typically have a product owner and they continuously try to improve their product or service. While we also have a portfolio level and say if we have 400 applications we need to support the 400 services, what application do we need to prioritize on and what can maybe we don't want to invest anymore because the value is not there. So it's managing the entire portfolio of services. But then you're not ready either, right? So this is really about automation and pipeline but you still need to understand what service do I provide? So you have a sort of service administration there. You need to communicate and collaborate with your business. You have to measure this, measure analytics and reporting like big data for IT. You need to control it. You still, security is still a significant component in the life cycle and managing the risk around this. And finally also you still need to fund it. So there's a financial management involved. So before you know it, implementing a DevOps world is very complex. If you leave it to the different teams they're gonna implement DevOps and they will. They're starting to develop their own build and continuous integration tools. They select their own test tools. So before you know it you have a very complex IT management landscape. Well a lot of capabilities are similar that the different DevOps teams need. So one of the challenges is that can we provide as IT for IT that blueprint to give guidance to all these DevOps teams? And this is an example of a landscape in Shell to manage this also the DevOps world with the continuous delivery tools, the testing tools, the automated deployment tools, the monitoring systems, the risk management and compliance, security monitoring, identity and access management and so on. And larger IT organizations they all need this type of capability. And there's not much you can eliminate. Maybe you can standardize and simplify then combine components. But it is a very complex domain. And most organizations if you ask them how does a demand come in in your IT organization and how does it flow through your entire pipeline before something is actually delivering value and can you then monitor that value? It's not uncommon that there may be more than 50 tools are needed from an initial demand registration until something is proven to provide the value. And typically there are different administrations that you use, right? So you have tools like many capturing your portfolio, service portfolio management, have a project management system, your requirements management tool or an agile tool where you manage your Kanban board, you've got your source code repository, you've got your code analysis tools, continuous integration, security and so on. And the challenge is that these tools are typically not very well integrated. So you don't have the end to end visibility we'd like to achieve. Because if we wanna do DevOps you really want to understand where is something in the progress of the whole chain when a demand comes into production or if there's a defect detected can you solve it immediately? So that visibility is not there today and we need to solve that for the DevOps world, right? And as a result, and that's not uncommon even organizations that are very advanced in DevOps they will still face this problem here. They still have a lot of different solutions they need to manage this end to end automated pipeline. So they still have different repositories. So the product owner needs to log into a system to understand what are my user stories. They log into another system to see what's happening in production. The same for the risk analyst they have their own tool for managing the risk against those services. And we have cloud automation engineers making the patterns for automated provisioning of an infrastructure pattern and other people building the application blueprints for the automation and deploying the application in automated fashion. And other people look at the consumption of the cloud they look at how much resources are consuming from Amazon or Azure and can I calculate it back and do I need to turn things off if I don't add value that kind of thing. So there's a lot of components there's a lot of data and typically that data is incompatible. There's no single source where you can find or search the data. I'm not saying that everything needs to be in one repository but what you'd like to achieve is the ability to combine data and search across all these repositories. So a lot of effort is today lost in production by people looking at data they have to go through different logs ask people where what has changed recently even in a DevOps world they still have a lot of repositories to go through. As a result there's not really transparency and the ability to continuously improve your IT function. And it's a similar concept like this is that you have a lot of repositories and within IT for IT what we try to do is create a common language of what data do you manage across the different components that we can create a kind of a data lake for IT and get valuable information out of it without knowing maybe where the data is stored as long as it can reach it. We don't need to copy all the data or federate it but that's different methods you can use or you can even think about blockchain as a technology where data is really replicated in a lot of places where you can find the data on different places and it's trustful information. Now in the past we got away with this way of working, right? We have different tools and even if you have a pipeline automated you got away with it but in a new world it is very difficult to get away with it because the number of components is increasing. We don't have large applications we have a lot of small applications we have to deal with many more APIs and interfaces we have to manage more vendors. We have more agile teams. So in the past we had a number of siloed teams and maybe a team that's around specific applications like a network team and a database team now we end up maybe a few hundred agile teams that are each building their own capabilities. And of course we have more requests because people want access to a service and then when they move to another business that we need to take their rights back again. So we have more and more releases, more changes, more incident, more security events. So there is a need now more than ever to automate and automate more and more of this whole chain. Now that's of course where the IT for IT reference architecture comes in. It provides you the capabilities to manage this IT and automate the IT for IT activities for the DevOps world but also for continuous delivery and provide you the insight because there's a common data model beneath it so that data from different systems can be combined. Just to show, highlight a bit where how DevOps can be positioned into the value streams of IT for IT. I simplified the IT for IT model here a bit. So development and DevOps is basically about the requirement to deploy, typically about continually deliver new version, new releases and get it out there quickly and also deploying that as quickly as possible. And then once it is in production we can monitor and support that. But you see there is in the IT for IT world there's much more than that. It's not about an individual application or service that you can continue to develop and deploy and operate and monitor. It's also about the portfolio side. We typically have a few hundred of those services to manage. And suddenly we need to think about what has more as a more priority and how do you manage the entire portfolio? How do we move applications to the cloud for example? Manage the financials, manage the risks and manage our licenses and our contract with the vendors. So IT for IT adds on top of DevOps basically the capabilities to really manage that whole portfolio of all those agile teams and all those different pipelines. To enable as we stated in before and this is also IT for IT but also DevOps get the continuous feedback loops and also focus on the value and optimize the workflow from a demand to production or if something is detected in operations resolve this as quickly as possible. So if you look at the number of those use cases where also DevOps is implementing you see each of the value streams there are some key example use cases. For example for the strategy to portfolio it's really about there's a bigger demand coming in and we need to prioritize whether we wanna invest in this could be a new service or ability to rationalize our existing services or moving applications to the cloud and manage that could also be managing technology refresh or end of life of key services and we need to get rid of those and in the requirement to deploy we have those use cases that are focusing typically on a specific service and then continuously deliver that service so it's basically the continuous delivery part of it having the requirements back up maintained and building the epics and then continuously deliver releases based on the new requirements that are coming up. We could also fixing issues like a defect or a problem that has been identified in production and fix it in an emergency release. So it's about a continuous delivery and the request to fulfill typically is also about provisioning the application to a test and production environment but and that's typically where you see DevOps they stop they think about okay it's running now but it's IT for IT and IT managed that's much more once the application is there people need to subscribe to it so you need to have the ability for entries to request access to that service we provision the access we monitor whether they still need it and do costing and charge back for example. So people can cancel subscriptions with those kind of services there's a lot of automation involved in that part as well like the example that was given by then about onboarding a new person into your organization what do you need to do to onboard that person and what kind of request and automation you need for that to happen and then the detect to correct to basically resolve all the operational issues and ensure continuous operations so it could be as simple as an end user has a request or an issue through self help is resolved could be a security related incident that needs to be resolved or vulnerability for example or performance related issues if there's a performance issue can we out of skill the environment so that we add additional capacity or when we see that an application is not used that much we can maybe reduce the capacity allocated to it to save costs and of course more be more proactive prevent outages or prevent issues there but there is more of course in related to the costs we have use cases for managing the risk cost and compliance now if you want to implement those kind of use cases you typically need a lot of as I showed before there's a lot of building blocks you need to implement from an architecture perspective you could say what are the building blocks I need and it typically doesn't really make sense to select all those components and then try to integrate them because there is a all the components have in the market they don't have an open interface so it doesn't make sense to say okay I need my same the beam we need to be improved so I'm gonna buy a discovery tool and hope that resolves my issue it's a little bit more challenging of that but you can imagine we need to think about those building blocks where do we invest in and how do we integrate those now how do so further on in the presentation we'd like to demonstrate how do you how can you take an approach on that and what is what are the logical steps because the vendor market is very complex in IT for IT and here you see an example of the different vendors and it's not even complete right there's a lot of vendors building capabilities for this DevOps world for the continuous delivery world for the IT for IT landscape vendors on the strategy portfolio side for managing your portfolios the enterprise architecture all continuous delivery components that you need release and deployment automation monitoring and a lot of supporting components for the finance and risk and compliance and so on so it's a very complex landscape and that's why there is a need more and more that we help the customer or the organization consuming IT to create a pipeline and select the components that really integrate and create interoperability now this slide I used before in another presentation but that's actually showing what IT for IT is all about is trying to connect the different components to make an entrant chain to make entrant workflow visible and hopefully that each vendor that now has different connectors will use IT for IT SHP is showing their example making it open and integrate with different components to create an entrant value chain and this is an example of the thing even if I'm not sure if you know that from it's something for 3D printing but you can see IT for IT as that kit that we can create a sort of open interface that we can connect different components together and an example of that it would be that you have a new demand coming in it goes through service portfolio process it is coming in the backlog it's developed, it's tested, deployed and meanwhile we can track and trace the progress we know what version it is, where it is deployed what does it cost, all those things which span a lot of different processes, tools and data repositories now so first a lot of IT organizations need to realize that they need to transform and there's a significant change needed the traditional way of working will not help in this new DevOps world or this new world where we need continuous delivery so there's a first they need to realize that and the good thing is that most IT organizations are working on this path to DevOps and organizing themselves around value streams and trying to standardize the way they work because one of the things that they realize if you want to automate your end to end pipelines you need to standardize and it's on the infrastructure layer that you need to standardize but even on the way we develop services and maintain services to get that transparency and integration so that is one of the challenges of course because we're not on green field situate environment in most cases, there's a lot of legacy out there now let's look at the next slide, yeah this is a high level approach that was also documented in the IT for IT management guide I will not go in this slide in much detail but I would like to zoom in to some of those elements how you can get started with IT for IT to enable this DevOps journey and of course there is a new start typically with a vision without knowing exactly where you end because it's iterative approach it's not something that you can implement IT for IT or DevOps immediately we also need a sort of agile approach implementing IT for IT but it starts with a clear vision where your IT organization is heading and that relates to culture this relates to the strategy of the business so you organize, you create that vision and DevOps sits in that vision and being a broker could sit in that vision and move service to the cloud and be able to be transparent and be easy to work with and that kind of concept that guide the way you think an IT organization should work and then you need to think about but actually how do I then need to organize myself to be that and typically my current IT management tools potentially will not fit in that so we need to rethink about how do I organize that and where do I go to now there are a few approaches where you can take to implement this and most of them start at least is understanding the entire value chain and the value stream so that's a common method used in the DevOps world as well and continuous delivery look at your value stream so there's a demand coming in on the left and what are the activities that the system or the process goes through to actually get something in production and that's a lot of effort because when I'm working now in the financial organization it's very difficult to from one end to the other end from the start to the end to get a good understanding of what is really needed it could be even a risk approval summary in between or how do we get something released in production so getting a common understanding how things are done today and the challenge of course is that that could be different for each line of business and application so we really need to look at how is that value generated you need to look at how it's done today because typically what you will hear is that most businesses will say oh but I already know that and I'm already doing it next year we are ready for DevOps so they will always tell you I'm ready on it, I'm working on it I've almost solved it and that's what I have been saying for 10 years we almost solved it next release or next week or next month but really need to go see what's actually happening there and identify for example key work cues where is the work distributed and a work could be as simple as a user story that is managed in my agile development tool or I have a risk assessment where my risk tool is a work defined or my incident or my problems or my request could be a test task that people perform and look at how that is organized and integrated now if you do that you typically will see well there's a lot of spreadsheets in between to make things work and of course you got a lot of system to doing that and analyzing that plotting that to the IT for IT architecture you find that work is distributed in a lot of different cues so we have maybe on the portfolio side we have a portfolio backlog where the topics and epics are defined where we want to invest in then we have a product backlog we have backlogs for problems and incidents and maybe the request and deployment and risk and compliance and architecture and what IT for IT does is helping to organize all those backlogs to get understanding of all the work that the IT organization is planned and worked on and get that traceability because they're typically related to that common service that we talked about this is the service backbone because what is also done typically is that you go through this value chain and you identify impediments right that's the agile and the lean people like to identify impediments and this is an example of typical impediments that the most IT organizations face in moving to the DevOps strategy so that they analyze their workflow and this is where they come up with the typical impediments so one of them is for example we have not a clear funnel tool to manage all the funnel of demands coming in we don't have a single service portfolio with understanding of all the services we have or we miss entrant traceability from a requirement to until something is in production for example or there's a lot of rework or testing just takes too long so we want to test but the test environment is not available and it takes two weeks to get the test environment there or the actual approval of the change going in production is too bureaucratic so we are ready but you need to already two weeks up front tell you that you're going in production so you need to wait there's a lot of wait time although I see that the CNDB is not up to date and they say well as long as the CNDB is not up to date I cannot do monitoring correctly and have the impact or there is no good self-service we don't have insight in custom experience and yeah the supplier contracts they are blocking us so we have supplier contract but if I want to order a server at my outsourcer yeah the contract of the procedure says that we have this and this steps to do so it takes four weeks to get that server up and running now those are typical issues impediments, bottlenecks to implement DevOps or implement IT for IT and that is one of the challenges because what happens typically in a lean approach they just want to fix these and for example how do they fix things they say oh we have to see CNDB is not up to date let's fix it we select a good discovery tool and that will populate my CNDB it will not fix the problem because the problem is not that the CNDB is not up to date it's more about how does it really integrate with if you have a new release on the orders infrastructure how do we know which belongs to what discovery will not solve that it adds new data but it doesn't tell you who ordered this and why and where does it belong to for example so we typically don't fix the real problem by fixing individual impediments we only fix the real problem if we're going to look at it from an end-to-end perspective and then say okay what is the first step that we need to do probably seem to be changes not the first thing we need to do get an understanding of what the end-to-end pipeline looks like and how do we want to improve that so we need to think first from a system perspective so and that's basically DevOps as well or looking at from an end-to-end perspective and then focus okay what do we need to do to improve this and one of the key things we would like to achieve at least in the DevOps and continuous delivery space we want to automate as much as possible across the entire pipeline so that we can have a repetitive and it's traceable and it doesn't mean that every task needs to be automated as long as we can trace it back into the entire chain and this is what I explained a bit earlier as well so the challenge is that there are already so many initiatives that your IT organization is taking if you ask an organization and they move to DevOps they have all these projects currently up and running so they have the continuous delivery project they have a scrim and agile delivery project they have maybe the seem to be oh yeah application performance monitoring they want that as well of course because then you have an understanding how well my application is performing in production so they want all these capabilities and security wants cyber defense monitoring so before you know it you have all these separate initiative and project running and that is typically already running in your IT organization today without any glue in between so and there's some identity access management of course knowledge base you can imagine a lot of things are under the implementation today to improve your IT function now so the question is then how do you really start because if you want to implement all those capabilities at the same time that doesn't really help that much it will not result into end-to-end value creation in a lot of ways so one of the things you could do is implement a value stream so there's one approach and typically a lot of organization they start with for example requirement to deploy that's the first value stream they start with because they have a continuous delivery project continuous integration, continuous delivery and they select the amount of more applications and work on the backlog there getting the coding, development, testing and deployment that this could be a method and once you have that you can onboard other applications and other customer that I've been working for is more focused on the request to fulfill they say we want to automate all those recurring requests like people wanting access to an application or order new infrastructure services or modify the capacity allocated to it or cancel subscriptions so that's one approach or of course detect to correct and focus on monitoring and get the automated incident creation and also maybe resolving automatically so the whole pipeline of detecting to resolve the challenge is that it is typically a lot of effort because you all want to take this monitoring for a lot of applications at the same time so an alternative approach could be that you do a more select a early mover application or service as a team and try to really implement it across the entire value chain so we implement partially for that team the backlog on the portfolio side manage the high level epics there we implement for example the request to deploy and so on so you have the entire chain end to end fulfilled for one team and that doesn't solve all the issues because you cannot automate everything at the same time but it gets you a learning curve and a demonstration of how the new IT organization need to work and you also need to understand that you have different pipelines so for example I'll call it an application but the term application slash service should be used better we have services that are developed like an application services but you also have infrastructure services being developed if you develop a new cloud service that is also going through the same pipeline but then there's more infrastructure related components and services but the challenge is that you end up with different pipelines depending on the type of technology but hopefully a lot of common components are used so for example what you could do is start with the .NET application or Java and take that application from an end to end perspective and implement that pipeline with standardized components as much as possible so on the left side we make sure that for that specific Java applications the epochs are stored, the services are identified, the owner is identified, we maintain the source code do the continuous delivery make sure that people can access request for accessing that service and we make sure that monitoring is enabled so that's what organizations are trying to do to create a small application end to end and that way you can learn how things need to be managed for example things like when do we use a risk sign off in the stage or if we run into issues of getting infrastructure faster provisioned maybe we can fix that temporarily but at least get the flow end to end working this demonstrates then the new way of working in a DevOps environment and based on that there is learning so typically creating an end to end flow hopefully you can do that in three to six months for a number of applications as long as they are simple stack application like .NET on the Azure cloud or in Java application on Amazon have a sort of standard patterns there where you can deploy with automated provisioning that you do monitoring from those components but a very lightweight limited for a number of applications and then based on that you learn how to apply IT for IT you learn where opportunities to automate and identify issues for improvement and not focusing only on the tools but also on the way of working with the different teams and this is about the way of working because DevOps is not that simple that you say we just have a DevOps team that does everything in reality you have for example service DevOps teams that develop services like a specific CRM application for example they have a DevOps teams that they develop that service or maintain that but we also have a sort of brokering DevOps teams that maintains the standard infrastructure components and we don't want every team to manage to define that we just have one team developing standard patterns infrastructure patterns and every application team can reuse those patterns while they can focus on building their topology or blueprints for the application reusing standard blueprints for example for serverless computing or standard load balancing web servers and the database and having those predefined with security metrics in it because that's where you have the teams below defining those standard deployment patterns from an infrastructure perspective so this is a challenge to organize around standard patterns on the bottom and then have the different teams working on that and reuse what is defined below and this way you make sure that the development teams can focus their value delivering business value for the applications and they don't need to understand how infrastructure needs provisions we give them infrastructure code templates they can use that of course they need to understand a little bit about infrastructure layer but typically we don't want them to reinvent the wheel how security needs to be organized in Azure or how to provision a whole stack with load balancers down to the database for example and then there is also a governance involved in your organization if you want to implement DevOps or implement IT for IT then you could say okay who will be owning these automation capabilities in the IT organization so typically you can think about like a safe skilled agile framework on the portfolio there is somebody responsible for the IT for IT portfolio for all your automation tools that you have in your enterprise there are different value stream owners that focus on improving the tooling and the processes and the way of working within the value streams like somebody responsible requirements to deploy developing the practice route continuous delivery there and of course the different teams working on the solutions like the deployment tools and the monitoring tools so to wrap up is the story was about the business is changing and IT is changing and also the role of IT has changed and most IT organizations now realize they need to transform in a sort of cloud brokering of defender sourcing models and they will apply new methods like DevOps will probably a key method or principle that they will use and to implement DevOps for example or continuous delivery there will be more dependent on having to automate the IT capabilities and use IT for IT as that foundation basically for implementing DevOps so coming back to the Phoenix project that was the book of Gene Kim and you know there's a lot of challenges and issues identified there and it would have been nice if the Phoenix project had that IT for IT reference architecture because that would have solved a lot of their problems that they were facing so now getting your IT organization ready for the digital enterprise 3.0 that is probably what you face in your IT organization as well and yeah I see that something is broken because you really need IT for IT reference architecture to get your IT organization ready for the digital enterprise and I'm not sure if you've seen this kind of slide before when something is wrong with your machine they have a number of options that you can go through one of course you could say I got my troubleshoot and started to fix it myself like a lot of organizations are doing today they're going through the journey of DevOps and try to fix it themselves or even there's an option to turn off your IT organization completely or there's one other option is basically continue and using IT for IT to get started with this new digital realization and digital enterprise, thank you