Recently I took over as the manager of the Emerging Technologies team at IBM/Rational. One of the Emerging Technologies that my team is supposed to focus on is the area of DevOps. So now I have a small team that is focused on DevOps. But what in the world is DevOps? I thought that I knew what it was, but I figured that I would do a quick experiment to improve my understanding. I decided to ask several different people for their definition of DevOps. Surprise!! I got back about as many different answers as people that I asked. (OK, I wasn’t surprised, but that is why I did the experiment in the first place)
“Big deal”, you may be thinking, “all you have done is to state the obvious”. But the more that I thought about it, the more that it bothered me. The goal of my team is to help launch our new technologies in the area of DevOps into the market. We do this by having conversations with our customers, participating in conferences, writing in our blogs (Freddy has some good DevOps material in his blog already), and other various enablement activities. If we cannot have a common definition of what DevOps is, then how can I expect my team to establish a common language and terminology to talk about DevOps? It would be like trying to teach math when you cannot agree on what a number is.
So I looked at the IBM DevOps page on IBM.com, and found a set of entry points for DevOps. Drilling into those led me to specific IBM products, but it really didn’t answer my question. So then some smart people pointed me at the IBM DevOps page out on developerWorks. I read this and found myself agreeing with most of it (even though it is marketing), so I decided that maybe this is something that I could use as a working definition of DevOps. On that page they say:
“It’s a set of principles, practices, and products to help organizations deliver high-quality software to market faster, while minimizing cost and risk. The IBM approach to DevOps drives end-to-end innovation throughout the entire software lifecycle.”
This still feels somewhat fuzzy to me. I am a nuts and bolts guy. I like “Janitors” a lot better than “Sanitation Engineers”, and I like “Software Testers” more than I like “Quality Assurance Engineers”. Let’s face it, I am a “Manager”, not a “Talent Direction Technician”. So I want a little more direct definition DevOps.
So I dug in a little deeper and looked at the DevOps Practices page. This is a little better, it has more for me to sink my teeth into. They basically highlight five key practices for what IBM considers DevOps. These are:
- Plan, Track, and Version Everything
- Dashboard Everything (my personal favorite, I am a big believer in transparency)
- Automate Everything
- Test Everything
- Monitor and Audit Everything
That helped me sort it out in my mind. Now I think I understand the IBM definition of DevOps. It’s the blanket of improved software delivery (better, faster, cheaper) by using the five practices listed above. That is a good starting point for me. Unfortunately, it covers the automation, tracking, and reporting of (you guessed it) “Everything”. That is a pretty massive scope. I am still wrestling with this part of the DevOps definition.
So maybe by now you’ve become convinced that you need to address DevOps, but you’re struggling with what DevOps is, and just what you should address first. My advice is to talk to people in your organization, and find out what the most painful piece of the software delivery lifecycle is. Address that piece first, and attack it in small chunks. You need to start breaking down the technical and organizational barriers, and share these five key practices with everyone in your organization. DevOps is a philosophy, a way of looking at the entire software development process. By encouraging these 5 practices in your organization, you’ll slowly see improvements in how your software development is done, and begin to realize the promise that “DevOps” has to offer.
Now I am lucky, because I have a dedicated team that is focused on DevOps. You can see this in Freddy’s DevOps blog, in Darrell’s blog, and soon in Smith’s blog. I can ask them questions when I am too busy (or dumb) to figure something out. You can use some of the same resources that I used, and you can ask our experts questions on their blogs.
Dan Toczala's Blog 