 So an impressive CV is thank you very much for the introduction. So it saves me explaining my role a key thing That I really wanted to get across before I do the presentation was also a practitioner. So I'm not just doing a consulting work or architecture work. I was the CTO for Heathrow So those of you who fly via Heathrow capture, but I runs all the IT at Heathrow and I was the CTO at Heathrow and I had had the opportunity to work on various different big clients in the past and And all the clients have a lot of the themes and come in the IE speed, agility, flexibility and cost and I want to cover those two key things during my 35 minutes just talk about DevOps in an IT for IT context and give you some ideas and Some suggestions in terms of the material that you can find in the IT IT IT for IT forum Now when I talk about DevOps, I typically say DevOps is a bit like Rookby I don't know. I hope all of you know what Rookby is. It's almost like football. It's just a different ball Rookby in theory is very simple because all you have to do is you have to take the ball You have to get across the line to score And so it seems for DevOps It's the same because a lot of people nowadays are talking about DevOps are saying well If you want to be faster if you want to reduce outages you do use DevOps But for those of you who have applied the DevOps concept it can be rather difficult and rather tricky And so it is with Rookby if you play Rookby yourself you find it very quickly That's quite difficult to take a ball and score a point So I wanted to cover three things first just wanted to give you an overview over DevOps second Articulate a bit the challenges in a DevOps context. They're quite high level and a lot technical and Thirdly give you some again some ideas some hints and tips of the material that we have produced over the years in an IT IT IT for IT forum from a DevOps perspective I'll call it as well. Very nice. So we've a go on to the overview. There we are First of all DevOps is not a product DevOps isn't something you can buy You can't go to a shop and say give me half a kilo of DevOps or I'd like No, two thousand licenses of a DevOps solution DevOps is a is a philosophy DevOps is an approach And DevOps that's really important and that's why it fits spotted into the IT for IT Concept because you talked about before you heard about before the business value point is about driving real business value So DevOps is really positioned to help organizations to drive value And it's typically about speed and of course out the transaction but more on that later You see often nowadays people saying that you if you implement a tool like those of you have probably heard of Docker or Huppert or chef All these new tools that are now appearing in the market if you apply them you have DevOps It is a bit true, but there's a large part that is still missing because you only implemented the tool You're still missing the process and the people side But again more on that a bit later in the slide deck DevOps is I've been an IT for 26 years. I always find it fascinating It's actually something that has been around for a while, but some clever clock created this this concept of the term DevOps A bit like when cloud was appearing we all did virtualization many many years ago for those of you work the main frame we used L past logical petitions We virtualize the main frame in the 70s in the 80s Somebody said in the 2000s now we're doing cloud everybody thought oh, there's something new. It's a bit like get DevOps as well DevOps was coined in 2009 and it was really kind of created by by a couple of chaps who thought well We really need to break down this barrier. There's this this wall of confusion They're called it between development and operations We really need to make sure that people who are develop developing code. I actually also doing it with operations in mind And not just focusing on the functional aspects of a solution and When you are deploying tools into a live environment that you actually consider all the aspects And if it fails well, you don't just try it again in six months time We try to find and identify the root causes So we're really trying to they were really trying to get to to the bottom of some of the outages or the issues that We see when we're delivering applications or we're when we're deploying code into life DevOps can can drive significant value. That's where what you actually should be starting with never mind How you implemented or what tools you should be deploying that's first focus a bit on the the value proposition of DevOps Well, puppet laps did a survey the issue. This is the result for the survey I think from 2015 and they found that there are two key value propositions for organization for deploying a DevOps Approach first is agility so speed and second is reliability So they have found this is the material the outcome from the report you can get the report online When they found that you can almost do 8,000 faster deployment times. Sorry lead times than peers or you can increase the frequency of deployment by 30 times or You can also increase your reliability by 2 or you mean time to recover by 12 times They also thought that these are the kind of the the primary objectives or the primary business cases or The primary applications for DevOps agility reliability and they found that organization use a DevOps approach Can typically also get secondary objective or target, which is more competitiveness I having the ability to grow their market share or having the ability to penetrate their market better because they're using a DevOps approach When you look at the business cases or so these are kind of the outcomes typically you see four key business cases for DevOps implementation Two of which are I guess the most prevalent ones, but still four are really important from a DevOps perspective First is the agility side So DevOps has been applied in context areas where you want to be faster if you want to speed up You want to speed up your deployment Secondly is about increasing quality. So a lot of organizations nowadays are using a DevOps approach to improve quality Third if you're using tools to automate So you're free up your staff from manual labor or manual intensive labor activity You actually freed them up to do some thinking so you can increase your web You can increase your innovation cycles because you have more people thinking about better ways of doing certain activities or newer product cycles for instance And then the last point is around reducing an outages. So typically you see The 80% these are statistics or numbers that you can get from forest or a gardener 80% of all outages are change related So only 20% of outages in the data center are related to failure hardware failure or power failure 80% is down to change related outages So when you are deploying code into live or you're making changes to your application an outage of an application is typically caused by this And DevOps is really trying to Organization are using DevOps to take that 80% down to maybe 40% or to 30 or to 20 And within that is a huge amount of value for organizations a particular organizations that have very customer-facing applications or services You can imagine if an application isn't available the Implication from a direct product perspective or the indirect implications can be significant for a bank for instance So cost avoidance is a big question or quick a big objective for organizations or banking particularly and They reduce up reduced outages is typically something that they focus on when they are deploying a DevOps deployment or DevOps approach When you when you talk about DevOps a lot of people focus on the agility part, it's quite good That's certainly one key aspect and it's quite interesting when you sometimes compare the various different Organization from their agility perspective to see you know how where you want to be from an organizational perspective Many organizations that's typically where where I worked in as well We used to identify requirements you develop solutions your test solutions You deploy them or you follow the IT FIT framework And that typically takes six to twelve months and then you deploy a big release every quarter every half a year Obviously with DevOps you try to shrink this you try to shrink this not from a not just from a duration perspective But also shrink it from a cycle perspective So you try not to have a release maybe every quarter you may have a release every week or maybe have a release every day The question is where do you want to be if you look at organizations nowadays these are numbers That I found from the internet when Amazon did a presentation And Google as well. They do 20,000 deployment per day. So these are 20,000 changes in life per day They are Amazon website is all based on microservices and they are making changes to all their applications every day You may look say that's a bit weird. Can I really do this? Well, I don't work for Amazon I can't really vouch for it, but When I did a co-presentation with the with one of the Amazon lead architects They were showing me the way they approach a solution life cycle very different to I guess we all used to Google do about 5,000 Netflix about three to 500 a day and then you have your Facebook Twitter And then your typical organizations. The question is if you want to deploy a DevOps approach Where do you want to be? Do you need to be? releasing Changes to your live organization or application environment every second every minute every hour or is a day is a week is a month sufficient It's not so much to to question or to say well you agree or disagree these numbers is more to say Okay, where do you need to be? What are your requirements from a? Receive recycle sorry a release perspective. What are your requirements from a deployment perspective? And it has a big impact on the tools and the way you need to employ or deploy a DevOps approach That's clearly if you want to be a Amazon like well, you have to probably follow the same Footpath as Amazon is doing a Google and Netflix But if you say well every week is okay And I'm currently every year or every half a year And still that will apply a certain level of changes to your organization from a people and process perspective But it's quite important to know when you when you have a DevOps approach and approach in mind And you want to deploy these tools and techniques in the organization I mentioned these three things before and that's also really important a lot of material you see nowadays In the market focuses a lot on the right-hand side Many many organizations are saying, you know, you want to deploy a DevOps approach use a tool Tool is good, but only a tool will give you maybe automatic approaches or will Reduce your money your activities in your environment. You also need to think about the process So how do you actually deploy a code into life and more importantly probably and that goes back to the first picture I showed you more importantly is probably the people side And more importantly is to help the people to take down this wall of confusion to stop the separation between development and life to stop the Inertia that you sometimes have an organization when you are deploying changes in your in your life environment So you need to focus on those three key things when you want to deploy a DevOps approach So this was a very quick nine minutes run down through a high level view on DevOps So I just showed you quickly the four key business cases for DevOps So remember agile and out at reduction and then the the three key aspect of DevOps, which is people process and tools now DevOps challenges. There are Typically two challenges or two angles you can see or you can have a look at at employing or deploying a DevOps approach You typically see it from an outside in perspective Which stops you from using DevOps and an inside out perspective which we call or I call inside out challenges Within the outside in challenges typically what stops you from deploying DevOps So when you want to speed up or you want to reduce outages what stops you from from doing or deploying these tools are typically complex settings in your pre-production of your project and your project environment Which leads to an issue when you have error Identification or error prevention because it's very hard to identify what the root causes are when you have an outage in life You know quite often you hear or you see an issue causes in life or an outage in life And you go to the developer and you say that the developer this code isn't working the developer saying well It works on my laptop So there's typically of course a difference between pre-production and production and if you want to speed up if you want to address Outages then you need to find a way of addressing these two key points complexity and the issue of finding root cause analysis or doing root cause analysis There's also this what I mentioned before the wall of confusion again If you want to speed up if you want to reduce outages you need to make sure that you are addressing the people side So typically you have the development team in one IT organization probably reporting completely differently to your operational Division sometimes operation division for Organizations might report to the CFO. Maybe the developer reports to a completely different functional division And you need to adjust this when you are deploying a DevOps approach And the last point which is something we all have to battle with is the speed of innovation I had a stuff that is changing every week every month It is mind-boggling at the moment So if you are running implementation program for DevOps say for instance, you have a task in your organization to speed up your deployment from six months to every week and Also to reduce your outages by 50% Then one of the challenges that you will have next to complexity the diagnosis and the silentness of your organization It's a speed of innovation because you need to deal with these new tools and techniques that are appearing almost every week Next to that is a couple of inside out challenges So again, imagine you had this task to To speed up and to reduce outages for your organization. Well, first of all your organization may not really understand what DevOps is There are plenty full of definitions of DevOps currently You'll see later the open group definition of DevOps that we have suggested so far But there are many different definitions for DevOps. Gatner will have one Forrester has one IDC has one Organizations have one technology vendors like Capgemini have one We all have our own view on DevOps that is in itself a big challenge when you are deploying a DevOps approach in your organization Tools connected with innovation Again, if you if you look at the open-source markets, there are tools coming out every day So when you are When you think I've got my head around dev Docker or puppet and chef and now know how all these things hang together Your boss may come up to you and says, well, have you worked with this? He's a no You may be not be on the the latest and the greatest So you need to deal with the DevOps tool cocktail of the tools that you can deploy You speed and your reduction in outages And then there's a big question and as again related to for IT for IT is the big bang versus step-by-step So how do you approach an implementation of tools technologies and people changes? When you want to speed up or you want to reduce outages? Do you do it in one big bang or do you want to do it in step-by-step and You also have the current changes in your organization So when you are deploying a DevOps change in your organization, you have all the other projects still running You may have I don't know a desktop professional program You may have a relocation of a data center a deployment of cloud solution whilst you're doing all this You are trying to reduce outages and you're trying to speed up the organization so there's a lot of Issues and challenges and constraints that you have to deal with when you're deploying a DevOps activity or DevOps approach So how can IT for IT help? Well, first of all, there is a material available. So Most of the material that I show you now is taken from agile scenarios. It's a white paper that we've issued in March There's a link on the deck or you can get link from the from the website. So this is to directly taken from the paper First of all, of course, you have when you look at These two objectives that I mentioned agility and reducing in outages of reduction in outages One key thing that you clearly need in the organization is a standard way of running your IT So many organizations are every single organization has a different definition for their solution life cycle for their deployment approach I work with one client. They call it go to go to production. The other one called it run into life Every single organization has a different methodology in a different Dictionary for the features and the functions that they employ or deploy from going from requirements gathering or strategy down into Implementation and you know, you heard it before the key value of IT for IT gives you that framework and that framework is the first starter It doesn't give you the answer But deploying the framework you don't get DevOps directly out of the box But it gives you at least a framework to to work against and that's very important when you're focusing on Reducing outages or when you want to speed up deployment from left to right, which DevOps is is all about Here's the definition of DevOps. So this is a white paper suggested definition So was issued in February in 2016 And here's the the words that I used before when I explained to you the DevOps approach But first of all DevOps is a way of collaborating and industrializing using highly automated approaches And it's deployed to deploy solutions that evolve as fast as your business needs it So it's really important to see the the connection between the business outcome and the activities of deploying solutions and in collaborative and industrializing way We said in the paper that by adopting DevOps Organization can of course improve value developed by its business again really important the value proposition from a business perspective So not so much IT centric its value to the business and it does that by tearing down these traditional silos and using I guess the IT for IT framework to really connecting the various different parts of an organization again You can take that directly from the sorry from the Agile white paper. So it's the Agile scenarios white paper The words are really important. So you have to see that if you look at DevOps, it's not so much It's not just the tool side. It's the people the process side and it's the the real focus on business outcomes The real focus on what is it you want to achieve? What is the speed you have to achieve? What is the agility side cycle you have to achieve and what quality aspects do you have? How many organizations have outages you probably have to live with outages But what is the kind of the level of outages that you should have in your organization that is acceptable rather than the one you have currently in in a In a scenario where you Provide or you execute a continuous release cycle So when you look at material in DevOps, you see when you dive into DevOps content or material you talk usually around agile Agile is a way of creating functional specifications or delivering functional specifications and Non-functional as well, but if you really try to achieve kind of Netflix approach So I'm not talking about you know releasing every quarter or a reason every month if you have the need in your organization To deploy changes on a daily or on a hourly basis You need to do continuous integration or continuous release release cycle and in the IT for IT forum You have material that helps you to frame your approach. So from a process perspective Mentioned before you have people process and tools in IT for IT. We've defined Guidelines and some specifications of how of how you could do or you could deploy a continuous release cycle and what we also did and that's really important because Typically when you see these pictures they look very nice You have a couple of boxes a couple of arrows and you think well, okay So what does that mean to me the key value getting from the IT for IT is the definition of the objectives So we spend a lot of time articulating actually What is the objectives the targets and the requirements that you should actually have against your framework? So you remember the framework that we we specified before the IT for IT framework There are clear value propositions against each of the stages which you see in a second And this is really important when you talk about a value chain because the value chains We have your from your left to the right your strategy down to to your deployment You really need to focus on or you need to ideally focus on the key outcomes and the value propositions that sits within each of the value chain components and That is against your people process in the tools So that's really the trick when you're deploying a DevOps approach not just considering the technology aspect. So maybe technology on your Automatic monitoring and workload Workload management might be when you might be using chef or puppet or see a unit center or something and maybe on the technology side on the On the strategy side you may have some interactive or collaborative tools that helps you defining strategies in much more Interactive way We also need to do the same thing on the process and on the people side a bit more tricky on the people side to define the The physical aspects, but people could be that you have to maybe reorganize your your structure You may have to co-locate you may have to think about you're having your developers much closer to your operational staff ask one of the Organizations I was working with who started on a DevOps journey and ask them What was the the main value or the main thing that they deployed on the people side to get the developer to talk to the Operational guy and they said well what they did is they gave each of the developers a clear objective Which was linked to outage? So a developer had a business a personal target to make sure that his code doesn't cause a certain amount of outages If he achieves or achieves that target he gets a certain amount I don't know how much a bonus payment was maybe say $500 and it is the same thing on the operational stuff So the guy who was running the server who had very little to do from a development perspective had also a target from a functional Perspective so the amount of function points deployed was also his personal target Of course, his main target was as a laying KPI But he also had a target to make sure that there's change introduced all the time at a certain level and he was also given the bonus so The clients that they're very happy and they're now working together because they had a personal objective of Getting their target so they get their money So of course there's one approach to take another client has relocated their stuff They are working together in the same room and they forced them to talk to each other Which is a challenge in itself. You have operational guys who look down on developers because Developers don't understand functional specification and you look at developers who look down on operational stuff because they don't understand functional specification so this is wall of confusion that you have to address and that's quite a An area that spent you typically spend a lot of time on When you talk about implementing DevOps and remember DevOps is just a title What's behind us are these use cases these business cases that are specified before namely agility and reduction in outages And this is the material you get from the agile scenarios Also within the agile scenarios we suggested a DevOps maturity model So again when you think about I'm in an organization, I would like to start on DevOps Sounds good. Other clients are doing it as well. Everybody's doing DevOps. So I may do it as well quite sure it means My objective is to speed up from quarter to week and I want to reduce my outages by 50 percent Where do I start was a great great question to ask So we sat down. We thought well, maybe we should specify a maturity model maturity model with a couple of steps Where we have or where we can specify characteristics Per step which helps maybe guiding an implementation approach for DevOps So I hope you can read this a bit white apologies for this We specified a couple of levels. So first of all, we said well level one basic There's certain Characteristics defined it gets a bit easier to read when I go a bit higher So if you look at the top for instance top level There are certain Characteristics certain attributes that you could specify to an organization that has a top level maturity on DevOps against people process and tools Again, this is just a summary when you look at the agile scenario You can get a couple pages worth of more description behind these And this can help when you starting on your DevOps journey You may remember one of the slides I showed the outside in and inside our challenges so if you are have an objective of Speeding up reducing outages you have to have an implementation plan for DevOps I e the changes that you have to do from a tools from a process and from a people perspective Having a maturity model which gives you kind of a compass where you want to be is really important Really helpful. Also, it may define that you don't want to be or need to be and top level It may suffice us for your organization to be maybe enhanced or maybe coordinated because you say well I'm okay to do a change every quarter. I don't need to be a Netflix on Amazon One of the banks when I did a presentation to one of the the CTO from a large organization for large bank He said absolutely not so when I do a change in life. I personally review the change going into life. I Personally, I'm accountable for any failures that is caused by the changes to be put into life The last thing I want is one of these open source thingies to do deployment to life and don't trust them So I want to do it myself. So I'm quite happy to do a release every six weeks Okay, fine. Fair enough to don't you don't have to have a full continuous integration Which can do a release in 16 seconds from the delivery from deployment into life But it helps I guess your organization or helps you to to give you a guide post And you are kind of the The description of the the next level down So if you drill into this level one on the agile scenarios, this is the material you then get I'm not gonna go through the words But it just gives you more material Which helps you maybe to guide your DevOps implementation doesn't give you the answer It's not gonna say or I can't tell you what are the changes that you have to do in your organization To speed up, but it gives you that framework that reference model to help you to guide within the IT for IT value chain What are the the characteristics that you should consider from a people process and from a tools perspective? If you want to really speed up against maybe every quarter every month every day or every hour There's also a suggestion of implementation approach again, if you look at the agile scenario document is a bit more Again taken taken from the from the document There's some some guidance or some ideas of what else you could do to speed up and to reduce outages Now as I mentioned before DevOps is a term a lot of the tools and techniques that we have deployed over the last 20 years was focused on speeding up reducing outages not since 2009 that we certainly think about this in the IT industry So there are certain aspects that are obvious like train your stuff Very obvious in terms of automates But also maybe not so in terms of strategy and architecture and that's where IT for IT comes back in So really seeing IT as a business differentiator Seeing IT as something that drives business value is in itself a key first step to getting to a much more agile organization Because if you have an organization which sees IT as a back office function that only costs money and doesn't deliver any value it's very hard to then work together with the business of Increasing your speed to a live environment if your organization However understands the value that use an IT organization delivered to the business It makes it much much easier to work together with your business to speed up and to reduce outages And a couple of other things which are obvious in terms of reducing complexity Optimizing process and orchestrate your your your activities across the life cycle Are also applicable Okay, so oh, sorry Only a couple of slides left These are examples of material that you can get get from the from the agile scenarios again, and these are Suggested goals you could take them as a starter for 10. So again if your scenario is that you want to deploy Changes to increase your speed and reduce your outages. These are things that in the agile scenarios White paper suggested that he may want to have a look at from a goals perspective There's also a reference model. So No white paper without reference model. Let's define all the meta models, but they are Example of this is the reference model for for the IT for IT landscape that is applicable to the DevOps context That helps you to start from a DevOps implementation perspective doesn't give you reference model is not the answer It's not the solution. He is a reference that helps you against your implementation plan against people tools and process Particularly here on the tool side, of course What you have to deploy or what capabilities you'd need And there it is very pretty as a picture missing in the front but you have the IT IT for IT agile scenario, which was issued in February and If you want to read more on the material that I've just shared Remember the latter part was just a summary of it. Then please have a look at the white paper Or ask questions later. And that was my presentation. Thank you Thank you very much if you could just take a a seat. We'll have a chance for just a very small number of questions To keep on track very small questions all about the marathon a small number. Yeah, I doubt there'll be a small To answer but yes asking the questions is the open group CTO Dave Lounsbury, so Thank you gonna I'm going to take I know we're tight on time. So I'm going to take the liberty of Combining two questions here So 20,000 deployments per day sounds like a great idea But how do you tie the rate of deployment to the value for your business and closely related to that is How do you make the case for investment in the dev-op tools and people and processes to actually hit the rate you select? Great question. I think as I mentioned before Forget the number for a second. You need to start with the business. So you really need to understand what what is What does the business have to do to increase their footprint in the market? What does the business have to do to sell more products because at the end of the day? We are all here to make money revenue and margin So if your organization say your organization has a market penetration of 5% and if you had the ability to release products 50% faster your market penetration might go up to 25% So your business case is the increase then in market penetration, which you can translate into revenue numbers So if you could then say you will you increase your revenue by 10 million the implementation cost might be 5 million Your business case is there, but it's really finding and working That's why I said that the end is really important that you have the relationship with the business to talk With into the business and the business sees you as somebody who delivers business value Because if they look at you and say well, I talked to you when I asked about my email address Or I talked to you when I knew the new data center, but what do you know about revenue increase? What do you know about market share? There's a really really important point around getting it as a partner as a peer to and with the business Organizations who have managed that so where at the board level the guy who's accountable for it He sits at the board level and has a say in the business strategy in business direction They manage these massive penetration increases organizations, which sees it as a back office somewhere and Attached to the CFO not to undermine the CFO or say that he's not valuable Don't so it's a really important point to take away so How when you're doing dev ops, how do you manage? And to implement dev ops when you've got products that aren't weren't originally designed for you enterprise legacy projects or products Products that weren't defined as they weren't they weren't originally designed with dev ops. Oh, okay. I take it so there are Give you an example. There is an organization that has a massive mainframe deployment on IBM mainframe they use kicks for those of you kicks is a tool on the mainframe and They have had the same questions that okay We use all these new web-based applications on PC, but our mainframe is still old Asia's dinosaur There are tools nowadays available IBM is making more in rows with a plumex of connecting kicks with the dev ops based approaches But maybe there is a case of kicking off of replacing them So if your tools isn't up to to the speed that you need you may have to have a look at whether the tool is fit for purpose Which then comes with its own challenges again because then you need to deploy Changes to to put new tools in your environment There's a big change program is the dev ops implementation if you want to speed up reduce outages It's not just deploy a docker or a puppet is really Rethinking the way the organization is connected to the business and drives value into the business So I think last question in the interest of time How does the company advertise for dev ops skills to get that people component in there people already know the processes So if they how do you how do you get their skills and capability? And how does the company test test their CV when they come in wow as a quick question? So I mean if it's a bit like 15 years ago with with clouds a lot of people now putting cloud dev ops on their CVs I think you really should do two things first I think you need to talk to these guys or people who are you need to employ and really see that they Understand it's not just about the tool side So and dev ops is a means to an end the end is speed and reducing in outages So if I'm in dev ops engineer and I come with my my docker on my backpack Doesn't mean I'm dev ops. It just means I know docker But if I come in and say well I want to help you to increase your speed to market because you need to increase your market penetration Maybe and that people process and tools aspects to it You probably stand a better chance to to have a dev ops based approach or philosophy This is the the existence of the it for it value chain and reference model Help you sort some of those position some of those skills and that's why the description and there is really helpful So when you look at the value chain it tells you you know what are the characteristics or the objectives that you need to focus on these Different stages if you have a developer, that's what he or she needs to think about functional and non functional outages and functional Aspects as well and speeds and then you have the same on the on the operational guy So if you employ somebody who runs your operational environment that he or she understands that the connection between The people process and tools side from a it for it perspective across the value chain That's it from the floor Steve anything from you Not in the interest of time. I do have one that I'll take offline if I may No, we must we must move on. So thank you once again gonna mental. Thank you