ChapterPDF Available

Structural Coupling, Strategy and Fractal Enterprise Modeling


Abstract and Figures

The concept of structural coupling, which comes from the biological cybernetics, has been found useful for organizational decision making on the higher level, such as management of organizational identity and strategy development. However, currently, there is no systematic procedure for finding all elements (other organizations, markets, etc.) of the environment to which a given organization is structurally coupled, or will be coupled after redesign. The paper tries to fill the gap by employing enterprise modeling to identify structural couplings. More specifically, an extended Fractal Enterprise Model (FEM) is used for this end. FEM connects enterprise processes with assets that are used in and are managed by these processes. The extended FEM adds concepts to represent external elements and their connections to the enterprise. The paper drafts rules for identifying structural couplings in the model by analyzing FEMs that represent different phases of the development of a company which the author co-founded and worked for over 20 years.
Content may be subject to copyright.
The final version was published and copyrighted by Springer in LNBIP Vol 385, pp 95-111
DOI: 10.1007/978-3-030-50316-1_6
Structural Coupling, Strategy and Fractal Enterprise
Ilia Bider
DSV - Stockholm University, Stockholm, Sweden
Abstract. The concept of structural coupling, which comes from the biological
cybernetics, has been found useful for organizational decision making on the
higher level, such as management of organizational identity and strategy
development. However, currently, there is no systematic procedure for finding
all elements (other organizations, markets, etc.) of the environment to which a
given organization is structurally coupled, or will be coupled after redesign. The
paper tries to fill the gap by employing enterprise modeling to identify structural
couplings. More specifically, an extended Fractal Enterprise Model (FEM) is
used for this end. FEM connects enterprise processes with assets that are used in
and are managed by these processes. The extended FEM adds concepts to
represent external elements and their connections to the enterprise. The paper
drafts rules for identifying structural couplings in the model by analyzing FEMs
that represent different phases of the development of a company which the author
co-founded and worked for for over 20 years.
Keywords: Strategy, organizational identity, enterprise modeling, structural
coupling, socio-technical, fractal enterprise model, FEM, enterprise engineering
1 Introduction
The concept of structural coupling comes from biological cybernetics, more
specifically, from the works of Maturana and Varela, see, for example, [1]. The idea of
structural 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. Moreover,
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. According to Luhmann [2], a system
deliberately chooses to limit its couplings to few elements, as a strategy of dealing with
the complexity. These elements, in turn, function as information channels to other parts
of the environment.
An element of the environment to which a system becomes coupled, being a system
on its own, may, in turn, adjust its structures to the given system, which creates
interdependency between the two structurally coupled systems. The process of
emergence of the structural coupling during the co-evolution of two interacting systems
is represented in Fig. 1. As the result of mutual interdependency, the structurally
coupled systems change together, one changing itself as a reaction on changes in the
other. The coupling might not be symmetrical, i.e. one system may dominate the other,
making it more likely that the latter would change as a reaction on changes in the
former, than vice versa.
Fig. 1. Emergence of structural coupling. Adapted from [3].
The concept of structural coupling along with other concepts developed by Maturana
and Varela, such as autopoiesis, was adopted by other fields that use system theoretical
concepts. A typical example is Social Science, to which this term was brought by N.
Luchmann, see, for example, [2]. However, in the domain of organizational systems,
which are socio-technical systems, the usage of the concept of structural coupling is not
widely spread. Actually, we have found only two works that apply the concept of
structural coupling to the organizational/business world [4], [5].
The first work [4] suggests using the concept of structural coupling for the purpose
of defining the notions of organizational identity and identity management. According
to Hoverstadt [4], the identity is defined as a set of structural couplings an
organization/enterprise has to other systems/agents in the organizational/business
world, such as markets, customers, partners, vendors, regulators. The identity
management is defined as activities aimed at maintaining the structural couplings in the
dynamic environment, i.e. reacting on changes in the structurally coupled systems, or
inducing changes in them when making changes in their own structures.
The second work [5] defines the strategy as a goal of reaching a certain position in
relation to the structurally coupled elements of the environment, such as customers,
partners, competitors, supplies etc. As an example, consider a segment of market where
there is a "herd" of similar companies. Then a position in relation to the herd can be
defined as a "leader", "in the middle", "independent", etc. [5] presents around 80
patterns of strategy to choose from, alongside with the requirements on what is needed
to implement each pattern.
As far as applying the concept of structural coupling to identity management, we
have followed up this idea in own research [6]. Here, we have achieved some success
by explaining a number of changes completed in our department under a couple of
decennia as reactions on the changes in the structurally coupled elements of the
environment. As far as using structural coupling in strategic decision making, though
we have not followed it up in any finished research, the idea seems promising.
In connection to the application of the concept of structural coupling to the
organizational/business world, a question arises on how to find all structural couplings
of a given organization/enterprise. This is important for both identity management and
strategic decision-making, including situations when a change in the structural
couplings of the organization is planned. As the idea of using the concept of structural
coupling is not spread in the Management, IT or Information Systems research fields,
we could not find any answer on the question above in the research literature.
Hoversadt and Loh [5] suggest a practically-oriented way of looking for structural
couplings that is based on the structure of the business/organizational world. More
specifically, dependent on the desired strategy, they suggest looking for main
competitors, regulators, key partners, key customers, and key market segments. Our
work [6] suggests another approach for finding structural couplings, which is based on
finding who is producing inputs for the organizational activities, and who is consuming
outputs of the organizational activities. In addition to the input/output approach, a
position of the organization in a larger system is determined in accordance to the Viable
System Model [7]. The latter gives a hint to find out structural couplings that are
connected to the management level of the larger system. Also, a geographical position
of the organization is considered to see whether there is a structural coupling to the
Both approaches - from [5] and from [6] - can be used in practice, but both have their
drawbacks. The approach presented in [5] is pragmatic, but it requires good
understanding of organizational/business world. While it can be successfully used by
experienced people, e.g. expert management consultants, it might be not as good for
less experience people, for example, new entrepreneurs. There is a risk that some
important structural couplings would remain outside the consideration when discussing
the strategy. The approach from [6] is more formal, i.e. defined on a more abstract level.
It does not employ such notions as supplier, partner, market, etc., but rely on formal
notions of input, output, position in the larger system, and geographical location.
However, using this approach alone, though it worked well in a case of an institution
of higher education, may result in missing some important structural connections, like
partners. It also does not guarantee that all important inputs and outputs will be taken
into the consideration.
The question arises whether it is possible to develop a more systematic and
comprehensive method for identifying if not all, than the major part of structural
couplings of an organization. A possible way of designing such a method is via using
an enterprise model of some sort that depicts not only internal components of the
organization, but also components of the environment. Having such a model, it might
be possible to add a set of rules that determine which components of the environment
constitute structural couplings. The goal of this paper is to investigate whether a
particular enterprise modeling technique could be useful for this end. The technique in
question is called extended Fractal Enterprise Model (FEM) [8].
FEM has a form of a directed graph with two types of nodes processes and assets,
where the arrows (edges) from assets to processes show which assets are 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.
Choosing the FEM technique as the first one to try has two reasons. Firstly, the
author belongs to the team that has developed and is continue developing FEM. Thus,
there is a personal interest to start the trial with FEM. Secondly, recently, we tried to
apply FEM to explain autopoiesis [1] and homeostasis [9] in socio-technical
(organizational) systems [10]. This research has resulted in an extension of FEM that
allows to represent in the model, at least, some part of the organizational context. This
is done with the help of two new notions added to FEM – an external pool and an
external actor. With this extension, FEM seems enough equipped to be tested as a
means for finding structural couplings of an organization.
Our approach to conducting a trial is pragmatic, we take a real case, build relevant
fragments of FEM for this case and see whether we can identify structural couplings in
the model. Then, the findings are generalized as a set of rules on how to determine
structural couplings more formally.
The rest of the paper is structured in the following way. In Section 2, we give an
overview of FEM with the extension suggested in [11]. In Section 3, we discuss our
research approach and business case to be used. In Section 4, we build a FEM model
for our business case and analyze structural couplings of the company in the center of
the business case. In Section 5, we draft rules of identifying structural couplings
through generalizing what has been discovered in the previous section. In Section 6, we
summarize our contribution and draft plans for the future.
2 Extended Fractal Enterprise Model - an Overview
2.1 Basic Fractal Enterprise Model
The original version of Fractal Enterprise Model (FEM) from [8] includes three types
of elements: business processes (more exactly, business process types), assets, and
relationships between them, see Fig. 2 in which a fragment of a model is presented. The
fragment is related to the business case analyzed in this paper, and it represents the
model of initial business design of a Swedish consulting company called IbisSoft [12].
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
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,
and 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 affected, for example, the
label acquire identifies that the process can/should increase the pool size.
Note that the same asset can be used in two different processes playing the same or
different roles in them, which is reflected by labels on the corresponding arrows. It is
also possible that the same asset can be used for more than one role in the same process.
In this case, there can be more than one arrow between the asset and the process, but
with different labels. Similarly, the same process could affect different assets, each in
the same or in different ways, which is represented by the corresponding labels on the
arrows. Moreover, it is possible that the same process affects the same asset in different
ways, which is represented by having two or more arrows from the process to the asset,
each with its own label. When there are too many arrows leading to the same process
or asset, several copies can be created for this process or asset in the diagram. In this
case, the shapes for copies have a bleaker color than the original, see asset Reputation
as a good system vendor in Fig. 2 that appears in two places.
Fig. 2. A fragment of a FEM for IbisSoft
In FEM, different styles can be used for shapes to group together different kinds of
processes, assets, and/or relationships between them. Such styles can include dashed or
double lines, or lines of different thickness, or colored lines and/or shapes. For example,
a diamond start of an arrow from an asset to a process means that the asset is a
stakeholder of the process (see the arrows Workforce in Fig. 2).
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) are standardized. This is done
by using a relatively abstract set of relationships, 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 a number of types of relationships that show how an asset is used in
a process (see example in Fig. 2), 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 the kinds of assets that can be used in
a given category of processes. The asset-processes archetype shows the kinds of
processes that are aimed at changing the given category of assets. The whole FEM
graph is built by alternative application of the two types of archetypes in a recursive
manner. Actually, the term fractal in the name of our modeling technique points to the
recursive nature of the model, for more detailed explanation, see [8].
Note that in FEM, each process node represents a socio-technical system, while the
assets connected to it with solid arrows represent different sides of this system, e.g.
people (workforce), technology (technical and informational infrastructure). However,
there is no explicit graphical representation of these assets being aligned between
themselves. Implicitly, such alignment is presumed, however, as it is necessary for a
process being able to function properly. Moreover, changes in any of the assets
connected to a particular process node, e.g. people or technology, require readjustment
of other assets connected to the node. This issue is covered in more details in [13].
Hereby, we finish a short overview of the standard FEM. The reader who wants to
know more about the model and why it is called fractal are referred to [8] (which is in
Open Access), and the later works related to FEM.
2.2 Extensions to FEM for Representing the Context
Two new concepts were introduced to FEM in order to represent the business context
of the organization and connect it to specific processes [11]. These are as follows:
External pool, which is represented by a cloud shape, see Fig. 2. An external pool is
a set of things or agents of a certain type. As an example, in Fig. 2, there are two
such pools: (1) pool of organizations that needs an information system, (2) pool of
software developers looking for a job. 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 a label
starts with indefinite article "a" or "any", the box represents a set of agents of the
given type, see Fig. 2, which have three external actors 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 acquire process,
see two examples of such relations in Fig. 2.
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 two examples
of such relations in Fig. 2.
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 provides
entities to the external pool (there are no examples of such relations in Fig. 2, but an
example of this type will be introduced later).
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.
2, but an example of this type will be introduced later).
External pools and actors represent the context in which an organization operates.
External pools can be roughly associated with markets, 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, or an external actor. The difference reveal itself in how the organization
is connected to the internal processes; an external actor is always connected via an
external pool.
3 Research Approach
The research presented in this paper belongs to the Design Science (DS) paradigm
[14,15], which focuses on looking for generic solutions for problems, known, as well
as unknown. The result of a DS research project can be a solution of a problem in
terminology of [15], or artifact in terminology of [14]; alternatively, the result can be
in form of "negative knowledge" stating that a certain approach is not appropriate for
solving certain kind of problems [15].
This research is part of a broader undertaking connected to FEM. Initially, FEM has
been developed as a means for finding all or majority of the processes that exist in an
organization. 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. One example of a specific application of FEM,
beyond already mentioned work on autopoiesis [11], is using FEM for business model
innovation, see, for example, [16]. From the point of view of classification of DS
opportunities introduced in [17] and adopted in [15], we use exaptation (in terminology
of [17]) or transfer (in terminology of [15]), which amounts to extending the known
solutions to new problems, including adapting solutions from the other fields/domains.
According to both [15] and [17], exaptation provides a research opportunity.
From the pragmatic point of view, our research is directed from a specific case to a
generic solution through the generalization of the specific case. More exactly, we take
a real business case, build relevant fragments of FEM for it, and then review them in
order to mark FEM components that represent structural couplings of the organization.
After that, we specify properties of these components that can serve as generic
indicators for a component being a structural coupling. To be able to fulfill the plan,
we need a case for which we can gather enough information to be able to determine
structural couplings. Identification of structural couplings requires observation of the
system in the environment for some period of time, as only in this case, we can see
whether the system adjusts its structures to some elements of the environment and/or
affects (indirectly) the structure of these elements.
To satisfy the requirements on the case, we have chosen a case from own practice.
More specifically, the case used in this research is a small Swedish IT consultancy
called IbisSoft [12], which was cofounded by the author of this paper and for which he
worked for more than 20 years in the period from 1989 to 2011, as a technical leader,
as well as a business and IT consultant and software developer. Due to my position in
the company, I have intimate knowledge on the strategic and tactical decisions made
during this period, and was partly responsible for successes and failures that resulted
from these decisions. The eight years have passed after my leaving IbisSoft, which
creates enough distance for analysis and reflection to be independent from the feelings
of the days of personal engagement in the everyday business activities of the company.
Note that as the business case has been taken from the practical experience of the
author, we can regard, at least partly, our research approach as reflective theory building
[18]. The latter does not change the fact of our research belonging to the DS paradigm.
4 Building and Analyzing IbisSoft's FEMs
4.1 Initial strategy design
Ibissoft [12] was started as small consultancy with four partners in April 1989. The
primary process was envision as developing a new kind of business information
systems. The latter was reflected in the company's name IbisSoft, where Ibis, besides
being a bird with connotation to the Egyptian god of wisdom Thoth that had an Ibis
head, served as an abbreviation to Integrated Business Information Systems. The
primary business design in FEM terms is represented in Fig. 2. IbisSoft was to develop
a new kind of business information systems to the customers. Getting the first relatively
small order, IbiSoft started system development of a new kind.
As the company had very small staff - two full time employees and some partners
that could be engaged, the company needed a high-level system development tool (of
the 4th GL kind) to achieve the necessary productivity level. After thorough
investigation of the tools market, a particular tool from an US company JYACC (Just
Your Average Consulting Company), called JAM (JYCC's Application Development)
was chosen. Later, the company, as well as the tool were renamed to Prolifics [19],
which is reflected in Fig. 2. After some more time, the product was once more renamed
to Panther [20], which will not be used in any figures in this paper.
4.2 Strategy for growth
While the first system was under development, the IfbiSoft's board needed to design a
strategy for continuing and expanding the company's operations. As the tool acquired
for own system development showed to be quite good, the following strategy had been
decided on and implemented. IbisSoft becomes a reseller of JYACC's tools in Sweden.
This would require setting a business of selling JAM licenses, and at the same time
setting a consulting business to help the customers that have bought JAM licenses to
start using JAM and successfully complete their system development projects. The idea
was (a) to get cash flowing in the company from reselling, and, in a higher degree, from
consulting, and (b) get in touch with organizations, some of which could become
customers for the main business activity depicted in Fig. 2.
The strategy was fully implemented as shown in Fig. 3, which depicts two
interconnected primary processes. One is related to selling licenses, the other is
technical consultancy for the companies that already have the JAM/Prolifics licenses.
Actually, the first process could be split into two, the second concerns providing
support on the subscription bases, but we will not go into this level of details here.
As we see from Fig. 3, the two processes are synergetic. Selling JAM/Prolifics adds
new actors to the pool of companies/organizations who use the tools in their system
development processes. This pool is used to recruit new customers for the consulting
services. For our Swedish market, the major part of this pool was created by our own
sales, however, sometimes we got a request from a potential customer that had acquire
a license in a different way. Another synergy consists in our efforts to demonstrate the
consulting customers how to use JAM/Prolifics in the best possible way, thus helping
to create a reputation of it being an excellent tool. This, in turn, helped to conduct the
license sales, as there were enough happy customers to whom we could refer.
The design in Fig 3 worked well enough for arranging a cash flow and ensuring some
basis for expansion. As far as the second purpose was concerned, i.e. getting customers
to the business depicted in Fig. 2, it does not work well. In retrospective, the design
error is quite clear, as depicted in Fig. 4. Namely, the pools from which JAM/Prolifics
consulting sales and system development sales acquired customers did not have much
intersection. Therefore, most of the customers acquired for JAM/Prolifics consulting
were not interested in purchasing development of a new system. The only synergy
between the consulting and system development processes that really worked was the
JAM/Prolifics consulting served as a maintaining process for the software developers,
as it increased their expertise in the use of the tool, which was also used in own system
Fig. 3. Strategy for cash flow and getting in touch with potential customers
4.3 Back to system development
Implementing the strategy described in the previous strategy resulted in IbiSoft being
stuck with the business activities depicted in Fig. 3 for many years. Actually, they were
expanded by recruiting additional staff to deal with JAM/Prolifics consulting projects,
but they took all resources that were at IbiSoft's disposal at the time. As the original
business activity in Fig. 2 had no synergy with the expanded business, the sporadic ad-
hock attempts to get orders for the system development activity were unsuccessful.
Fig. 4. Comparison between two sales processes
The business situation changed by the end of 1990ths in two aspects, one external and
one internal:
1. The market for high-level system development tools (4th GL and similar) crashed
due to appearing WEB, Java and Java script, i.e. system development went back to
using low-level programming. Measures taken by Prolifics to adjust to the new
deployment platform (WEB), i.e. creating a module for the WEB deployment, did
not help much against aggressive marketing for JAVA development. This affected
the size of the pool "Swedish companies/organizations looking for high-level system
development tools, e.g. 4GL" in Fig. 3, which, in turn, led to substantial decrease in
sales of the tools licenses. However, support and consulting continue to give
revenues due to the existent customer base. The crash of the market for the old school
high-level development tools was substantial all over the world. In the end, this
resulted in Prolifics ceasing to exist as a tool vendor and transforming itself into a
consulting company, see [16].
2. The principles of the new kind of information systems to be produced by the business
activity in Fig. 2 were re-conceptualized as principles of building a new kind of
business process support systems. Based on the reconceptualization, a new way of
looking at, modeling and supporting business processes was developed, which was
later dubbed as a state-oriented view on business processes (see [21] for a historic
overview). The state-oriented modeling of business processes has been tested in
practice and got positive feedback from the customers, see [22].
New business situation required changes in the strategy. Reselling JAM/Prolifics was
put on hold. No active marketing and selling was done, though we continued providing
technical support to the existing customers. Tool consulting was continued for the
existing customer base for quite some time. New activity was designed to deliver
process models for the customers' processes. The thinking behind it was that some of
the customer could decide to purchase a system from IbisSoft to support their
process(es). The new strategy, which has been successfully implemented, is presented
as a FEM diagram in Fig. 5.
Fig. 5. New strategy
The FEM fragment at the bottom of Fig. 5 represents a revised version of the diagram
in Fig 2. The upper part represents a new business activity - providing the customers
with models of their business processes. The difference between the new design and
the original one, as in Fig. 2, is as follows.
The system development activity is supported by process modeling activity.
Organizations that have completed their process modeling and redesign projects
might be more willing to take the next step and introduce a computerize support for
their processes. This is represented by a pool of companies that want/are ready to
introduce computerized support for their process, and two arrows that connect it to
the IbisSoft's activities. The first arrow goes from the process modeling activity to
the pool; it shows that this activity adds new organizations to the pool. The second
arrow shows that the sales process for system development uses the pool to fill the
customer asset for the system development activity. Note that other companies, e.g.
management consultants that design process models, can also add to this pool.
The pool from which the system development sales acquires new customer is much
more strictly defined than it is in Fig. 2. Namely, it consists of organizations that
want to acquire support for their business processes. As the concept of business
process management had been already established by the time the new strategy was
put to implementation, it was much easier to conduct the sales activities.
4.4 Identifying IbisSoft's structural couplings
Analyzing FEMs for different phases of IbisSoft's evolution, we can identify the
following three main components that represent the company's structural couplings:
1. Asset JYACC/Prolifics. This asset is present in all FEM fragments depicted in Fig.
2, 3 and 5, but the nature and the strength of the coupling differ from fragment till
fragment. In Fig. 2 and 5, the coupling is due to JAM/Prolifics is used as an internal
tool for system development. JYACC/Proifics was the partner who ensured that the
tool worked by producing bug fixes and new releases that allowed to move our own
applications to new platforms, e.g. Windows. As the tool was chosen based on
specifics of the systems being developed and we invested much time in learning to
use it, the tool was an essential part of the business, and it was not easy to substitute
it by any other tool. In the beginning, JYACC/Prolfics was the only agent that could
maintain the tool, due to it being a proprietary software. At the end of our usage of
the tool, the dependence on JYACC/Prolifics had been substantially lowered, due to
the source code was published at some point of time, and we were able to fix or
enhance the tool ourselves.
For the first business process in Fig. 3 selling licenses JYACC/Prolifics was a
partner without which it could not function. We could not substitute this partner
without stopping selling the JAM/Prolifics licenses. For the second process, we were
as dependent on JYACC/Prolifics as in the activities depicted in Fig. 2 and 5.
2. Asset Swedish companies/organizations looking for high-level system development
tools, e.g. 4GL. This external pool from Fig. 3 represents the market for the process
of selling tools licenses. The structural coupling to this market caused the process
removal when the market crashed. The second business activity in Fig. 3 – consulting
– continued after the crash, as the pool of companies/organizations that had
JAM/Prolifics in their development processes continued to exist for quite a time.
Indirectly, through the pool/market of tool seekers, IbisSoft was also connected to
all external actors whose efforts were directed to fill the pool. Here belong all our
competitors that advertised and promote their tools, thus inspiring customers to look
wider and compare different tools before buying a license.
3. Asset Companies/organizations that want/need to have process models. This
external pool from Fig. 5 represents the process modeling market. The whole
strategy presented in Fig. 5 was dependent on the existence of this market. Indirectly,
IbisSoft was also coupled to all actors that were "boosting" this market, e.g.
management consultants establishing the needs to have processes modeled.
5 Rules for Identifying Structural Couplings
Suppose we have built a FEM for an essential part of the business activities of an
organization that includes the important external elements – pools and actors. Then, we
can use the model to identify structural couplings based on the rules presented in the
sub-sections that follows. These rules are obtained through generalization of findings
from section 4.4, while taking into consideration suggestions from [5] and [6].
5.1 A partner asset as a structural coupling
This rule is based on generalization of the first structural coupling from Section 4.4 and
ideas on looking for key partners, vendors, customers from [5]. The rule is formulated
as follows. If in a FEM of an organization:
1. there is an essential asset, which is impossible or difficult to substitute for some other
(e.g. similar) asset, and
2. one or several processes that are used to manage this asset, i.e. Acquire, Maintain or
Retire, have a Partner asset that is difficult or impossible to remove or substitute,
then the organization is structurally coupled to the Partner asset.
A partner that constitutes a structural coupling can be a vendor of essential
infrastructure component, as in case of JYACC/Prolifics in Fig. 2 and 5. It can, also, be
a vendor that delivers important spare parts, formally, it will be a partner in an Acquire
process that manages the stock of spare parts. It can also be a key customer, if the
company relies on a small number of existing customers. In this case, the customer will
be a partner of an Acquire process for the stock of orders for products or services.
IbisSoft had some such customers, but for simplicity, we have not placed them in Fig.
3 and 5.
5.2 An external pool as a structural coupling
This rule is based on generalization of the second and third structural couplings from
Section 4.4 and ideas on looking to key markets from [5]. The rule is formulated as
follows. If in a FEM of an organization:
1. there is an essential process, which is not easy to remove, and
2. this process has an essential asset with high rate of depletion, which needs to be
constantly filled, and which is not possible or not easy to remove or substitute, and
3. an Acquire process for this asset is connected to an external pool from which it is
getting new elements to fill the asset
then the organization is structurally coupled to the pool.
As an example, a pool of seekers of the high-level tools in Fig. 3 satisfies this rule.
As most licenses were sold to new customers, the sales process needed to get both a
new customer and a new order at the same time to fill the stock of orders and get new
customers to provide support to. Note that the essential asset in the rule needs not to be
of the stock type; for example, it can be a pool of work seekers, in case the turnover of
workforce for an essential process is high.
Besides being coupled to an external pool as an input, an organization can be
structurally coupled to a pool where one of its outputs, e.g. waste, goes, as discussed in
[4]. A typical example of such coupling is an institution of higher education that
provides new entities to a work seekers pool, see Fig. 2, as an overflow of this pool (not
enough job for the graduates) will substantially affect the business. Due to the space
limitation, we do not express this rule formally here.
5.3 External actors as structural couplings
The external actor rule is based on formalization of the input/output approach presented
in [6], and we do not have examples of this rule in the business case of Section 4. The
coupling is indirect – through an external pool. This rule is formulated as follows:
If an organization is structurally coupled to an external pool, it may also be structurally
coupled to the actors that fill this pool, or draw from the pool (e.g. competitors).
Note that the coupling can be quite strong if there are only few actors filling or drawing
from the pool. For example, only few educational institution preparing people for a
certain profession (filling the pool), only few companies dealing with the waste
produced (drawing from the pool) or only few companies that employs the graduates
from the educational institution (drawing from the pool).
6 Concluding remarks and plans for the future
We started the paper with identifying the gap of absence of a systematic procedure that
helps to identify structural couplings of an organization. This gap, though not much
important for experienced management consultants, might be a barrier to use the
concept of structural coupling in strategy development by less experience people, e.g.
new entrepreneurs. To fill the gap, we suggested to use enterprise modeling for the
purpose of creating a systematic procedure. As a starting point, we used FEM for this
end. We drafted a set of formalized rules for identifying structural couplings based on
the analysis of a business case that depicts the strategy evolution of a small company.
In addition to analysis of the business case, ideas from [5] and [6] have been used.
Our work on the set of rules for identifying structural couplings is in progress, and
our current results have a number of limitations. Firstly, while it covers most of the
pragmatic rules from [5], it does not cover the one that concerns regulators. The same
is true in connection to [6], our rules cover structural couplings based on input/output
relationships, but they do not cover couplings related to the position in a bigger system,
and geographical location. The question whether the excluded couplings can be
detected via FEM remains open, and may have a negative answer. Getting a clearer
answer on this question is included in our plans for the future research.
Secondly, the rules we created require more thorough validation, as the business case
that we have used for their design can be considered only as a limited validation/
demonstration of their practical usefulness. The existence of this case is an important
factor for showing that the rules are not arbitrary, but are rooted in practice. However,
this might not be enough to convince other practitioners on the solidness of the
approach and its usefulness for practice.
From the point of view of Design Science Research (DSR), we can interpret this
work using an approach suggested in [15] that describes a DS project as movement
inside and between two worlds: (a) the real world of specific problems and solutions in
local practices, and (b) the abstract world of generic problems and solutions. Each of
the two worlds can be represented by a state space with three coordinates: (1) situation,
(2) problem, and (3) solution.
In the state space of the abstract world, we have reached a point, called a hypothesis,
with coordinates: (1) generic situation: an organization, (2) generic problem: need to
find structural couplings of the organization, (3) generic solution: build FEM for this
organization and apply rules from Section 5. For this hypothesis, we determined one
point in the state space of the real world, called a test case, that instantiates the
hypothesis. This point has the flowing coordinates: (1) concrete situation: IbisSoft, (2)
concrete problem: finding structural coupling of IbiSoft (3) concrete solution: build
FEM for IbiSSoft and get structural couplings according to rules from Section5. This
test case, can be assigned weight +1 (the instantiation supports the hypothesis), as the
application of the instantiated solution results in a right set of structural couplings for
From the two worlds point of view, it does not matter whether we (a) first created a
generic solution based on previous works in the area and some logical analysis, and
then applied it to IbisSoft, or (b) first worked on the level of a concrete company ibiSoft,
and then generalized it to obtain a set of generic rules. In this paper, we have chosen to
show the actual way of how the research has been conducted; however, the direction
does not matter for the end result. Note also that the result achieved has an additional
validation that consists of the rules suggested in this work, at least partially, covering
empirical/pragmatic rules from [5] and [6].
Two direction are planned for farther validation. Firstly, conduct case studies that
(a) start with building FEMs and (b) end with the stakeholders agreeing on the identified
structural couplings really being important elements of their business context.
Secondly, we plan to present the approach to the experienced management consultants
and ask their opinion on the suggested procedure.
Besides helping to create a set of rules for identifying structural couplings, our
business case has shown other ways of using FEM in strategy development. Namely,
FEM could be used for identifying the presence or absence of the synergy between
different organizational activities. We plan exploring this new opportunity to extend
the area of FEM application in practice.
Acknowledgements. The author expresses his gratitude to the anonymous reviewers
whose comments helped to improve the text.
Maturana, H.: Autopoiesis, Structural Coupling & Cognition. Cybernetics & Human
Knowing 9(3
4), 5
34 (2002)
N.: Introduction to Systems Theory. Polity Press (2013)
Fell, L., D, R.: An introduction to ‘Maturana's’ biology. In : Seized by agreement, swamped
by understanding. Hawkesbury, Sydney (1994)
4. Hoverstadt, P.: Defining Identity by Structural Coupling
in VSM Practice. In : UK Systems
Society, Oxford (2010)
Hoverstadt, P., Loh, L.: Patterns of Strategy. Taylor & Francis (2017)
Bider, I., Perjons, E.: Using Structural Coupling Approach for Defining and Maintaining
Identity of an Educational Insti
tution. Experience Report. In : STPIS'18, vol. CEUR, Vol
2107, pp.24
39 (2018)
Beer, S.: The Heart of Enterprise. Wiley (1979)
Bider, I., Perjons, E., Elias, M., Johannesson, P.: A fractal enterprise model and its
application for business developme
nt. SoSyM 16(3), 663
689 (2017)
Cannon, W. B.: The Wisdom of the Body. Norton & Company, New York (1939)
Bider, I., Regev, G., Perjons, E.: Linking Autopoiesis to Homeostasis in Socio-
Systems. In : STPIS 2019, Stockholm, vol. CEUR Vol. 2
398, pp.160
170 (2019)
Bider, I., Regev, G., Perjons, E.: Using Enterprise Models to Explain and Discuss
Autopoiesis and Homeostasis in Socio-
Technical Systems. Complex Systems Informatics
and Modeling Quarterly, Issue 22 (2020)
Ibissoft AB In: I
bissoft. Available at:
Bider, I., Perjons, E.: Using Fractal Enterprise Model to Assist Complexity Management.
In : BIR Workshops 2018, CEUR, Stockholm, vol. 2218, pp.233
238 (2018)
Hevner, A., March, S. T., and, P.: Design Science in Information Systems Research. MIS
Quarterly 28(1), 75
105 (2004)
Bider, I., Johannesson, P., Perjons, E.: Design science research as movement between
individual and generic situation-problem-solutio
n spaces. In : Organizational Systems. An
Interdisciplinary Discourse. Springer (2013) 35
Bider, I., Perjons, E.: Defining Transformational Patterns for Business Model Innovation.
In : Perspectives in Business Informatics Research: 17th Internation
al Conference, BIR
2018, Stockholm, Sweden, LNBIP, vol. 330, pp.81
95 (2018)
Anderson, J., Donnellan, B., Hevner, A. R.: Exploring the Relationship between Design
Science Research and Innovation: A Case Study of Innovation at Chevron. In :
ons in Computer and Information Science, 286, pp.116
131 (2012)
Mott, V.: Knowledge comes from practice: Reflective theory building in practice. In
Rowden, R. W., ed. : Workplace learning: Debating five critical questions of theory and
practice. Josse
Bass, San Francisco, CA (1996) 57
Prolifics In: Prolifics. Available at:
Prolifics: JAM/Panther Tools. In: Prolifics. Available at:
Bider, I.: In Search for a Good Theory: Commuting between Research and Practice in
Business Process Domain. In : Enterprise, Business-
Process and Information Systems
Modeling. BPMDS 2011,
EMMSAD 2011., London, UK, vol. 81, pp.16
30 (2011)
Andersson, T., Andersson-
Ceder, A., Bider, I.: State flow as a way of analyzing business
case studies. Logistics Information Management 15(1), 34
45 (2002)
... Hereby, we finish a short overview of the standard FEM. The reader who wants to know more about the model and why it is called fractal are referred to [5] and the later works related to FEM, some of which extend FEM to represent the business context in which an organization operates [10], [11]. ...
... The second phase is developing a method of using FEM for this purpose, provided that the case study has confirmed that FEM could be useful in the context. One of the areas where such methodology was exploited is using FEM for Business Model Innovation (BMI), see [11], [15], [16]. The current paper concerns the second phase of developing a method for using FEM in operational decision-making. ...
... For example, sales may need to be in close proximity with the pool of potential customers. Such condition may be expressed in terms of two new concepts -external pool and external actor -introduced in [11], see Fig. 12. The cloud shape in Fig. 12 represents external entities that can become elements of an Asset via an Acquire process. ...
Full-text available
A pattern is a concept widely used in engineering and other disciplines for variety of purpose, e.g. business or system analysis. In this work, we present the concept of patterns usage within enterprise modelling. The undertaking is a part of the larger case study dedicated to Fractal Enterprise Modelling (FEM) development deploying Design Science (DS) research methodology. Based on the case study, we have identified three FEM related patterns: one modelling pattern and two analyzing patterns. A modeling pattern advises on a proper way of building a model for a particular purpose, while an analysis pattern helps to find places in a business where a decision could/should be made. More precisely, the modelling pattern identified in this study helps to build a model on an appropriate level of granularity for a certain purpose (operational decision-making). The analysis pat-terns identified in the study are divided into two categories of patterns: transformational patterns and problem patterns. Transformational pattern is a pattern that contains a condition and an action parts that represent a standardized solution or an opportunity. Problem pattern is a pattern that expresses conditions where a problem might exist without specifying a definite action. These patterns contribute into the creation of the bank of patterns to guide practitioners in modelling and analyzes of the business situations using FEM.
... Though FEM already existed at the time we worked on [10], it did not have enough concepts to cover structural couplings. In the latest works [12], [13], FEM has been extended with new concepts that allows to use it for identifying structural couplings. In this article, we use the same business case and the same decisions that were analyzed in [10], but we do it in a different way. ...
... Due to having the same topic, business case and examples, the current article can be considered as an extension of [10]. At the same time, it can be considered as continuation of [13], as it adds additional rules to how identify structural couplings based on FEM. ...
... This project has already had a number of cycles of the Problem seeking type in the classification from [16], where FEM was tested for solving various problems. In respect to the FEM project, the current article continues the works started by [12] and [13], which have extended FEM in a way that it becomes possible to use it in combination with the concept of structural coupling. ...
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.
... An external pool can represent a market segment, e.g., a labor market, and an external actor can represent an external organization or private person acting on the market. The extended FEM showed to be useful for strategic work [4] [5]. ...
... In this section, we give an overview of Fractal Enterprise Models (FEM) introduced in our earlier works, especially in [3], and in the extended form in [4]. FEM includes five types of elements: business processes (more exactly, business process types), assets, external pools, external actors and relations between them, see Fig. 1 in which a FEM of an institution of higher education is presented, the example being taken from [5]. ...
Conference Paper
Full-text available
If an Enterprise Model is to be used in the strategic decision-making, it should represent the connections between the elements of internal structure, like processes, machines, people, and the elements of the business environment, like market segments, competitors, regulators. The paper presents and discusses a modeling technique – Fractal Enterprise Model (FEM) – that allows to represent such connections, and a computerized toolkit – FEM toolkit – that supports the modeling process. The presentation is done based on a running example. The attendees will learn about an innovative presentation of a business environment in an enterprise model.
... This toolkit was used to draw FEM diagrams in the project. The toolkit also includes a recent extension to FEM [26], which, however, was not used in the current project. ...
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.
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).
Conference Paper
Full-text available
This paper deals with the problems of a complex organizational system in which not each of its parts is directly connected to all other parts. For such a system, it is important to identify which parts/sub-systems need to be directly connected to each other, and which could be left without such connections. The paper puts forward a hypothesis that a suitable enterprise model could be used for this end, and investigates the suitability for this end of one particular enterprise modeling technique called Fractal Enterprise Model.
Full-text available
The pace of changes in the business environment in which a modern enterprise operates requires the enterprise to constantly review its business models in order to survive and prosper in the dynamic world. This exploratory study investigates how to help the enterprise to innovate their business models based on the concepts of fractal enterprise model and transformational patterns. The paper suggests an approach to Business Model Innovation (BMI) where the focus is on transformational patterns. It discusses the structure of such patterns, and based on examples, it presents an approach on how such patterns can be derived from cases of completed business transformations.
Conference Paper
Full-text available
An extended version of this paper is available: This paper presents an ongoing study on defining and maintaining organizational identity of an institution of higher education, such as a department or school. The theoretical background used in the study is the concept of structural coupling that comes from biological cybernetics. The study concerns the authors own department. The paper presents proposals of to which elements of the environment such an institution is structurally coupled and how the identity maintenance is arranged. The paper provides examples of how maintaining identity works or not works in practice based on reflections on the authors' experience of working in their own department. It also shows that maintaining identity may requires changes in different components of the socio-technical system, e.g. methods, people, technology.
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.
Conference Paper
Full-text available
This paper looks at the traditional approach in VSM practice of defining the identity of systems by ascribing purpose, looks at some of the conceptual and practical issues this raises and questions where this approach is helpful and where it creates problems for the modeller, especially given the in-built capacity with VSM for modelling systems with multiple purposes.. We go on to set out an alternative methodological approach to defining identity based on the work of Maturana on structural coupling. The paper concludes with some of the practical and theoretical implications of such an approach .
Full-text available
Design science is an emerging research paradigm in the Information Systems area. A design science project typically includes the activities of problem analysis, requirements definition, artifact development, and evaluation. These activities are not to be seen as sequential but can be carried out in any order. The purpose of this paper is to propose a conceptualization and formalization of design science research that show the possible ways in which a design science project can be carried out. The proposal is based on the state oriented view on business processes and suggests that design science research can be viewed as movements in a space of situations, problems and solutions
Patterns of Strategy is a revolutionary approach to developing business strategy that shows how the strategic fit between organisations drives their strategic direction. It is essential reading for those who wish to understand how to manoeuvre their organisation to change its strategic fit and play it to their advantage. Although traditional approaches to strategy have required organisations to assess the environment around them, they have ignored the dynamic nature of this relationship. Patrick Hoverstadt and Lucy Loh describe strategy as an emergent process that influences and is influenced by the wider system to which an organisation belongs. It is a systemic approach to strategy that focuses on the relationship between organisations, rather than just the organisation in its own right. As well as a new language of strategy and an explanation of what drives emergent strategy, the authors offer 80 'patterns’ of strategy which organizations can use to understand the relationship that their business and their strategy have to the actors around it. These patterns provide a toolkit for designing different ways to collaborate, and also offer alternative types and approaches of competition. A practical and authoritative guide, this book can be used to plan and navigate your way to the future.
Conference Paper
What is the relationship between design science research and innovation? Our industry-academic collaboration poses this intriguing question and suggests a context and an experimental design for its study. We wish to understand the synergies between the active research areas of DSR and innovation by exploring their overlapping concepts and identifying unique ideas in each that have the potential to inform the other. We present a case study of an actual innovation process in Chevron as a source of empirical data for the exploration and subsequent analysis of how the application of DSR guidelines might inform the practical implementation of innovation processes.