In the first section, we saw the context of my client’s operations management, as there are so many others, as well as its current modes of operation. We must now think of an organization that can render the services expected in a global transformative context based on agility. This part focuses on the different DevOps organizational approaches that are taught, or that benefit from documented experience feedback.
First of all it is necessary to take up DevOps’ mantras which must be appropriated, by the analogy to the Buddhist mantras which are repetitive vocal figures whose sounds have the power to channel the mind and to remind oneself of certain virtues of benevolence… As far as we are concerned, the mantras that are mentioned here allow us to refer to the founding principles that serve as benchmarks for both setting up the organization but also for realigning it regularly when faced with the issues and difficulties that were inevitably encountered during a product’s life. Here we return to the principles set out in the DevOps Agile Skills Association (DASA) certification program and in the SAFe framework.
DASA thus showcases the founding principles:
- Customer-centric actions: DevOps must meet a global goal focused on the user’s satisfaction and need. For that we must have the end user’s feedback at the earliest possible moment, readily change directions and continuously innovate. It also helps to prevent the organization from focusing on its own operation rather than the user’s experience.
- Create with the end goal in mind: Each team member must have the overall vision of the expected product in mind and not a fragmented understanding by component where only the management understands the outcome at the assembly’s endpoint. Each member of the organization must act to create a product that works for the end user.
- End-to-end responsibility: The DevOps team is responsible for the product “from concept to grave”. There is no responsibility transfer between developers and operations. It is one and the same global activity aimed at building, sustaining, and developing the product. In other words, there is no single team dedicated to development, or a different one to MOC, another to deployment, and yet another to operations and oversight. This is a single team responsible from start to finish.
- Cross-functional autonomous teams: A product team must be autonomous and therefore able to be autonomous. The resources must therefore be versatile, “T-shaped”, that is to say with transverse skills (horizontal bar) in addition to their depth of specialization (vertical bar). This involves training and sharing knowledge.
- Continuous improvement: A pillar of quality and adaptability, this lean and agile principle must be followed with discipline to eliminate production waste, meet the product’s quality requirement, constantly optimize delivery and engage with painful subjects to make them easy and controlled. “If it hurts, do it more often”. The higher the deployment frequency, the more it is mastered and the level of risk lowered. Conversely, the more we hold back the rollout time, the more risk is taken by adding uncertainty and complexity.
- Automate everything you can: Automation eliminates as much unnecessary work as possible, including administrative barriers that can be included in automated workflows. Automation follows a growing path throughout the product’s life-cycle: Continuous Integration -> Continuous Deployment -> Infrastructure As Code (and versioned) -> Maintenance Automation (fault prediction, auto-winding machines, automatic scalability, etc …)
SAFe also builds its DevOps approach around the acronym CALMR which defines the following principles:
C: Culture. The DevOps’ culture, the mindset, is DevOp’s very first founding principle, and probably the most structuring one. If you do not consider DevOps’ culture, even if you automate the entire deployment on your platform, you will not benefit from the DevOp’s related agility principles. This culture builds strong principles:
- Break the wall of confusion that separates developers from production engineers.
- Favor a collaborative and interactive attitude rather than procedural documentation and skills transfer that tend to freeze development.
- Tolerate risk-taking, and even encourage it, by putting in place effective and proven fail-over and rollback systems.
- Share knowledge throughout the community at any opportune moment that is conducive to exchange.
- Promote the versatility of skills rather than locking them into their area of expertise. A production integrator must have development skills, and a developer must have competency in systems and research.
A: Automation. Automate everything that can possibly be automated.
L: Lean. Build using Lean, by small batches, progressively. The architectural plan built upstream is to be avoided because it is static, it freezes the options and ultimately prevents learning. On the contrary, we must think of simple, sufficient solutions that make it possible to take definitive decisions later and thus reduce the gap between what is expected and what is achieved.
M: Measurement. It is necessary to have data on the system’s behavior to make informed decisions. The data allows objective, shareable decisions and avoids the usual blame games (rejections of responsibility).
R: Recovery. Be able to reassemble a system without service loss and on the chosen version. This technical requirement must be included in every choice made and is necessary to promote the acceptance of risk taking. Recovery procedures must be played continuously during sprints. There must be no doubt about how they work.
Through these two approaches, we see that they tend to move towards the same objectives with a strong emphasis on the culture of agility and the teams’ empowerment. Break the wall of confusion, you build it you run it, fail fast, automate everything, improve the meantime to recovery, improve time to market, if it hurts do it often, T-shapes skills…. These mantras defined above must come back in each review to ensure that the organization follows the DevOps’ path. It is important to keep these broad principles in mind, which are sometimes counter-intuitive for compartmentalized organizations, but essential for a lasting and profound transformation of IT organizations.