A Ranger4 ThoughtPaper: DevOps for CEOs


Published on

This Ranger4 ThoughtPaper looks at DevOps from the perspective of a Chief Executive Officer - what do they need to know, what should they avoid doing, how can they ensure the success of a DevOps project in their business.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A Ranger4 ThoughtPaper: DevOps for CEOs

  1. 1. DevOps for CEOs A Ranger4 ThoughtPaper www.ranger4.com © Ranger4 2014 1
  2. 2. Contents 1.0 Did Someone Say “DevOps”? 2.0 The CEO’s Role in a DevOps Project 2.1 What causes resistance? 2.2 Leading from the top 2.3 Measuring Success 3.0 Getting Started 3.1 Things you need to make sure your CIO isn’t doing 3.2 Things you need to make sure are happening 4.0 Conclusions www.ranger4.com © Ranger4 2014 2
  3. 3. 1.0 Did Someone Say “DevOps”? Did your CIO say “DevOps” today? Or did you see it in a Gartner paper? Is it just another one of those IT buzzwords like eBusiness or SOA or BPM that you’ve seen come and go over the years? Are you going to be asked to lay some investment down to do some “DevOps”? Chances are in 2014, yes, your business will be asked by IT to invest in DevOps. Here are the things you need to know. DevOps is a philosophy designed to resolve conflict between IT and Development teams. Jeez. Can’t they just get on with their jobs? Well, no. You see, IT has changed quite a lot over recent years. Where once IT was, for many organisations, a function, often located in the basement, to keep a few internal, not all that heavily used systems running, things have become much more complex. You may have noticed this in your own business. How have your IT investments and resources changed over the years? Do you now report on how much of your business is transacted through digital channels? Do your marketing team talk to you about your social and mobile strategies? Over the years, your IT teams have built ever more complex and integrated architectures and smarter applications - making your business more competitive, delighting your customers. IT has become your strategic weapon. So why the conflict? You’re pushing your developers to deliver innovation and that demands change in the systems. You’re also demanding optimum performance from all of your applications - and the best way to keep things stable is not to change them. Therein lies the conflict - one group championing change, another stability. So what can you do to help? Why would you want to? Resolving this conflict will help you to: - Innovate faster Delight your customers more Be more competitive Report greater earnings to your shareholders But how? www.ranger4.com © Ranger4 2014 3
  4. 4. 2.0 The CEO’s Role in a DevOps Project A DevOps initiative drives change and you’ll probably know from experience that driving change is hard. It can be painful, there may be pockets of resistance, and mistakes may be made. Here are some key tenets of DevOps philosophy that you might find useful to remember during your DevOps project: - Change is essential for improvement Failure is essential for learning Blame has only a negative effect Collaboration is key 2.1 What causes resistance? People fear change because they fear for their jobs. Although DevOps is a philosophy for cultural movement, its ultimate goal is often something called Continuous Delivery optimising the software delivery pipeline through automation. And people have always feared automation because it does the jobs they are used to doing. You might find (and if you have time, we highly recommend you read the DevOps novel, ‘The Phoenix Project’ by Gene Kim, Kevin Behr and George Spafford) that you have key members of staff who hold all the knowledge around certain processes and, whilst they are often held up as heroes during IT disasters, actually they are bottlenecks. And they like their positions of safety and indispensability. Knowledge is power, after all. The thing is, these people are often amongst your most talented. In fact, your whole IT department is full of highly trained, super-capable and often very creative people. Freeing them up from mundane, error-prone tasks and making massive reductions in the time they spend troubleshooting and fixing problems allows them to have and act on more ideas. More innovation for you. And less disasters, less embarrassment and less explanations to the shareholders and press. It’s your job to make resistance futile. The future of your business may depend on it. www.ranger4.com © Ranger4 2014 4
  5. 5. 2.2 Leading from the top So in order to combat the resistance, your DevOps stakeholders and evangelists need your support. They need you to mandate their project and make sure that everyone in the company understands its importance and is fully engaged to make sure it’s a success. It’s also worth mentioning that although the term DevOps refers to your IT Development and Operations teams, there are other roles in your IT department that need to be involved too - your technical architects, information security people, testers and QA experts. And not only them - your business analysts too as they will be the conduits of your system and application requirements. And also your lines of business as these people are the ultimate source of your business’ innovative ideas - whether it’s your marketing, sales, finance or product people, everyone needs to understand that you are implementing a program of change that will make your business the best it can be and they all need to be a part of that. Everyone’s input is valued. 2.3 Measuring Success As CEO you’re ultimately responsible for the bottom line, and DevOps is also about cash. When systems are down that often means your business is losing transactions. It means you’re losing customers to the competition and damaging your reputation. If you’re not innovating fast enough, those cool new features, mobile apps or social media fandangles your competition are showing off are attracting your customers away from you. A central tenet of DevOps is metrics. You need to become metric obsessed, if you aren’t already, and push the love of stats through your whole organisation. If your CIO isn’t baselining your position at the start of your DevOps project, you should ask that they do. Ask them for metrics for: - The volume and frequency of application releases The number of software defects/bugs over time and time spent troubleshooting Frequency and length of application outages (and cost to the business where possible) Current infrastructure costs in pre-production and production (hardware and software) Those metrics are all technology based, so why not try for some softer, culture-based metrics around customer satisfaction and employee satisfaction? www.ranger4.com © Ranger4 2014 5
  6. 6. 3.0 Getting Started Hopefully your CIO has come to you with a proposed plan. We recommend starting with a piece of consulting to review and measure (baseline) the current state. We believe it’s helpful to have a third party to perform this piece of work because: - You can choose a team of experienced DevOps experts to work with your teams - the experts in your business - Often companies find it difficult to find the time to save time. Sometimes people are so busy firefighting they find it impossible to take a step back and plan for change - Humans are emotional and political and sometimes it helps to have a non-invested third party take a look - you might find you are told little you don’t already know but pragmatically delivered observations can carry more credence - You might want some help visualising your desired future state from people that have taken other organisations there already - You’ll need a fit assessment of proposed projects and some technology recommendations from people that know the market and have experience implementing proposed tooling 3.1 Things you need to make sure your CIO isn’t doing - Don’t let them create another silo - i.e. a DevOps team - Hiring DevOps people doesn’t work either - Rushing out and buying tools isn’t a good idea - it’s best to first understand and fix the people and process issues - That said, at some point, commitments to automation projects need to be made as this is the only way you’ll achieve the optimum benefits of reducing your innovation’s time to market - Not baselining and producing quantifiable, measurable project targets - how are you going to report on the payback on your investment without these? How can you congratulate your teams on their successes without knowing what they are? 3.2 Things you need to make sure are happening - You receive regular reports on the quantifiable metrics of success to share with the whole company - Rewards are given and success is recognised and celebrated - Failures are reported and investigated, without blame, with the intent to improve and learn - Everyone is being heard - Your people are becoming happier and your customers are delighted www.ranger4.com © Ranger4 2014 6
  7. 7. 4.0 Conclusions DevOps is here and companies worldwide are reporting significant benefits and improvements through implementing DevOps best practices. Ranger4 are experts in DevOps and offer a DevOps Maturity Assessment to get organisations started on their DevOps journey. We can measure you against our DevOps Maturity Index (DMI) and give you a score - a quantified number that you can aim to improve. To find out more, visit www.ranger4.com www.ranger4.com © Ranger4 2014 7