Quantifying DevOps Capability: It’s Important To Keep CALMS

One of the hot debates in the DevOps community right now what exactly DevOps is and whether it even needs a definition. Community member and vendor, ScriptRock, elegantly summarized it here; Skelton Thatcher built on that here; and DevOpsGuys’ Stephen Thair continued the conversation here.

I agree with their assertion that DevOps needs a definition. It is hard to engage with a topic when you are bombarded with comments around culture and collaboration. They are unavoidably important, but to get you started and to onboard new adopters, DevOps needs something more tangible, something that you can look at and see the beginnings of in your business. Otherwise we risk that you leave bewildered about what to do next.

When I think about what DevOps is trying to solve – performance and efficiency in IT organisations — I can’t help but let myself be dragged to ITIL and the thought that we’ve been here before. I felt justified in doing so when I read this in a recent blog post:

It’s unavoidable that DevOps is rooted in ITIL’s lineage. It emerged as a direct response to the siloed and over-regulated implementations that ITIL spawned in enterprises. But back in 1980s, when scientists like W. Edwards Deming first inspired it, ITIL was a new way to improve IT performance and generate efficiency. It all sounds very familiar. DevOps has an obligation to respect its lineage and learn from its predecessor’s mistakes.

If you took away the structured framework of the ITIL library, how would you explain it to a newcomer? How would you convince them that at its heart there is a cultural approach within it that improves their ability to execute IT? It is the tangible elements of ITIL that enable initial adoption and create the opportunity for an organisation to embed it as part of the culture.

To be clear, I don’t think that DevOps needs a 400-page operating manual. But I do think that at a minimum it needs a scaffold to hold together key components and concepts so you can assess your capability, compare yourself to your peers and build clear programs to manage deficits.

I think this framework already exists in the community – it was introduced by Damon Edwards and then refined by Jez Humble into the acronym we now know as CALMS:

  • Culture – Own the change to drive collaboration and communication
  • Automation – Take manual steps out of your value chain
  • Lean – Use lean principles to enable higher cycle frequency
  • Metrics – Measure everything and use data to refine cycles
  • Sharing – Share experiences, successful or not, to enable others to learn

These are the pillars of a successful DevOps implementation. Ignoring just one can compromise overall effectiveness. They also serve as an excellent benchmark to assess your current capability and highlight the areas you need to improve.

From here you can set plans and priorities for initiatives to move the elements forward. Breaking these down into smaller horizons allows you to focus on smaller projects and components and also means you have plenty of opportunity to assess progress and make course corrections. You should also prioritise the initiatives that will have the biggest impact to your customers – this is lean in action during transformation as well as product development.

Be prepared for the definition of High to keep moving. This is continuous improvement in action! The DevOps community will continue to innovate and the advanced practitioners will continue to push the envelope to unlock operational performance. The community continues to play a huge role in helping create context for what Low, Medium and High mean, and you can immediately play your part in that based on your experience and context.

DevOps will continue to enter common terminology in the IT industry at a rapid pace. The way that it attracts and engages new adopters will need to mature as it makes that transition from niche to mainstream. If you find the community difficult to penetrate and hard to map to your own business, consider CALMS as the yardstick by which your transformation will be measured. And when you pitch the DevOps transformation to your colleagues, remember its lineage; it’s the first step to making a sustainable cultural change.

At Rackspace we’re building our DevOps Advisory Service around this approach and methodology so we can understand the key risks that would stop businesses from taking advantage of our DevOps-enabling Managed Services. If you’d like to know more about DevOps Advisory Service and our other DevOps services, please visit http://www.rackspace.com/devops.

Rack Blogger is our catchall blog byline, subbed in when a Racker author moves on, or used when we publish a guest post. You can email Rack Blogger at blog@rackspace.com.



Please enter your comment!
Please enter your name here