Antifragile or Reactive?
- April 11, 2013
- 12 Comments
Keith Swenson is probably the foremost proponent of ACM. He has a new series of blog posts and talks that touch on Nicholas Taleb’s book “Antifragile,” a new wrinkle on his theme of knowledge work and ACM. His presentation at bpmNEXT leaned on this concept as well. He gave a series of excellent examples and analogies from nature and commerce to support the concept of a system that gets more robust when it is stressed, rather than more fragile. Not just reacting to external stress, but actually becoming less fragile. Forests are more robust if forest fires are allowed to burn, rather than intervening to stamp them out (the fires clearing the underbrush for example).
Sandy has a good writeup of the talk. In particular, the demo, in which he showed a research prototype of how one would:
[…] create a case, referred to as a project, that is completely empty. The case owner can add documents, including sending an email to external participants with a URL for uploading documents without having an explicit login, and write notes. A project can be used as a template, and its characteristics merged into an existing project. Goals (tasks) can be created and assigned, and turned into subprojects for more complex activities. Other users may have the project in their watch list, and have goals assigned to them. In order to link projects together, a project can generate a streaming link that is linked into another project; the projects can then be set up to synchronize goals and documents between the linked projects. The system is intended for non-technical knowledge workers to create cases on the fly; there is no “design time” environment or more technical requirements.
So far so good. But I was waiting for the punch line- the part where ACM (or the prototype) actually achieves or demonstrates its anti-fragile characteristics. Creating a case on the fly, in reaction to external stress.
- Fragile: small perturbations tend to magnify and destabilize the system. Picture a coin balanced on its edge. The slightest touch is likely to knock it over – or the slightest breath of wind.
- Robust: small, medium, possibly even large perturbations fail to destabilize the system. Picture how hard it is to tip over a coin laying on its face. However, an extreme force – say, a tornado – could overcome this robust nature.
- Anti-fragile: in its normal state, robust but not remarkably so. However, with greater stress the system becomes more stable, rather than more fragile. Apparently a pyramid/cone of the right dimensions and angle has this property with respect to wind forces knocking it over. The higher the wind force, the greater force holding that shape to the ground, rather than lifting it up or pushing it around.
The examples and analogies are compelling narrative and motivation to the topic, and Keith is a great speaker. But I was looking for the closing argument to show me that the system wasn’t just responding to stimulus, that it was getting more robust as a result of having previously responded to stimulus.
So I asked the question after his talk – but the answer didn’t address how the system had become more robust in the process (e.g. anti-fragile). I was convinced that given an external request or stress, a user could put a case together to respond to it. But I wasn’t convinced that a second stress or external request would be handled better than the first. Or that the 10,000th request would be handled better than the 2nd.
(As an example, in our mobile presentation we showed an app that lets the user define pre-requisites, tasks, documents, etc. We didn’t present this in an ACM context, but all the capabilities are there. But I wouldn’t describe it as anti-fragile. You could describe it as robust or not-fragile, but not “anti-fragile”.)
Anti-fragile remains an excellent goal for organizations to strive for. But I don’t think we have the silver bullet yet. Being anti-fragile as an organization means repeatedly taking a look at how you run your business operations and looking for ways to improve. That might mean changes to standard process, it might mean rolling out new software, it might mean new training or skills are required. It might also mean empowering users to react to unexpected situations by providing better tooling. But it is an organizational imperative to be anti-fragile, rather than an IT system imperative. The software won’t do it for you (yet!)…