Dynamic Behavior Control of Interoperability: An Ontological Approach
Wided Gu
´
edria
1
and S
´
ergio Guerreiro
2,3
1
ITIS, Luxembourg Institute of Science and Technology (LIST),
5 avenue des Hauts-Fourneaux, L-4362 Esch-sur-Alzette, Luxembourg
2
Instituto Superior T
´
ecnico, University of Lisbon, Av. Rovisco Pais 1, 1049-001 Lisbon, Portugal
3
INESC-ID, Rua Alves Redol 9, 1000-029 Lisbon, Portugal
Keywords:
Assessment, Control, Enterprise Networks, Interoperability, Maturity, Diagnosis, Meta-Model.
Abstract:
The obligation to become more competitive and effective in providing better products and services requires
enterprises to transform from traditional businesses into networked businesses. One of the challenges faced
by a network of enterprises is the development of interoperability between its members. Transformations
in this context are usually driven by Enterprise Interoperability (EI) problems that may be faced. In order to
quickly overcome these problems, enterprises need characterizing and assessing interoperability to be prepared
to establish means for collaboration and initiate corrective actions before potential interoperability problems
occur and then be obliged to make unprepared transformations that may be costly and induce unmanageable
issues. In this paper, we define an integrated metamodel for interoperability using DEMO. The proposed
metamodel is based on an Ontology of Enterprise Interoperability (OoEI) and concepts from a maturity model
for interoperability while taking into account principles from Enterprise Dynamic Systems Control (EDSC)
domain. It allows to understand and control the dynamic behavior of interoperability between companies.
1 INTRODUCTION
Historically, progress occurs when entities commu-
nicate, share information, and together create some-
thing that could not be achieved alone. Moving be-
yond people to machines and systems, interoperabil-
ity is becoming a key factor of success in all domains.
Interoperability seems to be a straightforward con-
cept. However, there is no common definition or
shared comprehension of it. Each expert defines and
understands interoperability, according to his domain.
To deal with this research gap, the Ontology of Inter-
operability (OoI) was proposed to formalize the inter-
operability domain while defining also problems and
solutions pertaining to it(Naudet et al., 2010). As in-
teroperability is a general issue that is tackled through
many different domains such as military, software, in-
formation systems, modeling, organizations or health,
the OoI was based on the General System Theory
(GST) (Von Bertalanffy, 1968) to have a general con-
sensus that stay applicable to any interoperability do-
main. The OoI was thereafter extended to the Enter-
prise domain by defining the Ontology of Enterprise
Interoperability (OoEI) (Gu
´
edria and Naudet, 2014),
where an enterprise is also considered as a system. In-
deed, any organizational system is subject to be con-
trolled and is compliant with the concepts from GST,
as referred by Enterprise Dynamic Systems Control
(EDSC) (Guerreiro and Tribolet, 2013) (Guerreiro,
2012).
The EDSC principles are grounded in the belief
that, during operation time, actors perform different
actions from the ones that have been prescribed for
them. Considering the models definition as ex-ante
1
,
and operation as ex-dure
2
, EDSC checks if ex-dure
complies with ex-ante. Other solutions, e.g. regu-
lations enforcement, check compliance between ex-
post
3
and ex-ante. Therefore, when a non compliant
situation is found, EDSC cannot take any actions. It is
too late to avoid the situation. EDSC acts at run-time,
observing the reality and checking continuously if it
complies with prescriptions. When a non compliance
situation is found, EDSC acts with a change in the
operation, or, if the situation is innovative a change in
the prescriptions.
Growing globalization, competitiveness and ris-
ing environmental awareness are driving many com-
panies to control their interoperability strategy. Nu-
1
before the execution
2
during execution
3
after the execution
GuÃl’dria W. and Guerreiro S.
Dynamic Behavior Control of Interoperability: An Ontological Approach.
DOI: 10.5220/0006517602610268
In Proceedings of the 9th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (KEOD 2017), pages 261-268
ISBN: 978-989-758-272-1
Copyright
c
 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

merous models, methodologies, tools and guidelines
exist that can help an organization, an enterprise, or
more generally a system, to develop interoperability
and improve the way it operates with others. Devel-
oping interoperability requires considerable costs and
efforts. Characterizing and measuring interoperabil-
ity, allows an enterprise to define its needed interop-
erability and to plan the migration path to reach it.
This has become a significant research challenge over
the past few years and maturity models have been de-
veloped in response to this challenge. Numerous ma-
turity models have been developed for different pur-
poses, some of which are dedicated to the interoper-
ability domain. A survey of the most known ones has
revealed that, in most cases, existing maturity mod-
els focus on one single facet of interoperability (data,
technology, conceptual, enterprise modeling, etc.). In
this research work, as we propose to have a general
view of the Enterprise Interoperability (EI) domain,
we will be based on the Maturity Model for Enter-
prise Interoperability (MMEI). MMEI was defined in
(Gu
´
edria et al., 2015) and was used as a main in-
put to the standardization work carried out in CEN
TC 310/WG1 and ISO TC 184 SC5/WG1 to become
later a standard maturity model for enterprise interop-
erability (CEN 11345-2). The particularity of this ma-
turity model is to be defined based on existing models
and to have a systemic view of the enterprise.
In this paper, we propose to use the EDSC princi-
ples to define a conceptual model that integrates con-
cepts from the OoEI meta-model and the MMEI ma-
turity model. This will allow to diagnose interoper-
ability problems and simplify the assessment process
by having the required information. This will in par-
ticular help enterprises in diagnosing interoperability
problems while assessing their ability to interoperate
and to prevent actions to undertake. The remainder of
the paper will be the following: the research context
and some preliminaries that are needed to understand
the main contribution of the paper are presented in
section 2. In section 3, we propose the meta model re-
sulting from the integration of the OoEI and concepts
from the MMEI. Section 4 concludes and perspectives
for future work are then given.
2 RELATED WORK
Generally speaking, interoperability is the ability of
two or more systems or components to exchange in-
formation and to use the information that has been
exchanged (IEEE, 1991). When this ability is not
achieved, interoperability becomes a problem that
must be solved.
Solutions to interoperability problems can be charac-
terized according to interoperability approaches de-
fined in (ISO, 1999). EI problems can be localized
into interoperability barriers and characterized by EI
concerns, as defined in the Framework for Enterprise
Interoperability (FEI). FEI has been initially elabo-
rated in INTEROP NoE (D. et al., 2007) and is now
published as an international standard (ISO 11354 -
1). It defines a classification scheme for interoper-
ability knowledge according to three dimensions:
• Interoperability concerns, defining the content of
interoperation that may take place at various lev-
els of the enterprise (i.e. data, service, process,
business).
• Interoperability barriers, identifying various ob-
stacles to interoperability in three categories: con-
ceptual, technological, and organizational.
• Interoperability approaches, representing the dif-
ferent ways in which barriers can be removed (i.e.
integrated, unified, and federated)
The first two dimensions, interoperability con-
cerns and barriers, constitute the problem space of
enterprise interoperability (EI) (Chen, 2006). In or-
der to avoid such problems, enterprises need to know
their strengths and weaknesses in terms of interoper-
ability in order to undertake corrective actions and be
prepared to potential interoperations. This is the pur-
pose of the interoperability assessment which can be
performed either as part of a continuous improvement
initiative, or as part of an analysis approach.
2.1 Ontology of Enterprise
Interoperability (OoEI)
The first attempt to define the interoperability domain
was made by (Rosener et al., 2004), where a model
for defining interoperability as a heterogeneous prob-
lem induced by a communication problem was pro-
posed. On the basis of these research efforts, the On-
tology of Enterprise Interoperability (OoEI) (Gu
´
edria
and Naudet, 2014) as an extension of the Ontology of
Interoperability (OoI) (Naudet et al., 2006) was devel-
oped using the Ontology Web Language (OWL). The
OoEI aims at formally defining Enterprise Interoper-
ability (EI) while providing a framework to describe
problems and related solutions pertaining to the inter-
operability domain.
Interoperability exists because there are at least
two Systems and a Relation between them. The re-
lation is of primary importance and is the source of
interoperability problems (Rosener et al., 2005). A
System is defined as a set of interconnected parts, hav-
ing a Structure, a Function, an Objective and a Behav-

ior (Giachetti, 2010). These concepts are necessary to
understand a system.
The OoEI was defined based on the FEI (Chen
and Daclin, 2005) (Gu
´
edria and Naudet, 2014). It
describes systems as interrelated subsystems: A Sys-
tem is composed of SystemElements, which are sys-
tems themselves, and Relations. The Relation con-
cept formalizes the existing relationships inside a sys-
tem, which is the source of the occurrence of interop-
erability problems.
An enterprise is considered as a complex system in
the sense that it has both a large number of parts and
the parts are related in ways that make it difficult to
understand how the enterprise operates and to predict
its behavior (Giachetti, 2010).
Dealing with EI requires considering the enterprise
from a general perspective, taking into account not
only its different components and their interactions
but also the environment in which it evolves and the
interface through which it communicates with its en-
vironment. The Interface is a SystemElement through
which a connection between the System and its En-
vironment can be established. It also represents the
systems boundaries.
The establishment or diagnosis of EI has led to iden-
tify the different operational levels that are concerned:
Business, Process, Service and Data interoperabilies
(i.e. the EI concerns as defined by FEI). Interoperabil-
ity is implemented as a subclass of the Problem con-
cept. Problems of interoperability exist when there is
a relation, of any kind, between incompatible systems
in a super- system they belong to or system they will
form. An exhaustive description of the OoEI can be
found in (Guedria, 2012).
2.2 Maturity Model for Enterprise
Interoperability (MMEI)
Generally speaking, a maturity model is a framework
that describes for a specific area of interest a number
of levels of sophistication at which activities in this
area can be carried out (Alonso et al., 2010). In our
case, the specific area of interest is EI. The MMEI has
been proposed in (Gu
´
edria et al., 2015). It takes into
account existing maturity models while extending to
the whole domain of EI.
When an enterprise wants or needs to work or col-
laborate with other enterprises, different tools such
as guidelines or metrics might be useful in order to
ensure proper interoperation at all levels of the en-
terprise system. MMEI allows companies to evalu-
ate their interoperability potentiality in order to know
the probability that they have to support efficient in-
teroperation and to detect precisely the weaknesses
that are sources of interoperability problems. In this
section we present an overview of the MMEI model
with a brief description of its levels. The complete de-
scription of the model can be found in (Gu
´
edria et al.,
2015).
The proposed model differs from all other maturity
models dedicated to interoperability so far. It is in-
tended to cover the three interoperability levels (con-
ceptual, technological, organizational) which are used
to classify the barriers in FEI (Chen, 2006), at each
of the EI concerns (business, process, service, data).
MMEI defines five levels of interoperability maturity.
Each one of the maturity levels is described based on
a simplified version of the Framework of Enterprise
Interoperability (FEI) that contains only two basic di-
mensions ”interoperability barriers” and ”enterprise
interoperability concerns”. Table 1 provides a gen-
eral view of the MMEI model with its contents. Each
one of the five maturity levels is an instantiation of
this general view with an evolution of the content re-
garding the evolution of the level.
2.3 Enterprise Dynamic Systems
Control
General Systems Control Concepts. From the per-
spective of classic control concepts (Franklin et al.,
1991) the system that we propose to control is the ex-
ecution of the business transactions. The purpose of
a control system is to react whenever the disturbance
affects the behavior of the system or whenever a new
input is established. In other words, when the system
is not producing the desired output for the imposed
input. Control act in the input at the same time as the
disturbance is affecting the system.
System
output
input
disturbance
feedforward
System
output
input
disturbance
feedback
System
output
input
disturbance
(A)
(B)
(C)
Figure 1: Design pattern of control systems. (A) without
control, (B) feed forward control and (C) feedback control.
Figure 1 depicts classical design patterns for a
control system. In the top, (A), it shows a system that
is not controlled. The disturbance always affects the
output delivered by the system. In this pattern, it is

Table 1: General view of MMEI levels structure.
Conceptual Technological Organizational
Business Business models, enterprise visions, strate-
gies, objectives, policies
Infrastructure, technology Work methods, business rules, and organiza-
tional structure
Process Processes models Tools supporting processes modeling and ex-
ecution
Responsibilities, Process management and
rules
Service Services models Tools supporting services and applications Responsibilities, service and application
management and rules
Data Data models, (semantic, syntax) Data storage and exchange devices Responsibilities, data management and rules
A13
Access
provisioner
A12
Model
provisioner
A11
Business
rules
provisioner
A04
Interceptor
A07
Business rules
engine
A02
Model
manager
A03
Access
controller
CA04
User
T04
Observation
of run-time
session
Business rule
management
T12
Model
management
Access
management
Enterprise Governance
T01
Business rule
definition
Model
definition
T03
Access
definition
T05
run-time
control
A05
Run-time
controller
A06
Run-time
access
controller
T07
T06
run-time
access control
run-time
business
rule control
CPB14
CPB15
CPB16
CPB17
CPB18
1
CPB15
CPB17
T13
A01
Business
rule
manager
T11
T02
CPB16
Figure 2: DEMO Organizational Construcional Diagram for Organizational control (adapted from (Guerreiro, 2012)).
not possible to guarantee the behavior of the system
output. In the middle, (B), a feed forward pattern that
shows that the system input changes accordingly with
the actual disturbance. Therefore, the system dynam-
ics it not included in the control actuation. At the bot-
tom of Figure 1, (C), a feedback control pattern cal-
culates the system input accordingly with the actual
misalignment obtained between the output and input.
In this pattern, the control actuation calculation takes
into consideration the disturbance and the system dy-
namics. Because the system output depends on the
disturbance imposed in the system and on the system
dynamics itself. Moreover, to produce results, all sys-
tems control requires the capabilities of observation
and actuation (Guerreiro, 2014).
Organizational Control. In the scope of an organi-
zation, control is performed implicitly and the overall
organizational system maintains its stability involv-
ing all the actors, without a clear identification of
which parts are controlled and which parts are con-
trollers. Thus, our position paper states that control
(i) is not always either explicit or analytical, as cy-
bernetic control approaches are, (ii) it is not possible
to predict all the business transactions conditions to
control before execution due to the high number of
possible combinations that could happen at run-time
and (iii) the identified deviation from the stable state
is sometimes incorporated as organizational innova-
tion. Keeping in line with the scientific contributions
of (Beer, 1979) (Bertalanffy, 1969) an organization
is a huge non deterministic state machine, i.e. non
mechanic, composed by a set of systems that play a
complex intertwined orchestration, played fundamen-
tally by the actors, humans and computers. Besides
the machinery used by the organizations, actors are
humans with action freedom and act accordingly with
their purposes and orchestrations (Winograd, 1986),
organized in a social system. The organization ex-
istence is revealed while this social system performs
actions.
It is commonly agreed, since foundational works
in this area (Le Moigne, 1994), that control requires
the capabilities of observation, decision and control
actuation. It is an ongoing Plan-Do-Check-Act pol-
icy. However, in some complex system’s contexts the
observation and the actuation is only partial. The or-
ganization cannot be aware about everything that ex-
ists, neither by the abilities that are made available to
change.
Design of Organizational Control. The DEMO
Organizational Construcional Diagram (OCD) de-
picted in Figure 2 designs the ontology of a given

solution regarding the actors, the production banks,
the coordination banks, the boundary and the infor-
mation flow. The OCD is an adaptation from (Guer-
reiro, 2012). Figure 2 is textually described as fol-
lows. Control observations are enforced by T04. T03
and T13, specify and change, the involved actor roles.
T02 and T12 specify and change the state space and
transition space of the organizational system. An in-
formation link exists between A12 and T13 to obtain
the access configuration from the organizational sys-
tem’ models during the configuration phase of the ref-
erences. The A07 has three information links to the
T11, T12 and T13. They correspond to the control ac-
tion of changing a model and are taken when any mis-
alignment occur. T11 corresponds to a self-change
in a business rule. T12 corresponds to a change in
the organizational system model to be controlled, and
the model manager performs it. T1 corresponds to a
change in the access management. T05 enforces con-
trol by the mean of the business rules. CPB16 refers
to the Period that the enterprise control is being con-
sidered, by other words, the period where control is
valid, hence an information link exists with Organiza-
tional control boundary.
3 METAMODEL FOR
ENTERPRISE
INTEROPERABILITY
CONTROL AND
IMPROVEMENT
3.1 Integration of OoEI with MMEI
Concepts
The structure of MMEI is based on a simplified ver-
sion of FEI where we can find the EI concerns (i.e.
Business, process, service and data) and interoper-
ability barriers (i.e. conceptual, technological and or-
ganizational), as depicted by table 1. These concepts
can also be found in the OoEI (Naudet et al., 2008)
. Moreover MMEI and OoEI follow a systemic view
(Von Bertalanffy, 1968).
The content of each cell of the table 1 can be re-
lated to the OoEI as shown in Figure 3. The OoEI
concepts are presented with white ellipses while con-
cepts related to the MMEI model are presented with
gray color. Based on the OoEI and MMEI review,
three main dimensions of EI are considered: Interop-
erability aspects (conceptual, organizational and tech-
nical), Interoperating entities, also known as EI con-
cerns in FEI (business, process, service and data)
and Interoperability barriers (Conceptual, Organiza-
tional, Technological). These are represented by the
three concepts: InteroperabilityAspect, Interoperabil-
ityConcern and InteroperabilityBarrier respectively.
These are all modeled with their different constituents
represented here as dimensions describing Enterprise
Interoperability, as shown in figure 3. Within the con-
text of EI, interoperability problems are represented
by the InteroperabilityBarrier concept. The term
barrier is defined as an incompatibility, obstructing
the sharing of information and preventing exchang-
ing services (Chen and Daclin, 2007). The establish-
ment of interoperability (with its three aspects) con-
sists of removing identified barriers (conceptual bar-
rier, organizational barrier or/and technological bar-
rier). Hence each InteroperabilityBarrier is related
to the corresponding InteroperabilityAspect (see fig-
ure 3). For each OrganizationalBarrier, the criteria
that need to be verified are the definition and compat-
ibility of the Responsibilities, Work methods, Busi-
ness rules, Organization structure and strategy, as de-
fined by the MMEI model (see table 1). This is rep-
resented by the concepts Responsibilities, Work meth-
ods, Business rules, Organization structure and strat-
egy which are considered by the Organizational Bar-
rier. Similarly, the concepts of Business model, Pro-
cess model, Service model and Data model are con-
cerned with the ConceptualBarrier and the concepts
of IT infrastructure, IT tools supporting data storage
and Exchange devices are concerned with the Techno-
logicalBarrier.
This model can be used thereafter to have the re-
quired knowledge to assess the EI of the considered
enterprise. The gray MMEI concepts (gray ellipses)
in the figure 3 presents the requirements and related
information that need to be verified. For example, in
order to assess the EI at organizational level, some
of the requirements that assessors have to verify are
whether responsibilities supporting business, process,
service and data interoperability concerns are prop-
erly defined and that are compatible with those used
within the enterprise environment.
3.2 Integrating Enterprise Dynamic
Control
Given the metamodel presented in the previous sub-
section (summarized by Figure 3), we propose to en-
force it using the Enterprise Dynamic Systems Con-
trol (EDSC) (Guerreiro, 2012) principles. This en-
forcement is explained using an examplification case
study of two companies (Company 1 and 2) that are
interoperating. The idea is to have a master controller
(Interoperation control) that is able to change access

Figure 3: Extract of the integrated model.
control configuration in both companies, when any
unexpected observation occurs in the business trans-
actions between them. The EDSC pattern presented
in Figure 2 is herein used to express the controlled
systems of each company and the interoperation con-
troller. EDSC is a generic pattern that could be used
for expressing the control of any type of system. Each
company is at the same time an internal controller
and a controlled system by the interoperation control.
EDSC pattern is terefore used to ground the systems
behavior’ description.
In the right part of Figure 4 is depicted two com-
panies that are interoperating with the business trans-
actions T-101 and T-102. Some business transaction
execution is being performed. A more complex net-
work could be considered, yet, for demonstration pur-
poses it is simplified. The execution of the T-101 and
T-102 are observed by the CA04 composite actor, us-
ing a DEMO information link. Here, the interopera-
tion control checks whether the observed information
complies with the access rules that were provisioned.
When the observations are not complaint with the pre-
vious configurations for access definition, another in-
formation link is used to change the access data bank
of the correspondingly Company 1 and 2. This action
changes the CPB15 with an access revokation or grant
to the execution of T-101 and T-102.
4 CONCLUSIONS AND FUTURE
WORK
In this paper, we have proposed an integration of
the Maturity Model of Enterprise Interoperability
(MMEI) concepts into the ontology of Enterprise In-
teroperability (OoEI) while taking into account the
Enterprise Dynamic System Control (EDSC) prin-
ciples. The integration was facilitated by the sys-
temic basis of the considered principles and models.
The integrated model allows to have the required kn-
bowledge for the interoperability assessment and save
human efforts in gathering information and validating
it for each assessment. This will facilitate the diag-
nosis of interoperability problems and a better control
of the behavior of the considered enterprise. This is
facilitated by the nature of the OoEI which were con-
ceived in a problem solving perspective and the EDSC
principles. Future work are planned to improve this
first version of the integrated model in order to im-
plement a tool for automatic assessment. This will
be supported by the automatic assessment process de-
veloped in (Gu
´
edria et al., 2015) and based on fuzzy
rules and linguistic variables. It can be also comple-
mented by a proposition of solutions to interoperabil-
ity problems by using best practices that were devel-
oped for the MMEI (Gu
´
edria et al., 2015).

A13
Access
provisioner
A12
Model
provisioner
A11
Business
rules
provisioner
A04
Interceptor
A07
Business rules
engine
A02
Model
manager
A03
Access
controller
CA04
User
T04
Observation
of run-time
session
Business rule
management
T12
Model
management
Access
management
Enterprise Governance
of company 1
T01
Business rule
definition
Model
definition
T03
Access
definition
T05
run-time
control
A05
Run-time
controller
A06
Run-time
access
controller
T07
T06
run-time
access control
run-time
business
rule control
CPB14
CPB15
CPB16
CPB17
CPB18
1
CPB15
CPB17
T13
A01
Business
rule
manager
T11
T02
CPB16
A13
Access
provisioner
A12
Model
provisioner
A11
Business
rules
provisioner
A04
Interceptor
A07
Business rules
engine
A02
Model
manager
A03
Access
controller
CA04
User
T04
Observation
of run-time
session
Business rule
management
T12
Model
management
Access
management
Enterprise Governance
of company 2
T01
Business rule
definition
Model
definition
T03
Access
definition
T05
run-time
control
A05
Run-time
controller
A06
Run-time
access
controller
T07
T06
run-time
access control
run-time
business
rule control
CPB14
CPB15
CPB16
CPB17
CPB18
1
CPB15
CPB17
T13
A01
Business
rule
manager
T11
T02
CPB16
T-
101
Interoperation 1
T-
102
Interoperation 2
A13
Access
provisioner
A12
Model
provisioner
A11
Business
rules
provisioner
A04
Interceptor
A07
Business rules
engine
A02
Model
manager
A03
Access
controller
CA04
User
T04
Observation
of run-time
session
Business rule
management
T12
Model
management
Access
management
Interoperation control
T01
Business rule
definition
Model
definition
T03
Access
definition
T05
run-time
control
A05
Run-time
controller
A06
Run-time
access
controller
T07
T06
run-time
access control
run-time
business
rule control
CPB14
CPB15
CPB16
CPB17
CPB18
1
CPB15
CPB17
T13
A01
Business
rule
manager
T11
T02
CPB16
Figure 4: Interoperation using the EDSC pattern.
ACKNOWLEDGEMENT
This is a collaboration work between the Luxebourg
Institute of Science and Technology and the Univer-
sity of Lisbon. It is respectively, conducted in the
context of the PLATINE project (PLAnning Trans-
formation Interoperability in Networked Enterprises),
financed by the national fund of research of the
Grand Duchy of Luxembourg (FNR), under the grant
C14/IS/8329172; and supported by national funds
through Fundac¸
˜
ao para a Ci
ˆ
encia e a Tecnologia
(FCT) with reference UID/CEC/50021/2013.
REFERENCES
Alonso, J., de Soria, I. M., Orue-Echevarria, L., and Ver-
gara, M. (2010). Enterprise collaboration maturity
model (ecmm): preliminary definition and future chal-
lenges. In Enterprise Interoperability IV, pages 429–
438. Springer.
Beer, S. (1979). The Heart of the Enterprise. John Wiley &
Sons Inc., New York.
Bertalanffy, L. v. (1969). General Systems Theory. George
Braziller, New York.
Chen, D. (2006). Enterprise interoperability framework. In
EMOI-INTEROP.
Chen, D. and Daclin, N. (2005). Framework for enter-
prise interoperability. In Interoperability for Enter-
prise Software and Applications, I-ESA05, pages 77–
88.
D., C., M., D., and B., E. (2007). Interop noe deliver-
able di.3: Enterprise interoperability framework and
knowledge corpus - final report. Technical report,
Interoperability Research for Networked Enterprises
Applications and Software (INTEROP Network of
Excellence), IST - Contract no.: IST-508 011.
Franklin, G., Powell, J., and E., A. (1991). Feedback Con-
trol of Dynamic Systems. Addison-Wesley Publishing
Company.
Giachetti, R. (2010). Design of Enterprise Systems: Theory,
Architecture, and Methods. CRC Press, Inc., Boca
Raton, FL, USA, 1st edition.
Guedria, W. (Bordeaux, France, 2012). A Contribution
to Enterprise Interoperability Maturity Assessment.
Ph.D. thesis, University of Bordeaux1.
Gu
´
edria, W. and Naudet, Y. (2014). Extending the ontology
of enterprise interoperability (ooei) using enterprise-
as-system concepts. In Enterprise Interoperability VI,
pages 393–403. Springer.
Gu
´
edria, W., Naudet, Y., and Chen, D. (2015). Maturity

model for enterprise interoperability. Enterprise In-
formation Systems, 9(1):1–28.
Guerreiro, S. (2012). Enterprise dynamic systems control
enforcement of run-time business transactions using
demo: principles of design and implementation. Insti-
tuto Superior T
´
ecnico-Universidade T
´
ecnica de Lis-
boa, Lisboa.
Guerreiro, S. (2014). Towards multi-level organizational
control framework to manage the business transaction
workarounds. In 16th International Conference on
Enterprise Information Systems, pages 288–294. IN-
STICC.
Guerreiro, S. and Tribolet, J. (2013). Conceptualiz-
ing enterprise dynamic systems control for run-
time business transactions. In 21st European Con-
ference on Information Systems, pages paper–393.
http://aisel.aisnet.org/ecis2013/56/.
IEEE (1991). Ieee standard computer dictionary: A compi-
lation of ieee standard computer glossaries. IEEE Std
610, pages 1–217.
ISO (1999). ISO 14258 - Industrial Atomation Systems
- Concepts and Rules for Enterprise Models. ISO
TC184/SC5/WG1.
Le Moigne, J.-L. (1994). La th
´
eorie du syst
`
eme g
´
en
´
eral:
th
´
eorie de la mod
´
elisation. jeanlouis le moigne-ae
mcx.
Naudet, Y., Latour, T., and D.Chen (2008). A systemic ap-
proach to interoperability formalization. In IFAC08
workshops.
Naudet, Y., Latour, T., Guedria, W., and Chen, D. (2010).
Towards a systemic formalisation of interoperability.
Computers in Industry, 61(2):176–185.
Naudet, Y., Latour, T., Haussmann, K., Abels, S., Hahn, A.,
and Johannesonn, P. (2006). Describing Interoperabil-
ity: the OoI Ontology. In EMOI-INTEROP.
Rosener, V., Latour, T., and Dubois, E. (2004). A model-
based ontology of the software interoperability prob-
lems: preliminary results. In CAISE04 workshops,
volume 3, pages 241–252.
Rosener, V., Naudet, Y., and Latour., T. (2005). A model
proposal of the interoperability problem. In EMOI-
INTEROP.
Von Bertalanffy, L. (1968). General System Theory:
Foundations, Development, Applications. Georges
Braziller, Inc., New York, USA.
Winograd, T. (1986). A language/action perspective on the
design of cooperative work. In Proceedings of ACM
conference on Computer-supported cooperative work,
pages 203–220.