Conference PaperPDF Available

Using Fractal Enterprise Model to Assist Complexity Management


Abstract and Figures

This paper deals with the problems of a complex organizational system in which not each of its parts is directly connected to all other parts. For such a system, it is important to identify which parts/sub-systems need to be directly connected to each other, and which could be left without such connections. The paper puts forward a hypothesis that a suitable enterprise model could be used for this end, and investigates the suitability for this end of one particular enterprise modeling technique called Fractal Enterprise Model.
Content may be subject to copyright.
Published in CEUR, Vol. 2218, p. 233-238,
Using Fractal Enterprise Model to Assist Complexity
Ilia Bider & Erik Perjons
DSV, Stockholm University, Stockholm
Abstract. This paper deals with the problems of a complex organizational system
in which not each of its parts is directly connected to all other parts. For such a
system, it is important to identify which parts/sub-systems need to be directly
connected to each other, and which could be left without such connections. The
paper puts forward a hypothesis that a suitable enterprise model could be used
for this end, and investigates the suitability for this end of one particular enter-
prise modeling technique called Fractal Enterprise Model.
Keywords: complexity management, Ashby law, requisite variety, enterprise
1 Motivation
In this position paper, we use a classical definition for complexity management in the
form of Ashby law of requisite variety [1]. The law states that for a system to survive
and prosper in a dynamic environment, its variety should match or be greater than the
variety of the environment. The variety itself can be roughly defined as a number of
possible states of the environment or system respectively. In essence, the law requires
that for any relevant for the system perturbation in the environment, the system needs
to have an appropriate response.
There are two ways for managing variety, either to decrease variety of the environ-
ment, using so-called attenuators, or increase variety of the system, using so-called am-
plifiers. Normally, a combination of both is used. One of the accepted ways of increas-
ing the variety of a system is to structure the system in a number of subsystems, each
of which is responsible for its own segment of the environment, and does not look at
other segments at all. As the result, the variety of the system will be much greater than
when each system's element is related to each segment of the environment.
One way of structuring the system to achieve greater variety is suggested in Viable
System Model (VSM) of Stafford Beer [2], where each unit of System 1 is responsible
for its own part of the environment. In addition, such a unit can be recursively decom-
posed according to VSM, thus splitting the unit to smaller parts – System 1 units of the
next level. Another way of structuring a system to increase variety is a layered archi-
tecture. A typical example of how such architecture works is presented by Michael Po-
lanyi in the essay "Life's irreducible structure" [3], where different layers concerns dif-
ferent aspects of reality, e.g. physical vs. mental, and each layer provides a mechanism
for the next layer to implement its functionality. A similar concept is used in the IT
world, e.g. for creating communication protocols.
The maximum variety that could be achieved by system structuring is when the en-
vironment can be represented as a set of completely independent segments, which never
happens in reality. Therefore, it is impossible to structure a system so that all its sub-
systems are completely independent from each other. Some mechanism of interaction
between the subsystems is needed. In VSM, coordination between the System 1 units
that work on the interdependent or intersecting segments of environment is entrusted to
so-called System 2, while System 3 has an overall responsibility for cohesion of work
of System 1 units. In the layered architecture of Polanyi, the coordination between the
layers is achieved by the next layer setting constraints on the functioning of the previous
When the subsystems need to interact with other subsystems, the increase of system
variety will be maximized if each subsystem interacts only with few other subsystems,
not all of them. This will create a really complex system in terms of Niklas Luhmann
[4], who differentiates simple complexity, where each element of the system is con-
nected to each other element of it, and complex complexity, where total interconnec-
tivity is not achievable, and each element is connected only to few other elements.
An interesting example of complex complexity is given by Michael Polanyi in his
essay "The republic of science: its political and economic theory" [3]. The question
raised in the essay is how Science can function as a whole given extreme specialization
of scientists. He shows that cohesion in Science as a system is achieved through the
interdisciplinary fields where two or more "pure" scientific fields become intercon-
nected. This interconnections help to propagate new achievements in one field to some
distance to a completely different field, ensuring wholeness of the system.
The question that we want to raise in this paper is how to find which subsystems of
an enterprise, or any other type of organizational system, need to be directly connected,
and which do not need such a connection. We aim to use a special type of enterprise
models for this end that is called a Fractal Enterprise Model (FEM). It was first
introduced at PoEM 2012 [5], and then extended and improved in [6]. FEM has a form
of a directed graph with two types of nodes Processes and Assets, where the arrows
(edges) from assets to processes show which assets are utilized by which processes and
arrows from processes to assets show which processes help to have specific assets in
healthy and working order. The arrows are labeled with meta-tags that show in what
way a given asset is utilized, e.g. as workforce, reputation, infrastructure, etc., or in
what way a given process helps to have the given assets “in order”, i.e. acquire, main-
tain or retire.
A FEM is built recursively by using a so-called unfolding procedure and two types
of archetypes: process-assets archetypes that show which kind of assets might be
needed for running a process, and an asset-processes archetype that shows which pro-
cesses are needed to maintain an asset in order. Unfolding starts with a primary process
- a process that delivers value to a customer/beneficiary - by applying process-assets
archetypes and alternating them with the asset-processes archetype.
The rest of the paper is structured in the following manner. As FEM is not a com-
monly used model, in Section 2, we give a short overview of it. The reader interested
in the details, and the reasons why the model is called fractal and what was the motiva-
tion for its development could get this information from [6]. In Section 3, we discuss
how FEM can assists in finding which subsystems of an organizational system need to
be interconnected. Section 4 is devoted to concluding remarks and plans for the future.
2 Fractal Enterprise Model
A Fractal Enterprise Model (FEM) includes three types of elements: business processes
(more exactly, business process types), assets, and relationships between them, see Fig.
1 in which a fragment of a model is presented. The fragment is related to a hypothetic
company that sells books over the Internet. Graphically, a process is represented by an
oval, an asset is represented by a rectangle (box), while a relationship between a process
and an asset is represented by an arrow. We differentiate two types of relationships in
the fractal model. One type represents a relationship of a process “using” an asset; in
this case, the arrow points from the asset to the process and has a solid line. The other
type represents a relationship of a process changing the asset; in this case, the arrow
points from the process to the asset and has a dashed line. These two types of relation-
ships allow tying up processes and assets in a directed graph.
Fig. 1. A fragment of a FEM, adapted from [7], drawn with the help of Insight maker.
In FEM, a label inside an oval names the given process, and a label inside a rectangle
names the given asset. Arrows are also labeled to show the type of relationships be-
tween the processes and assets. A label on an arrow pointing from an asset to a process
identifies the role the given asset plays in the process, for example, workforce, infra-
structure, etc. A label on an arrow pointing from a process to an asset identifies the way
in which the process affects (i.e. changes) the asset. In FEM, an asset is considered as
a pool of entities capable of playing a given roles in a given processes. Labels leading
into assets from supporting processes reflect the way the pool is affected, for example,
a label acquire identifies that the process can/should increase the pool size.
Note that the same asset can be used in two different processes playing the same or
different roles in them, which is reflected by labels on the corresponding arrows. It is
also possible that the same asset can be used for more than one role in the same process;
in this case, there can be more than one arrow between the asset and the process, but
with different labels. Similarly, the same process could affect different assets, each in
the same or in different ways, which is represented by the corresponding labels on the
arrows. Moreover, it is possible that the same process affects the same asset in different
ways, which is represented by having two or more arrows from the process to the asset,
each with its own label.
In FEM, different styles can be used for shapes to group together different kinds of
processes, assets, and/or relationships between them. Such styles can include using
dashed or double lines, or lines of different thickness, or colored lines and/or shapes.
For example, a diamond start of an arrow from an asset to a process means that the asset
is a stakeholder of the process (see the arrows “Workforce” in Fig. 1).
Labels inside ovals, which represent processes, and rectangles, which represent as-
sets, are not standardized. They can be set according to the terminology accepted in the
given domain, or be specific for a given organization. Labels on arrows, which repre-
sent the relationships between processes and assets, however, can be standardized. This
is done by using a relatively abstract set of relationships, like, workforce, acquire, etc.,
which are clarified by the domain- and context-specific labels inside ovals and rectan-
gles. Standardization improves the understandability of the models.
3 Using Fractal Enterprise Model for Complexity Management
To use FEM for identifying systems interactions, we need to introduce some kind of
systems related to FEM's nodes. For this purpose, we consider a Business Processes
(BP) from a systems perspective suggested in [6]. According to this suggestion, we can
identify two types of systems related to BPs, one belongs to the level of process in-
stances the other to the level of process types:
1. On the instance level, we consider a Business Process Instance (BPI) as a temporal
system created for handling a specific situation, for example a request for quotation.
After the situation has been dealt with, the temporal system is disbanded. This inter-
pretation corresponds to the idea of respondent system from [8].
2. On the type level, we consider that for each type there exists a permanent socio-
technical system that is responsible for starting and monitoring process instances of
the given type, and supplying them with resources/assets needed for attaining the
instances operational goals, such as people, tools (e.g. IT systems), procedures (e.g.
manuals, process maps), etc. We call this system a Business Process Work System
or BPWS for short. Note that term work system was introduced by S. Alter, see, for
example, [9], and BPWS can be considered as a particular class of work systems.
Note that not only a BPWS is a socio-technical system, but also a BPI. The latter can
be quite complex and it can have a long life length. However, our focus in this work is
more on the BPWS than its BPIs. Note also that a BPWS does not coincide with a
particular department that is responsible for the process, but it includes all people, meth-
ods, tools engaged in the process.
Returning to FEM, we can consider that a process node with all connected assets
nodes that are used in the process represents a BPWS related to this process. Having
this view, two BPWSs can be considered as connected to each other if there is at least
one common asset to which both have links. Such connections can be classified in three
1. Both BPWSs manage the same asset. For example, both BPWS System development
and System maintenance in Fig. 1 manages Webshop software. Naturally, they need
to interact with each other. System development needs to provide system documen-
tation and answer questions when needed. System maintenance needs to report the
problems to be addressed in the next version of the system. We refer to this type of
interactions as to horizontal interactions.
2. One BPWS manages an asset used in another BPWS. For example, Hiring manages
asset Developers that is used in BPWS System development as Workforce in Fig. 1.
Naturally, these two BPWSs, Hiring and System development need to interact. Sys-
tem Development provides requirements on what qualifications are required to Hir-
ing. Hiring provides information on the state of the job market. The latter may be
used for redesigning the system development process. We refer to this type of inter-
actions as to vertical interactions.
3. Both BPWS share the same asset. For example, two BPWS may use the same IT
system (there is no example in Fig. 1 for this case). Naturally, these two BPWSs
need to interact to come to agreement, for example, on the requirements for shared
asset, or/and on the way it is shared. We refer to this type of interactions as to coor-
dinating interactions (it has the same meaning, more or less, as System 2 in VSM).
Note that our classification of interactions between BPWS is somewhat related to the
classification of interactions between work systems suggested in [10]. The difference
lies in that we consider a specific type of work systems - BPWS, and specific interac-
tions between BPWSs being connected to the same asset.
4 Concluding remarks
This is a position paper aimed at raising interesting questions for discussion, rather than
giving the answers. The contribution of this paper is threefold. Firstly, we formulated a
question for discussion on "how to identify which sub-systems of a really complex or-
ganizational system need to be connected", where by really complex we mean a system
in which not each of its parts is directly connected to all other parts. Secondly, we put
forward a hypothesis that an enterprise model could be used as a tool for answering this
question. Thirdly, we investigated a particular enterprise modeling technique, FEM, to
see how this hypothesis could be implemented in practice. The investigation is prelim-
inary, but it gives some direction for further research.
As far as practical application of using FEM for complexity management is con-
cerned, we see FEM, in the first place, as a diagnostic tool that helps to identify the
places where interactions should exist and asses the quality of the channels for these
interactions. Besides ensuring that interactions are happening in timely and consistent
manner, these channels should be decentralized. The latter ensures that a channel itself
does not create extra connections to the sub-systems that do not need to be connected.
As far as directions for further research are concerned, the most important one is
answering the question of how interactions between connected BPWSs could be prac-
tically arranged. This can be answered analyzing current practice by conducting case
studies. Another research direction is comparing the usage of FEM for complexity man-
agement with other modeling techniques, e.g. VSM, to find out benefits, drawbacks and
limitations. Note, however, that different modeling techniques decompose a system into
subsystems differently. Thus, most probably, the results achieved while applying dif-
ferent techniques will be rather complementary, than contradictory. For example, VSM
places focus on coordinating units of System 1, which constitutes System 2. The issues
of coordination between System 1 units and supporting functions, which are spread
through System 3, 4 and 5, are left in the shadow. The latter is what using FEM can
help with.
Ashby, W. R.: An introduction to cybernetics. Chapman & Hall, London (1956)
Beer, S.: The Heart of Enterprise. Wiley (1979)
Polanyi, M. S.: Knowing and Being. University of Chicago, Chicago (1969)
Luhmann, N.: Introduction to Systems
Bider, I., Perjons, E., Elias, M.: Untangling the Dynamic Structure of an Enterprise by
Applying a Fractal Approach to Business Processes. In : Proceedings of PoEM 2012,
Springer, LNBIP 134, pp.61
76 (2012)
6. Bider, I.,
Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its
application for business development. Software & Systems Modeling (2016)
Bider, I., Perjons, E.: Using a Fractal Enterprise Model for Business Model Innovation. In
: BPMDS 2017
RADAR, CEUR Vol 1859, pp.20
29 (2017)
Lawson, H.: A journey through the systems landscape. College Publications (2010)
Alter, S.: The Work system method: Connecting people, processes, and IT for business
results. Work System Press (2006)
r, S.: System Interaction Theory: Describing Interactions between Work Systems.
Communications of the Association for Information Systems: Vol. 42 , 42(Article 9) (2018)
... The second phase is developing a method of using FEM for this purpose, provided that the case study has confirmed that FEM could be useful in the context. One of the areas where such methodology was exploited is using FEM for Business Model Innovation (BMI), see [11], [15], [16]. The current paper concerns the second phase of developing a method for using FEM in operational decision-making. ...
Full-text available
A pattern is a concept widely used in engineering and other disciplines for variety of purpose, e.g. business or system analysis. In this work, we present the concept of patterns usage within enterprise modelling. The undertaking is a part of the larger case study dedicated to Fractal Enterprise Modelling (FEM) development deploying Design Science (DS) research methodology. Based on the case study, we have identified three FEM related patterns: one modelling pattern and two analyzing patterns. A modeling pattern advises on a proper way of building a model for a particular purpose, while an analysis pattern helps to find places in a business where a decision could/should be made. More precisely, the modelling pattern identified in this study helps to build a model on an appropriate level of granularity for a certain purpose (operational decision-making). The analysis pat-terns identified in the study are divided into two categories of patterns: transformational patterns and problem patterns. Transformational pattern is a pattern that contains a condition and an action parts that represent a standardized solution or an opportunity. Problem pattern is a pattern that expresses conditions where a problem might exist without specifying a definite action. These patterns contribute into the creation of the bank of patterns to guide practitioners in modelling and analyzes of the business situations using FEM.
... people or technology, require readjustment of other assets connected to the node. This issue is covered in more details in [13]. ...
Full-text available
The concept of structural coupling, which comes from the biological cybernetics, has been found useful for organizational decision making on the higher level, such as management of organizational identity and strategy development. However, currently, there is no systematic procedure for finding all elements (other organizations, markets, etc.) of the environment to which a given organization is structurally coupled, or will be coupled after redesign. The paper tries to fill the gap by employing enterprise modeling to identify structural couplings. More specifically, an extended Fractal Enterprise Model (FEM) is used for this end. FEM connects enterprise processes with assets that are used in and are managed by these processes. The extended FEM adds concepts to represent external elements and their connections to the enterprise. The paper drafts rules for identifying structural couplings in the model by analyzing FEMs that represent different phases of the development of a company which the author co-founded and worked for over 20 years.
Full-text available
Interactions between systems are a necessity, a source of opportunity, and a source of difficulty and complication in building, implementing, and maintaining IT-reliant systems in organizations. This paper presents system interaction theory (SINT), a theory for analysis that covers almost all intentional and unintentional interactions between work systems that may be sociotechnical or totally automated. SINT is a broadly applicable theory that encompasses interactions between the types of systems that are central to the IS discipline. To minimize redundancy, this paper summarizes SINT immediately after introducing the research goal and, thereby, provides a context for the many distinctions and references that follow. A discussion of SINT’s domain and scope explains why SINT views interacting entities as work systems rather than as tasks, components, or software modules. The literature review positions SINT in relation to topics under headings that range from general systems theory and computer science to human computer interaction and organization science. Topics in SINT include relevant characteristics of systems and system interactions, purposes and/or causes of system interactions, system interaction patterns, direct effects of system interactions, responses to direct effects, and outcomes related to system interactions. The paper discusses a variety of potential contributions to theory, practice, and research.
Conference Paper
Full-text available
In their previous work, the authors have developed a new kind of enterprise model, called fractal enterprise model, that connects enterprise processes via assets used for running these processes. One of the possible usages of this model is facilitating innovation, more exactly, changing or extending a business model used in the enterprise. This research-in-progress paper presents the idea of how such facilitation could be arranged, and lists the problems that need to be solved in order to convert the idea into a practical methodology. The discussion is based on a hypothetical example.
Full-text available
Paper is in open access: This paper suggests a new type of enterprise models called fractal enterprise models (FEM), with accompanying methodological support for their design. FEM shows interconnections between the business processes in an enterprise by connecting them to the assets they use and manage. Assets considered in the model could be tangible (buildings, heavy machinery, etc.) and intangible (employees, business process definitions, etc.). A FEM model is built by using two types of patterns called archetypes: a process-assets archetype that connects a process with assets used in it, and an asset-processes archetype that connects an asset with processes aimed to manage this asset (e.g., hiring people, or servicing machinery). Alternating these patterns creates a fractal structure that makes relationships between various parts of the enterprise explicit. FEM can be used for different purposes, including finding a majority of the processes in an enterprise and planning business change or radical transformation. Besides discussing FEM and areas of its usage, the paper presents results from a completed project in order to test the practical usefulness of FEM and its related methodological support.
Untangling the Dynamic Structure of an Enterprise by Applying a Fractal Approach to Business Processes
  • I Bider
  • E Perjons
  • M Elias
Bider, I., Perjons, E., Elias, M.: Untangling the Dynamic Structure of an Enterprise by Applying a Fractal Approach to Business Processes. In : Proceedings of PoEM 2012, Springer, LNBIP 134, pp.61-76 (2012)
A journey through the systems landscape
  • H Lawson
Lawson, H.: A journey through the systems landscape. College Publications (2010)
The Work system method: Connecting people, processes, and IT for business results
  • S Alter
Alter, S.: The Work system method: Connecting people, processes, and IT for business results. Work System Press (2006)