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.