Whilst researching how to reconcile ITIL with DevOps I came across this interesting blog post from the IT Skeptic entitled "Kamu: a unified theory of IT management – reconciling DevOps and ITSM/ITIL". This lead me to Jez Humble's post on "On Antifragility in Systems and Organizational Architecture" referencing Nicholas Taleb's book "Antifragile" and generally lead to a lot of intense cogitation on fragility versus robustness versus antifragility.
The IT Skeptic (Rob England) expands on his thoughts in this presentation which introduces this diagram below
However I struggled to mentally conceptualise the differences between the 3 points of the triangle until I came up with the following analogies (and please bear with me while I explain my thoughts behind them!):
- Fragile = Humpty Dumpty
- Robust = A medieval castle
- Anti-fragile = The Borg collective
Fragile
"Fragile" systems are those (often legacy) systems that you really, really don't want to touch if you don't have to! Like Humpty Dumpty, one good push and all the King's horses and all the King's Men and a 24 hour round-the-clock marathon from the Ops team won't get that pile of crap system up and running again. It's a snowflake – not documented properly, there are dependencies you can't trace, the hardware's out of warranty, the platform is 3 versions behind and can't be upgraded because of some customisation that no-one understands, the code is spaghetti and the guy that wrote it retired last year. We all know what fragile looks like!
Robust
"Robust" systems are those that have been through the ITIL life-cycle and for most of us they are probably our pride & joy. Monitored, instrumented and well documented with their own run book and wiki pages they are highly available with redundancy at every level we "know" they can withstand the slings and arrows of outrageous fortune.
Just like a medieval castle they are impregnable. The very essence of robust!
And then comes along the "black swan" event… something we haven't anticipated, a failure mode we can't have foreseen, a cascade of errors that we did not plan for. Just as our predecessor, the medieval castle owner, didn't foresee the invention of gunpowder and cannons that reduce his impregnable castle to rubble. Just like the builders of the Maginot Line didn't anticipate the invention of Blitzkreig and mechanised warfare nor the defenders of the dams of the Ruhr Valley – a bomb that bounces.
This is the key message of Taleb's book and Jez's post – that the "robustness" mindset often leads to a resistance to change. As Jez explains in the context of organisations:
"The problem with robust organizations is that they resist change. They aren't quickly killed by changes to their environment, but they don't adapt to them either – they die slowly." – Jez Humble
A castle is robust… but it's fixed, immobile, and its very robustness to "normal" assaults reduces the incentives to change and adapt.
Anti-fragile
Contrast these to the "anti-fragile" system (or organisation) typified by the Borg Collective. The Borg seek out new life and new civilisations to assimilate into the Collective in order to improve.
With each change and adaptation the system (the Collective) becomes more resilient – it improves as the result of the external stress (the essence of an adaptive, evolutionary system).
Anti-fragile organisations seek out and embrace change – they are inherently "outward-focused" and seek to be continually learning, adapting and assimilating (not hiding behind the walls of their castle, content in their robust impregnability).
Likewise, DevOps seeks to be "anti-fragile" by embracing change (and disorder a la Chaos Monkey) whilst incorporating feedback mechanisms (the "3rd Way" of DevOps) to ensure that learning is correctly assimilated.
The DevOps mindset encourages continual learning; through experimentation and collaboration in order to seek to improve the current system as opposed to a codified mindset of a fixed position of "one way of doing things" implied in a formulaic, rigid ITIL worldview.
In this way DevOps encourages what Schumpeter called "creative destruction" – clearing out the old to make way for the new (and hopefully improved) system.
Summary
I've summarised these 3 points of the triangle into the following table;
|
| Fragile | Robust | Anti-Fragile |
| Icon | Humpty Dumpty | Medieval Castle | The Borg |
| Methodology | "Spaghetti" | ITIL | DevOps |
| Attitude to change | Fear Change | Resist Change | Embrace Change |
| Response to change | Break | Repel | Adapt |
| Rate of Change | Ideally never! | Slow | Rapid |
| Change initiated by | Needs CEO approval | Change Management Board | User-initiated |
| Focuses on | Survival | Process* | Business Value |
* Yes, I know that ITIL v3 in particular *IS* in theory very focused on business value and benefits realisation BUT in my experience the end result of an "ITIL implementation" is often the triumph process over outcome.
If anyone has any ideas for more rows to add to the table please let us know on the comments!
-TheOpsMgr
No comments:
Post a Comment