Download our diagram CALMS Model of DevOps

What CALMS stands for

John Willis and Damon Edwards coined the acronym CAMS in 2010 which was later expanded to CALMS by Jez Humble.

CALMS stands for:

Culture
Automation
Lean
Measurement
Sharing

Let’s take a look at these in turn.

Firstly, Culture. We have written at length in our blog on what a DevOps culture means – we even have an infographic for it but at it’s heart a DevOps culture is one that embraces change, is constantly seeking feedback in order to improve, and seeks to take accountability and responsibility, not shirk it or pass it onto other people. A DevOps culture seeks to push decision making responsibility as close to the edge (autonomy) as opposed to centralising all decision making (Command&Control).

Automation

Secondly, Automation. DevOps loves automation! The everything-as-code mindset is at the heart of DevOps, regardless of the tooling you might use (Ansible, Puppet, Chef, Terrform, Cloud Formation, ARM templates etc). Google express it best in their SRE (site Reliability Engineering) website when they talk about Toil:

“So what is toil? Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows. Not every task deemed toil has all these attributes, but the more closely work matches one or more of the following descriptions, the more likely it is to be toil:” – Google

Automation is the antidote to toil – by automating the low value toil it leaves more time for the higher value-add work. Automation should also improve repeatability and reliability in that the same taks is performed the same way every time, as opposed to manual work with can introduce high levels of variation.

Lean (IT)

Thirdly, Lean (IT) – the 5 key principles of Lean are well documented and the Lean IT movement seeks to extend these concepts into the world of Information technology, and software development in particular. Key texts are Lean Software Development by Tom & Mary Poppendieck and Lean Enterprise by Humble, Molesky and O’Reilly. Lean seeks to achieve FLOW – the smooth transition of work from one “work centre” to the next, in the minimum time. Ideally with as few queues/buffers as possible.

Measurement

Fourthly, Measurement. Whilst it is a truism “what gets measured gets done” (see management guru Tom Peters) DevOps seeks to take this to the next level. The Build-Measure-Learn model from Eric Ries book “Lean Startup” identifies the key cycle, and without measurement, you can never learn or improve. So “measure all the things” is the rallying cry (and a great meme). The annual State of DevOps report focuses on 4 key measures – 2 for speed balanced with 2 for stability.

Lead time (for change) – how long does it take from Code Commit to Production Deployment?
Change Frequency – how frequently are you deploying to production? Multiple times per day? Per week? Per month? Per year?
Change Failure Rate – how often does a change (either the code itself or the deployment process) introduce a bug into production?
MTTR – Mean Time to Repair – how long does it take you to restore service in the case of an incident?

Sharing

Lastly, Sharing – a focus on breaking down silos between departments and sharing knowledge and best practice. Sharing needs to be encouraged and rewarded, and hoarding of knowledge in silos discouraged. A great way to get started is by setting up our own internal “communities of practice” around DevOps, or even hosting your own “DevOpsDays” conference for your organisation. But more than that, it is the day-to-day knowledge sharing that’s important, whether it’s writing an awesome git commit message, a helpful Github README, or writing up an entire knowledgebase article in a wiki like Confluence. Sharing *IS* caring.

If you want to learn more about DevOps, and CALMS, our BCS Foundation Level Certificate in DevOps is based on on the CALMS model. You can sign up for classroom or online course here.

This work is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.