DevOps - The Future of Application Lifecycle Automation / Part 4
Gunnar Menzel, FBCS
Master Architect at Capgemini, BCS Fellow, Architecture, Strategy & Transformation Expert
Got a DevOps design? You selected a tool set? So how to get it "implemented?". In this DevOps part I will focus on the implementation part
As outlined in my previous blogs (check out part 1,2 and 3) the adoption of DevOps is hampered by a number of key aspects :
- The lack of a standard definition for DevOps has created confusion for infrastructure and operations (I&O) leaders, trying to adopt this philosophy
- There is no standardized or simplified approach regarding the adoption of DevOps by an enterprise I&O leader, causing confusion about how and where to start
- Each DevOps implementation is unique and every customer requires a customized approach
In practice, tools, methods, and technologies are seldom deployed on green-field sites and having implemented DevOps for more than a decade now, we believe that the key to successful is to :
- Define a clear target
- Establish a clear transformation plan AND
- Actively manage the plan execution
DevOps implementation should not be merely perceived as deploying a new tool like CodeStream or Docker. It should be viewed from a bigger perspective and should be planned and executed in an efficient manner. Poorly planned DevOps implementation may result in significantly higher costs.
DevOps implementation starts with creating a rationale business case, mapping a way for code migration between environments (considering people, processes, and technology), and placing focus on the target. Understanding the 'As-is' scenario, mapping the 'To-be' scenario, and estimating the benefits of moving to the 'To-be' are critical for success. DevOps implementation should be backed by a strong business case. Every environment does not benefit from full or partial DevOps deployment. For instance, environments with little change requirements may not benefit from DevOps implementation at all. In our experience, many DevOps projects have failed due to the absence of a strong business rationale or a poorly planned start.
1.) Define a clear target
DevOps claims to reduce impact of changes to reduce cost and minimise impact to the live services. As applicable to every change project, the decision to change culture or processes and to deploy the right tools must be backed by a strong business case. Many businesses struggle to take the right decisions at this stage. To estimate the benefits of DevOps implementation within their environment, they should analyze the existing situation - the existing tools, processes, resources and their skills. Then, as the “snowflake” point in Gartner’s paper [2], each client context is different and what works for one might not work for the next.
Capgemini is working on a generic DevOps Implementation Framework (DIF) that will formulate the “artefacts” needed to define the target and create a business case.
2.) Establish a clear transformation plan
Once the business case has been created and approved a detailed plan of actions is needed to manage the implementation of the changes needed to achieve the anticipated outcomes set out in the business case. Typically three actions need to be followed: 1. Change the culture 2. Establish one Development-to-Operations 3. Deploy common tooling The choice of activities that need to be executed for a solution depends on the actual context and needs to be established during the “define a clear target” step.
3) Actively manage the plan execution
In addition to careful formulation of the plan, it is important to carry out an efficient execution. Just like with any implementation project you must ensure that the "solution" is being implemented.
Summary
DevOps is an "old" approach understood and discussed by a relatively small number of professionals. With the advent of new technologies and growing demand for faster processes and better quality, DevOps has acquired new dimensions. Organizations across the globe have been implementing a full or partial DevOps solution. However, the road to DevOps is not straight. DevOps is a complex concept with no clear definition or list of products. It lacks a common vocabulary and capabilities required for DevOps implementation differ from one environment to the other.
To overcome the challenges we suggest:
- Define a clear target,
- Establish a clear transformation plan
- Actively manage the plan execution
To get maximum benefit from the DevOps implementation, we recommend focus on three key areas - change of culture, connection of processes, and common tooling. This is crucial to reduce development-to-operations costs and minimize change related outages.
[2] Gartner, Seven Steps to Start Your DevOps Initiative, 16 September 2014, G00270249, Ronni J. Colville
Thanks for reading my blog - you can download the full document here: https://www.capgemini.com/resources/devops-the-future-of-application-lifecycle-automation
Principal Domain Architect (Environment Agency) DEFRA
10 年Some great succinct stuff Gunnar, I'm looking at DevOps as an essential underpinning for adopting Microservice pattern(s) for delivery of certain solutions : do you or Capgemini have any Microservices insight you could offer?
Master Architect at Capgemini, BCS Fellow, Architecture, Strategy & Transformation Expert
10 年People change is the hardest part of DevOps. Also implementation challenges due to lack of a clear target and plan. Still, such an exciting subject with top benefits.
Technical Director @ Strategic Partnerships Germany, Middle East & Africa at Microsoft
10 年I think the "culture change" was probably the hardest part of our ongoing DevOps transformation - and we underestimated this: There are people who embrace the ideas behind newer methodologies like Devops and Scrum and people who resist (actively or passively) them. Interestingly enough, the very first people who lefts us were the "Brents" (Phoenix Project lingo): The guys who loved Priority 1 incidents because they could show the Organization that they were the "heroes". And after that, the people who had become very comfortable in their silos and didn't want to change During the last two years, 60% of our former "Ops" people have left us BUT instead we signed up people who really believe in DevOps. And THAT got the whole DevOps train rolling... We also had people leaving Dev and Infra for similar reasons - just not as many. We had a similar experience when we introduced SCRUM/Agile. Very painful but necessary - you need to make sure that you have the right people on the bus!
Production Owner, OP Sourcing at OP Financial Group
10 年The implemetation will fail if the mindset is not changed at the same time. This is company culture challenge. Change resistance will be enormous, in every level of the organization, which must align with the process. Otherwise it will be struck by silos in every challenge met, along the way and the devops implementation stalls. Executives then see it as never ending and costy project. This is where Conways Law come to picture and the DevOps implementors must think that through very carefully. BTW. The Phoenix Project, the book, is the implementation guide, in a novel format.