Content uploaded by Ilia Bider
Author content
All content in this area was uploaded by Ilia Bider on Aug 31, 2023
Content may be subject to copyright.
The final version was published and copyrighted by Springer
DOI: 10.1007/978-3-030-93547-4_10
Tool Support for Fractal
Enterprise Modeling
Ilia Bider1,2, Erik Perjons1, Victoria Klyukina1
1Department of Computer and Systems Sciences, Stockholm University, Stockholm, Sweden
2Institute of Computer Science, University of Tartu, Tartu, Estonia
{ilia | perjons | victoria.klyukina}@dsv.su.se
Abstract This chapter discusses the authors’ experience of building tool support
for a modeling technique called Fractal Enterprise Model (FEM) using the ADOxx
metamodeling environment. FEM is introduced as a means for helping the manage-
ment to comprehend how their organization operates, giving a picture in under-
standable for the management terms. FEM depicts 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 ma-
chinery, etc.) and intangible (reputation, business process definitions, etc.). First,
the paper presents FEM informally - as a text with examples, and formally - as a
metamodel. Then, the authors present the requirements on a tool support for FEM
and discuss how these requirements were fulfilled in a tool called FEM toolkit de-
veloped with the help of ADOxxx.
Keywords Enterprise modeling ● Fractal Enterprise Model ● FEM ● ADOxx,
1 Introduction
According to [1], modern organizations have become so complex that no one in the
management of an organization fully understand how it operates. The paper also
states that for Enterprise Architecture to be taken seriously, it should provide the
business with models that the management understands. The two terms in italic
from the above text constitute two requirements on the model that is needed for
providing management with reliable information for decision making:
1. Providing a holistic view on how the organization operates.
2. Being understandable for business people, which might not have any technical
or computer science background.
To the two requirements as above, we can add a third requirement that is related to
the fact that there might not exist a single person in an organization that has a ho-
listic view on all organizational operations. Thus, it would be helpful if a modeling
technique could:
3. Guide the modeler through the organization and its operational activities with
respect to what to look after and from whom to get information for building the
model.
There is a multitude of modeling techniques, some of which are used in practice,
others are used, mainly, in academia. Some of the techniques are widely popular,
such as Business Process Model and Notation (BPMN) [2], others are used by a
minority of business consultants, such as Viable System Model (VSM) [3].
Many of the existing techniques focus only on specific aspects of the company
operations, e.g., goals [4] or business processes [2]. Thus, they do not satisfy the
first requirement on providing a holistic view on the company’s operations. Other
techniques, like ArchiMate [5], come from IT world, and they are doubly satisfying
the second requirement of being understandable for business people. In addition,
they do not provide guidelines mentioned in the third requirement. In fact, one needs
to understand the business quite well to be able to draw a set of ArchiMate diagrams
that cover all parts of the business. Yet other techniques do not have good means
for visualizing specifics of a given organization, e.g., VSM [3]. In addition, VSM’s
guidelines for investigating the business are rather vague, thus, requiring certain
level of expertise from the modeler in order to build a model [6].
The factors listed above make the set of modeling techniques that satisfy all three
requirements relatively small. As an example of modeling technique that in our view
satisfies all requirements to a certain extent, we can name IDEF0 [7]. Though in the
last decades, it lost its popularity to more aggressively marketed modeling tech-
niques like BPMN [2] and ArchiMate [5].
Based on the deliberation above, we can conclude that today, there are a room
and practical needs for new modeling techniques that satisfy all three requirements
discussed above. This paper is devoted to one of such techniques, still under devel-
opment, and especially to the tool support for it that is being developed using the
ADOXX metamodeling environment [8].
The technique in question is called Fractal Enterprise Model (FEM) [9]. FEM
has a form of a directed graph with two basic types of nodes processes and assets,
where the arrows (edges) from assets to processes show which assets are used in
which processes and arrows from processes to assets show which processes help to
have specific assets in “healthy” and working order. The arrows are labeled with
meta-tags that show in what way a given asset is used, e.g., as workforce, reputation,
infrastructure, etc., or in what way a given process helps to have the given assets
“in order”, i.e., acquire, maintain or retire. Besides processes and assets, the latest
version of FEM includes two new types of nodes – external pools and external ac-
tors [10]. These are introduced to represent the environment outside the organiza-
tion, e.g, markets or competitors, and connect it to the internal processes.
The rest of the chapter is structured in the following way. In Section 2, we give
an informal overview of Fractal Enterprise Model. In Section 3, we discuss its se-
mantics, metamodel, and requirements on tool support. In Section 4, we discuss
FEM toolkit and its usage in practical and research projects. Section 5 contains con-
cluding remarks, and plan for continuing development of the toolkit and methodol-
ogy of using FEM in practical projects.
2 Fractal Enterprise Model
2.1 Informal Overview
In this section, we give an informal overview Fractal Enterprise Models (FEM) in-
troduced in our earlier works, especially in [9], and in the extended form in [10].
The basic version of FEM includes three types of elements: business processes
(more exactly, business process types), assets, and relations between them, see Fig.
1, in which a fragment of a model describing operational activities of a manufactur-
ing company is presented.
The example is taken from [11]. The case considered in this paper concerns Rob-
ert Bosch GmbH, Bamberg-plant, that manufactures different lines of products for
automotive industry, like spark plugs, fuel injection and sensors. These products
can be bought by companies, retailers or end-consumers for their usage. The com-
pany uses different machines for producing the products, like laser machines and
robots. In this paper, we refer to these machines as to sophisticated manufacturing
equipment.
The equipment requires maintenance, both periodical, and emergency mainte-
nance (i.e., when a machine stops working). The maintenance requires service tech-
nicians, machine process experts and robots’ providers (who are also partners in
providing spare parts, advice on maintenance, etc.). To improve effectiveness of
maintenance, the company has developed Diagnostic & Predictive Software that
helps to detect whether the equipment needs urgent maintenance and/or whether the
periodic maintenance can be postponed, as the equipment is still in a good shape.
To develop and support this software the company has a special software develop-
ment process and people engaged in it, which are called data scientists.
Returning to FEM, graphically, a process is represented in FEM by an oval, an
asset is represented by a rectangle (box), while a relation between a process and an
asset is represented by an arrow. We differentiate two types of relations in the fractal
model. One type represents a relation 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 rep-
resents a relation 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 relations allow
tying up processes and assets in a directed graph.
Fig. 1 A fragment of FEM for a manufacturing company
In FEM, a label inside an oval names the given process, and a label inside a
rectangle names the given asset. Arrows are also labeled to show the type of rela-
tions 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 or infrastructure. A label on an arrow pointing from a process to an asset
identifies the way in which the process affects (i.e., changes) the asset. In FEM, an
asset is considered as a pool of entities capable of playing a given role in a given
process. Labels leading into assets from processes reflect the way the pool is af-
fected, for example, label Acquire identifies that the process can/should increase the
pool size.
Note that the same asset can be used in multiple 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 plays multiple roles in the same process. In this
case, several labels can be placed on the arrow between the asset and the process.
Similarly, a process could affect multiple assets, each in the same or in different
ways, which is represented by the corresponding labels on the arrows. Moreover, it
is possible that a single process affects a single asset in multiple ways, which is
represented by having two or more labels on the corresponding arrow.
Labels inside ovals (which represent processes) and rectangles (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 relations between processes and assets) are standardized. This
is done by using a relatively limited set of abstract relations, such as Workforce or
Acquire, which are clarified by the domain- and context-specific labels inside ovals
and rectangles. Standardization improves the understandability of the models.
While there are several types of relations that show how an asset is used in a
process (see example in Fig. 1), there are only three types of relations that describe
how an asset is managed by a process – Acquire, Maintain and Retire.
Two new concepts were introduced to FEM in order to represent the business
context of the organization and connect it to specific processes [10]. These are as
follows:
External pool, which is represented by a cloud shape, see Fig. 1. An external pool
is a set of things or agents of a certain type. As an example, in Fig. 1, there is one
such pool – a pool of Companies that need the manufacturing products. The label
inside the external pool describes its content.
External actor, which is represented by a rectangle with rounded corners. An
external actor is an agent, like a company or person, acting outside the boundary
of the organization. The label inside the external actor describes its nature. If the
shade represents a set of external actors the box has a double line, see Fig. 1,
which has one external actor of this kind.
External pools and external actors may be related to each other and to other elements
of the FEM diagram. Such a relation is shown by a dashed arrow that has a round
dot start. More exactly:
A business process may be connected to an external pool with an arrow directed
from the pool to the process. In this case, the process needs to be an acquire
process to one or more assets. The arrow shows that the process uses the external
pool to create new elements in the asset for which this process serves as an ac-
quire process, see an example of such relations in Fig. 1.
An external actor may be connected to an external pool with an arrow directed
from the pool to the external actor. In this case, the arrow shows that the external
actor uses the external pool as bases for one of its own acquire processes, see an
example of such relations in Fig. 1.
A business process may be connected to an external pool with an arrow directed
from the process to the pool. In this case the arrow shows that the process pro-
vides entities to the external pool (there are no related examples in Fig. 1).
An external actor may be connected to an external pool with an arrow directed
from the actor to the pool. In this case, the arrow shows that one of the actor's
processes provides entities to the external pool (there are no examples of such
relations in Fig. 1).
Two pools can be connected to each other, which means that elements from one
pool can move to another based on external condition (there are no examples of
such relations in Fig. 1).
External pools and actors represent the context in which an organization operates,
i.e., its external environment. External pools can be roughly associated with mar-
kets, e.g., a labor market, etc. External actors represent other organizations that are
connected to the external pools. Dependent on the nature of the external pool, an
external actor connected to it can be a competitor, provider, or collaborator. Note
that an external organization can be an asset, e.g., partner or customer vs. an external
actor. The difference reveals itself in how the external organization is connected to
the internal processes; an external actor is always connected indirectly, i.e., via an
external pool. If needed, an arrow that connects an external pool to some other ele-
ment can be supplied with a label to clarify the condition on when or why the ele-
ments can be added to or withdrawn from the pool.
2.2 FEM Architypes
To make the work of building a fractal model more systematic, a FEM modeler can
use archetypes (or patterns) as 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 labelled. In-
stantiating an archetype means putting the fragment inside the model and labelling
ovals and rectangles; it is also possible to add elements absent in the archetype, or
omit some elements that are present in the archetype.
FEM has two types of archetypes, process-assets archetypes and an asset-pro-
cesses archetype. A process-assets archetype represents the kinds of assets that can
be used in a given category of processes. There are several archetypes of this sort.
Fig. 2 presents a so-called generic process-assets archetype, which can be applied
to any process. There are also specific process-assets archetypes [9], which will be
discussed in the next section.
The asset-processes archetype shows the kinds of processes that are aimed at
changing the given category of assets. There is only one such archetype, which is
presented in Fig. 3.
The whole FEM graph can be built by alternative application of these two types
of archetypes representing self-similar patterns on different scales, fractals. One
usually starts with a primary process – a process that produces value for an external
beneficiary, and continues down with finding assets needed for this process, and
then, finding supporting processes aimed at managing these assets. The term fractal
in the name of our modeling technique points to the recursive nature of the model
built with the help of alternating archetypes.
Fig. 2 A generic process-assets archetype
Fig. 3 Asset-processes archetype
2.3 Areas of FEM Application
As is explained in [9], the initial goal for FEM development was to find a way to
identify if not all, but at least the major part of the processes that exist in the enter-
prise. The result - FEM, however, was much more powerful, and it was envisioned
to be of help in multiple other areas. Though the initial goal has never been tested
in a practical project, indirectly, it was used in some projects to identify not all pro-
cesses in the company, but all processes that were relevant for a particular purpose.
Besides getting the relevant processes listed, using FEM helped to list relevant as-
sets used in the processes, which was at least as helpful as listing the processes.
Paper [9] envisioned several additional areas of usage for FEM. In this chapter,
however, we will not repeat this list, but discuss the areas for which FEM has been
tested. One additional area of application will be considered in Section 4. Other
suggestions for using FEM in practice can be found in [12].
2.3.1 Business Model Innovation
The idea of using FEM for industry level Business Model Innovation (BMI) [13]
was suggested in [14]. The industry level BMI concerns creating new products and
services for already existing or new markets. The idea of using FEM in BMI con-
sists of finding a supporting process in the existing business that can be converted
to a primary one in a new business. For example, a manufacturer can become a
designer by converting a supporting process of designing products for own manu-
facturing into a primary process of designing products to be manufactured by others.
This idea was further developed to include patterns for the industry level BMI,
which is discussed in [11,15]. Fig. 1 is adapted from [11] and the example of BMI
presented in it will be explained in more details later in this chapter.
2.3.2 Arranging Process Documentation
When an organization has not adopted a uniform and standardized way of producing
and storing process documentation, keeping track of and maintaining process doc-
uments can be a real challenge. There can be hundreds of documents and models
created at different times for various purposes, and related to different, but some-
times intersecting parts of the business. In such a case, finding a document related
to a specific process, or part of the business, can be a challenge.
FEM was tested as an organizing framework at a company that had more than a
hundred of process documents. A simplified FEM of the company was built, and
the existing documents were related to the nodes of this model. A test was conducted
with the management of the company whether they can find a process document, or
attach a new document to a right node. Both tests gave positive results. More on this
project, see in [16].
2.3.3 Structural Coupling
The concept of structural coupling comes from biological cybernetics, more specif-
ically, from the works of Maturana and Varela, for example, [17]. The idea of struc-
tural coupling is relatively simple; it suggests that a complex system adjusts its
structure to the structure of the environment in which it operates. The adjustment
comes from the constant interaction between the system and its environment. More-
over, during the system evolution in the given environment, some elements of the
environment and interaction with them become more important than others. The
latter leads to the system choosing to adjust to a limited number of environmental
elements with which it becomes structurally coupled.
The concept of structural coupling can be successfully used in the organizational
practice. For example, [18] suggests using structural coupling for defining and man-
aging organizational identity, while [19] defines enterprise strategy as achieving a
desirable position among the organization’s structural couplings. Using these ideas,
however, requires to find all structural couplings of an organization, which can be
a difficult task, especially for unexperienced people. In [10], we suggested to use
FEM of an organization to identify its structural couplings. The paper presents a set
of rules of how to identify the elements of the model - assets, external pools, and
eternal actors - as structural couplings. A structural coupling can be a customer (as-
set), a partner (asset), a competitor (external actor), or a market (external pool). For
example, the company represented by the FEM in Fig. 1 might be structurally cou-
pled to the external pool Companies that needs manufactured products, or/and the
asset Customers that acquire manufactured products and/or the asset Equipment
vendor. However, more information is needed to identify to which elements the
company is actually structurally coupled.
3 Method Description
3.1 Metamodel and Semantics of FEM
A metamodel for FEM is presented in Fig. 4. In this metamodel, all associations
represented by solid arrows heads are of many-to-one type, where one corresponds
to the arrow head. Arrows with a hollow arrow head represent generalization. Clas-
ses Asset, Process, Environmental relation, External relation, and Flow relation
have one attribute – Label – which appears inside the oval or rectangle for the first
two, and near the corresponding arrow for the rest. Also, for the first two classes
Label cannot be NULL, while it can be NULL for the others.
The meanings of the UsedInAs relationships that appear in the metamodel in Fig.
4 and in the generic archetype of Fig. 2, are as follows:
1. Workforce – people trained and qualified for employment in the process, e.g.,
workers at the conveyor belt; physicians; researchers.
2. EXT – process execution template. An EXT is an asset that governs or controls
the process in some way. This can, for example, be: a software development
methodology accepted in a software vendor company; product design docu-
mentation for a manufacturer; technological process documentation, also for a
product manufacturer; description of the service delivery procedure, e.g., a pro-
cess map for a service company. 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 recruitment
process.
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 pro-
cess; a lab that completes medical tests on behalf of a hospital. Partners 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.
Fig. 4 FEM metamodel
4. Stock – a stock of materials or parts that are used in the process. This, for exam-
ple, 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 supplier for each process instance. In the latter case, it is enough
to represent a supplier as a partner. Note, the stock does not need to be physical.
For example, in Fig. 1, we have a stock of manufacturing orders. The main char-
acteristic of stock that differs it from other assets is that each process instance
depletes this asset by consuming one or more elements from it. Thus, the stock
needs to be constantly refilled by some process. This is not the case with other
assets. To show the special nature of the stock relation, its arrow has a different
starting point - with two extra lines, see Fig. 1.
5. Technical and Informational Infrastructure – equipment required for executing
the process. This, for example, can be: a production line; computer; communi-
cation line; building; software system; database.
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 partici-
pating stakeholders, e.g., suppliers if such payment is considered as part of the
process.
The metamodel in Fig. 4 corresponds to the informal description of FEM in Section
2, but introduces several more concepts not fully explained in Section 2. In partic-
ular, it introduces a subclass of class Process called Primary process. 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 gov-
ernment paying for services provided to the public. A primary process needs to have
a special asset called Beneficiary, see Fig. 1, in which the asset Customers is con-
nected with the primary process by an arrow labeled Beneficiary. For the primary
process, the generic archetype in Fig. 2 can be extended to become an archetype for
the primary process presented in Fig. 5. This archetype “forces” the modeler to seek
for who is a beneficiary of the process.
The relation ManagedBy, see the metamodel of Fig 4, can be only of three types,
which are as follows:
1. Acquire – a process that results in the enterprise acquiring new assets 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 prod-
uct-oriented enterprise, acquiring new customers (beneficiary) is done through
marketing and sales processes. Acquiring skilled work force is a task of a re-
cruiting process. Acquiring a new EXT for a product-oriented enterprise is a
task of new product and new technological process development.
2. Maintain – a process that helps to keep existing assets in the right shape to be
employable in the business process instances of a given type. For beneficiary,
it could be a Customer Relationship Management (CRM) process. For work-
force, it could be training. For EXT, it could be product and process improve-
ment. For technical infrastructure, it could be servicing.
3. Retire – a processes that phases out assets that no longer can be used in the
intended process. For beneficiary, it could be canceling a contract with a cus-
tomer that is no longer profitable. For EXT, it could be phasing out a product
that no longer satisfies the customer’s needs. For workforce, it could be actual
retirement.
Fig. 5 Archetype for the primary process
In the metamodel of Fig. 4, three UsedInAs relations, namely, Beneficiary, Work-
force and Partner are grouped in a subclass called Stakeholders. This is done be-
cause their management processes, especially Acquire, require an asset called At-
traction, which is specific for stakeholders. For finding customers, for example, At-
traction could be an interesting 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. For recruiting
partners, it could be a lucrative exclusive contract.
An example of Attraction for acquiring new customers is presented in Fig. 1 –
Reputation of good quality. This is a special type of assets which belong to the sub-
class isTacit in the metamodel of Fig. 4. The subclass means that the asset is intan-
gible, and it exists only in the “heads” of a certain group of people. In Fig. 1, this
asset has a dotted border to differentiate it from other types of assets. Having tacit
assets allows to add to the model things that are not expressed as any physical or
informational object. For example, an EXT of a process can be fully or partly tacit
– exists only in the head of the process participants.
A special archetype can be introduced for processes that deal with acquiring
stakeholders, which is presented in Fig. 6. It “forces” to look for attraction, and also
to find out from which external pool new elements will be acquired. In Fig. 1 this
pool is labeled as Companies that need the manufactured products.
3.2 Requirements on Toolkit
A tool that supports drawing FEM diagram should have visual means to represent
all FEM concepts so that a FEM diagram could be drawn using the tool, while com-
plying with the syntax of FEM expressed in the metamodel in Fig. 4. However, this
is not enough, the toolkit also needs to facilitate creating diagrams in a consistent
way, and ensure that the results are understandable for the intended audience. As
we stated in the introduction, our goal is to explain to the management how their
enterprise operates. Thus, the models produced with the toolkit should be under-
standable by non-technical people. Below, we present requirements on the toolkit
that would make it fit to the goal discussed above:
Fig. 6 Archetype for acquiring stakeholders
1. As has been discussed in Section 2, one way of building a FEM is by applying
archetypes to processes and assets that have already found their place in the
model. It should be possible to invoke an archetype for any process or asset to
facilitate building the model a bit further. Expanding a node according to an
archetype will initiate seeking for information to insert labels in the elements
that the invocation has produced (see also the requirement 3 in Introduction).
2. A model can become quite complex, especially, when the same process or asset
is used in multiple relations, or there are many processes and assets in the or-
ganization that need to be depicted. There is a need to introduce the same model
element, e.g., an asset, several times without losing the information about the
sameness. For example, an ERP system can serve as Technical and informa-
tional infrastructure in many processes. When there are too many elements in
the model, it should be possible to split the model in several pieces making the
same elements (e.g., the ERP system) to become a mechanism for tying the
models together. Thus, there is a need to have a navigation between models so
that it is easy to find other models that have in them some model element, e.g.,
a process or asset.
3. Quite often, a modeler needs to use different level of granularity when creating
an enterprise model. For a high-level overview, the granularity will be coarse,
while when one needs a detailed overview of a particular part of the business,
a fine level of granularity is required. To make the connection between the
models on different granularity levels, there needs to be a way to relate a con-
cept/model element of a higher level to a fragment of the diagram on the low-
level, i.e., the level with higher granularity. For example, a business process
that is depicted as one element in one model may need to be related to an inter-
connected set of subprocesses in a more detailed model.
4. In a specific modeling project, there often is a need to differentiate elements
from the same class, e.g., asset. For example, in a FEM, one might need to
differentiate assets that have tight connection to a physical location, e.g., a
warehouse, from the assets for which physical location does not matter, as they
can be accessed from anywhere, e.g., electronic documents, or IT systems.
There is a need to have means to make the difference highlighted visually.
These means should be easily adjusted to the needs of a specific project. It also
should be possible to add textual explanation to elements of the model, easily
accessible by the intended audience.
4 Proof of Concept
4.1 FEM Toolkit
FEM toolkit [20] was developed using the ADOxx modeling environment [8], and
now it is in its version 0.7. The overall layout when drawing a model with the help
of the toolkit is presented in Fig. 7. The right-hand side presents a model under
development. The column in the middle presents all modeling elements that can be
picked and dropped in the modeling area to the right. The left-hand side has two
areas. The area at the top shows the names of all models grouped in model groups.
A model name in red color shows that the model has been changed, but not saved,
while a model name in blue color shows that the model has been changed and saved
in the current modeling session. The area at the bottom, Navigator, enables zooming
parts of the model visible in the modeling area.
A FEM is built by adding processes, assets, pools and external actors and con-
necting them with arrows that represent relations between them. The toolkit ensures
syntactic correctness by not allowing drawing relations that are against the meta-
model in Fig. 4. This is an improvement in comparison with drawing FEM with a
general diagram drawing tool, or even a specific tool that is not designed to support
FEM. In fact, before creating our toolkit, we used to employ InsightMaker [21] – a
tool designed to support System Dynamics modeling. The main problem when us-
ing it, especially, by novices, e.g., students, was the modeler tending not to observe
the standardized set of labels on the arrows.
Besides ensuring syntactic correctness, FEM toolkit also implements features
that fulfill the requirements discussed in the previous section. These are described
in the following subsections.
Fig. 7 FEM toolkit – general overview
4.1.1 Archetypes
The archetype function is invoked by a modeler via clicking on a “plus” sign placed
at the bottom of each process and asset in the model. A menu that lists the relations
from the generic process-assets archetype from Fig. 2, or from the asset-processes
archetype from Fig. 3 appears, see the upper part of Fig. 8. Then, the modeler can
adjust archetype by removing relations in which he/she is not currently interested
from the list. After clicking on Choose, new model elements are added to the model
and connected to the current one by chosen relations, see the bottom part of Fig. 8.
Other process-assets archetypes can be implemented in the same manner as the ge-
neric one shown in Fig. 8, but it has not been done yet.
4.1.2 Ghost Feature
To solve the problem of multiple instances of the same model element, we have
introduced the concept of ghost, which has been borrowed from InsightMaker [21].
A ghost is a copy of an element that already exists in the model. The ghost in Isight-
Maker is differentiated by lighter background color compared to the original ele-
ment. The ghost is accompanied with a simple navigation mechanism that allows to
find an original which the ghost duplicates. We have extended this concept in three
ways:
More clear visual difference between the ghost and the original element, not to-
tally relying on the background color. An example of a ghost is already presented
in Fig. 1, which has a ghost for asset Reputation of good quality. The ghost has
a thick arrow above the shape that represents the modeling element; clicking on
the arrow will move the focus to the original modeling element.
Fig. 8 Invoking a process-asset archetype
Usage in multiple models, i.e., allow the ghost to be placed in a different model
than the original. In Fig. 9, we have a number of ghosts of the elements that
appear in Fig. 1. In addition to an arrow over the ghost shape, a special color
scheme is used in Fig. 9, ghost having a lighter background color. To create
ghosts, a modeler selects a number of elements in the current model, and choose
an item in the pulldown menu called Create ghosts from selected, see fig. 7. A
new window appears, which allows to select in which model the modeler wants
to create ghosts. Default is the current model (see Fig. 10). Note that the ghost
menu in Fig. 7 also allows to move the originals to another place and substitute
them with ghosts, as well as some other functions (which are not described here).
Note that Fig. 9 represents a case of business model innovation in the manufac-
turing business presented in Fig. 1. As follows from Fig. 1, the node Diagnostic
& Predictive software requires quite a complex structure underneath that needs
to be in place in order the software could be used in practice. As this structure
involves considerable costs, the management decided to explore a possibility to
convert these costs into profit by licensing the software to other manufacturers
that used the same equipment, including own competitors. Fig. 9 shows how the
new business could be set in operation. Ghosts in this picture show how the new
business could benefit from the usage of assets that the company already has.
This example demonstrates how the ghost feature can be used for connecting a
model of organization “as-is” to a model of organization “to-be”. More details
on this case, see in [11]. Background colors in Fig. 1 and 9 will be explained in
Section 4.1.4.
Fig. 9 A model with ghost taken from the model in Fig. 1
Extended navigation – allow to find all ghosts of the given element starting from
a ghost or the original. This is done after choosing an element and using a popup
menu attached to it. In it, the modeler can choose to find all occurrences in the
current model or in all models. The relevant elements will be highlighted by a
special kind of borders, see Fig. 11. If the modeler chooses to show occurrences
in all models, a window that lists all relevant models appears, and it can be used
for navigation, see Fig. 11.
4.1.3 Decomposition
We use nestling together with the ghost functionality for presenting the decompo-
sition. This is illustrated in Fig. 7, which represents the decomposition of process
Sales from Fig. 1. The decomposed process is presented as a special type of ghosts
– group ghost, and it has two new processes inside it. All FEM elements provide an
attribute that qualifies them for being a group or not. By changing the attribute
value, the appearance of the selected element automatically changes, e.g., from a
solid border line to a dashed border line and light background color. The group
attribute exists independently of the ghost feature; thus, any element can become a
group. However, for decomposition, choosing the ghost group is essential as it fa-
cilitates easy finding of the original element.
To show the connection between the new processes in Fig. 7 and other elements
of the model from Fig. 1, ghosts of the connected elements are presented in the new
model. The decomposition in this example is of specialization type, but other types
can be depicted in the same way, e.g., by more tightly connecting the elements in-
side the group, which will be illustrated in Section 4.2. The ghost navigation means
facilitates easy movement from the undecomposed element to the model that depicts
the decomposition and back.
Fig. 10 Selecting a model to place ghosts
Fig. 11 Finding all occurrences of the current shape
4.1.4 Subclassing
Subclassing is a way of differentiating elements of the model that belong to the
same class in the metamodel, see requirement 4 in section 3.2. Visually, elements
of subclasses are differentiated by their background color. Technically, subclassing
is introduced in the toolkit by a special type of models called FEM subclassing.
Such a model consists of a number of subclasses that use the same shapes as the
nodes of the ordinary FEM, e.g., oval – for a process, rectangle – for an asset, etc.
Each subclass has a dedicated background color and a label that describes what this
color represents. There can be at the maximum one subclassing model in a modeling
group.
As an example, consider a FEM subclassing model in Fig. 12 that is defined for
the modeling group that includes models in Fig.1 and Fig 9. The example concerns
a Business Model Innovation (BMI) case from [11], where a product manufacture
considers starting a new business of developing and licensing diagnostic and pre-
dictive software for complex equipment.
A FEM subclassing model presented in Fig. 12 is designed for the usage of FEM
for BMI. It differentiates four types of processes: (1) a current primary process –
beige, (2) a supporting process that can be transformed into a new primary process
– yellow, (3) a process that can be used in a new business as is – blue, (4) a temporal
transformation process, which is needed for creating a new business, but will be
disbanded after that – red. Processes of the first two subclasses appear in Fig. 1;
processes of the third subclass appear in both Fig. 1 – current business, and in Fig.
9 – transformed business. Processes of the fourth subclass appear only in Fig. 9.
There is one subclass of assets in Fig. 12 – existing assets that can be used in a new
business – blue – as is or changed through the transformation processes. These as-
sets are presented in both Fig. 1 and Fig. 9.
Fig. 12 An example for FEM subclassing model
Assigning a subclass to a model element is done by a special menu, see Fig. 13.
Note that the subclassing allows to define a different background color for ghosts –
normally lighter than the main background color. This can be seen in Fig. 9, in
which there are a number of ghosts that originated from Fig. 1.
4.1.5 Notes
As was discussed in the requirement 3 from Section 3.2, there is a need to add tex-
tual explanations in the model. This can be done in two ways. Firstly, each element
has a set of properties, one of which is the textual Description. However, this
method has a drawback – to show the description one need to open the property
sheet. A second method is adding notes and connecting them to particular elements
as shown in Fig. 7.
Fig. 13 Assigning a subclass to a shape
4.2 Example of Usage – Identifying Areas for Improvement
The first version of FEM toolkit was used in a project of identifying areas for im-
provement completed by the authors in 2019-2020. This project has initiated adding
to the toolkit some of the new features discussed in Section 4.1, e.g., subclassing.
The project aimed at investigating opportunities for improvement in an EMEA
(i.e., Europe, Middle East and Africa) branch of an international high-tech business
concern. The concern provides test measurement products and related services to
other high-tech organizations. The project started by a request from the department
director of the internal Business Support and Services (BSS) department whose
prime responsibility is sales support and managing supply chain activities. The BSS
department is entrusted with the task of relieving sales and service departments from
administrative work. Thereby, these departments could concentrate on their core
businesses, i.e., increasing sales, and providing efficient high-quality calibration
and repair of products. As a result, BSS completes the activities in business pro-
cesses that belong to other departments, while having no total responsibility for
these processes. The staff of the BSS department is distributed across several Euro-
pean countries residing in sales and services headquarters of these countries.
The background of the request that triggered the project is the exposure of the
EMEA branch to a significant economic decline that requires adjustment of the op-
erational cost. Several alternatives to achieve cost reduction were considered, such
as changing responsibility structure or relocating the staff to a lower-wage country.
Our task has been to suggest a set of alternatives for organizational changes based
on modeling of operational activities of the BSS department.
Building FEM for the department business activities was part of the project. FEM
was found very useful to understand the whole business in general, and especially,
the role played by BSS, which was quite difficult to grasp in the beginning. A sim-
plified FEM of the whole EMEA is presented in Fig. 14. In this figure, border color
is used to define who is responsible for the process: red – BSS; purple – another
department of EMEA; black - a third party.
Fig. 14 A general model of the EMEA business
The processes in Fig. 14 where decomposed in separate diagrams to get more
details on BSS engagement. As an example, Fig. 15 shows a simplified diagram of
the decomposition of Sales order delivery.
Fig. 15 Decomposition of Sales order delivery
Besides helping us to understand the overall business and BSS engagement in it,
FEM has helped to identify areas with potential for improvement. Two patterns that
point to such areas were identified. One is when a process/subprocess has no phys-
ical connection to a certain place on the earth; this allows to move the team that
handles it to a more preferable place, e.g., a low-wage country. The other one is
when a process/subprocesses uses multiple software tools and information sources
and requires the team to manually move information from one place to another. In
this situation, integrating the systems or substituting them with an integrated one
could make a considerable improvement. More details on the project and usage of
FEM in it, see in [22].
4.3 Other Projects with FEM Toolkit
The team that completed the project described in Section 4.2 included FEM experts.
Recently, two other projects were completed, which employed FEM and FEM
toolkit, where the project teams did not include FEM experts; some help from FEM
experts, however, was provided.
The first project [23] was completed by Steven Lego at Tartu Water Utility com-
pany. The project aimed at designing a new digitalization strategy at a company
with an outdated IT systems park, as well as creating more detail requirements for
completing the first step of the strategy. FEM was successfully used in the following
tasks:
1. Understanding of how the company operates in general, especially, in a situation
where a domain is new for the business analysts engaged in the project.
2. Gathering detailed information related to each of the 14 departments. FEM was
used as a guiding tool to find the gaps between the details obtained in the first
round of interviews, and formulate questions for the next rounds.
3. Producing a set of detailed diagrams of the business “as-is” for each department,
which served as an informational basis for decisions on what needs to be
changed.
4. Producing detailed diagrams of the business “to-be” for each department. These
diagrams showed the changes to be introduced via a new strategy. They were
also linked to the “as-is” diagrams, to show the difference. The “to-be” diagrams
were also used as an informational basis for creating requirements on new IT
systems and for initial market investigation.
5. For communicating changes to be introduced to the internal stakeholders.
As Steven has experience as business analyst from similar projects, his opinion
on usefulness of FEM reflects a comparative strength of the tool in the tasks listed
above. Using FEM allowed him to use time allocated for the project more effec-
tively, especially, regarding the first task on the list.
The first project was completed by a person with experience of system analysis,
but without experience of FEM. In difference from this project, the second project
was completed by two MS students, Erik Falenius and August Carlsson, from
Stockholm University as their MS thesis work. Neither of the students had any busi-
ness analysis experience, and they did not have any knowledge of FEM before the
project started. Nevertheless, they managed to obtain practically important results
with the minimum guidance from their supervisor (the first author). FEM structure
and archetypes were used in the project to guide gathering and analyzing the infor-
mation; this “guiding” property of FEM played the major role in their success.
The project practical goal was to suggest improvements for a so-called sourcing
process in an international concern. The sourcing project aimed at signing long-term
purchasing contracts for all branches of the concern. By creating FEM model of the
process and its context, the students could find several problems in it, the major one
was not reusing information obtained in the previous instances of the process. The
management of the concern agreed that suggested improvements made sense and
could be implemented. As a side effect of discussions held using FEM, internal
business analysts became interested in the technique, and wanted to use it in other
projects.
5 Conclusion
This chapter started with formulating a goal of giving the management a model that
explains how the organization operates in an, for the management, understandable
way. We suggested that our Fractal Enterprise Model (FEM) could satisfy this goal.
Furthermore, we presented the latest version of FEM, both informally and formally
– as a metamodel, and then proceeded with discussing a toolkit to support building
FEMs.
We consider creating a toolkit as an essential step in promoting FEM as a prac-
tical solution to the problem defined in Section 1. As has been discussed in the
paper, supporting building a single model does not satisfy the needs of the modeler.
A modeler, usually, needs to create a package of diagrams, each filling its own pur-
pose. Some diagram needs to present an overall picture; thus, the granularity of the
model will be coarse. Others need to present the details of certain parts of the busi-
ness; thus, their granularity should be finer. Some models will present the current
state of the business, others will suggest changes. What is more, the models that
constitute the package need to be connected, so that the user of the package can
easily go from a general picture to a detailed one, or from a model “as-is” to the
model “to-be”. Also, the toolkit should help to visualize particularities of a specific
modeling project in a standardized way without substantially extending the toolkit.
By experimenting with the ADOxx environment, we have succeeded in imple-
menting the toolkit that satisfies the requirements. The metamodeling environment
was of great help here, as it allowed to test hypotheses, quickly modify the toolkit
when some feature showed to be inconvenient, and get us to the point when the
toolkit started to be useful in practice. The toolkit has already been tested in several
practical projects, and it is also used in master of science level courses to introduce
FEM to the students. Our plans include both further development of the toolkit, and
dissemination it among the practitioners via webinars and tutorials.
Acknowledgements. The authors are very grateful to the ADOxx team for
providing us with the environment for experimentation that allowed the creation of
a toolkit using the minimum of resources. We also much in debt to Dominik Bork
who implemented the first version of FEM toolkit and continues to support our ef-
forts. We are also grateful to our students and colleagues Steven Leego, Erik Fale-
nius and August Carlsson who independently tested FEM toolkit in practical pro-
jects. The first author’s work was partly supported by the Estonian Research Coun-
cil (grant PRG1226).
References
1.
Hoverstadt, P.: Why Business should take Enterprise Architecture seriously. In Gøtze,
J., Jensen-
Waud, A., eds. : Beyond alignment, Systems Volume 3. College publishing
(2013) 55
-
166
2. OMG: Business Process Model and Notation
(BPMN), Version 2.0.2, Object
Management Group (OMG), Document formal/2013-12-
09, December 2013. In: OMG.
(Accessed 2013) Available at:
http://www.omg.org/spec/BPMN/2.0.2/PDF
3.
Beer, S.: The Heart
of Enterprise. Wiley (1979)
4.
OMG: Business Motivation Model, Version 1.2, Object Management Group (OMG),
Document formal/2014-05-
01, May 2014. Available at:
http://www.omg.org/spec/BMM/1.2/PDF
5. The
open group: ArchiMate® 3.0.1 Specification. In: The Open Group. (Accessed
2020) Available at:
https://publications.opengroup.org/standards/archimate/specifications/c
179
6.
Hoverstadt, P.: The Viable System Model. In : Systems Approaches to Managing
Change: A Practical Guide. Springer, London (2010) 87
-
133
7.
NIST: Integration definition for function modeling (IDEF0), Draft Federal Information
Processing Standards, P
ublication 183, 1993. In: IDEF. (Accessed 1993) Available at:
https://www.idef.com/idefo
-
function_modeling_method/
8.
ADOxx.org: ADOxx. (Accessed 2017) Available at:
https://www.adoxx.org
9.
Bider, I., Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its
application for business development. SoSyM 16(3), 663
–
689 (2017)
10.
Bider, I.: Structural Coupling, Strategy and Fractal E
nterprise Modeling. In : Research
Challenges in Information Science. RCIS 2020, LNBIP 385. Springer (2020) 95
-
111
11.
Bider, I., Lodhi, A.: Moving from Manufacturing to Software Business: A Business
Model Transformation Pattern. In : Enterprise
Information Systems. ICEIS 2019,
LNBIP 378. Springer (2020) 514
-
530
12.
Bider, I., Chalak, A.: Evaluating Usefulness of a Fractal Enterprise Model Experience
Report. In : Enterprise, Business-
Process and Information Systems Modeling. BPMDS
2019, EMMSAD 20
19, LNBIP, vol. 352, pp.359
-
373 (2019)
13.
Giesen, E., Berman, S. J., Bell, R., Blitz, A.: Three ways to successfully innovate your
business model. Strategy & Leadership, Vol. 35 Issue: 6, pp. 35(6), 27
-
33 (2007)
14.
Bider, I., Perjons, E.: Using a Fract
al Enterprise Model for Business Model Innovation.
In : BPMDS 2017 RADAR, CEUR Vol 1859, pp.20
-
29 (2017)
15.
Bider, I., Perjons, E.: Defining Transformational Patterns for Business Model
Innovation. In : Perspectives in Business Informatics Research: 17th
International
Conference, BIR 2018, Stockholm, Sweden, LNBIP, vol. 330, pp.81
-
95 (2018)
16.
Josefsson, M., Widman, K., Bider, I.: Using the Process-
Assets Framework for Creating
a Holistic View over Process Documentation. In : Enterprise, Business-Proces
s and
Information Systems Modeling, LNBIP, Vol. 214. Springer, Stockholm (2015) 169
-
183
17.
Maturana, H.: Autopoiesis, Structural Coupling & Cognition. Cybernetics & Human
Knowing 9(3
-
4), 5
-
34 (2002)
18.
Hoverstadt, P.: Defining Identity by Structural
Coupling in VSM Practice. In : UK
Systems Society, Oxford (2010)
19.
Hoverstadt, P., Loh, L.: Patterns of Strategy. Taylor & Francis (2017)
20.
FEM toolkit. (Accessed February 27, 2021) Available at:
https://www.fractalmodel.org/fem
-
toolkit/
21.
Give Team: Insightmaker. (Accessed 2014) Available at:
http://insightmaker.com/
22.
Klyukina, V., Bider, I., Perjons, E.: Does Fractal Enterprise Model Fit Operati
onal
Decision Making? In : Proceedings of the 23rd International Conference on Enterprise
Information System (ICEIS) 2021, vol. 2, pp.613
-
624 (2021)
23.
Leego, S., Bider, I.: Using Fractal Enterprise Model in Technology-
Driven
Organisational Change Projec
ts: A Case of a Water Utility Company. In : 23rd IEEE
Conference on Business Informatics, CBI 2021, vol. 2, pp.107
-
116 (2021)
