Kamu: a unified theory of IT management - reconciling DevOps and ITSM/ITIL
I know many in the DevOps community wrote me off as a lost cause, but brothers and sisters I have seen the light after reading this: On Antifragility in Systems and Organizational Architecture from Jez Humble. I pledge myself to spending 2013 [and 2014 and 2015] uniting the DevOps and ITSM communities. Tweet this.
I'm old and stubborn: I'm sure the message has been staring me in the face. Never mind, I make no apologies here. Strong ideas survive and thrive in the face of opposition: they grow stronger fighting the headwind. There are more bad ideas than good ones - we should always test. I arm-wrestled DevOps and DevOps won. [Update: no that doesn't mean I have embraced DevOps as the answer to all the world's ills. it means I have seen that Devops stands up to tough interrogation, it has substance. DevOps and ITSM intersect, they fit one model, they can be reconciled - we need to find the common ground. Not the same thing. More here]
Humble's post is about Nassim Taleb's book AntiFragile (I'm still reading it). Jez says
Taleb discusses the behaviour of complex systems and distinguishes three kinds: those that are fragile, those that are robust or resilient, and those that are antifragile. These types of systems differ in how they respond to volatility: “The fragile wants tranquility, the antifragile grows from disorder, and the robust doesn’t care too much.” (p20) Taleb argues that we want to create systems that are antifragile – that are designed to take advantage of volatility. I think this concept is incredibly powerful when applied to systems and organizational architecture.
Taleb shows why the traditional approach of operations – making change hard, since change is risky – is flawed: “the problem with artificially suppressed volatility is not just that the system tends to become extremely fragile; it is that, at the same time, it exhibits no visible risks… These artificially constrained systems become prone to Black Swans. Such environments eventually experience massive blowups… catching everyone off guard and undoing years of stability or, in almost all cases, ending up far worse than they were in their initial volatile state” (p105).
This a great explanation of how many attempts to manage risk actually result in risk management theatre – giving the appearance of effective risk management while actually making the system (and the organization) extremely fragile to unexpected events. It also explains why continuous delivery works. The most important heuristic we describe in the book is “if it hurts, do it more often, and bring the pain forward.” The effect of following this principle is to exert a constant stress on your delivery and deployment process to reduce its fragility so that releasing becomes a boring, low-risk activity.
That did it for me, thank-you Jez. The light came on. The conflicting worldviews of DevOps and ITSM aren't between fragile and robust, they are between antifragile and robust. Ting! [Update: note that I don't see antifragile as the magic answer to everything either. I'm not saying Devops=antifragile=good, ITSM=robust=bad. I think we'll find both robust and antifragile strategies have their place in the world and the best place is a balance of both because...]
In fact the world isn't that black and white of course. If an organisation's IT is unstable, we can move from a fragile condition to a spectrum of better states, ranging between antifragile and robust.
One of the biggest problems with the whole DevOps-ITSM thing has been the religious positioning of DevOps as the antithesis to ITIL. Which it is, they are the two ends of that spectrum. But some voices have called for the death of ITIL, the overthrow of ITSM, the ascension of only DevOps. This has alienated the "Robust" camp who see DevOps as a barbarian attempt to pull down the defences that keep IT safe and stable.
And of course the IT Skeptic foams at the mouth at any attempt to position a new idea as the magic pixie-dust solution to complex problems. Which may have happened once or twice over Agile and DevOps :)
Both camps tend to compare their own perfect theory to their opponents' imperfect practices, and compare their own poster-child success stories to their opponents' horror stories. The same company names come up over and over ....
Lately more nuanced, reasoned positions are emerging, with rabid anti-ITIL voices like Galtieri and Chambers replaced in my feeds by the more moderate ones of Kim, Humble, Orzen, Willis...
I will devote 2013 to helping reconcile the world-views of ITSM and DevOps. Please join me. Tweet this. There is a unified understanding in there somewhere.
Kamu means "join together in singing the chorus to a song", which I think sums up nicely what we want to achieve: each group has sung its verse, now it is time to sing a common song.
The symbol is a pikorua.
Piko is the new shoot of a fern frond, symbolising life and growth, also a path or journey.
Rua means two: there are two entwined pikopiko. The entwinement symbolises a relationship between two entities. They are entwined without beginning or end, symbolising eternity.
Hence the pikorua is the symbol of a lasting relationship that endures or returns over time.
With one twist in it, the pikorua symbolises eternal love or loyal friendship between two people. With multiple twists as I have used, it means the unity or reconciliation of two groups or cultures.