We’re delighted to announce that popular presenter Mark Smalley will be leading our upcoming DevOps webinar on 23rd September. As a taster, here he explains why DevOps really is ineffable.
It’s a frustrating but intriguing paradox that I’ve been struggling with since I got involved in the DevOps space: what are we actually talking about? Is it more about adopting a state of mind than following a set of practices? Can you ever say that you’ve implemented DevOps?
This has led me to creating a story called Kill DevOps, in which I draw a parallel with Zen Buddhism. When a monk, on the road to awakening and enlightenment, has a vision that he understands Buddhism, he is warned by the Zen master: “If you see Buddha on the road, kill him”. This refers to the ineffable nature of Buddha. Because it is unknowable, the monk’s destiny is to keep meditating, in the certainty that he will never reach the goal. Yet in so doing, he is practicing Buddhism.
Although some might think otherwise, DevOps is not a religion. But because it is based on the core principle of continual experimentation and learning, the same applies. If you think that you’ve discovered what DevOps is, you’re mistaken. It was possibly true for a moment, but no longer. Kill DevOps as you thought it was. Keep improving your way of working, and in so doing practise DevOps.
Functional diversity and dysfunctional hype
An additional difficulty in understanding DevOps is that there is not a single well-defined, stable and standardised body of knowledge. Much guidance is available in the form of static publications and presentations and dynamic physical and virtual communities, but the guidance is heterogeneous, ambiguous and evolving.
The guidance is heterogeneous and ambiguous because there is no authority that owns or governs DevOps. Various bodies have their own codification of the guidance, mainly for training and certification purposes. While people often prefer the comfort (blanket) of a single source of truth, this diversity in well-considered guidance is functional: it provides valid options to consider and keeps the practitioner on his or her toes. There is also dysfunctional diversity when the term DevOps is used ‘creatively’ for marketing purposes. Which it often is, so beware of the hype.
To further complicate matters, not only is the guidance diverse because of the multiple sources of truth and hype, but the guidance is also evolving because new insights are continually emerging.
In the middle of this dynamic diversity, the book The Phoenix Project (2013) is one of the most stable sources of guidance. It is where many people have gained their initial understanding of DevOps. Its prescriptive companion, The DevOps Handbook (2016), develops the principles and cultural norms in The Phoenix Project, identifying 67 technical practices. A third book, Accelerate (2018) uses the research and the methodology behind the annual State of DevOps Report (1st edition in 2012) to identify 24 organisational capabilities. As such, this set of publications is an example of evolving and coherent guidance. The reputation of the ‘family’ of authors makes this one of the more credible sources.
Learning challenge
This dynamic diversity makes it quite a challenge to understand DevOps, as I’ve found in my half-day DevOps Introduction courses, which are often complemented by putting the theory into practice in GamingWorks’ highly interactive The Phoenix Project game. During the introduction, I often find myself balancing between “this is DevOps” and “but then again, it isn’t”.
I’m not only reluctant to define DevOps but I also want to emphasise that each organisation will use different parts of DevOps in differing ways, depending on their nature and their goals. So ‘doing’ DevOps means different things to different people.
While most people get the message, it does tend to leave them with more uncertainty than they’d prefer to have. On the other hand, it wouldn’t be right to dumb it down to a ‘six silver steps to success’ formula. There are, however, some relatively stable beacons that guide the way, such as the foundation on Lean, Agile, and Safety Culture. I try to emphasise these beacons, while encouraging people to explore the space in between, deciding not whether it’s DevOps but whether it’s useful.
‘Doing’ DevOps
The dynamic diversity of DevOps guidance has serious implications regarding its application. One cannot ‘implement’ DevOps as a one-off exercise. It’s better to adopt and adapt a set of concepts, principles and practices – and tools – that addresses current concerns. Frequently review whether there are new insights that lead to a revised way of working. Also review whether the concerns have changed, possibly requiring different (application of) concepts, principles and practices. This evolutionary approach is consistent with a more enlightened understanding of organisations and organisational change. While some parts of an organisation may be relatively ordered and therefore predictable, many parts are complex and exhibit emergent behaviour – things just happen without a clear relationship between cause and effect. This requires an approach that is more organic than one based on engineering. Each step will have unexpected effects, positive and negative, that demand reassessment of the next step.
In summary, here are some practical suggestions to consider:
- Develop a foundational understanding of Lean and Agile, and also Safety Culture
- Identify and study various sources of DevOps guidance (books, blogs, conferences, communities, recordings of presentations, training)
- Decide on an issue to work on: is the problem speed, resilience or happiness and who’s business problem is this going to solve?
- Select a small set of concepts, principles and practices that appear to have potential
- Automate what can be automated, but get the basics sorted out before automating
- Experiment and observe the results
- Dampen negative effects, reinforce positive effects
- Reflect and improve.
The most important preconditional (organisational and cultural) changes are to dedicate time to improvement and to encourage experimentation. Continually improve, step by step. And kill DevOps whenever you think that you’ve arrived at your destination!
Mark Smalley
Mark was the Lead Editor of ITIL 4 High Velocity IT. Also known as The IT Paradigmologist, he thinks, writes and speaks extensively about IT 'paradigms' – in other words our changing perspectives on IT. Mark is an IT Management Consultant at Smalley.IT and delivery partner for GamingWorks' DevOps and ITSM business simulations. He is a Global Ambassador at the DevOps Agile Skills Association (DASA) and has contributed to bodies of knowledge such as ASL, BiSL, BRM, COBIT, DevOps, IT4IT, ITIL, and VeriSM. Mark has lectured at various universities and has spoken at hundreds of events in more than thirty countries.
