Use the CALMS framework for a smooth DevOps transition
Adopting DevOps can be challenging, especially when communicating across IT and business teams. The five elements of the CALMS framework can help organizations measure progress.
DevOps has become a common approach to managing the flow of code across development and operations teams. But monitoring a shift to DevOps from models such as Waterfall development can be hit and miss -- and even when IT teams take steps to track progress, the business itself is often excluded.
To address this, early DevOps proponents John Willis, Damon Edwards and Jez Humble introduced the CALMS framework: Collaboration, Automation, Lean, Measurement, Sharing. Development and operations teams, including testers, can use the CALMS framework to gain better insights into their organization's DevOps adoption.
Collaboration or culture
Although DevOps is predicated on greater collaboration between developers and operations staff, it does not mandate collaboration between these groups and the business itself. At the culture level, the CALMS model aims to ensure that the organization as a whole agrees on why DevOps is in place and what is expected from the initiative.
The CALMS model emphasizes that the only reason for technology is the end result; it must exist to support and enable the business, not just because it is the latest technology. Introducing collaboration among business, development and IT ops teams at the beginning of a DevOps transition sets the stage for gaining support across the board for changes in how projects are run and delivered.
Such collaboration must be based on nontechnical dialogue with business teams, getting them on board to fund and support continued work on projects that will reap rewards further down the line. Technical staff must ensure that perceptions of capabilities, costs and timescales are accurate and explain any changes to these parameters to the business side.
Automation
DevOps without automation is a bad idea, but bad automation that forces through changes can be even worse. Although DevOps is closely tied to continuous development and delivery practices, it is still important to take steps to ensure that poor code is not pushed through in deployments due to inadequate testing. CALMS promotes maintaining a solid testing regime without significantly slowing down DevOps processes.
Introducing automation too early is likely to be counterproductive. It's far better to stick with manual processes at the beginning of a DevOps implementation and then introduce low-risk automations as the teams involved get used to how DevOps works. Move on to more advanced automations once the level of risk has been reduced through IT teams' increased familiarity with the tools in use.
Lean
Ensuring that automation doesn't negatively affect performance requires agreeing upfront what the organization means by being lean, a concept drawn from the 1980s Lean manufacturing philosophy. Although lean software development focuses on increased efficiency and reduced waste, keep in mind that cutting corners is not being lean -- it's taking unnecessary risks.
Taking a lean approach means identifying a suitable risk profile for your company, defining the desired outcomes of a DevOps project and cutting any steps that don't support those areas. This should be a learning, iterative process, where lessons from one project are used in others. For example, areas noticed in one project as steps that could be eliminated should be caught and codified for the next project.
Similarly, any steps that lead to problems must be treated as learning opportunities, rather than repeating the same mistakes hoping for a different outcome. Such learning comes fastest in the first few projects at the beginning of a DevOps transition, when the biggest amount of "fat" can be identified and more easily cut out.
Measurement
As with any approach, organizations won't learn from the process of shifting to DevOps without using metrics and monitoring to understand what is happening and the end results. Business-centric tooling must be in place to track KPIs and expected outcomes. Use metrics that measure success in business terms, whether financially or in terms of required capabilities.
At first, organizations just starting to adopt DevOps will find that monitoring and measurement only show them where the problems are. However, creating a baseline and using monitoring and metrics as part of an evolution toward continuous improvement can accelerate an organization's DevOps journey.
Sharing
Ensure that all participants in DevOps processes maintain visibility into what is happening. Most DevOps tools have built-in feedback loops that include operations and development teams, with most bringing in the help desk as well.
However, remember that what is being done is ultimately for the business. IT teams must keep the business aware of what is happening and project outcomes. This brings us back to the Collaboration step -- a reminder that the CALMS framework is a circular approach.
What to keep in mind when adopting CALMS for DevOps
Without viewing CALMS as a circular process, attempts to implement the model will fail. The idea is to learn continuously and improve on how the organization uses the DevOps approach. These improvements should be fairly large to start and become more incremental as the organization and its DevOps experience mature.
Bear in mind that CALMS is a framework, not a set of tools in itself. Organizations applying CALMS still have room for choice when it comes to the tools that are built into DevOps pipelines. These include products from vendors like Atlassian and HashiCorp as well as open source DevOps tools such as Git, Puppet and Jenkins.
CALMS is also not a replacement for other development philosophies and systems that can be used to ensure a greater level of control over DevOps. Approaches such as Agile, for example, can provide much-needed consistency and solidity around how a company implements DevOps. However, CALMS can help measure the maturity and effectiveness of an organization's DevOps initiative.
