The final version was published and copyrighted by Springer in LNBIP Vol 385, pp 95-111
Structural Coupling, Strategy and Fractal Enterprise
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
The concept of structural coupling comes from biological cybernetics, more
specifically, from the works of Maturana and Varela, see, for example, . 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 , 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 .
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, . 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 , .
The first work  suggests using the concept of structural coupling for the purpose
of defining the notions of organizational identity and identity management. According
to Hoverstadt , 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  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.  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 . 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
A B A B
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  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  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 . 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  and from  - can be used in practice, but both have their
drawbacks. The approach presented in  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  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) .
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  and homeostasis  in socio-technical
(organizational) systems . 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 . 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  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 .
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
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 .
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 .
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  (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 . 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
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
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 , or artifact in terminology of ; alternatively, the result can be
in form of "negative knowledge" stating that a certain approach is not appropriate for
solving certain kind of problems .
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 , is using FEM for business model
innovation, see, for example, . From the point of view of classification of DS
opportunities introduced in  and adopted in , we use exaptation (in terminology
of ) or transfer (in terminology of ), which amounts to extending the known
solutions to new problems, including adapting solutions from the other fields/domains.
According to both  and , 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 , 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
. 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  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 ,
which is reflected in Fig. 2. After some more time, the product was once more renamed
to Panther , 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
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 .
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  for a historic
overview). The state-oriented modeling of business processes has been tested in
practice and got positive feedback from the customers, see .
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  and .
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 . 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 . 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
. 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 , 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  and  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 , it does not cover the one that concerns regulators. The same
is true in connection to , 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  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  and .
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
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
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
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
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
Hevner, A., March, S. T., and, P.: Design Science in Information Systems Research. MIS
Quarterly 28(1), 75
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
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
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
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
Andersson, T., Andersson-
Ceder, A., Bider, I.: State flow as a way of analyzing business
case studies. Logistics Information Management 15(1), 34