Since the term was established organisations have been trying to implement “DevOps”. Many see it as a / the answer to speeding up, to increase quality and to reduce cost. The market also does its best to try to position DevOps as a solution – a simple answer to a simple question; “how do I speed up whilst increasing quality and reducing cost?” – deploy DevOps. However, as with many things in IT, finding that simple answer can be a complex process.
One key step towards a “DevOps related solution” for many clients is to understand current. Without a solid view of the current issues and challenges and the related root causes, deploying any changes can be counterproductive. Finding solutions to address the challenges you will have to analyse and detail the root causes. . The table below is an example:
The answer to addressing the challenges are related to people, process, tools + building an AWS type infrastructure. It is about “revolutionising” the transition, de-risk IT deployments, eliminate the excuse” but-it-works-on-my-system”, and break the silos between developers, testers, release managers, and system operators as well as streamlining the build to run process.
As these issues are no unique to organisations the term DevOps was coined  as a “catch all” phrase covering all that is needed to address these key issues.
And herein lies the issue – as soon as a simple phrase is being created all expect that DevOps will be a silver bullet for all – a simple answer to a simple question.
99% of my clients have existing, long standing and established traditional IT that can be tricky & costly to change. Lets us an example – assume that there is an existing SAP environment that supports a critical business service (like CRM or ERP) and let’s say that from initiation to provisioning a new server can take 12 weeks. The duration was acceptable 2 or 3 years ago but today the business has to shift faster and therefore it is expecting to cut the 12 weeks to 1 week.
On paper a DevOps and Cloud approach is / can clearly be the right answer. However, to understand the actual “solution” you will have to dissect the 12 weeks into detail to really understand the reasons for the 12 weeks. Simply jumping straight to the conclusion that using ancible together with chef + pushing all to “the cloud” might accelerate the actual physical provisioning time – but what if the previous provisioning effort what only 5h across the 12 weeks – automating the effort will shave 5h off the 12 weeks and not the require 11 weeks.
Maybe it would have been better to look at compliance related provisioning & procurement activities. Maybe simply re-assessing the risk profile of the ERP solution would have sufficed to cut a large part of the actual process.
There a number of key leanings that should be applied when it comes to DevOps:
1. Being too Focused on Tools & Technologies
a. DevOps is not just about tools or a technologies; t is a foremost a people and process transformation
b. Tools are fairly marginal, focus on the people and process
2. Thinking DevOps is Anything more than Process Excellence
a. DevOps is mostly “Process Excellence” and “Lean manufacturing” applied to IT.
b. Dust off “The goal” and those lean manufacturing books find your constraints, reduce WIP, and start optimizing your value chain.
c. If you want lean management with an IT perspective read “The Phoenix Project” by Gene Kim et al.
3. Trying to Eat the Elephant in One Bite
a. Don’t try to take on all of IT, all workloads, all projects, all people all at once
b. Start with a workload, group, project, assess the value chain, create a plan, do, learn, repeat.
c. Do this until you have success, knowledge, capabilities, lessons learned, and then scale out to the next beach head
4. Creating a DevOps Team that has No Idea How You Operate
a. If you hire a new DevOps transformation team your Operational teams will need to spend a lot of time getting them up to speed
b. Try mixing some “new blood” with some “old blood” that wants to change
5. Thinking DevOps is a Quick Project
a. For most large companies DevOps will be a multi-year journey
b. Hit the high value areas first to create momentum
6. Not understanding root causes
a. You will have to dig into the challenges to understand root causes
b. Don’t see DevOps as a silver bullet
c. Have a Plan for addressing the root causes
Achieving the objectives – to speed up, increase quality and to reduce costs – an organisation should move step-by-step rather than big bang to ensure objectives are being met :
- Define a clear target solution
- Establish a clear transformation plan
- Actively manage the resulted transformation program.
Point 1 and point 2 are all typically about understanding root causes, establish a clear target (for people, process and technology) and ensure that there is a clear detailed plan to move to that target. Not an easy task as Clients have to deal with the complexity of existing environments – pre-production environments do seldom reflect live production which can make it difficult to perform fast root-cause analysis. In addition existing teams work in some separation to each other and the speed of innovation in the software and hardware area is increasing. In addition, clients have to deal with the fact that DevOps is still misunderstood.
The fact that many see DevOps as a Tools implementation and that it can be difficult to devise an effective and efficient implementation approach. Plus our clients never stay still – typically they have a significant change programme underway and DevOps implementation has to co-exist.
Clients typically should proceed step by step, following a clear DevOps based maturity model  :
Yes, well integrated tools that will maximise automation and therefor increase speed & quality are key ingredients. And looking at organisations that successfully implemented a “DevOps” approach it seems to many that the answer is simple. However, finding that simple answer can be complex.
Thanks for Reading.
About the Author: Gunnar Menzel has been an IT professional for over 25 years and is VP and Chief Architect Officer for Capgemini’s Cloud Infrastructure Business. His main focus is business – enabling technology transformation & innovation.
 Patrick Debois is widely being credited for establishing the Term DevOps
This article was written by VP Enterprise Architect and Gunnar Menzel from Capgemini: Capping IT Off and was legally licensed through the NewsCred publisher network.