The physics definition of entropy is straightforward enough: it’s a corollary of the second law of thermodynamics, the way in which energy flows from a hotter region to a colder one, and so on. Entropy goes up as the range of possibility and action goes down. And it’s deemed to be irreversible – ‘the arrow of time’ – with everything fading away over (long) periods of time to the ‘nothingness’ that is the heat-death of the universe. Other common metaphors are the silting-up of a river, or a mechanical-clock winding down until the final stop: not hard to see analogues of those in business-processes and the like…
The catch is that it’s not as straightforward as it looks. To quote the Wikipedia entry:
Outside the range of classical thermodynamics, the definition of the entropy of a small local region is no simple matter. … It is often assumed without proof that the instantaneous global entropy of a non-equilibrium system can be found by adding up the simultaneous instantaneous entropies of its constituent small local regions. For a given physical process, the selection of suitable independent local non-equilibrium macroscopic state variables for the construction of a thermodynamic description calls for qualitative physical understanding, rather than being a simply mathematical problem concerned with a uniquely determined thermodynamic description.
In other words, it’s starting to look much like enterprise-architecture, where the qualitative factors (including human-factors) mean that we can’t do all of the work with simple calculations: the whole of the system can be greater or less than the sum of its parts. Hmm…
Anyway, some good points there, but I couldn’t see how to apply it in business: too technical, too much of a metaphor, and potentially too confusing. Useful though it still looked, I shelved the concept of entropy from my enterprise-architecture work for a while.
Yet a few weeks back I was watching a BBC documentary on entropy (by physicist Jim Al-Khalili, I think?) Quoting standard physics, he says that entropy always moves (or increases) from order to chaos: and to illustrate this, he pushes a ceramic vase off the table, and lets it smash on the floor. Order, he says, is like the intact vase: we can do useful work with it. Chaos is the broken vase: we can’t use it to do the useful work of carrying water any more.
From order, to chaos: an irreversible decline. And yeah, we see that often enough in business too.
But hang on: just wait a minute, willya? ‘Order to chaos’ is the wrong way round - a special-case of both the terms ‘order’ and ‘chaos’ that doesn’t match up well with anything elsewhere in physics. For example, elsewhere in thermodynamics, a ‘chaotic’ state for matter is a plasma – the highest energy-level, not the lowest. And the lowest energy-difference, the highest entropy-level, is also the most ordered: a stasis, where nothing moves, nothing changes, nothing happens. And yep, we see that all too often in business, don’t we…?
So although the usual description of entropy is a move from order to chaos, in terms of energy the clockwork winds downward from chaos to order. Available-energy will fall, and entropy will rise, as we move downward from the chaotic mountain-stream to the silted-up river-delta; entropy rises as we move from chaos to order.
Or, in a bit more detail:
- (ultimate start-point is primordiality – ‘the moment before the Big Bang’)
- from chaos (maximum potential, maximum possibility)
- to useful order (maximum exploitable energy in constrained possibility)
- to non-useful order (low exploitable energy and/or misaligned possibility)
- to decrepitude [self-order] (no apparent energy and/or alignment of possibility)
- to stasis (no energy)
The reason we usually won’t see any reference to chaos in this more correct sense here is because true chaotic contexts are often not directly usable as such: for example, there’s often too much energy or possibility to be exploitable in practice. Instead, it’s simpler for most views to start with ‘useful order’, and end at the ‘decrepitude’ stage because it looks (and, at first glance, often is) an unusable mess.
Compare a factory working at full blast with an abandoned brownfield industrial site: the first is ‘useful order’, the second is a seemingly-unusable mess. The latter is self-ordered in a way that we can’t use: hence, in colloquial terms, ‘chaos’ – yet a misuse of the term ‘chaos’ that has some seriously misleading impacts here. Oh well.
Okay, fine, but so what? Does that pretty piece of petty pedantry have any use – any practical use – in business and the like?
Quite a lot, is the real answer: in fact it’s actually right at the core of all change in business. Hence why it kinda matters which way round we put it…
First, the slowdown implied by entropy is a natural and inevitable fact of physics. There is no such thing as an order that can be maintained indefinitely. Over time, even in business, useful order will always decay into non-useful order. We can perhaps delay that decay, but we can’t prevent it – and fighting to prevent it from happening will only make things worse. This is a really important fact of nature that needs to be understood right at the root of every enterprise-architecture.
Entropy applies to every system in business, including business-processes, system-configurations, work-rosters, business-models, facilities, resources. Everything decays and/or goes out of date. Entropy applies just as much to people in business: memory fades, capability fades, people leave, people die. And there’s nothing we can do about that fact: it’s inevitable, and irreversible.
In short, a pretty gloomy picture.
Yet that’s not actually what we experience in practice, is it? Sure, entropy is always there in the background, and we can never really escape it. But there’s also something else going on that can give an odd kind of ‘get-out clause’ that, even if we can’t ever truly escape entropy, shows us that can sometimes bend it and twist it in some very useful ways - if we’re willing to accept how it actually works. The catch is that the way that it works is almost the exact opposite of what most current business-paradigms either want or expect.
Part of this is entropy is not evenly distributed. Different isotopes and elements have different rates of radioactive decay, different alloys rust at different rates, and so on. The same applies to differences between business-processes, business-facilities or whatever. There’s also varying ’variety-weather‘, where the factors affecting entropy and the like change over time and between different places. These are differences that we can leverage: for example, in some cases we can use something with a slower rate of decay to refresh something that has a faster decay. The ISO-9000 quality-system standard is built around exactly that principle: over time, work-instructions need to change faster than procedures, which change faster than policies, which change faster than enterprise vision – so in that sense, enterprise-vision can act as a stable anchor for an organisation’s quality-system even under conditions of turbulent change.
Next, a corollary of the inevitability of entropy is that any apparently self-sustaining system is actually receiving energy from somewhere ‘outside’ of the nominal system-boundary. A simple real-world example is the rainfall-cycle: water evaporates from the sea or land-surface to form clouds, from which rain falls, and returns to the sea via stream and rivers – but it relies on energy from the sun to power the evaporation that drives the seemingly counter-entropy ‘upward’ part of the cycle. In business, the refresh of a business-process comes in part from ‘investment’ from outside of the business-process itself.
Another corollary is that potentially-useful order is the outcome of a decay from chaos - and once we start that decay going, entropy demands that it must inevitably continue towards non-useful order, and thence to decrepitude. We can ‘tame’ a mountain stream to give us useful hydroelectric energy, but the fact of extracting the energy leads inevitably to a faster silting-up of the stream.
A side-corollary is that intervening in a system to impose ‘useful order’ on that system inevitably changes the dynamics of the system towards a faster rate of decay. This particularly applies when the context itself is undergoing change: as architect Bert van Lamoen put it, “the most efficient system dies first”. In terms of entropy, the more we try to ‘control’ something, the faster it is likely to decay. Unfortunately, many standard business-paradigms teach managers to ‘take control’ of systems – yet fail to warn them of the inevitable consequences of doing so.
Decay is inevitable. In mechanical systems and any other systems that follow physical laws in a linear fashion, the decay is largely linear: once we ‘tame’ something to create useful order, the decay is already on its way. Yet chaotic-systems, complex-systems and other non-linear systems create ‘loopholes’ that can, in effect, locally reverse the flow of entropy. At a larger scale, non-linear systems still follow the rules – there’s still the same irreversible trend towards decay and stasis – yet there are loops and peaks and troughs where, for brief moments, the effective flow is in the opposite direction.
In effect, living systems leverage those loopholes to counter entropy within their own local context. By definition, it’s a risky tactic: if the living system catches the wrong edge of the curve, it will increase the rate of entropy rather than reverse it. Yet the payoff can be huge: even something approaching immortality, in some cases, at least at the species-level.
Within this, each species learns and remembers how to leverage opportunities for reverse-entropy. How exactly this learning and remembering takes place varies enormously from species to species and context to context – everywhere there’s some different mix of ‘learning by surviving’ (Darwinian) versus ‘acquired learning’ (Lamarckian) – but the actual mechanisms are usually less important than that the learning and adaptation does take place. There’s always some form of purpose to act as a guide for the trade-off between risk and opportunity, even if only as an ‘instinctual’ drive for individual and species survival.
All of this applies to business too: for example, in his book Antifragile, Nassim Taleb describes the implicit ‘species-level’ learning-process in the lifecycles of restaurants in a large city. Learning-by-dying is not so good for an individual restaurant, though: so at that level – the more typical concern for business-strategists, business-architects, enterprise-architects and the like – we need a more explicit learning-process, and usually a more explicit purpose as a counter-entropy guide, too.
An essential corollary from the above is that the more tightly the system is controlled, the fewer opportunities are available for reverse-entropy. Given ‘total control’, often the only option for the system to refresh itself is in a phase-change that’s often experienced as ‘catastrophic collapse’ or ‘revolution’. (It’s notable here that ‘revolution’ literally means ‘going round in circles’, but in essence it’s a cycle of catastrophic-collapse, reverse-entropy refresh and then a reimposed ‘order’, trending once more towards decay and decrepitude. We’ll see that a lot in business too…)
Reverse-entropy refresh is enabled by return towards ‘chaos’; ‘micro-refresh’ can occur by leveraging small moments of inherent-uncertainty. Another corollary here is that since opportunities for micro-refresh can occur all of the time, but can only be leveraged if access to those opportunities is available, rigid imposition of ‘order’ inherently accelerates the rate of decay.
A lesser form of refresh can be created by going part-way towards ‘chaos’, leveraging different rates of decay between the components of a system versus the system as a whole: loose-coupling of elements enables greater opportunity for micro-refresh of the overall system. This is the fundamental principle behind service-oriented design: the system-components (services) are more stable than the system-as-a-whole (delivery of ‘business process’), hence we can refresh the system by reconfiguring the relationships between services, without changing the services themselves. This is, in effect, a return from non-useful order to useful order, where the only chaos element is in the process of reconfiguring of service-relationships, and perhaps also of specific services, rather than redesign of the entire system.
There’s probably a lot more that we can do with this, but I’ll stop here for now. Once again, the key idea here is that the decay of entropy flows from chaos to order – not from order to chaos – and that the imposition of ‘order’ is itself the key driver towards decay in the usefulness of systems.
Something to think about, perhaps?
Addendum: when I put out a note on Twitter that I was going to write this post, it kinda triggered a really nice back-and-forth between Eric Stephens (@EricStephens) and Stuart Boardman (@ArtBourbon), which seems worth including here:
- EricStephens: “entropy” is a favorite word of mine when describing dysfunctional architectures
- ArtBourbon: entropy is an unavoidable aspect of our environment. The trick is not to make a dysfunctional response to it. No?
- EricStephens: agree not to have dysfx response. But can “architectural entropy” be minimized with a disciplined #entarch approach?
- ArtBourbon: good question. Maybe we need to redefine discipline in this context. Ashby seems relevant.
- EricStephens: Sorry, not following “ashby”
- EricStephens: IMHO, entropy = neglect, lack of maintenance, forethought. // I admit some misalignment may be part of normal “wear and tear” or environmental/competitive forces
- ArtBourbon: [re 'ashby'] the law of requisite variety.
- EricStephens: just reading up on requisite variety last night. thx.
- ArtBourbon: Re “wear and tear” yes but dysfunctional responses to entropy are indeed a big problem. So, yes, agreed. // I tend to stick to the concept of entropy in physics – the degree of uncertainty/instability.
- EricStephens: despite my paltry knowledge of physics, that is my view of entropy as well.
- ArtBourbon: So EA can’t manage entropy by creating artificial certainties, rather by creating/enabling ability to change – fast
- EricStephens: exactly: after the drawing and hand waving is done, EAs need to formulate and lead a set of concrete actions…
Another addendum: another colleague pointed me to Frank Buytendijk’s post ‘Aristotle and Enterprise Architecture‘, which also mentions entropy in business, though more from the classic view of ‘from order to chaos’. Well worth a read, anyway.
That’s it for now: over to you for comment, as usual?