Tag Archives: antifragility

The absolute chaos in the wake of last Friday’s air-traffic control issues at Swanwick seems to have unwittingly shed a light on the failures of archaic large-scale IT systems and highlighted the benefits of a more ‘evolutionary’ approach, as Matt Ridley’s article in The Times eloquently describes it:

“GDS…is reshaping the way in which the public sector does big IT projects to make sure cost and time overruns are history.”

Ridley celebrates contemporary approaches to development; implementing change, learning from failure, monitoring and changing continuously to optimise outputs with the user at the focus. In today’s society it is essential for governments to successfully operate large-scale services that are simple to use and which work effectively – as we can see, breakage, at this scale, is disastrous.

Operating continual monitoring, analysis, testing and development on government IT systems means that services are more accessible and less prone to breaking. Improved communication and co-working means that different skillsets are working together; pooling resources to solve problems quickly and to innovate changes as soon as they are required.

This feedback led approach will allow large-scale government systems to develop continuously, fulfilling the needs of the user as they arise and solving problems before they can impact extensively. We are encouraging an environment of communication and integration over silo-led, ‘creationist’ approaches, which have continuously failed in the past.

It is an attitude and a system that is transferrable across a variety of processes; from IT systems development to office management and work ethic. Essentially, DevOps makes the world a happier place…

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).

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
(via automation)

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!