Law of Requisite Variety

From P2P Foundation
Jump to navigation Jump to search


John Waters:

"Specialization is an inescapable consequence of the Law of Requisite Variety (Ashby's Law). Although "variety" can be defined precisely in theory, in practice it's more useful to think of it as a rather fuzzy "measure of what we can each cope with" (the word "requisite" helping to define the context in which the "coping" must take place).

We each see the world (and whatever aspect of the world we are led to focus upon) through a different window and even where perspectives overlap it can take a long time to negotiate a shared understanding. Consequently it also takes a long time to negotiate a shared agreed on priorities. This is another consequence of Ashby's Law. The systems around us that we're each somehow attempting to "put right" are all structurally coupled and co-evolve faster than we hope to adapt to; we just don't have any capacity to develop sufficiently rich models to allow us to act upon more than a small subsystem, and (where practicable at all) we manage that by constraining the variety - by modelling what we can as precisely as possible and minimizing sensitivity to the remaining uncertainties. This requires a lot of "partitioning", but that's inescapable.

Cyberneticians often refer to the Conant-Ashby Theorem (a.k.a. the Good Regulator Theorem) to describe the challenge. In control engineering the twin concepts of "observability" and "controllability" are probably more familiar terms. However, they are essentially formalizations of similar problems.

Therefore (I would argue) specialization is an absolute necessity if we are to work effectively towards common goals of people care, Earth acre, sustainability, resilience and whatever else we (on this list at least) share. Without specialization and focus we can't adapt sufficiently to change.

We are never going to be able to develop a fully shared strategy, but we can't afford not to agree upon the ultimately shared objectives and fortunately we do seem too. Nevertheless these may need to be specified somewhere (and I'm sure that they have been in many places).

We do need to be able to interact and generate/harvest synergy however, but we can only do that within our own personal and organizational limitation (i.e. where we have "requisite variety").

The best clues to managing variety (and by "best" I mean that no-one has yet shown me anything else that comes close) lie in the books of Stafford Beer (including "Platform for Change", "Designing Freedom", "Brain of the Firm" and "Diagnosing the System") and those of Ross Ashby ("Mechanisms of Intelligence", "Design for a Brain", "An Introduction to Cybernetics") on which Beer built his own models.

For several years I've been using the term "Archipelago Island Model" to describe an approach to managing local economic tools (such as credit unions, CDFIs, time banks, time networks, mutual credit variants, the gift economy) by enabling each "island" (neighbourhood, village, town, region, on-line social network, common bond, and so on ... scaling in various "recursive dimensions") to seed its own local ecosystem from tools for which it recognizes an immediate need (in some cases time banks, in others credit unions, in others LETSystems, and so on ...) then gradually extending the option by adopting new tools and progressively interacting with more communities, progressively reaching further but only as far as necessary to match resources to needs. In that way efficiency and cohesion can be increased progressively while reducing emissions and resource consumption. The "sea" in this metaphor is the unseen infrastructure lying out of sight and able to be brought into use as and when (but only when) needed; a solution in search of a problem is no solution at all, but it does become the solution when circumstances present themselves. (At other times we've spoken of this as "constructing the lifeboats and safety nets in the shadows".)

That however requires the development of metasystemic tools for measurement, modelling, simulation and guidance, and existing software is not designed with this in mind. Any attempt to design a universally applicable software platform would be futile; Ashby's Law would assert itself. The design of open standards and protocols for interoperation and synergy generation is now the norm (or at least becoming so) and Matthew has done us all a great service in driving forward the development of an approach to mutual credit interoperation (as have others in different ways). Far more ambitious, and very much a work in progress, are the CEPTR protocols being developed by Eric Harris-Braun and Arthur Brock. In different ways each is taking us further towards cohesion (at least among economic tools) but are able to do so only because of specialization.

Every approach being advocated and discussed here matters not least because it matters to its own advocates. Each may not always agree with the others' priorities, but that's just Ashby's Law asserting itself again.

Cohesion is essential however, and that's largely about "negotiating" a path that eliminates inconsistencies, and that really only involves eliminating inconsistencies between any particular approach and whatever simple shared guidelines, polices and objectives have been agreed (which anyone familiar with the Viable System Model will recognize as System 5)." (