A fractal enterprise model and its application for business development

Abstract

Paper is in open access: http://bit.ly/2c3RI8P
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.

Full text

Softw Syst Model (2017) 16:663–689
DOI 10.1007/s10270-016-0554-9
THEME SECTION PAPER
A fractal enterprise model and its application for business
development
Ilia Bider1·Erik Perjons1·Mturi Elias1·Paul Johannesson1
Received: 21 October 2014 / Revised: 4 June 2016 / Accepted: 2 August 2016 / Published online: 25 August 2016
© The Author(s) 2016. This article is published with open access at Springerlink.com
Abstract This paper suggests a new type of enterprise
models called fractal enterprise models (FEM), with accom-
panying methodological support for their design. FEM shows
interconnections between the business processes in an enter-
prise 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 transfor-
mation. 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 method-
ological support.
Communicated by Dr. Selmin Nurcan.
BPaul Johannesson
pajo@dsv.su.se
Ilia Bider
ilia@dsv.su.se
Erik Perjons
perjons@dsv.su.se
Mturi Elias
mturi@dsv.su.se
1DSV, Stockholm University, Forum 100, 164 40 Kista,
Sweden
Keywords Business process ·Enterprise modeling ·Fractal
enterprise ·Asset
1 Introduction
1.1 Motivation
For many projects related to business processes, it is impor-
tant to find all, or at least a major part, of the business
processes that exist in a given organization/enterprise. This is
not a trivial issue as only the most visible processes catch the
attention of management and consultants. These processes
represent the tip of the iceberg of what actually exists in the
enterprise in half-documented, or in totally undocumented,
form (tacit knowledge).
We, ourselves, experienced the difficulties in finding all
the processes in an organization when working on a project
examining process-orientation in a non-profit organization
[4]. The project included building a business process support
system, and it was important to see what processes could
or should be supported by the system. We partially solved
the problem by going through all departments, interview-
ing people about what kind of tasks they completed and the
inputs they received from other departments, what kind of
results they produced, and where these were delivered. From
the information obtained, we were able to connect the tasks
executed in various processes to each other and get a list of
process candidates to be supported by a system.
The approach taken in the project was tedious; besides, it
did not guarantee that all processes were found. In fact, at a
later stage of working with the organization, we found other
processes that were overlooked in the initial study. Thus,
the question arose whether there is a way of discovering
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

664 I. Bider et al.
processes more effectively, ensuring that a majority of the
processes is identified.
The task of process-orientation in an organization/
enterprise by introducing a process support system is not
the only task that requires finding all or a major part of
the processes in an organization. Any major organizational
change directed at identifying and/or solving a problem, or
expanding or optimizing the business may require discover-
ing all processes, or a major part of them, related to a specific
area. It may not be enough just to investigate one or several
main processes belonging to the area of intervention, as the
intervention may require adjustments in other parts of the
enterprise in question. The latter is a well-known fact in sys-
tems dynamics (SD), see, for example, Jackson [33]. In a
classical example from SD, optimizing a sales process may
result in losing customers if the processes related to the deliv-
ery of goods and services are not adjusted on time. Initially,
the optimized sales process may result in increasing the num-
ber of customers. However, if other processes are not adjusted
at the same time, delivery delays may follow which, in turn,
may result in losing customers.
The example above illustrates that even when only one
process is being redesigned, it is important to find out other
processes that could be affected by changes in the given one.
Furthermore, the processes affected can be in an entirely dif-
ferent area than the one being changed. For example, changes
in the sales process may require changes in the service
process to cover the demands from a larger customer base,
and changes in recruiting and training of service personnel
as a consequence. In addition to finding all processes, or the
processes related to the area of intervention, an organizational
change project may require understanding the connection
between the processes that may be affected by the interven-
tion. Thus, the problem above can be formulated as:
Finding all or a majority of processes in an organiza-
tion, or all or a majority of processes that can be affected
by an intervention in a specific area
needs to be complemented by
… and establishing connections between these
processes that could help in identifying a problem
and/or planning an intervention
To the best of our knowledge, the academic and practical liter-
ature does not include a description of an effective procedure
that can help in solving the two parts of the problem above.1
Suggesting such a procedure is the focus of the research
project, the preliminary results of which are presented in this
paper.
1This does not mean that there are no studies that contain knowledge
that can help in solving this problem; these are overviewed in Sect. 2
and compared with our approach in Sect. 7.
1.2 Overview of the solution
Our solution is based on the approach from [11] that consid-
ers a Business Process Instance (BPI) as a respondent system
[39] created by an enterprise/organization in reaction to some
(business) situation. After the situation has been resolved,
the BPI is disbanded. For the BPI to achieve its set goal, the
enterprise transfers some of its assets (e.g., people, infrastruc-
ture, equipment, etc.) to this system. To work smoothly over
a long period of time, the enterprise needs to have appro-
priate assets ready to be deployed when the next situation
triggers a new BPI. The assets need to be acquired and main-
tained all the time to avoid the depletion, for example due to
people leaving the organization or equipment becoming old.
Therefore, the enterprise/organization needs to have special-
ized processes aimed at maintaining the quantity and quality
of its assets on the right level, e.g., processes of recruiting
employees, purchasing equipment, training employees, and
servicing equipment.
Based on the deliberations above, we suggest the fol-
lowing recursive procedure for discovering processes in an
organization with the starting point being the visible part of
the “process iceberg,” i.e., the so-called primary processes.
Here, as primary we count processes that deliver value for
which some of the enterprise’s external stakeholders are
ready to pay, e.g., customers of a private enterprise, or a
local government paying for services provided to the pub-
lic. Typical examples of primary processes are hard (e.g., a
computer) or soft (e.g., a software system) product manufac-
turing, or service delivery (e.g., an educational process at a
university). After the primary processes are identified, one
proceeds with identifying assets that are needed to execute
the primary processes. Each asset type requires a package
of so-called supporting processes to have the correspond-
ing assets in “working order” waiting to be deployed in the
BPIs of the primary process. A typical example of supporting
processes is human resources (HR) processes (e.g., hiring or
retiring members of staff), which ensure that the enterprise
has the right people engaged in its primary processes.
To make the suggested procedure of process discovery
more systematic, we introduce two types of archetypes, or
patterns, to follow when moving from primary processes to
supporting processes:
•Process-assets archetypes (patterns) that help to identify
what assets are needed for a particular process, especially
for a primary process from which we start discovering the
rest of the processes.
•Asset-processes archetypes (patterns) that help to identify
supporting processes that are needed to have each type
of asset ready and available for deployment.
Having these archetypes/patterns helps to discover the
process structure of an enterprise starting from the primary
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 665
process and recursively applying archetypes in the following
manner:
“a primary process –(process-assets archetype)→its assets
–(asset-processes archetype)→processes for each assets –
(process-assets archetype)→assets for each process →…”.
As a result, we not only discover processes that exist in the
enterprise, but also indirect relationships between them, i.e.,
relationships through the assets. We call the outlined above
procedure unfolding procedure. This procedure produces a
potentially infinite tree with a repeating pattern of structures.2
The nodes of the tree alternate between processes and assets,
where the edges lead from a process to the assets it needs,
or from an asset to processes aimed at maintaining this asset
in “working order.” This tree represents a kind of process
architecture [26] of the organization in question.
Infinite structures that are obtained through a recursive
application of the same pattern are known in the scientific
literature as fractal structures [46]. By analogy, we refer to
the tree produced through the unfolding procedure as a fractal
enterprise model (FEM). Even though the repetition in FEM
exists only on the level of abstract archetypes, and not on the
level of processes and assets themselves, we have chosen the
term based on the following two reasons. Firstly, it highlights
the recursive nature of the unfolding procedure. Secondly,
and more importantly, the term fractal has already been used
by others in a similar meaning both in academic [58] and
practical [30] literature. By using the term fractal, we not
only highlight the recursive nature of our model, but also
explicitly position our work into an emerging field of research
and practice.
When using the word enterprise in the term fractal enter-
prise model, we do not intend to limit the usage of the
new modeling technique to for-profit organizations only. We
believe it is applicable to any kind of organization that pro-
vides products and services to a wider circle of people or other
organizations. We consider as an enterprise any organization
in which the operational activities are financed by external
stakeholders, i.e., people or other organizations outside the
enterprise itself. An enterprise can, for example, be a private
company that receives payment for its operational activities
from the customers, a head office of an interest organization
that receives fees from the members of this organization, or
a public office that receives funding from the taxpaying citi-
zens or residents.
As with any model, our FEM is an idealization and abstrac-
tion from some details of reality. Therefore, we do not
consider a FEM as a universal enterprise model suitable for
2Actually, this tree will have a limited size due to some processes and
assets being used in several places of the structure thus rendering it a
finite graph. This also leads to the tree becoming a directed graph of
generic type.
any possible purpose. The initial motivation for designing
FEM was looking for an answer to the first part of the problem
posed in Sect. 1.1 (i.e., finding all or a majority of business
processes). However, the resulting model turns out to be of a
more general nature, and it could be used for dealing with the
second part of the task (i.e., establishing connections between
the processes found), as well as for solving other problems
discussed in this paper.3
The main goal of this paper is to describe the FEM
model and provide accompanying methodological support
for building FEM for a particular organization and purpose.
The methodological support consists of an unfolding proce-
dure based on process-assets and asset-processes archetypes.
After introducing FEM and its related methodological sup-
port, we discuss its usability for solving practical problems.
To test the practical usefulness of the model, we created and
evaluated a FEM model for educational activities of a uni-
versity. We started from one of the primary processes of the
university domain—teaching—and discovered the processes
connected to it via recursive applications of the unfolding
procedure outlined above. The case was chosen because of
the authors’ own experience with this process as well as easy
access to the expertise of a university department. The cho-
sen case does not mean that the procedure is applicable only
to the academic world. When presenting the archetypes, we
offer examples from other domains as well.
The research presented in this paper utilized the design
science (DS) paradigm [13,29]. The goal of DS research is
finding and testing a generic solution [13]orartifact[29]fora
class of practical problems. The FEM and the methodological
support suggested in this paper constitute DS artifacts for
solving the problem discussed in Sect. 1.1. Though most of
the concepts used in building this artifact are not new, the
artifact itself, which is the main contribution of the paper, as
a whole, is new and original. In addition, we are not aware
of any research work specifically devoted to finding answers
to the questions above. So our solution, even if not perfect,
can be used in practice until a better one can be found.
1.3 The background and structure of the paper
This paper is based on an experience report Elias et al. [22]
presented at the working conference for Business Process
Modeling, Development and Support in 2014 (BPMDS
2014). The current paper has a more theoretical nature than
the experience report, the latter being used in the paper to
validate and illustrate our line of thought and findings. The
experience report [22], in turn, has been built on ideas pre-
sented at the conference on Practice of Enterprise Modeling
in 2012 (PoEM 2012), see [14]. Therefore, the current paper
3See also the comment from [15] “Essentially, all models are wrong,
but some are useful”, p. 424.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

666 I. Bider et al.
could also be considered as a substantial extension and revi-
sion of Bider et al. [14] based on the experience reported
in [22]. In the current paper, the fractal model, first sug-
gested in [14], has been improved by adding more details to
the archetypes. Besides the model improvement, this paper
includes a review of related literature, and an extended dis-
cussion on the usability of FEM.4
The rest of the paper is structured in the following way. In
Sect. 2, we provide an overview of literature from relevant
academic fields. In Sect. 3, we describe the research method
and background on which our solution has been built. In Sect.
4, we describe FEM in more detail. In Sect. 5, we discuss
the potential areas of usability for FEM. In Sect. 6,wetest
FEM in a case by applying the archetypes defined in Sect. 4
to unfold parts of the process structure of the Department of
Computer and Systems Sciences of Stockholm University. In
Sect. 7, we compare our approach for defining relationships
between the processes with the works of others reviewed in
Sect. 2. In Sect. 8, we discuss open issues. Section 9sum-
marizes the results achieved so far and outlines plans for the
future.
2 State of the art
There are several academic fields that are related to the
research reported in this paper including research on process
architecture, enterprise modeling frameworks focusing on
resources and processes, and fractal models of an enter-
prise. In the subsequent subsections, we will provide a short
overview of these fields. In this section we do not focus
on comparing FEM with the works of others, leaving such
comparisons for Sect. 8where we also present a framework
developed to this end.
2.1 Business process architecture
An enterprise architecture specifies the “essential elements
of a sociotechnical organization, their relationships to each
other and to the environment, in order to understand com-
plexity and manage change” [21]. An enterprise architecture
can, in turn, consist of a business architecture, an application
architecture, a data architecture, and a technical architecture,
as in The Open Group Architecture Framework (TOGAF)
[64].
In the business part of enterprise architecture, the focus
is often on the business processes [57,60]. These business
processes can, in turn, be organized in what is sometimes
called a business process architecture [26,37]. Such an archi-
tecture consists of a number of process models, specifying
4Note that material from neither [14], nor [22] has been previously
published in a scientific journal.
which business processes exist in an organization, how each
of them starts and ends, and the relationships between them
[18]. By using a business process architecture, an organiza-
tion can design consistent and integrated business processes.
Dijkman et al. [18] have identified five design approaches for
business process architectures, such as goal-based, action-
based, object-based, reference-based, and function-based
approaches, which briefly will be described below.
The goal-based approaches for business process archi-
tectures use a goal structure as the base, and from this
structure the business process architecture is derived [41].
That is, first, a number of business goals and their relation-
ships are specified, often in a hierarchy, and then, based on
the goals, business processes are identified. Thereby, these
business processes in the business process architecture can
be related to the goals of an organization. An example of
a goal-based approach relating goals and processes can be
found in [48,56], aiming at organizational change.
The action-based approaches assume that the interac-
tion between a consumer/customer and a provider can be
described as an action loop, consisting of a pattern of phases
that need to be carried out in order to finalize an interaction
[17,42]. These patterns and their phases can be used as a
base for identifying business processes in a business process
architecture.
The object-based approaches for business process archi-
tectures start by specifying business objects and their rela-
tionships in a business [26]. This results in an object structure,
often called a conceptual model. Based on the object struc-
ture, business processes can be identified, for example by
elaborating which operations can be carried out on the
objects, and then design business processes to support these
operations. Certain kinds of objects, such as an order or
a referral, can also be used to identify business processes.
These kinds of objects work as cases or as flow objects in
a business process, and the business process can be seen as
managing these objects, which change states during the exe-
cution of the business process.
The reference-based approaches [24,60] use a reference
framework consisting of a number of specified and related
business processes, such as the SAP reference model [16],
and the MIT Process Handbook [44]. Based on such reference
frameworks, which themselves can be interpreted as business
process architectures, a process architecture framework for
an organization can be designed.
Finally, in the function-based approaches, the business
processes are identified based on the business functions in
an organization [60].
Dijkman et al. [18] also specify a number of relation-
ship types between business processes in business process
architectures, such as decomposition, which is a part of
relationship; specialization, which is an ISA relationship or
generalization–specialization relationship; a trigger relation-
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 667
ship, which means that one business process triggers another;
and a use relationship, which mean that one business process
provides services used by another.
An approach to business process architecture that includes
a procedure to identifying processes is suggested in [19]. It
is based on initially organizing processes according to case
types and business functions. Large processes can then be
decomposed using guidelines that take into account logical
separation in time and space, transactional states, as well as
several other aspects.
2.2 Enterprise modeling frameworks focusing on
resources and processes
Two approaches that propose general frameworks for enter-
prise modeling with a focus on resources (called assets in
FEM) and their transformations in business processes are
those by Alter [2] and Osterwalder [49]. Alter [2] proposed
the notion of work system as a unit of analysis for reason-
ing about systems in organizations, thereby using business
processes as the central component. A work system is a sys-
tem in which human participants and machines carry out
work (processes and activities) using information, technol-
ogy, and other resources in order to produce products and
services for customers. In most business organizations, there
are work systems that procure materials from suppliers, pro-
duce products and services, deliver products to customers,
attract and retain customers, manage after sales services, hire
employees, as well as perform many other functions.
Osterwalder [49] has developed an ontology for business
models, which provides a conceptual basis for the business
models of organizations. Based on the ontology, Osterwalder
and Pigneur [50] have developed a strategic management
and entrepreneurial tool, called the Business Model Canvas
(BMC), which is intended to support people in describing,
analyzing, designing, and inventing business models. BMC
offers a visualization of the key elements of a business model
in the form of a canvas, including customer-oriented com-
ponents as well as resource oriented ones. The elements
of BMC comprise value propositions, customers, customer
relationships, channels, revenue streams, key resources, key
activities, partners, and cost structure. Comparing the BMC
with the work system framework proposed by Alter [2], it
can be noted that many of the elements overlap. However,
BMC is specifically tailored for modeling value generation
in business networks, while the work system framework can
be applied in many different contexts, e.g., for modeling
information systems, service systems or value chains. In this
paper, BMC and the work system framework are used as a
basis for the process-assets archetypes, in the sense that their
components provide a set of generic assets that are required
for main processes as well as supporting processes.
BMC and the work system framework offer a heli-
copter view on the processes in and across organizations
as well as their relationships to resources and partners.
Other frameworks go into greater detail on the interplay
between processes and resources, e.g., the REA ontology.
The Resource–Event–Agent (REA) ontology was originally
formulated in [45] and developed further in a series of publi-
cations, e.g., [32]. The ontology is based on the core concepts
of resources, events, and agents. Originating in accounting,
it also carries the underlying principle of duality in resource
transfers between agents, expressing that an agent offers a
resource only when expecting to receive another resource in
return. The same duality holds for production processes, in
which a resource can be produced or improved only if other
resources are used or consumed. These observations form
the basis for the value chain modeling using REA, which in
its most basic form depicts processes in an organization and
the flows of resources between them [20]. The REA value
chains have many similarities to the FEM models proposed
in this paper. However, the latter are more expressive than
REA value chains, as they make explicit the kinds of relation-
ships between processes and resources through the notion of
archetype. Furthermore, FEM offers an associated method-
ological support for discovering processes, while REA value
chains only provide a language for representing process and
resource flows.
2.3 Fractal enterprise models
Analyses of enterprises based on the idea of fractality have
been conducted by several researchers and practitioners, e.g.,
[30,47,55,58]. Their approaches differ from that of ours,
which comes as no surprise as there is no accepted definition
of what fractals mean with respect to the enterprise world. In
essence, fractals are a high-level abstract idea of an infinite
structure obtained by recursive application of the same pat-
tern. Dependent on the perspective chosen for the modeling
of a real life phenomenon, this pattern will be different for
different modelers. Below, we shortly summarize the works
on fractal structures in enterprise modeling, and show the
difference between them and our approach.
The book by Hoverstadt [30] used the viable system model
(VSM) to present the fractal structure of the enterprise via
the system–subsystem relationships. Subsystems are consid-
ered as having the same structure and generic organizational
characteristics as the system in which they are enclosed.
The resulting structure helps to analyze whether there is a
balance between the subsystems. Though our goals are some-
what similar to those of Hoverstadt [30], we use an entirely
different approach to enterprise modeling, instead of system–
subsystem relationships, we interleave processes and assets
when building an enterprise model.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

668 I. Bider et al.
Another approach to the analysis of enterprise models
based on the idea of fractality can be found in [58]. The idea
is to find fractal structures in an enterprise model built when
using a general modeling technique. Sandkuhl and Kirikova
[58] analyzed two such enterprise models in order to find
fractals in it. The results were mixed with some fractals
being found, but with the suspicion that many others were not
detected, as they were not explicitly represented in the mod-
els analyzed. The approach in [58] radically differs from that
of ours. We have a hypothesis of a particular fractal structure
to be found when analyzing an enterprise, while [58]was
attempting to find any type of fractal structure based on the
generic characteristics of organizational fractals.
Mercedes Canavesio and Martinez [47] presented a con-
ceptual model for analyzing a fractal company aiming at
supporting a high degree of flexibility to react and adapt
quickly to environmental changes. Main concepts included
project, resource, goal, actor, plan, and relationships thereof.
The approach by Mercedes Canavesio and Martinez [47]dif-
fers from ours in the kind of fractals used for enterprise
modeling. Fractals by Mercedes Canavesio and Martinez
[47] concerned the detailed structure of business processes
instances, while we are looking at the relationships between
different processes (and between processes and assets).
The focus on process organization when applying fractal
principles can be found in [55]. The author is using a pattern
of sense-and-respond processes on different organizational
levels each consisting of the same pattern: requirement, exe-
cution, and delivery. The difference between our approach
and that of Ramanathan [55] is the same as we have discussed
above. Ramanathan [55] is looking at the details of individ-
ual process instances, while we are trying to capture general
relationships between different processes. Moreover, the idea
of a recursive organization is also relevant for service sys-
tems, which recursively can be decomposed into constituent
service systems [43], although the idea of recursivity is not
further elaborated in this work.
The work by Hoverstadt [30] more than any other works
reviewed in this section highlights the idea of recursivity
when using the term fractal, and thus we consider it as the
most distinguished in the emerging field of the fractal enter-
prise modeling/architecture. This comes as no surprise, as
this work was based on the VSM model by Beer [9]. The
model presents the structure of a viable enterprise, i.e., an
enterprise capable of adapting itself to changes in its business
environment. According to the Ashby law [6], the complex-
ity of the structure of a system capable of adapting to the
environment needs to match the complexity of the environ-
ment by having the same number of internal states as the
environment. To achieve viability, VSM suggests a system
being constructed as a collection of semi-autonomous com-
ponents (units) placed on different levels denoted as System
1,2,3,4,5. Each component interacts with only part of the
business environment and is responsible for adaptation to
changes in this part. Having all parts of the environment
covered by such components produces a viable system that
satisfies the Ashby law in an effective way. Furthermore, each
component may also recursively be viewed as a viable sys-
tem which ensures viability when a system is relatively large,
e.g., an international corporation.
From the discussion, the term fractal enterprise/
organization as defined by Hoverstadt [30] is used to provide
a way to achieve viability/adaptability. Though the motive for
building our FEM was different, we believe that FEM can also
help in achieving viability/adaptability, which is discussed in
Sect. 8.
3 The research approach and background
3.1 The research approach
The development of our fractal model follows the pattern
of design science (DS) research [8,29,52], which seeks new
solutions for problems known or unknown [3]. To count as a
DS solution, it should be of a generic nature, i.e., applicable
not only to one unique situation, but to a class of similar situ-
ations, cf. Principle 1 of [62]. DS research can be considered
as an activity aimed at generating and testing hypotheses for
future adoption by practice [13]. Therefore, implementation
and verification of a generic solution [13]orartifact[52]in
at least one situation, is a critical part of DS, usually referred
to as demonstration or proof of concept [52].
Design science, as a way of generating and testing
hypotheses for generic solutions, requires researchers to act
in two different worlds: (a) the real world of specific situa-
tions, problems and solutions in local practices, and (b) the
abstract world of generic situations, problems and solutions
[13]. Design science does not impose any particular order of
movement in the two worlds. A researcher can start with a
specific problem in a specific situation, find a solution for it
(situation to-be that solved the problem), and then general-
ize all three parts of his/her test case: situation, problem, and
solution. Classification of the ways of working in this man-
ner is presented in [3]. The researcher can also start from
the other end—with finding a generic solution for a known
generic problem and then try to find and implement a test
case for its demonstration.
This research was initiated by a practical problem encoun-
tered in the consulting practice of the first author related
to business process analysis projects, namely “how to find
all processes in the given organization, using minimal
resources.” This problem did not have a satisfactory solu-
tion and was handled in a relatively ad hoc way, with a risk
of missing some important processes that are in place with-
out people in the organization being aware of their existence.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 669
During the research project, the problem, as discussed in
Sect. 1.1, was extended to:
Finding all or a majority of processes in an organiza-
tion, or all or a majority of processes that can be affected
by an intervention in a specific area and establishing
connections between these processes that could help in
identifying a problem and/or planning an intervention,
while using a minimum of resources
In this paper, we propose a solution in the form of a new type
of enterprise models called fractal enterprise models (FEMs)
as well as methodology support for designing FEMs. The
key requirement for FEMs is that they should be perceived
as useful for practical tasks by the people who participate
in the processes in an organization, and management who
is responsible for detecting and solving organizational prob-
lems and/or using new opportunities appearing in the market.
The key requirement for the methodology support is that it
should enable designers to build FEMs with relatively few
resources. The proposed solution is evaluated with regard
to these two requirements by means of a case study in a
higher education setting, see Sect. 6. This case study can
also be viewed as a demonstration showing the feasibility of
the proposed solution.
The knowledge for this solution is based on the following:
– Own practical consulting experience in the area of busi-
ness processes
– Own work devoted to considering business processes
from a system perspective [11]
– Existing literature related to fractal models and process
architecture reviewed in Sect. 2.
3.2 The background: business processes from a systems
perspective
The notion of business process can be considered from dif-
ferent perspectives. It can be treated as a flow of activities
or operations, i.e., workflow view, or as a communication
between people engaged in collaborative effects, to name a
few possible views. In this paper, we view business processes
from a systems perspective as suggested in [11].5Under a
systems perspective, we consider presenting a phenomenon,
e.g., a business process in our case, as a complex system
interacting with its environment.
The most straightforward way of considering a business
process from a system perspective that we found is by apply-
ing the idea of systems coupling diagram suggested by
Lawson [39]. A generic case of using such diagrams is shown
5In this paper we use the terminology and the set of concepts in a
slightly different manner, than in [11].
in Fig. 1. In this figure, the vertical double line represents the
border between the system of interest (SI)—to the right of
the border, and its environment—to the left of the border.
When SI detects a situation in the environment that needs
some reaction, it creates a so-called respondent system (RS)
to deal with the situation. The RS is built from the assets
that SI already has. Some of these assets are people, others
are of equipment type, stills others are control elements, e.g.,
policy documents, that define the behavior of the respondent
system. Lawson [39] defines a control element as an asset
that directs the respondent system when it operates and dif-
ferentiate it from other assets by using black dots (see Fig.
1).
As an example, consider a situation when a country/state
is an SI (system of interest). SI detects a suspicious move-
ment of the enemy on its border, which is a situation. It forms
a special army unit to deal with the situation, which is an RS
(respondent system), and sends it to the border. This unit
can be comprised from the existing military units, or by call-
ing reservists. Military codes, engagement rules, etc. serve
here as control elements. The enemy either withdraws, or is
beaten by the RS; after that the RS can be disbanded, and the
reservists can go home.
The term Business Process (BP), as used in the research
and practical literature, encompasses two distinct concepts
Business Process Instance (BPI) and Business Process Type
(BPT). A BPI (in some works referred to as case or run)isa
business situation being handled according to some common
procedure. A BPT refers to all BPIs (in the past, present and
future) aimed at dealing with a given type of business sit-
uation. For example, a sales process (type) represents BPIs
aimed at dealing with a situation of appearing of potential
customer. It is also worth mentioning that in the literature
devoted to BP, the term business process is often used with-
out a qualifier (type orinstance), the supposition being that
the qualifier can be understood from the context. To avoid
any misunderstanding, we use term business process with-
out a qualifier only in the meaning of business process type,
using the abbreviation BPI for referring to business process
instances. This is because the rest of this paper, starting
with Sect. 4, is focused on process types, rather thanprocess
instances.
From the systems perspective defined above, a BPI can be
considered as a temporal (respondent) system created by the
organization/enterprise to deal with a certain situation. The
situation can be of an expected (often occurring) type, like
a customer placing an order, or an exceptional one. To deal
with repeatedly appearing situations of a given type effec-
tively, an enterprise creates templates for dealing with the
majority of known types of situations. Such a template is
known under different names, like project template, business
process definition, process description and business process
model. We will refer to it as EXecution Template (EXT). An
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

670 I. Bider et al.
Fig. 1 System coupling
diagrams from [39]
EXT may exist in different forms, e.g., as tacit knowledge,
i.e., in the heads of people working with a given process,
or in an explicit form, e.g., employee’s handbooks or posi-
tion descriptions, or process diagram. It may also be built
into the hardware and/or software used to control, or support
the given process. From the point of view of systems cou-
pling diagrams (see Fig. 1), EXT is a control element as it
defines/directs the operational behavior of a BPI which we
regard as a kind of RS.
In the definition above, we take a very broad view on busi-
ness processes, which might differ from narrow views that
only deal with processes that have a highly strict control flow
of activities. In our perspective, two conditions need to be sat-
isfied for considering a process as belonging to the business
process category. Firstly, it should represent a repeating activ-
ity that engages people,6and secondly, there should be a kind
of template that is used when initiating and executing each
instance as a reaction to a business situation of the given type.
The template can exist in different forms. It can be defined as
a very detailed workflow diagram that determines the activ-
ities to be executed and their order, or as a number of forms
to fill out, as in case or adaptive case management [12,63].
In such a broad view, projects of the same kind completed
by a company engaged in a project-oriented business, e.g.,
construction, or software development, are also considered
as BPIs for which there normally exist templates, e.g., activi-
ties flow descriptions and standard Gantt diagrams. However,
one-time only projects are not considered in this paper as BP
and are thus outside the scope of this paper.
As a kind of RS, BPI needs to receive some assets to
effectively deal with the situation. Such assets (tangible and
intangible) can include:
– People with their knowledge and practical experiences,
etc.
– Physical artifacts—computers, telephone lines, and pro-
duction lines.
6In this paper, we regard a fully automated process as a kind of equip-
ment, i.e., as an asset in the terms of our model. This helps to diminish
the size of the model, thereby, making it more readable. However, if for
some reasons a fully automated process is of special interest, there is
no hinder in the model structure to consider it as a process.
– Organizational artifacts—departments, teams, networks,
and roles.
– Knowledge in explicit and tacit forms:
•Explicit knowledge—information artifacts—policy
documents, manuals, written instruction, etc.
•Tacit knowledge—knowledge that is imprinted in
people’s heads, e.g., organizational culture and tacit exe-
cution rules for executing instances of a given process
Note that assets here are not regarded in purely mechanical
terms. All “soft” assets, like sense of common goals, capa-
bility to collaborate, and shared vision, are considered as
belonging to the organizational assets. Note also that organi-
zational artifacts include not only the artifacts related to the
functional organizational structure, but any kind of project
teams are considered as organizational artifacts.
A BPI as a respondent system is created as a response
on a situation that has been detected. Its purpose is to han-
dle the situation with assets that it has to its disposal. With
such a definition, the task of detecting the situation and allo-
cating specific assets is left outside the BPI. Discussing the
mechanisms of detecting the situations and controlling BPIs
after their creation lies outside the scope of this paper, see,
however, the notion of sensors suggested in [11] as a mech-
anism for detecting situations that require the invocation of
BPIs.
Between the processes and assets, there are various kinds
of relationships. On the one hand, assets are used inside
BPIs when they are started. On the other hand, BPIs can
change assets. Some business processes are explicitly aimed
at changing assets. For example, the business process of
hiring employees is aimed at increasing the human asset
in size, while training of employees is aimed at improv-
ing the quality of the human asset. Other business processes
modify assets even when they are not explicitly aimed at
assets management. For example, people participating in
a particular process acquire experience, which changes the
quality of the human asset. Sometimes, this change can be
far greater than the one achieved by training. Other assets
that can change while employees participate in a business
process include attitudes and beliefs toward other assets
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 671
engaged in the process, e.g., equipment, management, EXT,
etc. Note that expressions like “an asset is used in a process”
or a process is “using an asset” above have a broad mean-
ing. Namely, they mean that BPIs of the given process
type cannot run without such an asset being at their dis-
posal.
From the discussion above, it follows that there can be a
duality in the relationships between a process and an asset.
An asset can be “used” in BPIs of the given process type and
at the same time be changed during its usage in an impor-
tant aspect that increases its value. Whether only one or both
relationships—“used in” and “changed by”–are to be rep-
resented (if both exist) in a model depends on the purpose
of the model. Other issues of multiple relationships between
process and assets are discussed in Sect. 4.5.
4 A fractal enterprise model (FEM)
4.1 The structure of the model
Our fractal enterprise model (FEM) includes three types of
elements: business processes (more exactly, business process
types), assets, and relationships between them, see Fig. 2in
which a fragment of a model is presented.7Graphically, 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 relationships
allow tying up processes and assets in a directed graph.
In FEM, a label inside the oval names the given process,
and a label inside the rectangle names the given asset. Arrows
are also labeled to show the type of relationships between 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,equipment, etc. A label of an arrow
pointing from a process to an asset identifies the way in
which the process affects (i.e., change) the asset. In FEM,
an asset is considered as a pool of entities capable of playing
the given roles in the 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.
7This is a fragment of a model for an educational institution built in
our case study and discussed in Sect. 6. Here this fragment is used just
for explaining the syntax of FEM.
As it will be shown in Sect. 6, 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.
Also, 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 borders of ovals,
rectangles and arrows 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. Example
of using styles will be presented in the next sections.
Labels inside ovals, which represent processes, and rec-
tangles, which represent assets, 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 represent the relationships between processes
and assets, however, can be standardized. This is done by
using a relatively abstract set of relationships, like workforce
and acquire, which are clarified by the domain- and context-
specific labels inside ovals and rectangles. Standardization
improves the understandability and interoperability of the
models.
To make the work of building a fractal model more sys-
tematic we introduce archetypes (or patterns) for fragments
from which a particular model can be built. An archetype
is a template defined as a fragment of a model where labels
inside ovals (processes) and rectangles (assets) are omitted,
but arrows are marked, see, for example, Fig. 3. Instantiating
an archetype, means putting the fragment inside the model
and labeling ovals and rectangles; it is also possible to add
elements absent in the archetype, or omit some elements that
are present in the archetype.
We introduce two types of archetypes, process-assets
archetypes and asset-processes archetypes. A process-assets
archetype represents which kind of assets that can be used in
a given category of processes. An asset-processes archetype
shows which kinds of processes are aimed at changing the
given category of assets.
Note that the fractal model does not represent direct rela-
tionships between business processes, such as generalization
or composition. On the level of abstraction accepted for the
fractal model, a process with all its possible subprocesses is
considered as one business process.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

672 I. Bider et al.
Fig. 2 A fragment of a fractal
enterprise model from Sect. 6
4.2 The generic archetype
We define several process-assets archetypes, starting with a
generic archetype that shows asset types that can be used in
any kind of processes. The generic process-assets archetype
is presented in Fig. 3. It has a process symbol (oval) as its
root and shows which type of assets can be used in a process
via labels on the arrows going from rectangles to the oval.
We identify the following assets for the generic archetype:
1. Workforc e —people trained and qualified for employment
in the process. Examples: workers at the conveyor belt,
physicians, researchers.
2. EXT —process execution template. This can, for exam-
ple, be: a software development methodology accepted in
a software vendor company; product design for a manu-
facturer; technological process design, also for a product
manufacturer; description of the service delivery pro-
cedure, e.g., a process map for a service company. As
discussed in Sect. 3, EXT represents the control elements
type of assets. Note that here EXT refers only to the
knowledge in its explicit form, other parts of EXT, for
example tacit knowledge of workers, are incorporated in
other type of assets, e.g., workforce. Note also that EXT
does not need to be in a form of a procedure or algorithm.
For example, a policy document on equal opportunities in
recruitment of staff is regarded as an EXT for the recruit-
ment process. In addition, this document could be used
as an EXT for developing an execution template for the
recruitment process. The same consideration concerns a
value proposition asset, for example, in the form of a
statement on what kind of value a customer gets from
a given service. This asset can be used as an EXT for
the service delivery process, and as an EXT for devel-
oping the service process itself. In the same way, the
value proposition for a product could be used as an EXT
in the product development process (e.g., the product
should include certain functionality), and in the technol-
ogy development process (e.g., high quality, or low cost
of production).
3. Partner—an agent, external to the given organization,
who participates in the process. This, for example, can
be a supplier of parts in a manufacturing process; a lab
that completes medical tests on behalf of a hospital. Part-
ners can be other enterprises or individuals, e.g., retired
workers that can be hired in case there is a lack of a skilled
workforce for a particular process instance.
4. Stock—a stock of materials or parts that are used in the
process. This, for example, can be: office products, e.g.,
paper, pens, printer cartridges, in any office, or spare parts
for a car repair shop. A stock needs to be represented in
FEM only if the organization itself maintains the stock,
and does not directly get materials or parts from the sup-
plier for each process instance. In the latter case, it is
enough to represent a supplier as a partner.
5. Technical and Informational Infrastructure—equipment
required for executing the process. This, for example,
can be: a production line, computer, communication line,
building, software system.
6. Organizational Infrastructure—a unit of organization
that participates in the process. This, for example, can
be: sales department, software development team.
7. Means of Payment—any kind of monetary fund that is
needed to pay participating stakeholders, e.g., suppliers
if such payment is considered as part of the process. We
use a double line border for presenting this asset to show
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 673
that it belongs to the monetary assets. This might be con-
venient for finding all places in FEM where money is
involved.
Below we provide some additional clarification on the list
of assets above.
•The order in which the asset types are listed is arbitrary
and does not reflect the importance of assets of a given
type, all of them are equally important.
•There is no limitation to how many assets of a given
type (connected by an arrow with a given label) could be
connected to a given process. For example, there can be
several different categories of people participating in the
process and several types of suppliers.
•Our notion of asset does not coincide with the one
accepted in the world of finance [23]. Except the stock,
technical infrastructure and means of payment, all assets
listed above belong to the category of so-called intangible
assets of the finance world. Intangible assets usually lack
physical substance and their value is difficult to calculate
in financial terms. Technical infrastructure belongs to the
category of fixed (i.e., aimed at long term usage) tangi-
ble assets. Stocks and means of payments belong to the
category of current tangible assets.
•The following two types of assets—workforce and
partners—belong to the category that we call stake-
holders. We differentiate them by the role they play in
business processes. The workforce directly participates in
the process instances and receives compensation for their
participation (e.g., in the form of salary). Partners provide
the processes with resources needed for process instances
to run smoothly, e.g., electricity (power provider), mate-
rials, parts, advice. We use diamonds at a starting point of
arrows to differentiate stakeholders from other types of
assets. This is useful when considering other processes
related to stakeholders.
•As discussed in Sect. 3, organizational knowledge is an
important asset that is needed for running any business.
However, we do not include it in the generic process
archetype as such, as this asset is incorporated in other
types of assets present in the archetype. Explicit knowl-
edge related to running BPIs is included in EXT (#2 in
the list above). Tacit knowledge is included in Wor k -
force (#1 in the list above), as we consider workforce
not as a collection of people, but as trained and experi-
enced workers that have knowledge on how to execute
the BPIs in which they participate. Some knowledge can
be embedded in assets of the type Technical and Informa-
tional Infrastructure (#5 in the list above). For example, a
software system aimed at supporting people in executing
BPIs of the given process type embeds operational knowl-
edge about this process. Also, we do not require that a
list of assets included in the generic archetype cover all
kinds of organizational knowledge. Specific types of such
knowledge can be included when the generic archetype
is being specialized. Some examples of such specializa-
tions are presented in the next subsections.
4.3 The primary process-assets archetype
We define a primary process as a process that (a) delivers
value to some of the enterprise’s external stakeholders (b)
for which the same or other external stakeholders are willing
to pay. Typical examples of primary processes are: delivery
of goods from the stock, product manufacturing on demand
and service delivery. A primary process in our model may
or may not be the one that creates the value delivered to a
stakeholder. In case of the service delivery, a primary process
also creates the value. In case of delivering manufactured
products from the stock, the manufacturing process, which
actually creates value, in our classification, is considered as
a supporting process. Note also, that value creation could
be spread through the chain of processes. For example, for
innovative products, the product design process is the one
that creates most of the value.
Our definition of the term primary, sometimes called main
or core, is not be the same as those of others [27,59]. For
example, we consider as primary processes neither sales nor
marketing processes, nor product development processes in
a product manufacturing company. Our definition of the pri-
mary also does not correspond to the one of Porter [53], who
distinguishes between primary—value creating—processes
and supporting processes.
The notion of primary process as a value delivery process
is introduced in order to define a root (or several roots) from
which to recursively discover other processes. This notion
does not represent the importance of these kind of processes
against the supporting processes. It is essential that both con-
ditions, (a) value delivery, and (b) payment, are satisfied for a
process to be considered as primary. For example, a market-
ing or sales process can provide “educational” value to some
organizations by informing them about a specific class of
products or services of which they previously had no knowl-
edge. However, as the enterprise is not getting paid for such
an “educational” service, we do not consider the processes
providing them as primary.
As already discussed in Sect. 1, when using the term enter-
prise in FEM, we mean not only for-profit organizations,
but also non-for-profit ones and public offices. As far as pri-
mary processes are concerned, a difference between for-profit
organizations and others is that for the former, normally, a
customer both receives value and pays for it, but for the latter,
receiving value and paying stakeholders may differ.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

674 I. Bider et al.
Fig. 3 The process-assets
archetype for generic process
Fig. 4 The process-assets archetype for primary processes
Fig. 5 An example of instantiation of the process-assets archetype for primary processes
The archetype for the primary process is presented in Fig.
4; it is obtained by specialization of the generic archetype
from Fig. 3. By specialization, we mean adding new assets
types to an already introduced archetype. In the case of the
archetype of the primary process in Fig. 4, it differs from Fig.
3by the presence of an additional asset, namely:
8. Beneficiary—an organization or person that receives
some value from the process, for which the beneficiary or
somebody else is ready to pay. A typical beneficiary is a
customer8who buys goods and/or services and pays for
them. There can be more than one beneficiary in a given
process. A beneficiary is also considered to be a stake-
holder of the process, which is shown by the diamond as
the starting point of the arrow connecting the beneficiary
to the process in Fig. 4.
Instantiation of an archetype is done by inserting labels
inside the oval and rectangles. As there can be more than one
8In some works all beneficiaries are considered as customers. We
prefer to differentiate between these two terms, to avoid engagement in
a terminological discussion not relevant to the issues of this paper.
asset of the same type used in the given process, instantiation
can also result in adding more rectangles by “multiply-
ing” some relationships between the process and assets it
uses. This is different from specialization, which adds new
types of relationships between a prototypical process and its
assets.9
Figure 5is an example of an instantiation of the archetype
from Fig. 4for an on-demand-based manufacturing process.
Note that this instantiation has been built for the purpose of
illustration only; it does not show the full complexity of the
process-assets, as there can be many assets of each given type.
The instantiation has been done based on our understanding
of the structure of a modern enterprise acquired partly from
our own consulting practice, partly from the existing body of
literature.10
9In principle, adding new types of assets when creating an instantiation
is allowed. However, conceptually, such instantiation can be considered
as consisting of two steps: pure specialization and then instantiation.
10 Designing a detailed procedure for instantiating archetypes is
beyond the scope of this work. This issue is discussed in more detail in
Sect. 8.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 675
4.4 The asset-processes archetype
In Sects. 4.2 and 4.3, we introduced eight types of assets
that are needed to ensure that BPIs of a primary process
run smoothly and with required frequency. Each asset type
requires a package of supporting processes to ensure that it
is ready to be employed in BPIs of the primary process. We
present this package as consisting of three types of processes
connected to the life cycle of each individual asset (see Fig.
6):
1. Acquire—processes that result in the enterprise acquiring
a new asset of a given type. The essence of this process
depends on the type of asset, the type of the process(es)
in which the asset is used and the type of the enterprise.
For a product-oriented enterprise, acquiring new cus-
tomers (beneficiary) is done through marketing and sales
processes. Acquiring skilled work force is a task com-
pleted by a recruiting process. Acquiring anewEXTfor
a product-oriented enterprise is a task for a new product
and new technological process development.
2. Maintain—processes that help to keep existing assets in
the right shape to be employable in the BPIs of a given
type. For customers, it could be customer relationship
management (CRM) processes. For workforce, it could
be training. For EXT, it could be product and process
improvement. For technical infrastructure, it could be
service.
3. Retire —processes that phase out assets that no longer
can be used in the intended process. For customers, it
could be canceling a contract with a customer that is no
longer profitable. For EXTs, it could be phasing out a
Fig. 6 Asset-processes archetype
product that no longer satisfies the customer’s needs. For
the workforce, it could be actual retirement.
An instantiation of the asset-processes archetype is done by
putting labels in the rectangle and ovals of the archetype. An
example of instantiation of the asset-processes archetype for
asset customers from Fig. 5is presented in Fig. 7. As with Fig.
5,Fig.7is just an illustration; the actual fragment of the FEM
related to customers might be much more complex. As can be
seen from this example, there can be two or more processes
attached to an asset with the same label. Both marketing and
sales are aimed at bringing more customers to the company,
marketing by attracting potential customers, sales by making
a potential customer to a real one by, e.g., signing a contract.
4.5 Unfolding the fractal structure of the enterprise
Based on the archetypes introduced in the previous sections,
we suggest the following procedure of finding processes that
exist in an organization.
1. We start with the primary processes, i.e., the processes
of which, usually, people working in the organization are
well aware, as they are essential for the cash flow.
2. For each primary process, assets that are needed for its
regular execution are listed by following the primary
process-assets archetype from Fig. 4. In this way, we get
a root (or roots if there is more than one primary process
of interest) of a FEM tree to expand in the subsequent
steps.
3. For each asset identified earlier, we identify processes
aimed at acquiring, maintaining and retiring the given
asset according to the asset-processes archetype from Fig.
6. This will expand the already built FEM tree (or forest)
with new “leaves”. For example, by attaching the frag-
ment from Fig. 7to the FEM from Fig. 5, we arrive at an
extended FEM presented in Fig. 8.
4. For each supporting process identified in 3, we iden-
tify assets that are needed for its execution. This can be
done by using the generic process-assets archetype to find
assets that are applicable to any kind of processes. After
all assets that are prescribed by the generic archetype
Fig. 7 An example of
instantiation of the
asset-processes archetype
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

676 I. Bider et al.
Fig. 8 Extending FEM—example
are found, an attempt is made to find assets specific for
the given process type (not prescribed by the generic
archetype). This can be done by asking questions, such as
“what else is needed to run the instances of this process
type?”. For some supporting processes, however, it is pos-
sible to define specific archetypes, which will be done in
the next section.
5. Go to step 3 for the next level of expansion, or stop if the
so far built FEM is adequate for the purpose for which
the model is being built.
The above procedure begins with a primary process for build-
ing a FEM. However, this starting point is not mandatory. One
can start at any place in a model and expand it down and/or
up. For example, one can start with a particular asset, e.g.,
employees, and find all supporting processes for it. The start-
ing point and decision where to stop depends on the purpose
for which the model is being built. To find all, or a majority,
of the processes in the given organization, one can use the 5-
step procedure defined above. To identify problems related
to the quantity and quality of workforce asset, it might be
enough to find and make an overhaul of all processes related
to this particular asset.
There are other issues that can affect what the final FEM
model would look like. One of them is the granularity of the
model. For example, having a supplier of some materials or
parts can be presented in two ways. The first one is having
a stock of parts which is maintained by special processes
of purchasing them from the supplier. The second way is
by just having a supplier as a partner in the process. Which
alternative to choose depends on the purpose of modeling.
For example, if we want to investigate all processes related to
stocks of materials or parts, we need to have stocks explicitly
defined in the model. If, on the other hand, we are interested
in processes related to management of partners, we can skip
stock assets and represent suppliers directly as partners in
the respective processes, independently of whether the stocks
exist in reality or not.
Using the unfolding procedure as above, we, potentially,
can get an infinite tree. As the idea of having such a tree
contradicts common sense, there should be some natural
stopping points. We see several stopping points that harness
the growth of the tree, beside the stops influenced by the pur-
pose of modeling which may not require expansion beyond
the area of interest. Examples of such stopping points are as
follows:
•Some processes, e.g., maintenance of infrastructure, can
be outsourced to a partner. In this case, the maintenance
process subtree of FEM can be represented in a simplified
form, having only one asset connected to the process—
partner who takes care of all work to be done in the
process.
•Some processes can share assets, e.g., workforce or EXT.
For example, recruiting of staff can be done according
to a generic procedure (i.e., EXT) independent from for
which processes the employees are recruited.
•Some processes can be of dual purpose and thus can be
placed in several places of the model. For example, the
consulting business of a software vendor can be consid-
ered as both a primary process, as it generates revenues,
and as a customer maintenance process as it helps to
ensure the customers’ continuing usage of the software
products. Another example, if a primary process directly
brings money to the company, e.g., order delivery that
includes charging and accepting fee, this process will
appear as a supporting process of type acquire for the
asset monetary funds, see Sect. 4.7 for a graphical pre-
sentation of this case. More examples on dual-purpose
processes and assets see in Sect. 6.4. Dual usage of
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 677
Fig. 9 Process-assets archetype for acquiring stakeholders
processes and assets means that the result of the unfold-
ing procedure is neither tree, nor a forest but a directed
graph of generic type.
•Some supporting processes may not exist in the organi-
zation in the sense that the needs for starting a process
instance arise rarely and are handled in an ad hoc manner.
For example, a small start-up may not have any routines
of hiring people until it gets bigger.
4.6 Archetypes for supporting processes
In the same way as we have done for primary processes, we
can specialize the generic process-assets archetype from Fig.
3for supporting processes. This is difficult (if ever possible)
to do in a general manner, thus the specialization is done
separately for each type of asset. In Fig. 9, we represent an
archetype for a process of acquiring stakeholders, e.g., cus-
tomers. This archetype can be applied to any acquire process
that is related to an asset that in its own turn is connected
by an arrow with a diamond starting point to some process.
An example of a place in Fig. 8where the acquire stakehold-
ers archetype can be applied is the Sales process, which is
an acquire process for customers—stakeholders of a primary
process. It can also be applied for acquiring other stakehold-
ers, e.g., recruiting employees, or finding suppliers.
As follows from Fig. 9, the archetype of acquiring stake-
holders has two additional placeholders for assets beyond the
ones that already exist in the generic archetype from Fig. 3:
•Attraction—For a customer, for example, it could be
a value proposition, i.e., a statement of benefits that a
customer will get by acquiring certain products and/or
services. For recruiting staff it could be salary and other
benefits that an employee receives. There can be more
than one parameter in the attraction, each of which can
be represented by a different asset connected by the
attraction arrow to the process. For example, beside a
competitive salary, an environment with a modern tech-
nical and information infrastructure can be considered as
an asset for recruiting talents. The latter is an example of
the same asset serving multiple purposes in the enterprise,
which is reflected in FEM by having it in several places of
the processes-assets structure. Another example, as was
already mentioned in Sect. 4.2, asset value proposition
as a statement of benefits for the customer can be used
as an EXT in the product/service development process,
and/or as EXT for the service delivery process.
•Reputation—is evidence that the attraction has been ver-
ified by experience, for example, by others who already
are, or have been stakeholders of the given type. We mark
this asset with a dashed border to differentiate it from
other asset types. We refer to such assets as experience-
based data on enterprise functioning. Reputation is not
the only asset that is of the experience-based data type.
Experience-based data, for example, could also be used as
an asset for business process improvement, which in FEM
terms is considered as a maintenance process for EXT
(EXecution Template). In this case, the experience-based
data is equivalent to process performance measurements.
An example of using the acquire stakeholders archetype is
presented in the Sect. 6. We believe that it is possible to define
other archetypes for supporting processes, but this task is
beyond the scope of this paper.
4.7 Layout of the model
If we strictly follow the unfolding procedure from Sect. 4.5,
we will get a layout where the arrows always point upwards,
i.e., from assets to a process that uses them, or from the sup-
porting processes to the assets they are aimed at managing.
This type of layout is not mandatory; it is possible to draw an
arrow that points downwards, for example, from the process
to an asset it manages. Suppose we have a primary process
that includes receiving payment for goods or services deliv-
ered. Besides considering it as a primary process that satisfies
the beneficiary(ies), this process functions as a supporting
process of acquiring monetary funds. The situation can be
represented in two ways as shown in Fig. 10.Ontheleft-
hand side, all arrows point upwards; on the right-hand side,
the arrow to the monetary fund points downwards. Which
layout to choose depends on the model’s purpose and which
one is easier to understand. For example, if monetary funds
are the focus, then the left-hand layout is more suitable than
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

678 I. Bider et al.
Fig. 10 Different layouts for the same fragment of the model
the right-hand one. If the processes are the focus, then the
right-hand layout could be more suitable.
We can mix upwards and downwards arrows even when
defining archetypes. For example, we could add an additional
monetary asset to the primary process archetype of Fig. 4,
which would concern getting payment from a beneficiary.
Note, however, that it is not mandatory that the payments are
formally coming from each primary process. For example,
the customer may pay for a service through subscriptions fee,
which will be part of the customer management rather than
the primary process of service delivery.
Another problem that arises when deciding on the lay-
out is that the same element of a model, i.e., a process or
asset, may be used in several places. This problem is illus-
trated in Fig. 11 where asset Office is used in two processes,
one as an infrastructure that supports process p1, the other
one—as an attraction for recruiting workforce. The meaning
of the second usage is the office building being very modern
and convenient, which may attract the potential candidates to
accept a position in such an office. Figure 11 shows two alter-
native layouts for such a model. In the left-hand layout the
office rectangle is connected to both processes. In the right-
hand layout there are two rectangles that represent the office
asset, but they are connected by a dotted double arrow that
shows that these two rectangles represent the same asset. We
consider the second alternative to be preferable, especially if
the model development is supported by some computerized
tool. In the latter case the dashed arrows can be shown on
demand and not be present all the time.
4.8 FM meta-model
In this subsection, we summarize the material presented
in Sect. 4by drawing a simplified meta-model of FEM.
The overall structure of FEM graphs can be represented
by Fig. 12, in which nodes are represented by rectangles,
relationships—by open arrows, labels on the relationships—
by ovals. In addition elements of the graph can be specialized
which is shown via arrows. Note that the diagram on Fig. 12
does not follow any standard notation for representing con-
ceptual models, but can easily be converted, for example to
an UML class diagram. Note also that the nodes of the FEM
graphs are labeled, which is not represented in the meta-
model as there are no constraints on choosing labels of the
nodes.
We do not present a meta-model of an archetype in a
separate diagram, as it has the same structure as a FEM
graph except that its nodes are not labeled. A node of a
FEM graph satisfies an archetype if its neighborhood can
be “obtained” by assigning labels to the nodes.11 Archetypes
can be arranged in a hierarchy through specialization, where
specialization is done by extending a more general archetype.
The hierarchy of the archetypes defined in this paper can be
represented in the following way:
•Archetype
–Generic process-assets archetype
•Primary process-assets archetype
•Acquiring stakeholders archetype
–Asset-processes archetype
The notions introduced in this section can be formalized, but
this task is beyond the scope of this paper.
5 Envisioned areas of usage for fractal enterprise
models
Below, we list several practical areas where a model connect-
ing all processes and assets in an enterprise and a procedure
for building such a model could be useful. This list is not
complete, and new areas can be added to it, some of which
are discussed in Sect. 8. Also, the order in which the areas are
listed is arbitrary and does not represent any kind of priority.
1. Producing a list of, if not all, then the majority of BPs
existing in an organization. Such a list can be used, for
example, for deciding which processes will be supported
by a new software system. This usage was one of the prac-
tical motivations for the current research, as discussed
in Sect. 1.1. Such a list could also be used as a basis
for prioritizing the processes when planning organiza-
tional change. In the latter case, the relationships between
the processes via assets could be of help, as prioritiz-
ing a process without paying attention to its connected
processes may result in the failure of the project (see dis-
cussion below).
2. As help in strategic planning for finding out all branches
of the processes-assets tree that require adjustments.For
example, when sales plans a new campaign that will bring
new customers, all assets required by the corresponding
11 The notion of “obtained” needs to be defined more exactly, but this
lies outside the scope of this paper; here we just want to illustrate how
our solution can be formalized.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 679
Fig. 11 Tw o alt e rna t iv es of
layout for a multipurpose asset
Fig. 12 Meta-model of FEM
graph
Process
Asset
Is used in
Supports
Acquire
Maintain
Rere
Stakeholder
EXT
…
Main process
Monetary fund Reputaon
Beneficiary Partner
Legend:
Node
Relaonship
Relaonship label
Generalizaon
Workforce
primary process should be adjusted to satisfy the larger
number of customers. This includes workforce, suppliers,
infrastructure, etc. The calculation itself can be done with
one of the known methods, e.g., SD [33]. This issue has
already been discussed in Sect. 1.1.
3. To prevent “organizational cancer”. The term has been
introduced in [30], p 57, to describe a situation when a
supporting process starts behaving as though it were a
primary one disturbing the balance of the organizational
structure. This is typical for IT departments that may start
finding external “customers” for software developed for
the internal needs. Placing each process on the FEM map
will make the goal of each process explicit. Processes
that have been identified as pure supporting processes
should focus on internal needs and are not allowed to
attract external customers, at least until the decision of
converting them to primary processes has been taken (see
the next item in this list).
4. As help in radically changing the direction. When all
supporting processes are mapped in a tree, it will be
easier for the enterprise to change its business activity
by picking up some supporting processes and converting
them to primary ones, while making appropriate adjust-
ments to the tree. For example, a product manufacturing
company could decide to become an engineering com-
pany. Such a decision can be made when manufacturing
becomes unprofitable, while the company still has a very
strong engineering department. An example of such a
transformation is described in [30], p. 74. Another exam-
ple comes from the experience of the first author who
worked for an US company that made such a transfor-
mation twice. The first transformation was from being a
software consulting business to a software product ven-
dor when the consulting business could not accommodate
the existing workforce. The second transformation was
the reverse of the first one; when a market for their line of
products suddenly collapsed, the company went back to
consultancy. The authors have a separate paper devoted
to this issue [28], which presents the models of transfor-
mations above.
5. To help in designing supporting process via pointing out
all places where a given asset is, or might be, used.As
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

680 I. Bider et al.
already discussed, many assets have multiple purposes,
which require special consideration when designing
processes to manage these assets. Missing some purposes
may result in the asset management processes producing
an asset that does not suit some of the purposes. The latter
creates a risk that the enterprise as a whole will not func-
tion satisfactorily. In more detail, this topic is covered in
the next section devoted to testing FEM.
6 Testing FEM: building a fractal enterprise model
for university teaching
To test whether a FEM can be built and be useful, we
completed a small scale project of building a FEM for the
department of the Computer and Systems Sciences of Stock-
holm University in which all authors worked at that time.
The research goals of the project were: (1) to test whether
such a model can be built with relatively few resources,
and (2) whether it would be considered useful by the peo-
ple who work in the organization, including managers and
teachers. Both goals are connected to the problem of creat-
ing an effective procedure discussed in Sect. 1.1. The first
goal is related to efficiency, the second one—to the qual-
ity of results. When testing usefulness, we concentrated on
area 5 from the previous section (dual use of assets and their
supporting processes).
In the subsequent sections we give the details of the
project, discuss the resulting FEM, and the opinions on its
usability from the potential stakeholders.
6.1 Project context
The context of the project was as follows:
•Organization. The project was completed in the depart-
ment of Computer and Systems Sciences (DSV). DSV
belongs to the Faculty of Social Sciences at Stockholm
University (SU) and carries out all types of academic
activities, i.e., undergraduate and postgraduate teaching
with about 5700 students, and research. It runs bachelor,
master, and doctoral programs in the fields of Computer
Science and Information Systems. It has about 280 staff
members including teachers/researchers and administra-
tive personnel. The primary business of DSV is teaching
and research. The focus of this study was on teaching
as a core business performed in the department. Thus
we started from teaching and learning as a primary busi-
ness process which aggregated all processes linked to
delivering knowledge to students. They included teach-
ing, examining and graduation. In the project, we also
investigated other business processes that are vital for
the successful execution of the primary business process.
•Team. The project involved two professional groups:
business domain experts and enterprise modeling experts.
The group business domain experts included senior staff
from both teaching and administrative units, such as the
director of studies, director of finance and administra-
tion, head of one academic unit, IT director, and senior
lecturers, some of them coordinators of several academic
programs. The group enterprise modeling experts con-
sisted of the authors of this paper.
•Tool. To build a model, we used a graphical tool called
Insightmaker [25]. Insightmaker is designed to support
building system dynamics and agent-based models and
run simulations. We have chosen this tool because it
supports the graphical shapes needed for FEM, and it
has several additional features that we found useful,
such as folders,ghosts and stories. The folders feature
allows wrapping a part of the model and making it fold-
able/expandable. The ghosts feature allows creating an
alias to a shape and using it instead of the shape in a dif-
ferent place; it also provides a simple way of finding the
source for a ghost. The ghosts feature solves the layout
problem for multipurpose assets and processes discussed
in Sect. 4.7. The stories feature permits creating a sce-
nario of unfolding the model in a stepwise way, which we
found convenient for presenting a model to the domain
experts.
6.2 Project execution
The project consisted of two phases:
1. Building a fractal enterprise model related to the educa-
tional activity of the department
2. Evaluation of the results
The model was built based on the procedure from Sect. 4.5
starting from the fragment in Fig. 13 that has Teaching &
Learning process as a root; this fragment was drafted based
on our own knowledge of the domain. When unfolding the
processes-assets structure further, we used semi-structured
interviews and document analysis. We interviewed nine busi-
ness domain experts, starting with the director of studies who
was the main senior person responsible for ensuring the suc-
cessful execution of the teaching and learning process. Based
on the initial interviews, the list of interviewees was extended
to the operational staff by obtaining the names of people
involved in supporting processes. Thus, the “unfolding” of
the interviewees followed the same principle as unfolding
the processes-assets structure.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 681
Fig. 13 The root fragment from which we started unfolding FEM
Gathering input from the operational staff who perform
the actual activities in various business processes, directly
or indirectly related to teaching and learning, increased our
understanding of the details of these processes. This under-
standing was complemented via document analysis. The list
of documents for analysis was obtained by explicitly asking
for relevant documents during the interviews. The interviews
protocols and documents were then analyzed and used for
building the FEM described in the next section.
The evaluation of the model was done by presenting the
model to our business domain experts (both teachers and
administrative staff), and conducting interviews with them.
The model was presented to each domain expert individually
using the stories feature of Insightmaker. The presentation
consisted of demonstrating the model to an expert according
to the unfolding procedure from Sect. 4.5. The story started
with identifying the assets needed by the primary process, in
this case teaching and learning, and then continued through
the steps of identifying acquire, maintain and retire processes
for individual assets. Upon finishing the demonstration with
a domain expert, a semi-structured interview was conducted
with him/her using an open-ended questionnaire to guide the
interview. The results of these interviews are summarized in
Sect. 6.4
6.3 FEM model for teaching and learning
The core part of the FEM model for teaching and learn-
ing is shown in Fig. 14. Actually, we worked with a more
extended root, depicted in Fig. 13, but we present here only
the activities more directly related to teaching and learning
as such.12 We omit financial consideration (e.g., payments
received from the Swedish government), office and teaching
facilities (rooms for teaching), partners, and some other parts
of the model. However, we believe that the remaining part
is sufficient to demonstrate the usefulness of the model with
respect to the fifth area defined in Sect. 5—discovering and
managing multi-purposed assets.
12 A more extended model is presented in [22]. However, the version
presented in the current paper is more developed and more internally
consistent.
The model depicted in Fig. 13 has a high level of granular-
ity.In it, the primary process teaching and learning represents
everything related to teaching and learning, including stu-
dents following a program from course to course, and
teachers giving a course in a particular subject. The latter
includes individual teaching and learning activities, like lec-
tures, tutorials, workshops, laboratories, project assignments,
and examinations. To successfully run the process of teaching
and learning, the following assets are of primary importance:
students, lectures, programs and instructional materials and
e-learning platform. These need to be synchronized with
each other so that the students’ level of preparedness and
aspirations are in synch with the programs, and the teach-
ers are able to successfully teach the programs using modern
tools. Achieving such synchronization will result in positive
experiences of the stakeholders participating in the process.
The latter can serve as an asset for some of the supporting
processes. In Fig. 14, we depict one such asset as the student’s
general opinion on the educational process in the department
(the rightmost asset attached to the primary process in Fig.
14). If needed, the teachers’ opinion could be introduced as
well. In addition, the general opinion of students could be
split into opinions on different issues—teachers, content of
the programs and courses, and e-learning platform.
On the next levels of Fig. 14, we present some of the
supporting processes aimed at managing the assets needed
for teaching and learning. We are not listing all processes
here, focusing only on the assets with multiple purposes.
The latter are introduced in the Insightmaker diagram using
ghosts. A ghost has the same label as the source asset or
process, but has a lighter filling color, than the one used in
the source shape.
6.4 Dual use of assets and supporting processes
As can be seen from Fig. 14, several assets are of multi-
purpose type, for example:
•The e-learning platform’s main usage is in the teaching
and learning process itself. However, it is also used in
the process of instructional materials development which
is an acquire process for another asset used in the pri-
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

682 I. Bider et al.
Fig. 14 FEM for teaching and learning
mary process of teaching and learning. In addition, the
e-learning platform can serve as an attraction to attract
students to enroll in the department’s programs, which
makes it an asset for the marketing process. The latter, in
turn, is an acquire process for the asset students needed
for the primary process.
•Assetprograms and instructional materials function as
EXT (EXecution Template) for the primary process
teaching and learning. At the same time it functions as an
attraction of having attractive programs and high quality
teaching materials in the marketing process, which, as
already mentioned above, is an acquire process for asset
students.
•The main usage of the asset lecturers is in the primary
process teaching and learning. At the same time, the
lecturers, more precisely their credentials, such as full
professors or Nobel Laureates, can be used as an attrac-
tion in the marketing process.
Identifying the multi-purpose assets is of importance for
designing business processes aimed at managing these assets.
To highlight this importance, we use the ghost processes
attached to the multipurpose assets. For example, in Fig.
14, the process develop and deploy e-learning platform is
repeated three times. This stresses the fact that the platform
should not only be adjusted to presenting the teaching mate-
rials to the students. It needs to be convenient for the teachers
to plan the courses and develop these materials without using
intermediaries, or any kind of coding. At the same time, the
platform also needs to have a modern look and feel to be able
to function as an attraction. Considering all three purposes
simultaneously will set a number of conflicting requirements
on the platform, and thus on the process of acquiring it
(independently of whether the platform is to be internally
developed or externally procured).
Currently, the e-learning platform employed in our depart-
ment functions more or less satisfactorily in the process of
teaching/learning. It is not sufficiently good for course devel-
opment, and it is not good enough to be used for attracting
students. This needs to be addressed in the processes of
acquiring, maintaining and retiring of the e-learning plat-
form.
In the model presented in Fig. 14, students are represented
only as an asset for the teaching/learning process, though they
undergo changes that, for example, make them more suitable
as workforce for employment. This fact is not represented in
the model due to it being developed for the university only;
thus, the model does not include processes that lie outside the
university. However, if a university has a policy of recruiting
its staff from its own graduates, the teaching learning process
can be also considered as a kind of acquire process for its
workforce asset.
6.5 Evaluation of the model
As already mentioned in the beginning of Sect. 6, the research
goal of the project was to answer the following two questions:
(1) to test whether a FEM model can be built with relatively
few resources, and (2) whether it would be considered useful
by the people who work in the organization. In the subsec-
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 683
tions below, we present our answers on these two questions.
Question 1 was answered based on our reflections after com-
pleting the project. The answer to question 2 was obtained
by demonstrating the model to our domain experts and inter-
viewing them immediately afterward according to the plan
presented in Sect. 6.2.
6.5.1 Reflections from the project
Building a FEM model for the educational process in the
department consisted of two main phases: investigation of
sources and the actual building of a fractal enterprise model.
Our reflections on these two phases are as follows:
1. Investigation of sources was the most difficult part. It
was completed through interviews and document analy-
sis. We interviewed nine business domain experts and
each interview took approximately 1h. The analysis of
the interviews took an additional 24h. The analysis of
documents took approximately 20 h. The investigation
and modeling phases were iterative. During the modeling
we also performed some follow-up interviews for further
clarification, which took at least 1 h. In total, interviews,
analysis of the interviews and document analysis took
approximately 80 h in a span of 2 months.
2. Applying the principles from Sect. 4to build a model for
education was relatively easy and straightforward com-
pared to conducting interviews. This took approximately
40 h. The work was guided by archetypes previously
developed in [14]. The major complications at this stage
were when we needed to adapt the archetypes from [14].
Using Insightmaker as a modeling tool greatly facilitated
our work. In particular, the ghost feature was of much
help in avoiding intersections of the arrows. The ghost
feature was also convenient for highlighting the presence
of multipurpose assets when demonstrating the model
to the domain experts. Another convenient feature when
presenting the model to the domain experts was the sto-
rytelling.
On the whole, it was not particularly difficult to identify the
major business processes and assets related to teaching and
learning processes and present them in the model to provide a
holistic view on business processes in the department. How-
ever, it was difficult to understand some of the processes and
assets that could be of importance. One of the processes that
we could not fully understand was the process for acquir-
ing “alumni society.” Despite the fact that the department
makes use of the alumni society as an asset for marketing,
it was not clear how, by whom and when the asset is cre-
ated and maintained in the department. This issue requires
further investigations with business domain experts. Another
part of the educational process that has not been captured in
the model concerns finances. It is very specific for Sweden,
and it is undergoing constant changes, which was one of the
reasons we decided not to investigate this part in detail.
From our experience, building a FEM model as such does
not require extensive resources. However, the initial effort
of understanding, to a sufficient degree, how a particular
enterprise operates may require both time and experience
of communicating with domain experts.13 Once one under-
stands sufficiently the operation of the enterprise in question,
the actual application of the archetypes to build a FEM is rel-
atively fast and straightforward.14
6.5.2 Feedback from the domain experts
The interviews with our nine business domain experts, which
directly followed the presentation of FEM, showed that our
model for educational activity was well understood and
appreciated by them. More specifically, there was good con-
sensus for the following questions:
•Whether it is important to make explicit all purposes of
all processes in the department. The results showed that
100 % (5 experts agreed and 4 strongly agreed) of the
business domain experts agreed that it was important to
make explicit all purposes of all processes in the depart-
ment.
•Whether the FEM model could be useful for explicating
business processes and their interconnection. The results
showed that 100 % agreed that the FEM model was useful
for explicating processes and their associated purposes.
•Whether a visual diagram that shows how all processes
in the department are interconnected could be useful for
business planning and development. The results showed
that eight experts agreed (5 agreed and 3 strongly agreed)
that a visual diagram that showed all processes in the
department and their interconnection would be useful for
business planning and development; one expert was not
sure. When asked why he was not sure, the expert said he
could only be sure after applying the diagram to practical
business development.
•Whether a visual diagram in the form of FEM could
be useful for business planning and development.The
results showed that 8 experts agreed (5 agreed, 3 strongly
agreed) that the presented way of depicting business
process interconnections was useful for business plan-
ning and development; again, one expert was not sure.
13 This is the case for building any kind of models in the Information
Systems domain.
14 Note that this was the first project of building a realistic fractal
enterprise model, and much time was spent on adjusting the modeling
technique itself.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

684 I. Bider et al.
Similarly, when asked why he was not sure, the expert
said he would be sure after applying the diagram in prac-
tice.
As multipurposeness of the assets and processes was the
focus of our test, we also asked the experts (informally)
whether they knew about the cases of multipurposeness of
assets/processes presented in our FEM. Most of them knew
about these cases, which came as no surprise as the model
was built based on the information they provided. However,
all of them agreed that having these facts in an explicit graph-
ical form offered several benefits. In our view, the fact that
the information revealed by the model already existed in the
tacit form does not diminish the value of the model. Actu-
ally, one of the aims of enterprise modeling is to gather tacit
knowledge spread all across the organization and present it in
an explicit form understandable for all stakeholders. It looks
like the experts we interviewed agreed with this view.
7 Comparison with other business process
architectures
A FEM model only includes resource-based relationships
between processes. In contrast, most process architectures
include additional relationships, such as trigger, flow, special-
ization and composition relationships, as defined by Dijkman
et al. [18]. A FEM model can, thus, be viewed as a partial
process architecture that includes all (or the major part of)
the processes in an organization but can be complemented
with additional process relationships.
In this section, FEM is compared and contrasted with a
number of other business process architectures. The com-
parison is based on three orthogonal dimensions of model
dependency, process relationship type, and domain depen-
dency, which are explained below.
Several business process architectures require an exist-
ing model on which the architecture can be based, i.e.,
they are model dependent. Examples of these are goal-based
architectures [18], such as Antón et al. [5]. Koubarakis and
Plexousakis [36], and Lee [41]; they all require an exist-
ing goal model to which the processes can be related. Other
examples are function-based architectures [18] that build on
a model of a function hierarchy, e.g., [1,60]. FEM, in con-
trast, is not model dependent, as having a model on which
FEM is based is not required.
The types of process relationships that may associate
processes vary between business process architectures. Gen-
eralization and composition relationships occur in several
architectures, e.g., the MIT Process Handbook [44]. Another
relationship is that of triggering, which specifies that one
process may trigger the execution of another process; this
relationship is common in action-based architectures [18],
e.g., [7,34]. FEM is based on indirect relationships between
processes mediated by objects according to the proposed
archetypes. In this sense, FEM is close to object-based busi-
ness process architectures [18], but while these can include
any kinds of objects, FEM is solely concerned with assets.
Therefore, we can consider FEM as belonging to the class of
object-based business process architectures.
Most business process architectures are domain indepen-
dent in the sense that they are not restricted to any particular
industry branch, such as car manufacturing or health care.
However, there are architectures that include domain-specific
processes, e.g., the MIT Process Handbook. FEM is domain
independent.
The relationships between processes in FEM can be
expressed in different architecture languages. In this paper,
we have not pursued this issue and only used an informal
diagramming technique. However, an interesting direction
for further work would be to investigate how an enterprise
architecture language, such as ArchiMate [40] that offers a
broad range of process associations, can be used for express-
ing these relationships.
Finally, to the best of our knowledge, there does not exist
much work on procedures identifying processes and their
relationships. In the works that exist, e.g., [19] mentioned
in Sect. 2.1, the main efforts are aimed at designing a well-
organized process architecture, while FEM primarily aims
at analyzing an organization and discovering its existing
processes, documented as well as undocumented ones.
8 Open issues
In this section, we identify and discuss open issues related to
FEM and the unfolding procedure that can serve as a basis
for planning future research.
8.1 Limited validation
The case presented in Sect. 6constitutes only a limited vali-
dation of FEM and the methodological support for building
FEM. The limitations concern several perspectives, e.g., only
one case has been investigated and only in relation to one
area of the envisaged usage (area 5 from the list in Sect.
5—multipurposeness of assets). We continue working on
validation trying to investigate more cases and in relation
to other areas from the list in Sect. 5.Inrelationtoarea
2 (strategic change of direction), we have investigated how
FEM can help in changing a business model as a reaction
to a problem or new opportunity in the market. During this
investigation [28], we analyzed one case of business model
transformation and built high-level FEM models for an orga-
nization before and after the transformation. We consider the
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 685
example as generalizable to a transformation model where
a primary process becomes a supporting process. We con-
tinue working in this direction looking for other patterns of
business model transformations.
In another study, we used the ideas from FEM to solve a
practical task that lies outside the areas listed in Sect. 5.The
task consisted of systematizing process documentation (e.g.,
process maps) obtained from multiple BPM projects in an
ad hoc manner. A simplified FEM was built to arrange the
documents related to the primary and supporting processes
identified during the investigation [35].
8.2 Limitations of the methodology support
The methodological support for building FEMs presented in
this paper is limited to a general procedure described in Sect.
4.5 (unfolding procedure) and a number of archetypes that
could be used in this procedure. Currently, it does not include
a set of rules for how to produce an instantiation starting at
a certain node of an already built fragment. The archetypes
themselves show “what to look for” but not “how to do it”.
Whether it is possible to extend the methodological support
for the procedure is an open question. Most probably, some
heuristic guidelines can be produced to cover the limitation
at a later stage. As far as the set of archetypes is concerned,
we believe that it can be extended through specialization; this
is one issue that we plan to investigate in future research.
For now, the limitation above sets some constraints on who
can use our solution. We believe that what is already devel-
oped could be sufficient for an experienced business analyst,
but not for a novice. Note that FEM with the unfolding pro-
cedure is not unique in this respect. Many known techniques
for enterprise modeling are born in this way, including the
popular business model canvas [50].
8.3 Dissemination and adoption
Design science research cannot on its own generate enough
test cases for statistical validation of an artefact/solution. This
can only be done by the industry adopting the solution. The
latter requires dissemination of results among practitioners
and devising a strategy to this end. Such a strategy should
identify a group of specialists to target, and channels through
which to transfer information about the new solution.
According to the classical works on the adoption and
diffusion of innovations [54], successful adoption requires
reaching a critical mass of adopters. To ensure that a criti-
cal mass is reached in the most effective way, efforts need
to be concentrated where the negative feedback can be
minimized, and the positive feedback maximized, which
should be observed when defining the targeted group. A
natural group for adopting our solution is management con-
sultants. However, traditional management consultants use
well-known methods and might not be interested in anything
new and non-traditional. Promoting our solution among them
has a risk of being rejected and receiving negative feedback.
Therefore, a more promising group to target is management
consultants already using non-traditional methods, especially
those that are based on systems theory, like casual loops dia-
grams, stock and flow diagrams and VSM (viable systems
model), as these methods and our FEM have the same roots.
As the target group is small relative to all management
consultants, and is spread all over the world, an appropriate
channel to reach them without spending too many resources
is via social media, using virtual groups that unite enthusi-
asts of non-traditional methods. Therefore we use a LinkedIn
group related to non-traditional methods, for example, Sys-
tems Thinking World [10] that has over 20,000 members
and Viable System Model [51] that has over 800 mem-
bers. Dissemination consists of (1) participating in the group
discussions, (2) publishing information about our research
papers and slides of presentation so that they are available
to the group members, (3) referring to these materials in the
discussions and private communications where appropriate.
So far, our efforts have produced some results of which we
are aware. For example, our ideas as published in [14]were
presented to the members of SCiO (Systems and Cybernet-
ics in Organizations) society [61] at one of their development
days, in connection to which a kind of extended conceptual
map of the FEM model has been created [38]. We plan to con-
tinue our dissemination efforts through social media using
already established channels and finding new ones.
8.4 “Reversed” archetypes
As defined now, the unfolding procedure allows moving
only in one direction, i.e., from a process to its assets and
then to the processes that support these assets. This consti-
tutes no hindrance if we start from the top, i.e., one of the
primary processes. However, if the process or an asset of
interest is in the middle of the tree and we want to know all
assets/processes around it without starting from the top, the
unfolding procedure will be insufficient. The question arises
whether it is possible to define archetypes that allow moving
in the opposite direction, i.e., from an asset to all processes
that use it, or from a process to all assets it supports. Such
archetypes cannot be obtained by “reversing” the currently
defined ones, thus a special investigation should be made to
define them. This investigation lies in our nearest plans for the
future. Currently, it is not clear how many reverse archetypes
can be defined, though their existence can be demonstrated
with the following example. Consider an asset Aused as an
execution template (e.g., a process diagram) for a business
process P, which means that A“hangs” on EXT relationship
between Pand A. Then it is possible that this asset can be
used in at least two other places of the FEM model:
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

686 I. Bider et al.
•As educational material for training personnel (to be)
engaged in process P, thus functioning as an asset to
the process of acquiring/maintaining a workforce for this
process;
•As design specification for building a software system to
support process P, thus functioning as an asset for the
process of acquiring/maintaining infrastructure for this
process.
8.5 Formalization
In this paper, FEM is defined and discussed on the concep-
tual level and in an informal way. This is sufficient for the
goal of testing the usefulness of the new modeling language.
As it seems that FEMs might be useful for practice, for-
malizing FEM becomes an important topic on the research
agenda. Formalization can be done according to the follow-
ing scheme. FEM is defined as a directed graph with two
types of nodes, processes and assets, where nodes of one
type are connected to the nodes of another type with a num-
ber of relationships. For such a graph to be considered as
a valid FEM, a neighborhood of each node should satisfy a
number of constraints in the form of patterns that correspond
to our archetypes. Though the task of formalization is beyond
the scope of this paper, Sect. 4.8 makes the first step in this
direction presenting a draft of a FEM meta-model.
8.6 Using FEM for achieving viability/adaptability
As discussed in Sect. 2.3, a fractal organization as defined
by [30] can be considered as a tool for achieving viabil-
ity/adaptability in the dynamic environment of today. Though
the motivation for designing FEM was different, we believe
that when built, it can be used for the same purpose. Vari-
ous processes discovered with the unfolding procedure are
connected to different parts of the external and/or inter-
nal environment of the enterprise. If participants of these
processes are entrusted to watch and report on changes in
their parts of the environment, it could create a set of effec-
tive sensors in the sense of [11] covering all aspects of the
enterprise environment. Connecting these sensors to firing
adaptation processes will close the “adaptation loop”. As
an example of the above, assume that the recruiting process
shows that it becomes difficult to recruit skilled workforce
for a primary process. This can prompt an investigative
process to find out the reason for these difficulties. It could
be that nobody is willing to learn such skills any more, or the
competitors are expanding and offer better conditions (e.g.,
salary), or the enterprise reputation as a good place of work
has been shattered. Based on the result of the investigation,
appropriate changes can be made in HR processes themselves
or in completely different parts of the enterprise.15
8.7 Strengths and limitations of FEM in discovering
processes
As discussed in Sect. 1.1, one of the motivations for devel-
oping FEM and the unfolding procedure was a problem of
identifying all processes in an organization, and their rela-
tionships, in an effective way. The resulting procedure is
aimed at finding the processes connected to the primary ones
via assets. The effectiveness of using the procedure, natu-
rally, depends on the experience of a business analyst who
uses it. An experienced business analyst might be able to find
a large number of processes using this procedure including
the ones that can be found by other methods. This especially
concerns supporting processes defined in [53] that could be
found by listing all assets and then looking for supporting
processes for each of the assets. Using the unfolding proce-
dure can also help to discover processes connected through
the value chain [53]. For example, if process P1produces
parts Ato be used in process P2and there is a stock where
these parts are stored, then a connection between these two
processes can be established as P2uses Aas an asset of type
stock, and P1functions as an acquire process for this asset.
However, as any other method of discovering processes
and connections between them, the unfolding procedure has
its own limitations. For example, it does not help in finding:
•Primary processes
•Subprocesses of a given process. For example, if process
P1produces parts that are used directly in process P2
without going to a stock, then the connection between
these processes cannot be discovered through the unfold-
ing procedure
•Adaptation processes discussed in the previous subsec-
tion. These might be better to discover following a VSM
view on an organization [9].
Another kind of relationship that FEM does not repre-
sent is relationships between EXTs of the generalization–
specialization type, especially if they are presented in the
form of process models. However, it might be possible to
include such relationship indirectly via a generalized EXT
(process model) serving as an asset for acquiring and main-
taining a specialized EXT.
The limitations as above means that for some practical
tasks there may be a need to use several frameworks, which
15 Note that adaptation processes themselves are not caught by the
unfolding procedure and lies in a different dimension than primary and
supporting processes depicted in FEM. This kind of processes are dis-
cussed in more details in [11].
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 687
brings forward a question of tying FEM with other frame-
works. An interesting approach toward such integration is
presented in the conceptual model by [38].
9 Concluding remarks
Patrick Hoverstadt in his paper “Why Business should take
Enterprise Architecture seriously” [31] highlights “the need
for an architectural model that provides business leaders with
a model of the enterprise that they can genuinely use to under-
stand how it operates”. Until this happens, the Enterprise
Architecture field will not be taken by business leaders as
seriously as it should. The most popular model notations, be it
from the field of Enterprise Architecture or Business Process
Management, so far, have not been able to satisfy this need.
Patrick Hoverstadt’s own suggestion, tested in his manage-
ment consulting practice, is a model based on Stafford Beer’s
Viable System Model (VSM). We believe that the fractal
enterprise model suggested in this paper could also satisfy
the need identified by Patrick Hoverstadt, at least partially.
The main arguments for the potential usefulness of FEM
for business development is its relative simplicity combined
with a sufficient expressive power to present interconnections
between different components of the enterprise architecture,
i.e., business processes and assets. The model shows depen-
dencies between the components on the same and different
levels, while it also identifies the usage of each component in
several places of the enterprise architecture. All this creates
a holistic view of the enterprise functioning. An additional
advantage of FEM is a possibility of building a model with
the requested granularity so that the modeling technique can
be used for both strategy and operational business develop-
ment. Also, there is no requirement to have the full model
before it can be used. It is possible to start at any place of
interest and unfold the fractal structure down and/or up from
this place. According to the test reported in Sect. 6, domain
experts have no problem in understanding FEM and its poten-
tial advantages. They also believe that FEM could be useful
for business development.
Summing up our experience, the FEM appears to have
good potential, but there is a need for more testing and fur-
ther development of the model and the unfolding procedure
as discussed in the previous section. There is also a need to
have a graphical tool dedicated to building fractal enterprise
models. Though Insightmaker proved to be satisfactory for
limited testing, it is a tool developed for a completely differ-
ent purpose, and thus it cannot be fully adjusted for FEM.
Acknowledgements The authors are grateful to our colleagues who
served as domain experts for the experimental part of the project.
Special thanks to Stefan Moller, Maria Bergholtz, Gustaf Juell-
Skielse, Tuija Lehtonen, Jan Moberg, Sofia Mattsson, Carina Bergholm,
Sundén Andrea and Joakim Snygg. The authors are also much in debt
to the anonymous reviewers whose comments helped to improve the
structure and readability of this paper.
Open Access This article is distributed under the terms of the Creative
Commons Attribution 4.0 International License (http://creativecomm
ons.org/licenses/by/4.0/), which permits unrestricted use, distribution,
and reproduction in any medium, provided you give appropriate credit
to the original author(s) and the source, provide a link to the Creative
Commons license, and indicate if changes were made.
References
1. Aitken, C., Stephenson, C., Brinkworth, R.: Process classification
frameworks. In: vom Brocke, J., Rosemann, M. (eds.) Handbook on
Business Process Management, vol. 2, pp. 73–92. Springer, Berlin
(2010)
2. Alter, S.: The Work System Method: Connecting People, Processes,
and IT for Business Results. Work System Press, Larkspur (2006)
3. Anderson, J., Donnellan, B., Hevner, A.R.: Exploring the relation-
ship between design science research and innovation: a case study
of innovation at Chevron. In: Helfert, M., Donnellan, B. (eds.)
Communications in Computer and Information Science, vol. 286,
pp. 116–131. Springer, Berlin (2012)
4. Andersson, T., Bider, I., Svensson, R.: Aligning people to business
processes experience report. SPIP 10(4), 403–13 (2005)
5. Antón, A., McCracken, W., Potts, C.: Goal decomposition and sce-
nario analysis in business process reengineering. In: Proceedings
of CAiSE. Utrecht, pp. 94–104 (1994)
6. Ashby, W.R.: An Introduction to Cybernetics. Chapman & Hall,
London (1956)
7. Auramäki, E., Lehtinen, E., Lyytinen, K.: A speech-act-based office
modeling approach. ACM Trans. Inf. Syst. 6, 126–152 (1988)
8. Baskerville, R.L., Pries-Heje, J., Venable, J.: Soft design sci-
ence methodology. In: DESRIST 2009, pp.1–11. ACM, New York
(2009)
9. Beer, S.: The Heart of Enterprise. Wiley, Chichester (1979)
10. Bellinger, G.: Systems Thinking World [Online]. https://www.
linkedin.com/grp/home?gid=2639211 (2010). Accessed 26 Aug
2015
11. Bider, I., Bellinger, G., Perjons, E.: Modeling an agile enterprise:
reconciling systems and process thinking. In: The Practice of Enter-
prise Modeling. LNBIP, vol. 92, pp. 238–252. Springer, Berlin
(2011)
12. Bider, I., Jalali, A., Ohlsson, J.: Adaptive case management as
a process of construction of and movement in a state space. In:
Demey,Y.T., Panetto, H. (eds.) On the Move to Meaningful Internet
Systems. OTM 2013 Workshops. LNCS, vol. 8186, pp. 155–165,
Graz, Austria. Springer, Berlin (2013)
13. Bider, I., Johannesson, P., Perjons, E.: Design science research
as movement between individual and generic situation-problem-
solution spaces. In: Baskerville, R., De Marco, M., Spagnoletti, P.
(eds.) Organizational Systems. An Interdisciplinary Discourse, pp.
35–61. Springer, Berlin (2013)
14. Bider, I., Perjons, E., Muturi, E.: Untangling the dynamic struc-
ture of an enterprise by applying a fractal approach to business
processes. In: Proceedings of PoEM 2012. LNBIP, vol. 134, pp.
61–76, Oslo, Norway. Springer, Berlin (2012)
15. Box, G.E.P., Draper, N.R.: Empirical Model Building and
Response Surfaces. Wiley, New York (1987)
16. Curran, T., Keller, G., Ladd, A.: SAP R/3 Business Blueprint:
Understanding the Business Process Reference Model. Prentice
Hall PTR, Upper Saddle River (1997)
17. Dietz, J.L.: The deep structure of business processes. Commun.
ACM 49(5), 58–64 (2006)
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

688 I. Bider et al.
18. Dijkman, R., Vanderfeesten, I., Reijers, H.A.: Business process
architectures: overview, comparison and framework. Enterp. Inf.
Sys. 10(2) (2016). doi:10.1080/17517575.2014.928951
19. Dumas, M., La Rosa, M., Mendling, J., Reijers, H.A.: Fundamen-
tals of Business Process Management. Springer, Berlin (2013)
20. Dunn, C., Cherrington, J.O., Hollander, A.: Enterprise Information
Systems: A Pattern-Based Approach, 3rd edn. McGraw-Hill/Irwin,
Boston (2004)
21. EARF: Enterprise Architecture Definition [Online]. http://samvak.
tripod.com/earf.pdf (2014). Accessed 5 Oct 2014
22. Elias, M., Bider, I., Johannesson, P.: Using fractal process-asset
model to design the process architecture of an enterprise: experi-
ence report. In: BPMDS 2014 and EMMSAD 2014. LNBIP, vol.
175, pp. 287–301, Thesalonniki, Greece. Springer, Berlin (2014)
23. Elliott, B., Elliott, J.: Financial Accounting and Reporting. Finan-
cial Times/ Prentice Hall, London (2004)
24. Fettke, P., Loos, P., Zwicker, J.: Business process reference mod-
els: Survey and classification. In: Business Process Management
Workshops, pp. 469–483. Springer, Berlin (2006)
25. Give Team: Insightmaker [Online]. http://insightmaker.com/
(2014). Accessed 12 Oct 2014
26. Green, S., Ould, M.: A framework for classifying and evaluating
process architecture methods. Softw. Process Improv. Pract. 10(4),
415–425 (2005)
27. Hammer, M., Stanton, S.: How process enterprises really work.
Harv.Bus.Rev.77(6), 108–118 (1999)
28. Henkel, M., Bider, I., Perjons, E.: Capability-based business model
transformation. In: Advanced Information Systems Engineering
Workshops. LNBIP, vol. 178, pp. 88–99, Thesaloniki, Greece.
Springer, Berlin (2014)
29. Hevner, A.R., March, S.T., Park, J., Ram, S.: Design science in
information systems research. MIS Q. 28(1), 75–105 (2004)
30. Hoverstadt, P.: The Fractal Organization: Creating Sustainable
Organization with the Viable System Model. Wiley, New York
(2008)
31. Hoverstadt, P.: Why business should take enterprise architecture
seriously. In: Gøtze, J., Jensen-Waud, A. (eds.) Beyond Alignment,
Systems, vol. 3, pp. 55–166. College Publishing, London (2013)
32. Hruby,P.: Model-DrivenDesign Using Business Patterns. Springer,
Berlin (2010)
33. Jackson, M.C.: Systems Thinking: Creative Holism for Managers.
Wiley, New York (2003)
34. Johannesson, P.: Representation and communication—a speech act
based approach to information systems design. Inf. Sys. 20, 291–
303 (1995)
35. Josefsson, M., Widman, K., Bider, I.: Using the process-assets
framework for creating a holistic view over process documentation.
In: Enterprise, Business-Process and Information Systems Model-
ing. LNBIP, vol. 214, pp. 169–183 (2015)
36. Koubarakis, M., Plexousakis, D.: A formal framework for business
process modelling and design. Inf. Syst. 27, 299–319 (2002)
37. Koliadis, G., Ghose, A.K., Padmanabhuni, S.: Towards an enter-
prise business process architecture standard. In: IEEE Congress on
Services—Part I, pp. 239–246. IEEE (2008)
38. Korycki, T.: Recursive Process-Asset Model [Online]. https://ku
mu.io/koryckaa/recursive-process- asset-model (2015). Accessed
26 Aug 2015
39. Lawson, H.W.: A Journey Through the Systems Landscape. Col-
lege Publications, London (2010)
40. Lankhorst, M. M., Proper, H. E., Jonkers, H.: The architecture
of the archimate language. In: Halpin, T., Krogstie, J., Nurcan,
S., Proper, E., Schmidt, R., Soffer, P., Ukor, R. (eds.) Enterprise,
Business-Process and Information Systems Modeling, pp. 367–
380. Springer, Berlin (2009)
41. Lee, J.: Goal-based process analysis: a method for systematic
process redesign. In: Proceedings of the Conference on Organiza-
tional Computing Systems, pp. 196–201. ACM, New York (1993)
42. Lind, M., Goldkuhl, G.: The constituents of business interaction—
generic layered patterns. Data Knowl. Eng. 47(3), 327–348 (2003)
43. Maglio, P.P.: Steps toward a science of service systems. Computer
40(1), 71–77 (2007). doi:10.1109/MC.2007.33
44. Malone, T.W., et al.: Tools for inventing organizations: toward a
handbook of organizational processes. Manag. Sci. 45(3), 425–443
(1999)
45. McCarthy, E.W.: The REA accounting model: a generalized
framework for accounting systems in a shared data environment.
Account. Rev. 57(3), 554–578 (1982)
46. McQueen, P.: Physics and fractal structures. J. Stat. Phys. 86, 1397–
1398 (1997)
47. Mercedes Canavesio, M.K., Martinez, E.: Enterprise modeling of
a project-oriented fractal company for SMEs networking. Comput.
Ind. 58, 794–813 (2007)
48. Nurcan, S., Rolland, C.: A multi-method for defining the organi-
zational change. J. Inf. Softw. Technol. 45, 2 (2003)
49. Osterwalder, A.: The Business Model Ontology: A Proposition
in a Design Science Approach. University of Lausanne Institut
d’Informatique et Organisation, University of Lausanne, Lausanne
(2004)
50. Osterwalder, A., Pigneur, Y.: Business Model Generation: A Hand-
book for Visionaries, Game Changers, and Challengers. Wiley,
Hoboken (2014)
51. Panagiotakopoulos, P.: Viable System Model [Online]. https://
www.linkedin.com/grp/home?gid=3680613 (2010). Accessed 26
Aug 2015
52. Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee, S.:
A design science research methodology for information systems
research. J. Manag. Inf. Syst. 24(3), 45–78 (2007)
53. Porter, M.E.: Competitive Advantage: Creating and Sustaining
Superior Performance. Simon and Schuster, New York (2008)
54. Rogers, E.M.: Diffusion of Innovations. Free Press, New York
(1962)
55. Ramanathan, J.: Fractal architecture for the adaptive complex enter-
prise. Commun. ACM 48(5), 51–57 (2005)
56. Rolland, C., Loucopoulos, P., Kavakli, V., Nurcan, S.: Intention
based modelling of organisational change: an experience report.
In: Proceedings of the Fourth CAISE/IFIP 8.1 International Work-
shop on Evaluation of Modeling Methods in Systems Analysis and
Design (EMMSAD’99), Heidelberg, Germany, June 14–15 (1999)
57. Ross, J.W., Weill, P., Robertson, D.C.: Enterprise Architecture as
Strategy: Creating a Foundation for Business Execution. Harvard
Business Press, Harvard (2006)
58. Sandkuhl, K., Kirikova, M.: Analysing enterprise models from a
fractal organisation perspective-potentials and limitations. In: Pro-
ceedings of PoEM 2011. LNBIP, vol. 92, pp. 193–207. Springer,
Berlin (2011)
59. Scheer, A.-W.: ARIS—Business Process Modeling. Springer,
Berlin (2000)
60. Scheer, A.W., Nüttgens, M.: ARIS architecture and reference mod-
els for business process management. In: Proceedings of Business
Process Management, Models, Techniques, and Empirical Studies,
pp. 376–89. Springer, Berlin (2000)
61. SCiO: SCiO—Systems and Cybernetics in Organisations [Online].
http://www.scio.org.uk/ (2011). Accessed 26 Aug 2015
62. Sein, M.K., et al.: Action design research. MIS Q. 35(1), 37–56
(2011)
63. Swenson, K.D. (ed.): Mastering the Unpredictable: How Adaptive
Case Management Will Revolutionize the Way That Knowledge
Workers Get Things Done. Meghan-Kiffer Press, Tampa (2010)
64. The open group: TOGAF Version 9.1 Enterprise Edition (2009)
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

A fractal enterprise model and its application for business development 689
Ilia Bider For a long time,
Ilia Bider has actively combined
research activities with practical
work, in the end settling down
in the academia as a Lecturer
at the Department of Computer
and Systems Sciences (DSV) of
Stockholm University to reflect
on his practical experience and,
if possible, transfer the knowl-
edge acquired to the younger
generation. Having background
in both engineering (M.Sc. from
a Moscow Technical University),
and science (Ph.D. from the
Swedish Royal Institute of Technology), he worked in practice in differ-
ent capacities, such as programmer, bugfixer, group and project leader,
technical and business consultant, functioning as an employee for oth-
ers, and as a cofounder of a Swedish consulting business called IbisSoft.
He used his practical experience as inspiration for research, and his prac-
tice as a testbed for new research ideas. Most of his published works
(rising to about 70) are, in one way or another, connected to his practical
work.
Erik Perjons Ph.D. holds a
position as senior lecturer at the
Department of Computer and
Systems Sciences (DSV), Stock-
holm University. His research
and teaching interest includes
areas such as enterprise mod-
eling, business process man-
agement, knowledge manage-
ment, and business intelligence,
but also research methodolo-
gies such as design science. A
main research focus has been to
design methods based on mod-
eling techniques and scientific
approaches for analyzing practical problems in organizations, and
designing business and IT solutions addressing these problems. He
has published over 70 publications in international journals and con-
ferences, participated in several domestic and international research
projects in domains such as health care, egovernment and telecom. He
has also a university exam in journalism and has worked as a journalist
at several Swedish newspapers, and as a media analyst, analyzing how
organizations and products are described in different media.
Mturi Elias was born in Serengeti,
Tanzania, in 1975. He received
his B.Sc. Computer Science
degree from the University of
Dar es Salaam, Tanzania, in
2001, and the M.Sc. Computer
Science degree from Osminia
Univerity, Hydrebad, India in
2004 and Ph.D. degree in Com-
puter amd Systems Sciences
from Stockholm University, Stock-
holm, Sweden, in 2015. He is
currently working with the Uni-
vesity of Dar es Salaam Comput-
ing Center as the Deputy Man-
aging Director. His current research interests include Business Process
Management, Enterprise Modeling, Enterprise Architecture as Platform
of conncted Government. Mturi works as a Technical Advisor on Health
Information Systems to the Ministry of Health and Social Welfare. He is
the current chair of the National eHealth Enterprise Architecture Tech-
nical Working Goup.
Paul Johannesson received his
B.Sc. in Mathematics, and his
PhD in Computer Science from
Stockholm University in 1983
and 1993, respectively. He holds
a position as professor at Stock-
holm University, where he works
in the area of information sys-
tems. Johannesson has published
work on federated informa-
tion systems, translation between
data models, languages for con-
ceptual modelling, schema inte-
gration, the use of linguistic
instruments in information sys-
tems, process integration, ecommerce systems design, and analysis
patterns in systems design. He has been a member of several EU projects
on knowledge based systems and requirements engineering. He has
been the project leader of and participated in several national projects
on information integration, the use of IT in teaching information sys-
tems design, process modelling and integration, and IT in health care.
He is the coauthor of textbooks on conceptual modelling and design
science.
123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.

1.
2.
3.
4.
5.
6.
Terms and Conditions
Springer Nature journal content, brought to you courtesy of Springer Nature Customer Service Center GmbH (“Springer Nature”).
Springer Nature supports a reasonable amount of sharing of research papers by authors, subscribers and authorised users (“Users”), for small-
scale personal, non-commercial use provided that all copyright, trade and service marks and other proprietary notices are maintained. By
accessing, sharing, receiving or otherwise using the Springer Nature journal content you agree to these terms of use (“Terms”). For these
purposes, Springer Nature considers academic use (by researchers and students) to be non-commercial.
These Terms are supplementary and will apply in addition to any applicable website terms and conditions, a relevant site licence or a personal
subscription. These Terms will prevail over any conflict or ambiguity with regards to the relevant terms, a site licence or a personal subscription
(to the extent of the conflict or ambiguity only). For Creative Commons-licensed articles, the terms of the Creative Commons license used will
apply.
We collect and use personal data to provide access to the Springer Nature journal content. We may also use these personal data internally within
ResearchGate and Springer Nature and as agreed share it, in an anonymised way, for purposes of tracking, analysis and reporting. We will not
otherwise disclose your personal data outside the ResearchGate or the Springer Nature group of companies unless we have your permission as
detailed in the Privacy Policy.
While Users may use the Springer Nature journal content for small scale, personal non-commercial use, it is important to note that Users may
not:
use such content for the purpose of providing other users with access on a regular or large scale basis or as a means to circumvent access
control;
use such content where to do so would be considered a criminal or statutory offence in any jurisdiction, or gives rise to civil liability, or is
otherwise unlawful;
falsely or misleadingly imply or suggest endorsement, approval , sponsorship, or association unless explicitly agreed to by Springer Nature in
writing;
use bots or other automated methods to access the content or redirect messages
override any security feature or exclusionary protocol; or
share the content in order to create substitute for Springer Nature products or services or a systematic database of Springer Nature journal
content.
In line with the restriction against commercial use, Springer Nature does not permit the creation of a product or service that creates revenue,
royalties, rent or income from our content or its inclusion as part of a paid for service or for other commercial gain. Springer Nature journal
content cannot be used for inter-library loans and librarians may not upload Springer Nature journal content on a large scale into their, or any
other, institutional repository.
These terms of use are reviewed regularly and may be amended at any time. Springer Nature is not obligated to publish any information or
content on this website and may remove it or features or functionality at our sole discretion, at any time with or without notice. Springer Nature
may revoke this licence to you at any time and remove access to any copies of the Springer Nature journal content which have been saved.
To the fullest extent permitted by law, Springer Nature makes no warranties, representations or guarantees to Users, either express or implied
with respect to the Springer nature journal content and all parties disclaim and waive any implied warranties or warranties imposed by law,
including merchantability or fitness for any particular purpose.
Please note that these rights do not automatically extend to content, data or other material published by Springer Nature that may be licensed
from third parties.
If you would like to use or distribute our Springer Nature journal content to a wider audience or on a regular basis or in any other manner not
expressly permitted by these Terms, please contact Springer Nature at
onlineservice@springernature.com