About 10 years ago, I was at a Gartner conference. One of the speakers introduced a CEO that had just came up with a great idea for an innovation of their business. He asked all of his C-level executives to come up with a plan for the implementation. They came back with action plans that took anywhere between two to four weeks. Except for the CIO. He expected it would take at least six months to implement all the necessary changes to the company’s IT solutions. Of course, this Gartner speaker may have been exaggerating. But the point was clear. And shockingly, it is still valid today. Many will say that DevOps is the answer to this problem. Let’s see if they could be right. And if they are, how to implement that in practice.
DevOps is arguably one of the most abused buzz words in information technology (IT) today. A search on Google will result in a wide variety of definitions, do’s and don’ts. Many of which are based on opinions or theory books, rather than real life experience. Based on experience gained at our customers, we provide a practical and hands on roadmap for implementing DevOps in a large international enterprise.
Before we dive into the details, let’s take a quick look at why we’re going through all this trouble again. In other words: what’s the added business value of implementing DevOps?
This picture gives a nice overview of the value proposition. We use scrum (or any other agile methodology) to take down the barriers between business and IT. And we use DevOps to take down the barriers between developers and operational support. The result is that we’re able to deliver IT value to the business faster and with a higher quality. But that’s just theory. The interesting part is how to do this in practice. In your own organization that never really compares to the pictures that the theory books paint.
For a good understanding of the roadmap, it is important to be familiar with some other terms that are often used in conjunction with DevOps: continuous integration, continuous delivery and continuous deployment. The picture below describes how these terms relate to each-other and how they cover the typical deployment pipeline that can be found in most IT departments.
The most important message from this picture is that there is a logical sequence in which organizations go from the traditional approach to DevOps. This sequence is the basis for the roadmap we are introducing here. Start working agile to become more flexible in responding to changing needs from the business. Switch from project to product thinking to bridge the gap between business and IT. Optimize the development and deployment pipeline to be able to deliver faster. And bring the Dev and Ops people together in one team to increase quality.
This leads to the following roadmap for implementing DevOps:
Now don’t be fooled by the apparent simplicity of this picture. Yes, the number of steps is manageable, the activities aren’t exactly rocket science, and if you’re dealing with only one team for one solution it should be doable within a month. But if you try to follow this map in a larger organization with multiple solutions, where the teams are geographically dispersed and different managers have different (and sometimes conflicting) interests, the challenge becomes clear. In those cases, it makes sense to take this step by step.
In the next blogs, we will describe what each step means in practice.
Read more about step 1: AGILE.