This post is a refresher to my previous one “DevOps is not just about the tools” from one and a half years ago now.

In the post I introduced the “CALMS” acronym

…and that acronym is still a valid prop to talk about the various pillars of DevOps. It nicely guides one through the different areas.

Working with it together with my colleagues and customers though, one of my co-workers came up with a different “version” of CALMS expanding on it and providing – in my opinion – more clarity in the process.

The end result is CALAMAS.

As you will notice CALAMAS is similar to CALMS but not the same.

  • There is now an “Agile” pillar
  • There is an “Architecture” pillar to support the “Automation” pillar
  • There is a “Structure” pillar to support the “Culture” pillar
  • The “Sharing” pillar has disappeared and parts of it have been collapsed into “Culture”, “Agile”, and “Structure”

What does each pillar of CALAMAS stand for?

  • Culture This pillar recognises the need for cultural change. While CALMS understands both organisational structure and organisational culture together in one “Culture” pillar these are now separate and that is because we find that these are the two aspects that organisations most struggle with.
    On the other hand, the “Sharing” pillar is now very much a part of “Culture” because it is almost the pre-requisite to an adequate culture of sharing and learning without unnecessary blame.
  • Agile This pillar was added to recognise that DevOps is not necessarily – what is commonly considered – “Agile” but that it has very much been born out of the agile movement. An agile approach to software development and delivery can facilitate a move to a DevOps culture in an organisation. On the contrary a traditional separation of concerns can hinder that transformation.
  • Lean This covers a strong commitment to value delivery. Principles from lean management (be it the Toyota Manufacturing System or others) can and must be applied in any DevOps organisation to achieve success. The exact type of lean methodology employed is less important here.
  • Automation Like mentioned in the previous post this is usually where companies start. Automation alone does not help foster a DevOps approach though. If anything, it makes things less secure and less predictable if the other pillars aren’t implemented.
  • Measurement is the pillar that is most often forgotten about when companies adopt DevOps. If they truly want to see problems as they occur, then they have to invest a great deal into this pillar.
  • Architecture This new pillar acknowledges that architecture makes a massive difference. Legacy can slow the adoption of DevOps but it is never a blocker. At the same time architecture patterns can be used to work with legacy while developing new content in a more flexible, encapsulated way.
  • Structure Culture always follows structure and too often companies make cosmetic changes to their middle management hoping that it will make a difference. We wanted to dedicate a pillar to structure to express that this is another important point where many do not go far enough.