=Paper=
{{Paper
|id=Vol-1999/paper3
|storemode=property
|title=Viable Systems Model: More Support Tools Needed
|pdfUrl=https://ceur-ws.org/Vol-1999/paper3.pdf
|volume=Vol-1999
|authors=Marite Kirikova
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/Kirikova17
}}
==Viable Systems Model: More Support Tools Needed==
https://ceur-ws.org/Vol-1999/paper3.pdf
Viable Systems Model: More Support Tools Needed
Marite Kirikova
Department of Artificial Intelligence and Systems Engineering, Riga Technical University,
Riga, Latvia
Marite.Kirikova@rtu.lv
Abstract. Stafford Beer proposed a Viable Systems Model, which was
supposed to support successful management of enterprises. Since then
numerous research works have referred to that model in management,
information systems, and computer sciences. However, in the area of enterprise
modeling there is a shortage of tools that would give an opportunity to create
detailed enterprise models that would adhere to the VSM and would also be
applicable for advanced model visualization and analysis. If available,
appropriate modeling tools could help to utilize such features of VSM as
fractality, distributed control, and variety handling mechanisms; and provide
the possibility of overall adherence to those principles of cybernetics that
become increasingly important in modeling enterprises in a socio-cyber-
physical context.
Keywords: VSM, fractal systems, service systems, variety management,
distributed control
1 Introduction
The Viable Systems Model (VSM) was introduced by Stafford Beer [1]. The
model was intended for management of autonomous enterprises in changing
circumstances. Many explanations in the original model descriptions refer to human
nature and organizational systems of enterprises. The author of the model also points
to challenges of the application of the model, e.g. difficulty in identifying the
granularity of the purpose to be achieved by the autonomous system [2].
The VSM is rooted in ideas of cybernetics and comprises five mutually related
systems [3]: System 1 is responsible for the production and delivery of enterprise
goods or services to the pertinent environment; System 2 is intended to determine the
set of organizational units which comprise System 1; the task of System 3 is to
manage the set of operational units comprising System 1; System 4 is mainly
responsible for decisions regarding the future role of the enterprise in the
environment; System 5’s function is to balance the present and future of the
enterprise; it constitutes the highest level of authority in the enterprise. One of the
essential features of VSM is its suitability for supporting self organization and
variability handling, e.g. System 5 can absorb all variability which Systems 3 and 4
cannot absorb between themselves.
Marite Kirikova
The VSM has been applied and supported methodologically and technologically
by several followers of Beer's ideas in organizational sciences. The most
comprehensive reports on these works are available in [3] and [4]. The model has also
been applied to other types of systems. For instance, the VSM has been used in
business process management [5, 6], information systems development [7, 8], and in
service systems management [9, 10].
Despite many attempts to use the VSM there is still a shortage of tools dedicated
to VSM based modeling. Therefore the purpose of this paper is to introduce a
discussion on requirements for modeling tools that can help to utilize the strengths of
the VSM in the contemporary enterprise modeling environments.
The paper is structured as follows. Section 2 considers benefits of the use of the
VSM and also challenges that are related to VSM based modeling. Section 3
discusses VSM based modeling issues in a particular VSM application area. Namely,
service provisioning systems are considered using the concept of Viable Enterprise
Bus [10]. Section 4 concludes the paper with a short discussion and points to further
research regarding VSM based modeling.
2 VSM Based Models: Benefits and Challenges
While enterprise modeling does not necessarily include detailed models of
information systems, in this paper we do not neglect them. Therefore, firstly we will
examine whether there can really be benefits resulting from the use of the VSM in
information systems oriented enterprise modeling (Section 2.1). Afterwards we will
discuss the challenges found in VSM based modeling (Section 2.3).
2.1 Benefits of Using VSM
Practically all sources that refer to the VSM, point to the following benefits of the
model [3, 4]:
Conformance to principles of cybernetics
Fractality
Variability management
Integration of centralization and decentralization (distribution) of control
These benefits apply to any systems of the enterprise, be they social, information
or physical systems.
With respect to information systems in particular, a comprehensive overview and
analysis of applications of VSM are provided in [11]. The authors derived the
following benefits achieved by using the VSM:
Viability (ability to assess viability)
Transparency (helps users who deal with local parts of the system grasp the
system in its broader context)
Modeling organizational structure, environment, and communication flows
between subsystems, and also between subsystems and the environment for
description, diagnosis, and design purposes
Viable Systems Model: More Support Tools Needed
Modularization that helps to decompose complex systems and perform different
types of analysis and further decompositions
Combinability (with different systems approaches, with organizational
knowledge, for closing the gap between theoretical and practical aspects of
agility)
Context independency (the model can be applied to different types of systems)
Considering the above mentioned benefits, it can be concluded that the use of the
VSM in enterprise modeling merits the support of enterprise modeling tools. In the
next section we will discuss VSM related modeling problems that may have hindered
its wider use in enterprise modeling.
2.2 Challenges of VSM based modeling
One of the main challenges is the fact that the model itself is not very simple. The
VSM prescribes 5 (sub) systems which are connected with a number of information
channels (also the information channels that connect subsystems to the environment
should be considered; see the visualization of VSM in Fig. 1).
Fig. 1. Viable Systems Model (available at https://commons.wikimedia.org/wiki/File:Vsm.gif)
A two dimensional view of the model does not allow all relationships clearly to be
seen. Neither does it allow fractal decomposition of the model to be seen. When
considering decomposition, there is no possibility of distinguishing between different
types of systems (e.g., software versus social systems). While one of the benefits of
the VSM is its independence of context, in the modeling of enterprise architecture it is
important to distinguish between different layers of the enterprise [12].
For better visualization of the model, its three dimensional representation with the
ability to navigate the fractal levels and relationships has been developed [4] and is
Marite Kirikova
available at http://www.vsmod.org/. However, this model can be populated with just
the text and it is tailored to organizational systems only. Thus it is hard to use it for
modeling business processes or information systems service architectures. However,
the implementation of multidimensional visualization of the model helps us to see that
this type of representation assists in better populating and navigating the VSM.
Thus, for meeting the first challenge "the model is relatively complex", the
following features of the tool could be helpful:
Multidimensional visual representation of the model (with navigation ability)
Possibility of populating VSM elements with diagrams
In the previous section, the possibility of combining VSM with other models has
been mentioned as one of the benefits. However there is no research to ascertain
which combinations are useful. Different authors use some of the possible
combinations [11], but specifications that could be used in tool development are far
from being well defined. It appears natural to combine VSM and ArchiMate [12]
language, or VSM and BPMN [13], however, currently suggested combinations do
not go beyond the level of hypothesis. Nevertheless we can derive the requirement,
that:
The modeling tools for the use of the VSM must offer an opportunity to directly
relate the VSM to models developed by other modeling tools, such as enterprise
architecture modeling tools, business process modeling tools, and possibly others.
The above-discussed issues also imply that the modeling tool has to support
different types of decomposition. We can distinguish between fractal decomposition,
where the elements of the representation do not change, but only the scale of
representation changes. A well known example of fractal decomposition is a multi-
level data flow diagram. In fractal decomposition of VSM, the VSM is decomposed
into VSMs at different levels of scale. On the other hand the decomposition into other
types of models should also be possible. In addition it might be necessary to switch
between alternative decompositions. Thus the following requirements emerge:
Support for VSM fractal decomposition
Support for nesting of alternative models
Maintaining several decompositions of one and the same node
Regarding the relationships to the environment (represented by clouds in Fig. 1),
these relationships actually can be business intelligence systems that perform
monitoring of the environment and analysis of monitoring results. Thus the
relationships (channels) in the original model can turn into the nodes in the case of
the use of business intelligence systems. Therefore one more requirement has to be
considered, namely:
The relationships in the model must have a dual nature: the nature of the link and
the nature of the node.
The above discussed challenges show that most probably the use of the VSM on a
regular basis in enterprise modeling could be possible only if dedicated modeling
tools were available. To develop these, further research is necessary to identify
Viable Systems Model: More Support Tools Needed
detailed requirements for VSM based modeling tools. To achieve this, both: (1)
theoretical analysis of the VSM and (2) analysis of its practical applications should be
performed. In the next section we will discuss the concept of Viable Enterprise Bus,
which is the application of the VSM to software service provisioning, in order to
illustrate some of the practical modeling issues that have to be considered in the
context of VSM based modeling.
3 Modeling Issues Regarding Viable Service Bus
In the previous section, while analyzing the challenges of VSM based modeling, a
number of requirements for the tools supporting this type of modeling were derived.
In this section we will see how these requirements apply to modeling issues with
respect to Viable Service Bus [10] that is suggested as a logical concept of service
provisioning systems. It should be noted that Viable Service Bus should not be
considered as an obsolete service management concept "enterprise service bus" to be
compared with microservice systems [14], as it does not contradict principles behind
the microservice architecture.
The author of Viable Service Bus concept [10] Jafarov, suggests accommodating,
within the model, 15 design principles based on cybernetic concepts of Beer’s VSM
[1] - see also Fig. 1. Table 1 illustrates how each principle relates to the tool
requirements discussed in the previous section. If the requirement is mandatory to
satisfy the principle, "x" is used, and if the requirement could help to satisfy the
principle, "v" is used; "!" is used if the implementation of the requirement may cause
tool related challenges with respect to the principle. In the remainder of this section
the citations of each principle from [10] will be provided. The relationships between
the principles and the requirements are derived from explanations of principles in [10]
which include detailed statements of the principles, service oriented architecture
rationale, and enterprise service bus implications.
Variety principle basically refers to service interoperability. It states that "To
obtain control, control must have the variety that is as great as the variety of the
situations to be controlled".
Viability principle refers to standardized integration of services for the sake of
interoperability. "Remaining viable is the ultimate goal of the system".
Value creation principle mainly refers to service reusability and standardization.
"Resources of the system are directed and controlled to achieve viability through
effective and efficient value creation".
Value preservation points to the interoperability between existing or newly
uploaded or alternative services. "The ongoing survival of the system is dependent on
risks management that is dedicated to preserving the proposed value".
Black box imposes service contracts that contain only essential information about
the services. "The system must be supplied with interfaces that describe what goes
into it, what goes out of it, and what the relations between inputs and outputs are;
encapsulating the logic of any functions behind it".
Channels principle refers to the messaging system. "The system must provide
transparency in capacity management and capability in data transduction, in a secure
and reliable manner, in order to achieve viable balance in information channels".
Marite Kirikova
Service recursion principle implies service abstraction, reusability, statelessness,
discoverability, and composability:" The design of the system, that is derived from the
design principles, is invariant, in order to provide cohesion in the system, so that the
synergies across the operational units are exploited at all levels of recursion so as to
ensure that the system as a whole delivers more than the sum of its parts".
Table 1. Tool requirements for supporting Viable Service Bus design principles
Service performance
Service intelligence
Service autonomy*
Value preservation
Service recursion*
Service deviation
Service bargain
Value creation
Service policy
Service audit
Service alert
Channels*
Black box
Viability
Variety
Requirement
Multidimensional x x x x x x x x x x x x x x x
visual representation of
the model
x x v v x v v v x v x
Possibility to populate
VSM elements with
diagrams
Relation to other x x x v v v x v v v v v
modeling tools
x x x x x v x x x x x x x x v
Support for VSM
fractal decomposition
x x v v v v v v v v v v
Support for nesting of
alternative models
x x v v ! v v v v v v
Maintaining several
decompositions of one
and the same node
The relationships in the v x x x x x x x x v x x
model shall have dual
nature: the nature of the
link and the nature of
the node
Service autonomy principle refers to high level of control of services over their
environment. "The system and its embedded subsystems must be designed as self-
organizing entities, with a maximum degree of autonomy for actions that would only
be constrained by the maintenance of cohesion towards the goal of implementing the
system".
Service deviation principle refers to good coordination of operations in order to
avoid deviations in subsystems. "The system must coordinate the operations to avoid
possible deviations in its subsystems, by adjusting them to accepted levels of service
provision and by reporting any possible deviations that would assist future
improvement and evaluation".
Viable Systems Model: More Support Tools Needed
Service bargain principle requires regulation of resource consumption. "The
system must regulate its resource consumption, collect the feedback on the services it
provides; as well as compare the services and converge them as necessary".
Service performance principle implies monitoring of service performance. "The
system must manage the services it provides and monitor their performance against
agreed objectives".
Service audit principle implies high variety and intra-operational checks on the
services. "The system must undertake sporadic, wide in variety, intra-operational
checks on the services it provides; to prevent and remove any impediments which
may arise from incidents and problems during operation".
Intelligence principle implies that services are aware of their environment. "The
system must have the awareness of the environment that surrounds it; by monitoring it
for possible opportunities, which could contribute to overall viability of the system".
Service policy principle implies compliance with legislative and regulatory
obligations. "The system as a whole must comply with legislative and regulatory
obligations, and have a clear policy that would define consistent identity of the
system, its goal and its purpose".
Service alert principle implies that the "system must be endowed with a
mechanism that would alert it in situations that require immediate actions".
Table 1 shows that all requirements derived from VSM tool support challenges are
relevant for Viable Enterprise Service Bus design principles. In the header of the
table, some principles are marked with an asterisk. These are principles (namely,
Channels, Service recursion, Service autonomy) that required features which were not
derived from the analysis of tool support challenges in Section 2. To support these
principles the following additional requirements for VSM based modeling support can
be stated:
The tool shall support bottom-up abstraction in each fractal level and among the
levels
The tool shall support searchable service (and possibly different architecture
pattern) library
Not only should the links of the VSM have dual nature (link and node), but the
same applies also to nodes of the VSM.
4 Conclusions
This paper introduces discussion about modeling tools that would be appropriate to
Viable Systems Model (VSM) based modeling. By analyzing challenges of VSM
based modeling, seven requirements for tool support were derived. These
requirements were analyzed against Viable Service Bus design principles as one of
the application examples of VSM based modeling. The analysis revealed that all
requirements are valid, but the set of these requirements has to be extended with the
addition of three more requirements. Thus the paper reveals altogether 10
requirements that should be met in tools that can be used for VSM based modeling.
These requirements are VSM specific and do not mention many "default" features
that are common in contemporary modeling tools. The statements of requirements
used in the paper are acknowledged to be rather shallow and have only an illustrative
Marite Kirikova
purpose. In future, in order to achieve more rigorous requirements, the direction
should be towards deeper theoretical research and experiments. Nevertheless the
paper provides a starting point for further activities in tool development for VSM
based modeling.
Acknowledgment. The research has been supported in part by the funding from the
research project "Competence Centre of Information and Communication
Technologies" of EU Structural funds, contract No. 1.2.1.1/16/A/007 signed between
IT Competence Centre and Central Finance and Contracting Agency, project No.
1.13.
References
1. Beer, S.: Platform for Change. Chichester: JohnWiley (1975)
2. Beer, S.: The Viable System Model:its provenance, development, methodology and
pathology, Cwarel Isaf Institute Available at
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.456.2285&rep=rep1&type=pdf
3. Espejo, R., Reyes, A.: Organizational Systems. Managing Complexity with the Viable
System Model, Springer, Berlin (2011)
4. Rios, J. P.: Design and Diagnosis for Sustainable Organization, Springer, Berlin (2012)
5. Azadeh A., Darivandi K., Fathi E.: Diagnosing, simulating and improving business
process using cybernetic laws and Viable Systems Model: The case of purchasing process.
In Systems Research and Behavioral Sciences, 29, pp. 66-86 (2012)
6. Stoyanov, E., Dalakakis, St., Roller, D. Wischy, M.: Supporting the rapid product
development by viable software architecture. In Engineering Design and Global Economy,
Samuel, A, Lewis W (Eds.), Institute of Engineers, Australia, Barton, 13 p. (2005)
7. Herring, Ch., Kaplan, S.: Viable systems: The control paradigm for software architecture
revisited, 0-7695-0631-3/00, IEEE, 9p (2000).
8. Preece, G., Shaw, D. Hayashi, H.: Using the Viable System Model (VSM) to structure
information processing complexity in disaster response. In European journal od
Operational Research 224, pp. 209-218 (2013).
9. Golnam, A., Regev G., Wegmann, A.: On viable service systems: Developing modeling
framework for analysis of viability in service systems. In: IESS 2011, LNBIP 82, Snene,
M., Ralyte, J., Morin J.-H. (Eds), pp. 30-41 (2011)
10. Jafarov, N.: Viable Enterprise Service Bus Model: A Model for Designing a Viable
Service Integration Platform, Thesis. Available at
http://www.unsworks.unsw.edu.au/primo_library/libweb/action/dlDisplay.do?vid=UNSW
ORKS&docId=unsworks_42290&fromSitemap=1&afterPDS=true
11. Richter, J., Basten D. Applications of the Viable Systems Model in IS researc -- A
comprehensive overview and analysis. In: Proceedings of HICSS 2014, IEEE, pp. 4589-
4598 (2014)
12. ArchiMate® 3.0.1 Specification (2017). Available at
http://pubs.opengroup.org/architecture/archimate3-doc/
13. BPMN Specification 2.0.2 (2014) Available at
http://www.omg.org/spec/BPMN/2.0.2/PDF/
14. What are microservices? Available at https://opensource.com/resources/what-are-
microservices