Requisite Variety

Definition

Requisite variety is a cybernetic law formulated by W. Ross Ashby. In simple terms, if the control system has fewer possible responses than the system it is trying to regulate, control will fail. The environment throws problems at it for which it has no answer. To remain stable, the variety of the regulator, such as an architecture function, must be at least as large as the variety of disturbances it faces.

System Mechanism

Imagine a goalkeeper who can dive only to the left. As soon as the striker shoots right, the system collapses. In IT, whether we are looking at servers or organizational units, systems face constant variety from the environment in the form of customer demands, hardware failures, or legacy defects. To survive, a system has only two mechanical options: increase internal variety through more tools, autonomy, or redundancy, or reduce external variety by saying no to features, limiting access paths, or simplifying demand.

Architecture Example

A central enterprise architecture board of five people tries to dictate technology choices for one hundred distributed microservice teams. Approval happens manually through gates. The architecture function immediately drowns in work. The variety of ideas, edge cases, and operational problems across those teams is vastly larger than the processing capacity of the board. Ashby's Law shows that the control system is mechanically undersized and becomes a bottleneck.

Organizational Example

A bank introduces a one-size-fits-all process for security approvals. Every project, from a tiny CSS fix to a major core banking update, must complete the same twelve-page risk questionnaire. The process does not have enough variety to respond appropriately to the variety of actual changes. Developers begin filling the form with "N/A" for trivial edits, effectively damping the external variety, and the process loses meaning.

Diagnostic Questions

1.Have we answered complex governance problems with a rigid standard process that simply does not match reality?

2.Which teams are on fire because they face highly unpredictable external variety but can respond only with a single tool or habit?

3.Where do we need to reduce external variety drastically so our architects and teams can regain control?

Diagram

Why This Concept Helps in Architecture

The principle of autonomy in agile teams and DevOps is, at its core, a response to Ashby's Law. Instead of escalating all variety upward to a centralized management function with low variety, we equip local cross-functional teams with the tools, budget, and decision space they need to handle disturbances where they occur.

How to Distinguish It from Similar Topics

Unlike *feedback loops*, which describe cyclical responses, Ashby's Law focuses on the bandwidth of possible responses. It explains mathematically why strongly centralized, bureaucratic control systems in complex IT environments are bound to fail: they simply do not have enough variety.

How to Use the Concept in Practice

When tech management complains about losing control, put Ashby's scale on the table. Either top management reduces environmental complexity through strict standardization, or it accepts that control must be decentralized and teams need empowerment. The middle path where "everyone can do everything, but we still control everything centrally" is a systemic illusion.

First Implementation Steps

Use the concept to challenge constant calls for more standardization. Show that reducing internal variety is helpful only as long as the environment itself remains highly predictable.

How You Recognize Impact

When defining a new review process, did we account for the fact that not all projects and services are alike and therefore exceptions require more variety in the process?

Sources

W. Ross Ashby — An Introduction to Cybernetics (Chapman & Hall, 1956)

Stafford Beer — The Brain of the Firm (John Wiley, 1972)

Wikipedia: Variety (Cybernetics) — Ashby's Law)