The Viable System Model (VSM) is a model of the organisational structure of any autonomous system capable of producing itself.
A viable system is any system organised in such a way as to meet the demands of surviving in a changing environment. One of the prime features of systems that survive is that they are adaptable - or viable. The VSM expresses a model for a viable system, which is an abstracted cybernetic (regulation theory) description that is claimed to be applicable to any organisation or system that is or should be a viable system and capable of autonomy.
The model was developed by operations research theorist and cybernetician Stafford Beer and described in his book Brain of the Firm. Together with Beer's earlier works on cybernetics applied to management, this book effectively founded management cybernetics.
The first thing to note about the cybernetic theory of organizations encapsulated in the VSM, is that viable systems are recursive; viable systems contain viable systems that can be modeled using an identical cybernetic description, as the higher (and lower) level systems in the containment hierarchy (Beer expresses this property of viable systems as cybernetic isomorphism). A development of this model has originated the theoretical proposal called viable systems approach.
Software systems are systems that ultimately should be capable to produce themselves - they need to be viable and to be capable of surviving in changing conditions (and as every software professional will admit, software corrosion due to “changing conditions” is a very common phenomenon).
If software systems are not viable, their lifecycle is constrained by the increasing complexity of the system, as a result of uncoordinated extensions to and manipulations of the system itself.
Classical software design principles are not enough for designing high-quality viable software systems.
The conventional software design principles still apply though and are worth to be remembered when designing any kind of software system, whether it should be viable or not:
Loosely-Couple
Separate Concerns
Implement Circuit Breakers
Think Service - Not Code
Simplify. Simplify. Simplify.
Design for Re-use
Provide Security by Design
Although these principles are still valuable and applicable, they do not provide actual system-level, holistic guidance to ensure that software systems are designed in a viable manner on the level of the “master system” (the system itself rather than the structure of its components) and its subsystems. Here, VSM offers the construct of 5+1 subsystems that need to be in place to realize a truly viable system.
Let's have a look at the cybernetic description of a system encapsulated as a VSM. Please note the common analogies with contemporary software design models, like microservices architecture and Service-Oriented Architecture (SOA), where principles related to separating implementation from the model, and other principles related to separation of concerns form a substantial part of the foundations of these kinds of architecture.
The model is derived from the architecture of the brain and nervous system. Systems 3-2-1 are identified with the ancient brain or autonomic nervous system. System 4 embodies cognition and conversation. System 5, the higher brain functions, include introspection and decision making.
A viable system is composed of five interacting subsystems which may be mapped onto aspects of a system's structure (or, in software terminology, the “architecture” of an system).
In broad terms, Systems 1–3 are concerned with the “here and now” of the system's operations, System 4 is concerned with the “there and then” – strategical responses to the effects of external, environmental and future demands on the systems. System 5 is concerned with balancing the “here and now” and the “there and then” to give policy directives which maintain the systems as a viable entity.
System 1 in a viable system contains several primary activities. Each System 1 primary activity is itself a viable system due to the recursive nature of systems as described earlier. These are concerned with performing a function that implements at least part of the key capabilities of the system.
System 2 represents the information channels and bodies that allow the primary activities in System 1 to communicate between each other and which allow System 3 to monitor and co-ordinate the activities within System 1. System 2 represents the scheduling function of shared resources to be used by System 1.
System 3 represents the structures and controls that are put into place to establish the rules, resources, rights and responsibilities of System 1 and to provide an interface with Systems 4 and 5. System 3 represents the big picture view of the processes inside of System 1.
System 4 is made up of bodies that are responsible for looking outwards to the environment to monitor how the system needs to adapt to remain viable.
System 5 is responsible for policy decisions within the system as a whole to balance demands from different parts of the system and steer the system as a whole.
In addition to the subsystems that make up the “inner part” of the VSM, the environment is also an explicit element of the model - the surroundings and context of a viable system, influencing the system from the outside. The presence of the environment element in the model is necessary as the space wherein the system functions and to which the system delivers output. Without it there is no way in the model to contextualize or ground the internal interactions of the organization.
Algedonic alerts (from the Greek αλγος, pain and ηδος, pleasure) are alarms and rewards that escalate through the levels of recursion, when actual performance fails or exceeds capability, typically after a timeout.
As a visual, VSM could look like this:
As you can see, the VSM is a complex, cybernetic construct and probably needs to be simplified in order to become useful as a meta model for software systems design, with the goal to realize viable systems.
In the next part of this series we will try to simplify the VSM and use it as a meta model for viable software design.