Thereโs an interesting parallel between Zen and DevOps. This is best illustrated by a kลan. Just to refresh your memory, a kลan is a story, dialogue, question, or statement. Kลans are used in Zen practice to provoke the โgreat doubtโ and test studentsโ progress in Zen practice. The kลan that appeals to me is โIf you meet the Buddha on the road, kill him.โ This is derived from an old kลan attributed to Zen Master Linji, the founder of the Rinzai sect, as Iโm sure you already know.
The last thing that Zen and Buddhism are associated with is violence but this, initially surprising, directive shouldnโt be taken literally. The road in the kลan refers to the path to Enlightenment or Awakening. Meeting the Buddha implies that you think that you have reached your goal. But reality is an impermanent illusion, so you never reach your goal in the sense of a static state. Keep on meditating and searching.
So what has DevOps got to do with a school of Buddhism? Apart being an airy-fairy cult in which anybody without a pigtail, t-shirt or iPad is regarded with suspicion. Just joking folks, but if youโve ever attended a DevOps event youโll recognize what Iโm talking about. It was the frequent discussions about the definition of DevOps that triggered the parallel with Zen. The notoriously unmovable Wikipedia entry refers to it as a software development method, which it ainโt. Some people associate it with an organizational construct. Others with tooling. Itโs much easier to define what DevOps isnโt, because what youโre then left with, is what it is. This in itself is Zen-ish. But wait โ thereโs more to come.
One of the best sources for a definition or description of DevOps is Gene Kimโs paper โThe top 11 things you need to know about DevOpsโ. Gene, one of the authors of the ground-breaking book The Phoenix Project, refers to DevOps as โthe emerging professional movement that advocates a collaborative working relationship between Development and IT Operations, resulting in the fast flow of planned work (i.e., high deploy rates), while simultaneously increasing the reliability, stability, resilience and security of the production environment.โ I like the word โmovementโ. In addition to meaning a group of people working together to advance their shared ideas, it also implies continual change.
The Phoenix Project describes three underpinning principles from which all DevOps patterns can be derived. They describe the values and philosophies that frame the processes, procedures, practices, as well as the prescriptive steps. The principles are:
- Systems thinking
- Amplify feedback loops
- Culture of continuous learning and experimentation
The first principle โ or โwayโ, as they call it, which reminds me of Tao and Zen โ emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department โ this can be as large as a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).
Amplify feedback loops is about creating information that allows corrections to be continually made. It includes understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where needed.
Finally, and most pertinent to my fondness for โmovementโ, is the Third Way. This is about creating a culture that fosters continual experimentation. This requires taking risks and learning from success and failure, and understanding that repetition and practice is the prerequisite to mastery. Experimentation and risk taking provide the drive to improve, and mastery of skills enables the dampening of unwanted effects of a experiments that have gone off at an undesirable tangent.
The experimentation approach is very effective in complex situations or โsystemsโ. These comprise many interacting elements with nonlinear interactions where minor changes sometimes produce disproportionally major consequences. These dynamic systems are unlike ordered systems that constrain the agentsโ behaviour. In complex systems, behaviour has a tendency to emerge rather than be predicted, let alone be planned. This means that in order to change and improve the situation, a probe-sense-respond approach is needed. In other words you experiment and observe what happens. If the results are favourable, you enlarge the experiment in order to amplify the effects. If they are harmful, you diminish or stop the intervention and deal with any collateral damage. So itโs about applying safe-to-fail experiments rather than relying on illusionary fail-safe design. This take on complex adaptive systems is part of Dave Snowdenโs comprehensive sense-making Cynefin framework. He distinguishes between systems that are ordered and therefore predictable (with a subdivision of obviously ordered and complicatedly ordered), unpredictable complex systems, and finally even less predictable chaotic systems (which require immediate and novel action in order to stabilize the situation).
Most enterprisesโ information system landscapes are a heterogeneous mix of legacy and modern technologies, with intimately intertwined interfaces between various component parts. The systems in turn are supported by an often equally heterogeneous and interrelated mix of internal and external IT organizational functions. This combination of system landscape and organizational ecosystem is often so complex that reliability cannot be guaranteed. The preferred strategy is to rely on resilience that is achieved by a combination of technical and organizational measures. The dynamic nature of the situation in which things are in constant flux, demands equally constant experimentation and learning to provide an adequate response. DevOps is part of the solution. But itโs never going to be a state that once created or emerged, remains the same. So if you think that youโve found it, kill it and keep on experimenting. The only desirable steady state is a constantly evolving state of mind.
References
- Cynefin Framework: A leaderโs framework for decision making, David Snowden and Mary Boone, Harvard Business Review Nov 2007,
