CALMS - A Holistic View Of Work
Tags: devops
Published: 2019-12-31 15:05:55

**CALMS**

Ever since hearing about CALMS the first time it is stuck in my head.

But first let's talk about how brutally misleading this acronym is. We are talking about changing the way of working and not even of the single individual, but of all the parts that make up a company. This is a revolution, who can keep calm in a revolution? Well okay to be fair this term is "just" a description of trends and ongoing processes, so it is not as near as dramatic as a real revolution. Except if you work in company which is still stuck on working the waterfall way, then you should be ready for quite a ride.

The term is not exactly new, [CALMS](https://whatis.techtarget.com/definition/CALMS) was coined in 2010, first as [CAMS ](https://web.archive.org/web/20190105123119/http://devopsdictionary.com/wiki/CAMS)by Damon Edwards and John Willis at the Devopsdays in Mountain View on June 25. Later that year in a talk Jez Humble added the L, sadly the slides of this are now inaccessible. Some folks perceive CALMS as a framework with the potential to supersede ITIL and ITSM, in my opinion they will much rather be adapted to the changing needs.

So what are the wondrous meanings of these five letters? Lets dig in!

**C - is for Culture**

This is the part with the revolution. A lot has changed since industrialization has changed society. It is time for society to turn the tables and change the ways that companies work into a more life affirming manner. The funny part is, that the companies will end up with higher motivated employees with improved problem solving skills and overall better productivity rates. Work does not have to be dull, boring and repetitive. But let's turn down the scope a bit, we are not talking about the [culture of societies](https://en.wikipedia.org/wiki/Culture) here but rather about the [organizational culture](https://en.wikipedia.org/wiki/Organizational_culture). The agile movement already has shaken the foundations and proven that at least for teams the waterfall system is ripe for retirement. With DevOps and CALMS on the rise the old management methods are fighting a losing battle. Companies which do not embrace that change will face rough times and their chances for survival are slimming.

**A - Automate me baby**

The most prominent part of DevOps is the [automation](https://en.wikipedia.org/wiki/Automation). In IT it is not as feared as in other industries. While in manufacturing many jobs have been replaced by machines, this is not so for the software industry. A very important part of the DevOps mission is to spread the A through the C. There are very many reservations against automation, deeply ingrained in the minds of the colleagues of other departments. In a future article I will talk more about automation, but for now let me state: if you already believe why it is great, collect the negative ideas of your colleagues and then prove them wrong! If you don't believe in automation, then I challenge you to back up your reservations by facts and check if they are hard enough to survive scrutiny.

For me automation is the key to increase performance and life quality for me and my colleagues. I love it when a small change reduces overhead, improves robustness and brings a smile to the team mates faces.

**L - Lean**

This concept has quite a history. Since 1948 Toyota actively developed [TPS ](https://en.wikipedia.org/wiki/Toyota_Production_System) yet only in 1992 they delivered a first publication about it. But already in 1990 the term [Lean](https://en.wikipedia.org/wiki/Lean_manufacturing) was invented, at that time it was only used for production. As the challenges in development are very different, already Toyota invented the [Lean product development](https://en.wikipedia.org/wiki/Lean_product_development) to improve the situation in these areas. Now all of this is manufacturing related, so why is it relevant for the IT area or the DevOps idea? Simply because the Agile Movement is based on lean methods. The most modern way of organizing development teams stems from there, so thank you Toyota.

There even is an institute solely dedicated to spreading the lean concepts - check out [https://www.lean.org/WhoWeAre/](https://www.lean.org/WhoWeAre/).

If you search for lean in books at Amazon you will have over 10 000 hits, too much to even look them all up. So these ideas and concepts are pretty popular and if you are not familiar with them, you should consider taking some time to discover more about them. I can guarantee you will find something which will help in your daily work.

**M - Measure All The Things**

Simple no? Just [measure ](https://en.wikipedia.org/wiki/Measurement)and [monitor](https://en.wikipedia.org/wiki/Monitoring) everything. Ha! Of course it is not so easy. First of all, to introduce logging will create technical overhead and requires storage for the data you want to keep. Also the data has to be evaluated in some way, so you will have to have people or software to do that for you. So only collecting will already cost something and evaluating will cost even more. Why not just do nothing and wait until a customer reports a problem? Besides that using your customers as product testers will cost more trust than is affordable, having no data to trace a problem will result in huge costs to find the failures.

With this you already have reasoning why to at least log as much data as you can afford to, but there is also the legal side. Many employers love to log data about their employees. This causes a continuous debate about [workplace privacy](https://en.wikipedia.org/wiki/Workplace_privacy). And just recently in Europe there were the new [GDPR](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation) regulations introduced, which greatly affect how customer data may be collected and used. So after all it is a very complicated matter, but if done right it is very rewarding.

**S - To Share Is to Care**

Since the rise of the [open source software movement](https://en.wikipedia.org/wiki/Open-source-software_movement) the idea to share knowledge becomes ever more popular. Companies which take the risky step to open up their sources to a community reap in the rewards if done right. The company I work for increased their license sales, since taking this step and many bugs and security issues are being reported by the community, even huge improvements are being provided. 

Or take a look at the history of [Wikipedia](https://en.wikipedia.org/wiki/Wikipedia) itself, which is freely sharing all existing information.

The natural enemy of sharing on the other hand is the [Intellectual Property](https://en.wikipedia.org/wiki/Intellectual_property), of course finding the best balance between the possibility to profit from ideas and free access to knowledge is difficult.

But this is the large scale, take a look on your own workplace. Maybe you could profit from sharing your knowledge and ideas? Do you really want to be a knowledge silo? Well I do not and the more the colleagues know of my duties the calmer I can sleep.


\*\*\*\*\*  
So, looking at these five letters you might realize, that the topics included encompass every aspect of work. And this is my reason for dubbing it as holistic view. Do you disagree? Let me know about it and get in touch :-\)