The influence of Lean Methodology in DevOps is exciting, and we are starting a series on the BMC DevOps Community on the subject. Check out my first entry in the series.
I encourage all of you to check out John Allspaw’s new blog series on automation. I am excited about changing the conversation in our industry from tool-happy discussions to how IT can mature in its use of automation. It doesn’t matter if you are pushing DevOps, Lean, ITIL, whatever. The point is that the IT industry needs to grow up and sit at the adults’ table. Too much of our economy rides upon the success of what we do for a living to let ourselves get distracted by the coolness of what we do, and forget the seriousness of what it means.
Push on Mr. Allspaw. Now, I will delve into those massive papers you referred to in your blog. I feel like I am in graduate school again. Too bad there isn’t any Jolt Cola in the house.
I was reading Tom Parish’s interview Lori MacVittie on the DevOps Leadership Series, and I came across her statement that DevOps and automation are not, in fact, tied at the hip. I think that asking if DevOps needs automation to be successful is a really good question. In fact, it may be one of the essential questions – which comes first? Process or Automation? Lori clearly lands on the process side, and I tend to agree.
I always make the analogy to a hammer and nails. After repairing my fence last year, I discovered what a wonderful thing a nail gun is compared to a hammer and nails. What would have taken me 20-30 minutes, took me 5 minutes – bam, bam, bam. But nail guns are also dangerous. You can’t shoot yourself in the foot with a hammer… I think automation is a lot like that. Just automating something with no firm process in mind is like handing a nail gun to someone who immediately attached their foot to the floor – in record time. And I am not innocent of this. At one point in my career I was fascinated with the power of JScript on Windows when enabled with Active Directory (yes – I am geeking out – bear with me). I could write one script that would execute across 10s of servers in a way that was more difficult in UNIX at the time. But that was the problem. I tested a script on a live environment, and almost took out a live site (we won’t discuss how close I came to doing just that…).
Now, the counter point is that well-tested automation following a good process can’t beaten. I remember back in my BladeLogic days when a sysadmin was intent on convincing me that she could make the same change to 20 UNIX servers, one after another, and be more accurate than an automated tool. Doubtful. But say she could. That only makes sense on the smallest of scales. But if she had automated that, she could have spent her on something actually useful. Imagine that. And isn’t that the point, to make ourselves more productive, so we can make the business (and ourselves) more successful?
That is why applying a methodology like KanBan to DevOps is so promising. Instead of blindingly applying automation with cool tools, you look at your processes holistically, and apply automation systematically where it provides the most value. Which is exactly what manufacturing has done over the last few years.
So, yes. You can do DevOps without automation. But that’s the wrong question. Can you do DevOps without well-understood process and culture change? No. And don’t apply automation unless you tackle that as well.
One of the best things about DevOps is the potential to harness technology more completely to the goals of the business. In particular, as Damon Edwards put it almost two years ago “DevOps is not a technology problem”, but rather a business problem. To put it differently – DevOps is a business solution, since the average corporation spends 50% of their budget on IT. Shouldn’t they expect more out of their IT organizations?
As Gene Kim, another great DevOps thinker, said in a BMC interview, even before DevOps was the latest trend, he found that high performing IT organizations were 5-7 times as productive as than their low-performing peers. The ground breaking application of agile and lean methodologies to the DevOps area are blowing that number out of the water as well, making John Allspaw’s 10+ deploys a day in 2009 look positively quaint for some businesses.
So, if the spirit of DevOps is made reality, then it has the potential to make IT a profit engine rather than an unfortunate and annoying cost. Bottom line, DevOps is the best opportunity in decades, maybe ever, for Operations to be relevant to the business, and a valued growth engine.
So, with all that said, why is most of the DevOps discussion still revolve around technology, and not the business and organizational obstacles to success? We in IT start with what we know – technology. How do I take this cool technology I love – like configuration automation, and apply it to the DevOps problem? Also, much of the discussion is also being driven by software companies that have a vested interest in selling technology and services rather than advocating change per se (As an aside, that is why we have tried so hard to keep the DevOps leadership series at BMC informational, rather than hawking product). In my opinion, this is the natural evolution of any technology trend. So, how do we move it forward, help DevOps continue to mature?
I would suggest that an earlier paper that I co-wrote with Tim Fessenden could provide a clue – building a center of excellence. I will spend some time in future posts working out the details of what that means, but I am convinced that a similar approach as we advocated is essential to implementing DevOps for the average enterprise IT shop (rather than extraordinary ones like Amazon or Etsy). The essential element of the argument is that most IT projects fail because they are incapable of proving their value to the business – usually because of a complete lack of established business metrics. Any why no business metrics – because nobody is held responsible for creating and reporting on business value. So, in short, here is one way to start fixing that:
1. Create a virtual “Center of Excellence” focusing on implementing DevOps at your company
2. Make sure to include business analysts on that team who will be responsible for business metrics
3. Agree on set of “success metrics” that will reported on something like a monthly basis to executives
4. Implement tools to gather and report on those metrics
5. Rinse and repeat for each new project
Over time, the hope is that you will have business expertise embedded in your operations team, and senior leadership will have a very clear idea of what value you are providing. Now, this does mean inviting the “suits” to the party, which might seem to be the end of the party. My suggestion is, ask them to lose the tie and jacket, make them pay for lunch, and you might find that you can work together pretty well after all.