ChapterPDF Available

Evaluating Usefulness of a Fractal Enterprise Model: Experience Report



The paper presents an experience of evaluating the usefulness of a particular modeling technique called Fractal Enterprise Model (FEM). FEM connects enterprise processes with assets that are used in and are managed by these processes. The evaluation has been conducted in a somewhat unusual manner. A model that covers an essential part of an enterprise's activities has been built without any practical goal in mind, e.g. finding a cause of a problem, designing or completing a transformational change, etc. Then, it was presented to and dis-cussed with the stakeholders that helped to build it. During the discussions, the stakeholders were asked to elaborate on the potential usages of the model in the practice of the enterprise. The result was a comprehensive list of possible usage of the model.
The final version of this paper has been published and is copyright by Springer in LNBIP, vol.
Evaluating Usefulness of a Fractal Enterprise Model
Experience Report
Ilia Bider*, Arian Chalak**
*DSV - Stockholm University, Stockholm, Sweden
**Försäkringskassan, Sweden,
Abstract. The paper presents an experience of evaluating the usefulness of a par-
ticular modeling technique called Fractal Enterprise Model (FEM). FEM con-
nects enterprise processes with assets that are used in and are managed b y these
processes. The evaluation has been conducted in a somewhat unusual manner. A
model that covers an essential part of an enterprise's activities has been built with-
out any practical goal in mind, e.g. finding a cause of a problem, designing or
completing a transformational change, etc. Then, it was presented to and dis-
cussed with the stakeholders that helped to build it. During the discussions, the
stakeholders were asked to elaborate on the potential usages of the model in the
practice of the enterprise. The result was a comprehensive list of possible usage
of the model.
Keywords: fractal enterprise model, business process, business process model-
ing, process architecture, experience report, evaluation, usefulness
1 Introduction
This paper reports on the experience of a project aimed at evaluating usefulness of
Fractal Enterprise Model (FEM) [1] for practical purposes. FEM presents an enter-
prise/organization as a network of interconnected processes and assets. From one point
of view, FEM can be considered as a model that expresses business process architecture
[2,3], as it shows interconnection between different business process that exist in an
organization/enterprise. From the other point of view, FEM can be considered as an
enterprise model (or an enterprise architecture [4]) in line with other enterprise models,
e.g. Viable System Model (VSM) [5], work systems framework [6], or Business Model
Canvas (BMC) [7], as it shows connection between the processes and enterprise's tan-
gible and intangible assets (resources in the terminology of other modeling techniques).
The objective of the project was threefold:
1. Introduce modeling technique into a company. This was to be done by creating a
model of the company business and then present it back to the company.
2. Find out new application areas for FEM, beyond those that were theoretically iden-
tified in [1], and partly investigated in other works, e.g. [8].
3. Test whether FEM can be built by a novice modeler in practical settings.
The objective has been achieved in a somewhat unusual manner. In normal practice, a
model is being built for some specific practical task, e.g. building an IT system to sup-
port a process, educating new members of staff, finding a cause of a problem or a solu-
tion when the cause has been identified. Having a practical task in mind is quite justi-
fiable, as building a model requires resources from the stakeholders when collecting
data on which to build a model. People need to be interviewed, documents related to
the object of modeling need to be provided, observation of activities need to be allowed,
etc. Providing these resources without having any practical task for which the model
should be built might be difficult to justify. However, in the case described in this paper,
we were lucky to obtain permission to use the resources for creating and discussing our
model without having a practical task to complete.
The strategy we used in this project was: (a) build a model based on information
obtained from different groups of stakeholders, and (b) present the model to each stake-
holders group separately and discuss for what purposes this model can be used in the
enterprise. The goal with building the model was to show to the stakeholders its capa-
bilities. As FEM is aimed at visualizing the interconnections between the enterprise
business processes and its assets, this general goal was translated into discovering rep-
resentative for the company business processes and assets and presenting as much in-
terconnection between them in the model as it was possible to discover. As the project
had limited resources, in terms of time and access to the information, there was no
attempt to build a full model of the whole enterprise.
An organization, for which a FEM has been built is a typical IT solution provider
that develops, supports, maintains and operates IT solutions for their customers. The
team who created a model consisted of an MS student – the second author who did all
fieldwork, and his thesis supervisor who guided the work via meetings held through a
video conferencing system. The first member of the team had minimal experience of
modeling in real practice in general and building FEM models in particular, though
FEM was included in one of the courses the second author took. He also did not possess
any domain knowledge, so the IT solution provider business was new to him. The sec-
ond member of the team, supervisor, has an intimate knowledge of FEM as being one
of the authors of the modeling technique, has long experience of building models of
various types in practical settings, as well as he has knowledge of the IT solutions pro-
viders business in general, being for a long time engaged in such business personally.
The composition of the team allowed us to include the third goal in the project's
objective, namely, "to test whether FEM can be built by a novice modeler in practical
The plan of first building, and then showing the model was successfully imple-
mented, though some stakeholders were a bit suspicious about the project as they did
not understand the goal with the project. The second part of the project showing to and
discussing the model with the stakeholders gave interesting results in both showing new
areas of application of FEM, and providing a more specific form for those areas that
were predicted in [1].
The rest of this paper is written according to the following plan. In Section 2, we
present a short overview of FEM to give the reader a possibility to read this paper with-
out studying the papers where FEM was originally introduced. Section 3 presents the
business case, i.e. necessary information on the IT-provider, and the ways of how the
FEM model has been built. Section 4 presents and explains the FEM model. Section 5
presents the stakeholders' views on how the model can be used in practice. Section 6
summarizes the findings.
2 Fractal Enterprise Model
As was mentioned in the introduction a Fractal Enterprise Model (FEM) belong to the
class of enterprise models and thus has some common features with other modeling
technique, and tools in this category. A full description of FEM, including its relation-
ships with other enterprise modeling techniques and tools is presented in journal paper
[1]. The latter has also explanation of why the model has been called fractal. The goal
of this chapter is only to give the basic notions so that the reader does not need to
become acquainted with [1] before reading this experience report.
FEM includes three types of elements: business processes, assets, and relationships
between them, see Fig. 1 in which a fragment of a model is presented. The fragment is
related to a business case considered in the next sections, and it will be explained in
more details in these sections. Graphically, a process is represented by an oval; an asset
is represented by a rectangle (box), while a relationship between a process and an asset
is represented by an arrow. We differentiate two types of relationships in the fractal
model. One type represents a relationship of a process “using” an asset; in this case, the
arrow points from the asset to the process and has a solid line. The other type represents
a relationship of a process changing the asset; in this case, the arrow points from the
process to the asset and has a dashed line. These two types of relationships allow tying
up processes and assets in a directed graph.
In FEM, a label inside an oval names the given process, and a label inside a rectangle
names the given asset. Arrows are also labeled to show the type of relationships be-
tween the processes and assets. A label on an arrow pointing from an asset to a process
identifies the role the given asset plays in the process, for example, workforce, infra-
structure, EXecution Template (EXT), etc. A label on an arrow pointing from a process
to an asset identifies how the process affects (i.e. changes) the asset. In FEM, an asset
is considered as a pool of entities capable of playing given roles in 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
Note that the same asset can be used in two different processes playing the same or
different roles in them, which is reflected by labels on the corresponding arrows. It is
also possible that the same asset can be used for more than one role in the same process;
in this case, there can be more than one arrow between the asset and the process, but
with different labels. Similarly, the same process could affect different assets, each in
the same or in different ways, which is represented by the corresponding labels on the
arrows. Moreover, it is possible that the same process affects the same asset in different
ways, which is represented by having two or more arrows from the process to the asset,
each with its own label.
Fig. 1. A fragment of a FEM representing a process from our case study
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
relationships between processes and assets, however, can be standardized. It is done by
using a relatively abstract set of relationships, like, Workforce, Acquire, etc., which are
clarified by the domain- and context-specific labels inside ovals and rectangles. Stand-
ardization improves the understandability of the models.
While there are many types of relationships that show how an asset is used in a
process (see example in Fig. 1), there are only three types of relationships that show
how an asset is managed by a process – Acquire, Maintain and Retire.
To make the work of building a fractal model more systematic, FEM uses 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 labelled. Instantiating 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-processes
archetype. A process-assets archetype represents which types of assets that can be used
in a given category of processes. The asset-processes archetype shows which kinds of
processes are aimed at changing the given category of assets.
3 Project Overview
3.1 The Business Case
As was already mentioned in the introduction, this research has been completed at an
IT Solutions Provider, which we refer to as ITSP in the rest of the text. Organization-
ally, ITSP is a local office of a large national concern that has many offices around the
country. It works quite independently serving their customers but uses some services
provided by the central office. ITSP develops, supports, maintains and operates IT so-
lutions for their customers. The company has few significant customers for which it
develops and operates solutions. Thus, their sales process is more directed at getting
more orders from the existing customers than acquiring new customers.
3.2 The Project Strategy and Plan
As follows from the introduction, the project strategy was straightforward; the project
plan consisted only of three steps presented in Fig. 2. At the same time, this strategy
was a bit unusual. The project was not connected to any specific practical task, like a
problem to solve, challenge to meet or improvement to introduce. Still, it required re-
sources from the company for all three steps, like time for answering interview ques-
tions, time to participate in the presentations, and time for understanding the model and
providing feedback. All these resources were requested without promising anything
particular in return.
Fig. 2. Project plan
As was already mentioned in the introduction, all field work of building and presenting
FEM has been done by the second author. The information for building a model has
been gathered from different sources, such as interviewing people that play various
roles in the processes, reading the documentation, and making observations while par-
ticipating in the meetings of the software development team.
Navigation through the information sources was done according to the internal re-
cursive structure of FEM. When a process of interest had been identified, a process-
assets archetype, such as the one presented in Fig. 3, was used to produce a set of ques-
tions that needed answers, e.g. who participate in the process (workforce), what tools
(information & technical infrastructure) are used in it, what templates/guidelines/meth-
ods steer the process (EXTs -execution templates), etc. These questions were answered
by interviewing the participants, who in turn could also point to other people partici-
pating in the process to be interviewed. Thus, a snowball-like method guided by arche-
types was used for building the model.
Fig. 3. A generic process-assets archetype (adapted from [1]).
As the time frame for the project was limited, there was no possibility to build full FEM
of ITSP; thus only a limited, but an essential fragment of FEM has been built. It includes
one primary process – IT Solution delivery, and one supporting process that belongs to
a category of sales processes, called Offering Development. The first process delivers
value to the customers for which they are ready to pay; that is why it is called primary
in the FEM terminology of [1]. The second process aimed to get orders for the first
process from the existing customers; that is why it is called supporting in the terminol-
ogy of [1].
Building FEM Presenting FEM to
Recieving feedback
on the areas of use
for FEM
Generic process
Workforce Tech&Info
Infrastructure Organizational
EXT Partner Stock
4 Fractal Enterprise Model of ITSP
4.1 FEM of a Primary Process
FEM for the primary process - IT Solution Delivery - is presented in Fig. 4. The process
includes both developing and delivering solutions. The model has been built using a
web tool called InsightMaker [9]. Though this tool is not designed for FEM diagram-
ming, its expressive graphical power is enough for many FEM diagrams.
The root of FEM in Fig. 4 is an oval representing the primary process; the assets
connected to it with the solid line arrows represent the assets that are used in this pro-
cess. There are many assets of the same type, i.e. assets that are connected to the process
with arrows that have the same labels. To make a diagram easier to grasp, assets are
grouped. Each group is represented by a visual element of InsightMaker called folder.
A folder is a group of visual elements that can be exploded or collapsed. As can be seen
in Fig. 5, an arrow can be drawn between a folder and a process. This arrow means that
each asset in the folder is connected with the corresponding process using the same type
of arrows like the one which goes from the folder.
Fig. 4 presents many assets that are used in the process of IT Solutions Delivery. It
took quite some time to identify and group these assets. The three groups of assets -
Software Environment, Basic Software Platform, and Advance Software Platform - rep-
resent environment/platform/tools used for solution development and employment.
They are connected to the process by arrows labeled as Tech. And Info. Infrastructure.
The fourth group connected by an arrow with the same label – Standardized Tools rep-
resents tools used to arrange the work of process instances of the primary process -
actual projects that produce and deliver solutions.
The group called Process Templates is connected to the primary process by an arrow
labeled EXT (EXecutable template). The group contains assets used for guiding differ-
ent phases of process instances; each asset includes descriptions of routines used in the
corresponding phase.
The group Software Development Team includes several assets that represent various
roles people play in solution development and delivery. The group is connected to the
primary process with an arrow labeled Workforce; each asset in this group represents a
particular category of participants of the development and delivery process. These par-
ticipants were the primary source of information for building the model. Representa-
tives of each group were interviewed as well as their meetings were observed. Note that
an arrow that leads from this group to the process has a diamond start. The diamond
start means that an asset or group represent a stakeholder of the process, which accord-
ing to [1] warrants a special kind of acquiring archetype to be used when expanding
this node.
The group, IT solutions Projects Orders, is connected to the primary process with
the arrow labeled Stock. The stock of orders is an essential asset that ensures that the
primary process can be run repeatedly. The stock always needs to be filled up, and this
is a responsibility of another process discussed in the next section. The orders group
consists of four different types of project orders, as shown in Fig. 4.
of the main process
Customer is an asset that fulfills two functions. Firstly, the customer functions as a
beneficiary for the process. Having a beneficiary, somebody who gets value from the
process for which the company can get paid is mandatory for a primary process. Sec-
ondly, the customer actively participates in the process, thus fulfilling the role of Part-
ner. Both arrows start with the diamond pointing out that this asset is of stakeholder
The last asset represented in Fig. 4 is Customer opinion on the quality of delivered
software. It is not an asset needed for running the primary process, but an asset that is
acquired and maintained by the process, which is represented by dashed arrows in Fig.
4. This asset is needed for another process, the one which is discussed in the next sec-
tion. This asset belongs to the particular type of intangible assets that represent the
opinion/reputation of some kind. Dashed borders highlight such assets.
For each asset represented in Fig. 4, there exist processes that manage it, e.g. hiring
and training people, creating and maintaining platforms, etc. These are not represented
in Fig. 4, except the ones that manage execution templates. The management processes
for the templates are presented explicitly to mark that these processes do not run by the
local company, but by the central office of the whole concern.
4.2 FEM of a Sales Process
The model for a sales process is presented in Fig. 1. The process belongs to supporting
processes, more precisely it is a process the goal of which is to get new orders from the
existing customers; this is why it is called Offering Development. This process serves
as an acquire process for a group of assets IT Solutions Orders, which is represented
by a dashed arrow from the process to the asset in Fig 1. All other assets connected to
the root process in Fig. 1, are assets that are used in the process.
As we see from Fig. 1, customer is an essential asset that functions as a partner in
developing new offers which it then accepts. Customer opinion is also a valuable asset
that makes the customer trust the companies even when all details of an offer are not
completely clear. Workforce is represented by a group of assets that includes several
roles. These are marked by a yellow background, which means that they also participate
in other processes presented in Fig. 1; the cases of repetition are denoted by a light-
yellow background. The offering process uses a number of Offering templates that are
being developed and maintained by the central office. Tech. & Info. Infrastructure is
represented by a group of assets that includes Project management tools and CRM of-
fering tool.
As can be seen from Fig. 1, an important asset for the offering development process
is a stock of suggestions. The stock is filled by two different processes Field based
discovery and Life cycle management. Both are connected to asset Suggestions via
dashed arrows labeled as Acquire. The Workforce for the first process is the Solution
development team, the same as identified in Fig. 4. The idea is that the team should
come with suggestions for new projects based on their knowledge of the existing sys-
tems and their communication with the customers. Though this source to generate sug-
gestions is very important, there are no standardized working procedures on how this
process should work. The latter is depicted in Fig. 1, by asset Templates under devel-
opment which is connected to the discovery process by an arrow labelled as EXT (Ex-
ecution template).
The second process that generates suggestions, Life cycle management, is based on
the idea of each product (solution) having a natural life cycle. The suggestions are made
to move the product to the next phase of the cycle, e.g. enhance the functionality, or
create a new version. One of the sources of enhancing and improving the products is
New trends and ideas coming from the ideation process. Life cycle management uses
Road map and Business plan templates for guiding the process of generating sugges-
tions. Three roles are included as Workforce for this process, these roles also participate
in the offering development process itself.
4.3 Connecting the Models
After both models for the solution delivery and offering development had been com-
pleted, they were integrated to give a holistic view of the company's activities. This
view is presented in Fig. 5, where the left-hand side represents the primary process, and
the right-hand side represents the sales process. The most important common assets are
represented once and connected to nodes on both sides. To these belong Customer,
Customer Opinion, IT solution project orders and Software development team. Other
assets that are included in both sides are represented by green background in the left-
hand side and light green background in the right-hand side. In addition the yellow
background is used in the right-hand side to show the assets that are used in several
processes on this side. Again, the light color is used to indicate the second (or third)
occurrence of the asset. Note also, that some groups of assets on the left-hand side are
collapsed and do not show all details that can be seen in Fig. 4.
5 Stakeholders Views
After the model had been built, it was separately shown to and discussed with different
stakeholders. Below, we summarize the feedback received from them. The summary is
structured according to the issues named by various stakeholders. The summary below
does not give all the details of the input, only the most important issues named by the
5.1 Assets Management
The FEMs produced, especially the one on Fig. 4, turned out to be the first visual re-
pository of all assets used in the organization. This repository, which also shows the
interconnection between assets, can be used for different purposes listed below. The
purposes in the list were mentioned by different stakeholders, each giving a feedback
from the perspective of his/her roles.
Fig. 5. An integrated FEM
1. The assets map could be used for ensuring that each project, which is an instance of
the primary process, has all assets needed for its completion assigned to it. Fig. 4
lists all assets that potentially can be required for the completion of various projects.
Each project may use some of these assets, but not the others. It is important to iden-
tify the assets needed for a particular project from its beginning by picking them
from FEM. It came from the Project manager point of view. To make it work, a tool
is needed that could help "instantiation" of FEM for a particular project (process
2. The assets map can be used for risk management to ensure that each asset is respon-
sible for having it in order. It came from the Risk manager point of view. To make
the connection between the assets and responsible persons, the FEMs presented in
Fig. 1, 3 and 4, should be extended with assets management processes and their
workforce assets.
3. As FEM shows all usages of each asset, it can help in optimizing the asset usage on
the company level. For example, if the need for a specific human asset becomes
lesser, FEM can help to identify where else this asset can be used, instead of firing
people. This suggestion came from the Project manager.
4. An enhanced FEM is Fig. 4 can be used for ensuring that the sizes of assets that
represent various categories of specialists in IT solution team match the needs. This
will require adding numerical values showing the sizes of various assets and con-
necting HR processes, e.g. hiring and training, to the model that should take into
accounts these values. This suggestion came from the Software developers.
5.2 Holistic View on the Company's Activity
A FEM that includes a number of connected processes can be used as a visual repre-
sentation of how the company works. This can be used for a number of purposes, ex-
amples of which are presented below.
1. It shows to a member of staff his/her responsibilities and also responsibilities of
his/her colleagues. This can help in educating the employees and creating a common
view of the company and how it operates. This kind of usage was mentioned by
several roles, such as the Project manager and Software developers.
2. It shows all the places where a particular asset is engaged, which can help in planning
changes, especially changes that concern updates of software related assets, e.g. an
Oracle database. For this purpose, having separate maps of assets attached to various
projects would be helpful. It will allow finding all instances that use a specified asset
and calculate the impact of its change on each particular instance. This suggestion
came from the Solution architect.
5.3 Process Development and Improvement
As well as being a repository of assets, FEM can be considered as a repository of the
company's processes. This repository can be used for a number of purposes, examples
of which are presented below.
1. It is important to have EXTs for each process, as a process without EXTs will be run
in an ad-hoc manner, which may affect both efficiency and effectiveness of the com-
pany. Also, each process template needs to have its managing processes and respon-
sible persons for them. Missing this part in the organization may result in that the
templates are never updated, thus resulting in them being not used in practice. FEM
can both point to the processes without templates, and templates without proper man-
aging processes and responsible persons. This suggestion came from the Project
2. FEM shows the connections between various processes, which can help to avoid
each process being handled in isolation. The latter may result in improvement (e.g.
optimization) in one process decreasing the effectiveness of the company instead of
increasing it. This suggestion came from the Product solution manager.
5.4 Field Based Discovery
Many stakeholders provided feedback related to a particular area of the FEM on Fig.4,
namely around the process called Field based discovery, which is one of the sources
for generating suggestions for Offering development. The feedback related to this pro-
cess came from the Product solution manager (in fact, most of his feedback was asso-
ciated with this issue), Project manager and Software developers.
All stakeholder considered that FEM in Fig. 5 highlights the importance of Field
based discovery and the need to involve in it the software development team fully. FEM
in Fig. 5, shows that the IT solution development process requires orders from the cus-
tomers. Otherwise, the development team will have nothing to do. At the same time
creating these orders requires help from the developers, as they meet the customers and
can obtain information about their needs that might be missed by the sales executives
and managers. FEM also shows that the process does not have EXTs, which creates
confusion among the developers. They are asked to participate in the process, and they
are willing to do so, but there are no clear guidelines of how to do this.
In general terms, this particular usage falls in the categories already discussed in the
previous sections. However, we decided to address it separately, as it seems to be one
of the major issues in the company. Also, this issue is of importance not only for this
particular company but can be found in many consulting companies that have similar
problems with the engagement of consultants and developers in sales.
6 Lessons Learned
On the whole, the strategy accepted for this project proved to be successful. It was
possible to build a model without having a specific purpose and present it to stakehold-
ers for discussions and reflections. It showed that the stakeholders fully understood the
model and were able to reflect on it, which allows to conclude that the first goal of our
project, i.e. introduce FEM to the company has been successfully achieved. One of the
significant factors that contributed to the success was that the model presented to and
discussed with the stakeholders was not abstract, but showed their business activities,
and in a visual way. This prompted a chain of ideas related to the problems and chal-
lenges each stakeholder experienced in his/her work.
The discussions with the stakeholders and their reflections also revealed a number
of possible usages of the model in the organization, which was the second goal of our
project. The areas of usage suggested by stakeholders are listed in Section 5. They fall
into general categories discussed in [1]. However, in difference from [1], where the
categories were defined in broad terms, the suggestions from the stakeholders were
more specific. Some suggestions require a special kind of tools that were not thought
of before.
As far as using the FEM technique by a novice modeler, it was both challenging and
supporting. Challenging - because it was not clear in the beginning what questions to
ask, and to whom to talk. Supporting means that when some process had been identi-
fied, it was relatively easy to unwind the FEM structure by finding things connected to
the process according to the archetypes. Using FEM gives an alternative way to under-
stand the business activities of the company. Instead of starting with the official state-
ment of mission and vision, and then continuing to how they are implemented, FEM
can help to dive into how the company works as soon as some of its primary processes
have been identified. This may give a more reliable view of the company, as the official
goals (e.g. vision and mission) may not correspond to what the company does in reality.
Despite the challenges, it was possible to build a FEM for a novice modeler with a
limited assistance from an expert. This allows us to conclude that the question posed in
our third goal, whether it is possible to build a FEM by a novice modeler, can be an-
swered positively.
Note that the main goal of this project was investigating the usefulness of FEM, all
issues related to syntactical or semantical correctness were left outside the scope of the
investigation. In this respect, we follow the famous statement from [10]: “… essen-
tially, all models are wrong, but some are useful", which puts the usefulness issue be-
fore the correctness.
Note also, that the results of our project support the statement of Patrick Hoverstadt
for the need of an architectural model that shows the management of how the company
works presented in [11]. Namely, many managers found the strength of FEM in giving
them a holistic view of the company's business activities, and especially on the im-
portance of taking into consideration interconnectedness of processes and assets.
Bider, I., Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its
application for business development. Software & Systems Modeling 16(3), 663–
Green, S., Ould, M.: A framework
for classifying and evaluating process architecture
methods. Software Process: Improvement and Practice 10(4), 415
425 (2005)
Koliadis, G., Ghose, A., Padmanabhuni, S.: Towards an enterprise business process
architecture standard. In : Services
Part I,
2008. IEEE Congress on, pp.239
246 (2008)
EARF: Enterprise Architecture Definition. In: Enterprise Architecture Research Forum.
(Accessed 2014) Available at:
S.: The Heart of Enterprise. Wiley (1979)
Alter, S.: The Work system method: Connecting people, processes, and IT for business
results. Work System Press (2006)
Osterwalder, A., Pigneur, Y.: Business Model Generation: A Handbook for Visionaries,
ame Changers, and Challengers. Wiley, Hoboken, NJ,US (2014)
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 Modeling, Stockholm, Sweden, Springer, LNBIP, vol. 214, pp.169-
183 (2015)
Give Team: Insightmaker. (Accessed 2014) Available at:
Box, G., Draper, N.: Empirical Model Building and Re
sponse Surfaces. John Wiley & Sons,
New York, NY. (1987)
Hoverstadt, P.: Why Business should take Enterprise Architecture seriously. In Gøtze, J.,
Waud, A., eds. : Beyond alignment, Systems Volume 3. College publishing (2013)
... The solution could be using lightweight enterprise modelling approaches that focus more on usefulness and impact, not on formal completeness and coherence [7]. A novel enterprise modelling technique called Fractal Enterprise Model (FEM) [9] could be particularly helpful, as it has been regarded as easily understandable for the people in the field and relatively easy to practice [10]. ...
... This does not exclude, however, usage of FEM by a novice analyst in smaller projects. The latter was tested in the practice of the second author while supervising Master students' thesis work that included using FEM, e.g., as described in [10]. ...
Conference Paper
Full-text available
Managing organisational change is becoming increasingly important in an ever-changing world. A novel "lightweight" enterprise modelling technique called Fractal Enterprise Model (FEM) can be helpful in this effort. This technique is formally established, but the range of application areas for it is not yet fully explored. This paper aims to fill the gap, at least partially. This goal is being achieved by using FEM in an industrial project in which a water utility company wants to digitalise its business operations and external communication. The paper follows the Action Design Research paradigm, which combines theory generation with solving organisational problems. The project was structured along a generic Business Analysis process and contained elements from a number of fields, such as requirements engineering, information systems engineering, enterprise architecture management, and business process management. The paper describes 11 different generic problems that were solved with the help of FEM, the project-specific constraints and how FEM was applied in the process. As the same person carried out both the research and the practical work, the usefulness of FEM is examined via reflecting on the experience and generalising the knowledge. FEM supported the business analysis activities by enabling quick and systematic information gathering and comprehensible communication with various internal stakeholders. These insights can be used as a guideline for future practitioners planning to use FEM and for conducting further research regarding the applicability of FEM.
... 2. Following a set of rules summarized in Table 4, detect potential structural couplings that the organization may have. Table 4 encompasses the rules from [13] and the ones added in Section 4. The last rule has been created based on [4], we do not have examples for this rule in [13] or this work, but a case that follows this rule is presented in [30]. 3. Investigate whether the indicated potential structural couplings are, in fact, structural couplings. ...
... Essential customer, new rule based on [4], an example is presented in [30]. Added here to cover all types of structural couplings listed in [4] ...
Full-text available
There are several ways of defining organizational identity and identity management. This article considers a less exploited one, namely, defining identity as a set of structural couplings that the organization has, and identity management as an activity aimed at maintaining these couplings. The concept of structural coupling comes from biological cybernetics, and it means that a system during its evolution becomes entangled with few other systems. The system at hand evolves together with these systems, adapts to them and causes them to adapt to it. The concept of structural coupling is applied in a study of an institution of higher education. To identify structural couplings, the authors use a so-called Fractal Enterprise Model that presents both internal structure of an organization and its business environment. The article analyzes to which elements of the environment an institution of higher education is structurally coupled and how the identity maintenance is arranged. The article provides examples of how well maintaining identity works in practice based on reflections on the authors' experience of working in the department. The article concludes with suggesting a generic procedure for identifying structural couplings and defining a strategy of maintaining these couplings.
... FEM as a language and notation is relatively mature, and it was used in a number of projects through the years, see, for example, [8]. Also, FEM is constantly revised and extended. ...
Conference Paper
Full-text available
While there are many tools that can depict a business process on any level of detail, there is lack of tools to depict and/or design process architectures - an interconnected set of business processes that exist or are to be introduced in an organization. The FEM toolkit bridges this gap by providing a tool for process architects to discover the process architecture of an organization as-is or to develop a new one. The FEM toolkit facilitates this by providing means to discover or develop a so-called Fractal Enterprise Model (FEM) for an organization. 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 machinery, etc.) and intangible (reputation, business process definitions, etc.). The FEM toolkit has been developed with the help of the metamodeling environment ADOxx. It was successfully used in a number of practically oriented projects and for teaching purposes.
... Readers who are interested in viewing examples from specific organizations are referred to other works devoted to FEM technique, e.g. [12], [17], [18]. ...
Full-text available
The article links two seemingly different fundamental theoretical concepts of autopoiesis and homeostasis and tries to apply them to the realm of socio-technical systems with the use of the Fractal Enterprise Model (FEM). Autopoiesis is the property of a system that constantly reproduces itself. Homeostasis describes a way a complex system constantly maintains its identity while adapting to changes in its internal and external environment. To be able to use FEM for this task, the original version of FEM has been extended by adding special elements for representing the system's context – part of the environment to which the system is structurally coupled. The approach taken in this article differs from other works in the same field in having the focus on the “body” (concrete elements being reproduced) of the socio-technical system, as well as on identifying concrete processes that reproduce the system, and demonstrating concrete ways of how a specific system adapts or can adapt to the perturbations in the environment (i.e. internal and external disturbances that affect the system).
... The result of this research produced more than a solution to the original problem, as FEM includes not only relations between the processes, but produces a map of assets usage and management in the organization. Therefore, we continue our work on FEM looking for other problems/challenges that can be solved using FEM; and enhancing FEM when necessary [37]. One example of a specific application of FEM is using FEM for business model innovation, see, for instance, [32]. ...
Full-text available
The article is devoted to developing a methodological support for planning Design Science (DS) research projects. More exactly, it is aimed at developing a classification of a particular kind of cycles, inherent to DS research projects, and guidelines on how to choose the next cycle in a specific project. The classification and guidelines are based on results from an analysis of DS literature and a reflective analysis of our own research practice. As far as own research practice is concerned, two DS projects have been analyzed in detail. The analysis revealed that though both projects included cycles, the nature of these cycles was different. In the first project, cycles concerned finding a better problem to solve, while in the second project, cycles concerned finding a better solution for more or less the same problem. Both projects concern developing methodologies in the area of socio-technical systems, and the guidelines on how to choose the next cycle have special provisions related to such systems. In conclusion, the article presents examples of other projects that followed the suggested guidelines and discusses the difference of the suggested approach from other approaches to conduct DS research projects.
Full-text available
Paper is in open access: This paper suggests a new type of enterprise models called fractal enterprise models (FEM), with accompanying methodological support for their design. FEM shows interconnections between the business processes in an enterprise by connecting them to the assets they use and manage. Assets considered in the model could be tangible (buildings, heavy machinery, etc.) and intangible (employees, business process definitions, etc.). A FEM model is built by using two types of patterns called archetypes: a process-assets archetype that connects a process with assets used in it, and an asset-processes archetype that connects an asset with processes aimed to manage this asset (e.g., hiring people, or servicing machinery). Alternating these patterns creates a fractal structure that makes relationships between various parts of the enterprise explicit. FEM can be used for different purposes, including finding a majority of the processes in an enterprise and planning business change or radical transformation. Besides discussing FEM and areas of its usage, the paper presents results from a completed project in order to test the practical usefulness of FEM and its related methodological support.
Full-text available
This chapter discusses why business leaders should take EA more seriously as a truly strategic discipline. The author argues that to manage a complex enterprise you must understand how it functions, and to understand it an adequate model designed for the purpose is needed. Also, you must have the right information on which to base decisions, and for the organization to provide that information reliably, an adequate model of the organization as a system is necessary to make any sensible judgment about the informational needs of strategic decision making.
Conference Paper
Full-text available
When an organization has not adopted a uniform and standardized way of producing and storing process documentation, keeping track of and maintaining process documents can be a real challenge. In this paper we suggest a framework for organizing process documentation which is created in different notations, for different purposes, and stored in different formats. We show how this framework has been applied in a real case in an organization where such problems are present. We discuss advantages and disadvantages of the framework and suggest further development and testing of the framework to improve its usability.
Piecemeal identification, development, and support of an organisation's processes may lead to problems: first, it may be difficult to identify which processes should be supported, and, second, it is unlikely that processes developed piecemeal will either optimise the achievement of an organisation's objectives, or work well together. One solution involves identifying and modelling an organisation's process architecture, and then using it to develop and subsequently support the constituent processes. However, this solution leads to a new challenge: a number of different types of process architecture method have been proposed, but it is not clear which should be used in a given situation. To address this challenge, the article outlines a framework for classifying, evaluating, and comparing process architectures. Following the work of Rolland et al.(1998), the proposed framework considers process architecture methods from four different views: contents, form, purpose, and lifecycle. To partially validate the framework, it was used to classify and evaluate Riva (Ould 2005), a particular process architecture method. The result of this application of the framework suggests how it might be refined. It could then be used for comparing other process architecture methods. Such a comparative analysis should help practitioners choose between process architecture methods. Copyright © 2005 John Wiley & Sons, Ltd.
Conference Paper
An effective process architecture helps provide a high-level blueprint of the complexity underlying an enterprise, which is used by executive committees during key decision and change processes. As existing service standards focus on co-ordination, they fall short in describing the motivational structure depicted in such models. In order to progress towards standardization in this area of complexity, we discuss the ldquopracticalityrdquo of a process architecture, and present a set of 22 questions that can be used in the functional evaluation and construction of a process architecture. We use these questions to evaluate the current "state-of-the-art'' in business process architecture. We then apply the knowledge gathered during our evaluation and other work to develop the proposal for a general mapping framework that is capable of answering the set of queries we have proposed.
The Work System Method: Connecting People, Processes, and IT for Business Results
  • S Alter
Alter, S.: The Work system method: Connecting people, processes, and IT for business results. Work System Press (2006)