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,
