You are trying to implement DevOps but results are far below expectations? In this article we will see why, and how to improve the situation.

CAMS stands for Culture, Automation, Measurement, and Sharing. It is a model, a set of values used by many DevOps engineers.

There are many definitions of DevOps, and, what is worse, several interpretations coming from people who have not worked directly on related topics. In some cases, they are simply selling the magic solution, the magic trick to convince directors and managers that they have found the quick way to solve all of their problems.

One of this magic solution consists in automating everything. Wait, what? Isn’t automating everything a good thing? Yes and no. Automating everything has to come in a clear framework, or you are simply going to move the problem somewhere else.

DevOps has born as a set of software-development practices that combines a software development mentality with other functions in the organization. It has born with issues and frustrations impacting operational and development world, trying to have them working together, exchanging working approaches and experiences between the two worlds. And not only between these two worlds.

Something that often is forgotten to tell, DevOps is first of all a human problem.

A human problem, nothing really related to using this or that other tool, or pretending that automatic everything will be enough to fix the problems.

On the contrary, admitting that DevOps is a human problem, we open the way to analyze and try to improve the general situation.

And here CAMS model comes at our aid!

CAMS Model

CAMS model has been created by John Willis and Damon Edwards. It stands for Culture, Automation, Measurement and Sharing.

These set of values can be seen as pillars of DevOps. It is really important to understand that they are supposed to be implemented together, or they will not be able to support the roof.
We could put all our effort in automating everything, integrating the best tool available on the market. But if we are not advancing as well on the cultural aspect, if we keep allowing the instauration of silos, we are not going to have a solid foundation.

Culture: according to Patrick Debois, DevOps is a human one. Again, not a technological one. Culture encompasses social behavior, institutions and norms. In short, mutual understanding of each other. It is not really about ping pong tables or free food. It is about having different groups being able to speak the same language, have a mutual respect and understanding, being willing to solve the conflicts and, in definitive, to care about overall goals.

Automation: we have just seen that we have four pillars. Thinking to reduce DevOps to automate everything, is just a way to fail DevOps implementation. And at the same time, it is an accelerator to unlock other DevOps benefits. Manual work isn’t so efficient, and automation allows to address quality problems in the value stream.

Measurement: It is said that we cannot manage what we cannot measure. It may not be totally true, but we need to observe and measure what is going on. In the system, and with the people. And we have to remember that there are several issues in doing so. We need to avoid to watch or measure the wrong things. For example, measuring people performance using the number of pull requests they produce. And, it has to be avoided to incentivize improperly. In DevOps, the idea is to measure outcomes across organizations.

Sharing: it is the foundation of collaboration. Requires transparency, and teamwork spirit. In order to learn and improve, these are key attributes. It can be done in several ways. For example with documentation, mentoring, peer reviews, pair programming and so on.

Conclusion

DevOps looks to change people’s behavior. Using automation to accelerate the change. Measuring what is done. And working together to build better products, and services.

What is important to understand, is that these values, these pillars, can deliver what promised only if grown together.