Conceptual Interoperability Barriers Framework (CIBF)
A Case Study of Multi-organizational Software Development
Llanos Cuenca
, Andrés Boza
, Angel Ortiz
and Jos J. M. Trienekens
Research Centre on Production Management and Engineering (CIGIP), Universitat Politècnica de València,
Camino de Vera s/n, 46022 Valencia, Spain
University of Technology Eindhoven, Eindhoven, The Netherlands
Keywords: Conceptual Barrier, Interoperability, Framework, Software Development.
Abstract: This paper identifies conceptual barriers to enterprise interoperability and classifies them along
interoperability levels of concern. The classification is based on the enterprise interoperability framework
by Interop NoE and introduces the concepts of horizontal and vertical interoperability. From the initial
classification a new conceptual interoperability barriers framework is proposed. The goal of the framework
is to present generic conceptual barriers to interoperability and show where they are interrelated. The
proposal has been validated in a case study of multi-organizational software development.
In business it is common knowledge that enterprises
no longer operate as single entities. Instead, supply
chains and supply networks of enterprises endeavour
to deliver the best possible value to their customers.
The current situation dominated by globalization
forces competence between enterprises. As a result,
supply chains and networks are now looking to
enforce collaborative agreements, which would
produce more efficient workflow, flexibility,
effectiveness, agility and coordination between
chain links (Vargas et al., 2013; 2014). Things
become even more complex when chains need to be
flexible to react to changing requirements to the
products or services they deliver (Grefen and
Dijkman, 2013).
Information Technology (IT) becoming an
increasingly important determinant of an enterprise’s
competitiveness, compatibility between enterprise
information systems is of utmost importance to
ensure the competitiveness of supply chains and
networks. According to ISO 15704, an enterprise is
defined as “one or more organizations sharing a
definite mission, goals and objectives to offer an
output such as a product or a service” (ISO, 2000).
A supply chain can then be perceived as a chain of
enterprises, all with their own missions, goals and
objectives, where each member adds value at a
particular stage to offer a final output to the end
customer. For enterprises, it is still a hard task to
identify best practices and improvements to start
implementing collaboration and interoperability
practices inside different types of networked
environments (Alonso et al., 2010).
A business collaboration network (BCN) enables
companies to communicate and collaborate with
their customers, partners and suppliers in a
productive way (Sterling, 2010). This cooperation
takes different forms, from simple information
exchange, to business processes interoperability
among independent enterprises (Sun, 2007;
Shishkov, 2009).
Enterprise systems are, like the enterprises they
belong to, heterogeneous systems which need to
work together. The heterogeneity of enterprises is a
key characteristic because it implies that their IT
systems are also heterogeneous. Therefore there is a
need for interoperability between enterprises and
their IT systems.
The paper is structured as follows; section two
presents the theoretical foundation of the proposal.
Main concepts are defined in section three. Section
four depicts a review of the literature used as a basis
for this research. A more thorough description of the
Enterprise Interoperability Framework by Interop is
given first, then the interoperability frameworks
developed in the 2000’s are discussed, before
concluding with the other relevant material
encountered. Section five presents the analysis and
classification of conceptual barriers along the four
Cuenca L., Boza A., Ortiz A. and Trienekens J..
Conceptual Interoperability Barriers Framework (CIBF) - A Case Study of Multi-organizational Software Development.
DOI: 10.5220/0005338405210531
In Proceedings of the 17th International Conference on Enterprise Information Systems (ICEIS-2015), pages 521-531
ISBN: 978-989-758-097-0
2015 SCITEPRESS (Science and Technology Publications, Lda.)
levels of concern. After that, a new framework is
proposed and elaborated on section six, which is
meant to identify generic conceptual barriers and
depict interrelations. The validation of the proposal
is included in section seven. The paper is concluded
with conclusions and references.
To explain the phenomena of non-interoperability
that can be observed in various situations, the
following hypotheses can be made (Ducq et al,
Enterprise systems are not interoperable because
there are barriers to interoperability that obstruct
exchange of information and services.
Barriers are different kinds of incompatibilities
and can be found at different levels and sub-domains
in an enterprise.
Barriers can be specifically linked to a particular
application in a specific domain; however there are
generic barriers which are common to all situations
of non-interoperability.
A better understanding of non-interoperability
problems might lead to development of adequate
solutions to solve these problems.
Philosopher Karl Popper (1902-1994) considered
that a statement is only scientific if this is open to
the logical possibility of being found false. This
means that interoperability problems and solutions
must be therefore tested in real systems and
One of the requirements to develop a science
base is to define an “instrument to use for
observing the phenomena of non-interoperability.
However this is difficult because non
interoperability problems are not always directly
According to Guedria (2012) based on the
relevant concepts from the General System Theory
(GST), a general formalization of the enterprise
interoperability can be elaborated. To this end, it is
necessary to study interacting enterprises and
relevant capabilities which are defined through
available interoperability frameworks and existing
models through a comprehensive literature review.
This paper contributes to define, conceptualize
and structure the phenomena of conceptual non-
interoperability. It provides a sound theoretical
foundation for understanding of the nature and
characteristics of the conceptual interoperability
A variety of frameworks for enterprise
interoperability have been developed in the 2000’s.
As part of a project meant to structure research on
interoperability, the Enterprise Interoperability
Framework by Interop developed using these earlier
frameworks. In the Interop framework, enterprise
interoperability is defined as “the ability to (1)
communicate and exchange information; (2) use the
information exchanged; (3) access the functionality
of a third system” (Chen, 2005). This definition is
not limited to different organisations, but can also
refer to different enterprise systems within the same
According to Vernadat (2010), it is important
that interoperability is not confused with integration.
When enterprise systems are integrated, they
function in a coordinated and uniform way, in other
words they become homogeneous systems.
Interoperability does not require that, only that the
otherwise autonomous systems be able to exchange
and use each other’s information and functions.
Enterprise Interoperability (EI) is a well-
established area of applied research that addresses
the problems related with the lack of systems and
applications’ interoperability in organisations and
proposes novel solutions for EI problems (Jardim-
Gonzalves et al., 2013). The framework presented
by Chen (2005) identifies three categories of
obstacles that inhibit interoperability, known as
barriers to interoperability. They are the conceptual-,
technical- and organisational barriers. “Barriers are
‘incompatibilities’ or ‘mismatches’ which obstruct
the sharing and exchanging of information”. “The
barriers of a conceptual nature relate to the syntactic
and semantic differences of information to be
exchanged as well as the expressivity of the
information” (Interop, 2006).
Conceptual interoperability aims to ensure that
information exchanged shares the same meaning and
syntax to enable systems to process information
exchanged. This requires definition of a common
semantic on the basis of structured language (Boza
et al., 2014). Also relevant are the four levels or
concerns of interoperability defined in the
framework. They are Data, Processes, Services and
Business concerns.
For enterprise systems to be interoperable, the
barriers to interoperability must first be identified
and removed.
However, no comprehensive list of any type of
barriers is available for enterprises to consult when
designing new- or connecting existing enterprise
systems. Therefore, taking conceptual barriers as the
point of interest, the objective of this research is to
identify conceptual barriers to enterprise
interoperability and classify them along the four
levels of concern developed in the enterprise
interoperability framework as developed by (Chen et
al., 2005) and to develop the basis of conceptual
barriers that enables users to identify generic
conceptual barriers and their interrelations and apply
them to any particular situation.
In order to identify conceptual barriers it was
necessary to conduct a literature survey of existing
works on interoperability. Using scientific search
engines like Scopus, ScienceDirect, Springerlink,
relevant articles were queried for. The main search
keys used were “enterprise interoperability”,
“interoperability barriers”, “conceptual barriers”,
“measures interoperability barriers”, “case study
interoperability barriers” and “criteria for
Research into interoperability requirements and
formalization of measures for interoperability added
new insights into conceptual barriers, as these could
be translated back to the barriers they were initially
meant to overcome.
The first section of this literature review explores
the enterprise interoperability framework that is the
basis for this paper in more detail.
The second section deals with the other
interoperability frameworks developed in the past
decade and a half. Unless stated otherwise, that part
of the review is based on the literature review on
interoperability frameworks performed by (Chen.
2005) and (Jardim-Gonzalves, 2013).
To conclude, previous work by various authors
focused on interoperability barriers is presented.
4.1 Enterprise Interoperability
Framework by INTEROP NoE
The EIF by Interop was first presented to structure
research on enterprise interoperability (Interop,
2006). Until then, research efforts on interoperability
were mostly uncoordinated because there was no
common understanding of the domain.
The framework presents three main dimensions
along which interoperability issues can be classified.
Interoperability barriers: Conceptual barriers
occur when there is no common understanding of
concepts. These different understandings can pertain
to a number of causes according to this framework.
Syntax: the structures used by people to represent
information, known as the syntax, may not coincide.
An example is the chosen modelling language to
represent business processes. Semantics: this second
difference pertains to the meaning assigned to
words. A customer order may be defined simply as
‘order’ in one enterprise, and as ‘customer order’ or
‘product order’ in another. Misunderstanding may
arise. Expressivity: concerns the ability to
communicate information in a pragmatic way that is
easy to understand. An example is that information
can be shown graphically for easier understanding,
but is only offered in text. The lack of expressivity
thus causes conceptual misunderstanding. The
barriers of technological nature are concerned with
the use of ICT i.e. problems relating to the
incompatibility of IT architecture & platforms,
infrastructure (Interop, 2006). A lack of compatible
technologies for systems to interact is a
technological barrier. Organisational barriers relate
to the definition of responsibility and authority
within an enterprise, i.e. the human and
organizational behaviour.
Interoperability concerns: Since one of the
objectives is to classify conceptual barriers along the
interoperability concerns, some further clarification
as to what they entail is appropriate. Business: the
concern of working in a harmonised way at the
highest level of the organisation. Issues like
corporate culture, business mission, vision and
objectives and commercial strategies are important
at this level. Processes: how they are defined and
connected to other processes. A process is the set of
activities that transforms an input into a desirable
output. Services: concerns the identification,
composition and operating of applications that make
an enterprise or network function. This concern is
not limited to computer applications and also
includes services performed in general within in an
enterprise. Data: the lowest level of abstraction
simply involves organising and use of data by
various services to perform their functions. The
database structure used is an example.
The third dimension in the framework is related
to interoperability approaches, or ways in which
barriers can be removed.
4.2 Other Interoperability Frameworks
and Barriers
Over the years there have been different
interoperability frameworks, we can find between
Levels of Information Systems Interoperability
(LISI): The first effort towards an interoperability
framework was LISI, developed by the U.S. C4ISR
Architecture Working Group (AWG) in 1997
(C4ISR, 1998). It is actually a maturity model that
prescribes which capabilities a set of systems must
possess to be interoperable, on four different levels
known as PAID (Procedures, Applications,
Infrastructure and Data). It focuses however, largely
on technological capabilities of the systems needing
to interact. Conceptual barriers were therefore not
included in LISI.
IDEAS Interoperability Framework: The first
European effort was the IDEAS interoperability
framework which also harnessed the idea that
interoperability is achieved in multiple layers. The
content of these layers formed the basis for the
interoperability concerns defined in the Interop
Enterprise Interoperability Framework (Chen, 2005;
Interop, 2006).
ATHENA Interoperability Framework (AIF): The
AIF in was considered complementary to the IDEAS
framework, as it provides relevant research elements
and solutions to interoperability issues, instead of
stopping at defining these issues. It is structured into
three parts (Athena, 2010).
e-Health Interoperability Framework: The E-health
interoperability framework distinguishes between
areas in which enterprises can be interoperable
(Nehta, 2005). It defines three levels of
interoperability across health organizations:
Organizational layer which provide a shared policy
and process framework across the E-Health
interoperability agenda covering each NEHTA
initiative. Information layer which provide shared
building blocks for semantic (information)
interchange. Technical layer is concerned with the
connectivity of systems for information exchange
and service use.
European Interoperability Framework (EIF): This
framework proposes yet another categorization of
interoperability areas. Within these areas, policies,
standards and guidelines are presented to which
enterprises should adhere to achieve interoperability.
Outside of the EIF, the author also identifies five
further possible barriers to enterprise systems
interoperability. They are in no particular order:
Trust, Security, Confidentiality, Legal and
Linguistic issues. In a collaborative effort, (Yahia et
al., 2012) formalised semantic relationships between
enterprise systems. (Lezoche et al., 2012) propose a
conceptualisation approach for semantics discovery
and management in enterprise information systems
models, based on applying fact-oriented
transformation rules. An interesting distinction not
made by other authors, is that between horizontal
and vertical interoperability as noted by (Panetto,
2007). When interoperability between two elements
at the same level of abstraction is being considered,
one talks of horizontal interoperability.
In 2007, the interoperability Score (i-Score) was
proposed by Ford et al., (2007, 2008). It considers
that interoperability must be measured in the context
of the operational mission which is implemented by
systems of many types and that the number of
interoperations is not as important as the quality of
these interoperations.
Morris et al., (2004) developed the SOSI model,
which addresses technical interoperability,
operational interoperability and programmatic
concerns between organizations building and
maintaining interoperable systems.
The semiotic interoperability framework is a new
concept that defines a set of interoperability levels,
and provides a sound foundation by explaining how
signs can be successfully communicated in different
levels (Li et al., 2013)
In the forthcoming analysis, all barriers identified in
the literature review will first be classified along the
four interoperability concerns. The end result of this
classification can be found in Table 1 at the end of
Section 5.1. Then, a new framework for the
conceptual barriers is proposed. This new
framework contains generic conceptual barriers and
the relationships between them and is shown in
Figure 1 in Section 6.
5.1 Classification by Concern of
Conceptual Barriers to
Business: At the business level of abstraction, the
researchers in the Interop project marked the
enterprise’s mission, vision, objectives and strategies
as potential conceptual barriers. These conceptual
elements are defined at high level and are thus
applicable to the business concern. Now let us check
if they are barriers. Using Chen’s definition of
enterprise interoperability, the first requirement of
accessing information will not necessarily be
inhibited if mission, vision and/or objectives are
different. However, the use of this information and
the use of functionalities may be quite pointless
because the information is created with the
aforementioned mission, vision and objectives in
mind. As a result, these can definitely be barriers.
Also consider two enterprise strategies that are not
aligned, one being a low cost strategy and the other a
differentiation strategy through high product quality.
The enterprises may not be able to use each other’s
functionalities because one may not require a
particular functionality at the lowest cost, but one of
the highest quality. Corporate culture is also
recognised as a conceptual barrier by both Interop
and the IDEAS framework. Cultures greatly
influence how business is conducted, and thus also
how enterprises are able to interoperate on the
business level. One only needs to imagine the
differences in the way European firms and Chinese
firms operate to see that culture is a valid potential
barrier. The IDEAS framework also deems the
relationships between the enterprise and the market
to be important concepts. They need to be viewed
similarly for enterprises to offer value together to
their market. One can extend this aspect to the
relationships with all stakeholders. It then becomes
obvious that enterprise’s stakeholders need to be
clearly defined for the relationships to be clear as
Process: A process is defined as “sequence of
interdependent and linked activities which consume
one or more resources to convert inputs into outputs.
The definition of the involved activities, resources,
inputs, outputs and end results have to be compatible
for processes to be interoperable. To group the
above, the meaning assigned to words describing the
concepts, i.e. the semantics, must all be the same.
The ATHENA framework proposes Enterprise
Architectures: models, meta-models, languages etc.
as quintessential solutions for the conceptual
integration of processes and lower levels of
abstraction. These solutions all pertain to the syntax,
which is the structure used to represent concepts
captured in the semantics. The modelling language
to design business processes comes to mind as an
example. Related to that, is the way that business
processes are connected to form a value
chain/network. Uniformity in this is also inhibited
by different models, or syntaxes. One organization
using IDEF0 to represent its processes, and the other
using process flow charts is an example of different
Service: Similarly to what has been identified at
process level, the names, descriptions and purposes
of services must be similarly defined in terms of
semantics and syntaxes. The IDEAS framework
adds to that the procedures, norms, rules and
references that either compose or support the
services. These too can be easily misunderstood, so
extra care needs to be taken regarding semantics,
syntax but also expressivity. How does one get the
correct meaning across to the other party, so both
have the same ideas about what the services should
do and how do they should be doing it. Each service
has an associated declarative policy that specifies
quality of service, availability, and other attributes
necessary to meet the overall business process goal
(Cuenca et al., 2014).
Data: Up to now, most research effort on conceptual
barriers has gone into interoperability at data level,
because it is the least abstract. Regarding semantics,
the terms used need to have exact similar meanings.
Any difference at all is what (Yahia et al., 2012)
referred to as a semantic gap. Two terms can have
no common meaning, i.e. they are ‘disjoint’. When
two terms have a partially common meaning, and a
unique part of meaning then the terms ‘intersect’.
‘Include’ occurs when one term completely
encompasses another, with former still possessing
additional meaning that is unique. Finally, two equal
terms is the preferred state, where no semantic gap is
present. Note that a semantic gap can occur at any
level of concern. The syntactic barriers then pertain
to the way data is structured. This can mean the use
of different modelling languages to model the data
structure, but also the choices made within the
language are important. Data on a given product
with a certain weight is stored in a database. The
weight is measured in a unit. Assume that the
semantics are the same. The data is modelled using
simple UML classes, so the modelling language is
the same. However, on the left, weight and the unit
of measurement are represented as attributes, whilst
on the right the weight is represented as a related
class. The database structure is not the same so
interoperability problems may arise when trying to
exchange data. Last but not least, care must be taken
concerning the validity of data. Data may be specific
to locations and therefore not valid in other systems.
An example is productivity rates for machines. In
one factory, this can be higher than in another. If the
location restriction is not clear, then data that is
invalid in another environment might be used
elsewhere anyway, leading to incorrect results. This
is known as the data restriction rule and was
identified in the EIF by Interop.
Miscellaneous: Of the five other potential barriers to
interoperability, trust, security and confidentiality do
not qualify as conceptual barriers. They are choices
to be made by organisations, but more in an
organisational context. The legal environment
influences how organisations interoperate, including
the conceptual part. E.g., if legislation requires
foreign enterprises to offer information in a certain
language that is not the enterprise’s, the definition of
concepts, i.e. the semantics, is influenced by legal
constraints. This legal environment is actually an
example of a relationship with a stakeholder, the
government in this case. To conclude, linguistics in
general is clearly a potential conceptual barrier. The
legislation example already showed that. Because
the choice for linguistics is made for the entire entity
or organisation, it is positioned at the business level.
Table 1: Conceptual barriers to interoperability classified
along the interoperability concerns.
Conceptual barriers to
Mission, vision
Business objectives,
Business strategy
Linguistics, Corporate
Relationships with
stakeholders (customers,
suppliers, government, etc.)
Vernadat, 2010
Interop, 2006
Chen et al., 2008
Ullberg et al., 2009
Process definition
-procedures, resources,
inputs, outputs
Process representation
-which enterprise
architecture employed
-connections between
business processes
Chen, 2010
Vernadat, 2010
Interop, 2006
Athena, 2010
Chen et al., 2008
Ullberg et al., 2009
Service definition
-name, description, purpose
-procedures, norms, rules,
Service representation
Interop, 2006
Chen et al., 2008
Ullberg et al., 2009
Semantics (disjoint,
intersect, include, equal)
Data characteristics
(definition and structuring)
Data description rule
Yahia, 2012
Ullberg et al., 2009
This new framework for the conceptual barriers to
interoperability is meant to identify generic
conceptual barriers and also show relationships
between them. The Interop classification of barriers
along the interoperability levels of concern is
employed, which are the business, process, service
and data levels. At process, service and data level,
the barriers are further divided into two categories,
those being semantics and syntax. This division is
not employed at the business level, because it cannot
be applied to all barriers.
The conceptual interoperability barriers
framework (CIBF) is shown in Figure 1. Within an
organisational entity, processes are designed to carry
out an enterprise’s business. The services in turn
support the processes and the data is used by the
services. For two entities e.g., interoperability at data
level is thus required first, before interoperability at
service level can be realised. The same applies
across all levels with interoperability at business
level being the highest form of interoperability. For
this reason, the framework is designed as a house
structure. The business level is placed in the roof to
show it encompasses the lower levels. The process,
service and data levels are placed in three stories
beneath the roof of business, to show they act as the
foundations upon which interoperability at higher
levels is built. The barriers at business level are
divided into two parts. The top part contains the
mission, vision and corporate culture. These are very
abstract barriers which do not directly influence
lower levels. Business objectives, strategies,
definition of stakeholders and relationships, and the
linguistics are conceptual barriers at the business
level that do influence lower levels more directly.
The objectives and strategies e.g. clearly influence
the way processes are designed. Therefore, they are
positioned closer to the lower levels.
The conceptual barriers concerning processes,
services and data basically consist of concepts
definitions and their structuring. Therefore they are
divided into a semantics section and a syntax
section. Examples of definitions and structures are
given in the framework at the corresponding levels.
Location validity of data is one conceptual barrier
that needs some explanation. Recall that data can be
specific to locations and therefore not valid in other
systems. Because this location validity is part of a
complete data definition, it is placed in the semantics
Horizontal and Vertical Interoperability. Two
organisational entities are depicted in the
framework, each containing the identified
conceptual barriers. The horizontal arrows between
them show that conceptual barriers must be
overcome at different levels for two entities to
achieve enterprise interoperability. The predominant
view among researchers is that the barriers impede
Figure 1: Conceptual interoperability barriers framework (CIBF) (Adapted from Hegeman and Cuenca (2013).)
this horizontal interoperability between two entities.
An additional conceptual barrier is what the Interop
project identified as expressivity. The way the
semantics and the syntax are communicated greatly
influence if the interoperability barriers can be
removed. It is therefore placed in between the two
organisational entities. Now, borrowing from
Panetto’s definition of vertical interoperability, the
definitions and structures used at the business,
process, service and data levels inside an entity must
also be interoperable with each other. That is to say,
within the organisational entity, definitions at
business level must be interoperable with definitions
at process level, these with definitions at service
level and so on until the data level. This might be
stating the obvious, but focusing on removing
barriers to horizontal interoperability could cause
vertical interoperability issues inside an
organisational entity. Mission, vision and culture are
not essential for vertical interoperability, therefore
the vertical interoperability arrow stops at business
The introduction of vertical interoperability
offers an invaluable view of the relationships
between barriers at different levels of concern. The
definitions of concepts and structures used to
represent them are interdependent. A definition at
any level automatically requires the other definitions
of the same concept at other levels to be similar. If
that is not the case, vertical interoperability issues
occur. The same applies to structures to avoid
misconceptions of important concepts.
7.1 Conceptual Semantic Barriers
The process of multi-organizational sofware
development is a clear example where we can
identify the interoperability barries at several levels.
The different stakeholders work at different and
distributed sites, with different specialities and
background (Mohtashamia et al., 2006). This matter
results in complex barriers to be avoided or
We can classify the problems identified in multi-
organizational software development through the
proposed CIBF in section 6 as follow:
Table 2: Generic conceptual barriers to interoperability in
the process of multi-organizational software development.
Conceptual Semantic Barriers
Business level:
Diverse organizational cultures
Multiples sets of business practices
Differing organizational goals
Nationalities and Languages
Lack of mediation and resolution
Different Rewards and compensation programs
Process level:
Expectation of behaviour
Multiple management models
Higher degree of uncertainty
Lower level of trust
One set of resources per partner plus shared
Multiply risk management plan
Some variation in professional standards
Independent plans
Biased risk identification
Service level:
Duplicate services
Deficiencies of partner’s practices
Failure to establish or use compatible services
Failure to establish proper boundaries between
Lack in version control
Data level:
Data sharing
Shared data security
Third-party information
Legal, political and intellectual data properties are
included in miscellaneous level. Once we have
identified the generic barriers, we will investigate
their appearance in practice on the basis of a
descriptive case study.
7.2 Case Study
The generic barriers have been investigated in a
business network of DEKRA Certification B.V. The
7.2.1 The Business Situation
The business network (set of collaborating
organizations) is an educational value network, in
which different types of organizations are
collaborating in the development of exam
(assessment) materials (i.e. examinations). The
customers are the employees of large organizations
in the energy (30.000 persons), the finance (150.000
persons) and the real estate domain (8000 persons).
All these employees have to do trainings and
examinations, on a one to three yearly basis, to stay
certified for doing their work (with respect to
financial safety, energy safety, and real estate
valuation safety). The collaborating organizations in
the network are:
DEKRA Certification (the certification body:
quality assurance tasks in training, examination,
The Exam Consultancy Office (ECO) (the
central party in the network): development and
maintenance of examination systems, both
custom made examination systems and
examination databases, and making these
systems available for Examination Institutes.
Examination Institutes: where customers can do
their exams (20-30 all over the country).
Software providers (A) of examination
Software providers (B) of custom made
examination systems.
Customer organizations (such as Bank
companies (e.g. ABN AMRO), and energy
suppliers (such as Enexis, Alliander, etc.)
7.2.2 The Methodology
The goal was to identify how the set of barriers
could be recognized in a business situation, and to
what extent their importance and relevance could be
discussed with representative practitioners. The
methodology to conduct the case study consisted of
three interviews with three experts (CIO level) of
three distinct companies in the network. The semi-
structured interviews consisted of a limited number
of open questions (15-20). Subjects of the questions
were respectively the collaboration and interaction
between companies (e.g. data sharing) in the
network, the joint development process on the
business level and the operational level, the
boundaries between the network components and
their implications regarding service orientation.
7.2.3 The Results, i.e. the Identification and
Discussion of the Generic Barriers in a
Real-life Situation
Regarding the multi-organizational software
development that takes place in the network, the
following collaborations could be distinguished::
1: The Exam Consultancy Office (ECO) and the
software providers (B) are involved in on-going
continuous development of the custom-made
examination systems (e.g. adding functionality,
improving performance etc.). The process consists
of: joint requirements engineering, iterative agile
development and testing, deployment, etc.)
2: Regarding requirements specification ECO
receives input from the various Examination
institutes (and input from their own employees
working with the systems).
3: ECO and software providers (B) both have to
collaborate (periodically) with software providers
(A) regarding the interfaces between the
examination systems and the examination databases.
4: DEKRA has to assess the examination systems
and databases regarding correctness, security, etc.
Regarding the generic conceptual barriers to
interoperability in the process of multi-
organizational software development (identified in
table 2 the following instantiations could be
identified in the business network (n.b.: text in italic
refers to Table 2).
On the Business Level: ECO and software
providers (B) have quite different organizational
cultures (e.g. software technology vs examination
business) and organizational goals (e.g. customer
satisfaction vs efficiency (cost/benefit)), etc.
Currently ECO is trying to set up an internal
business function 'IT-application management' to
improve the collaboration with the software
providers, and to be able to fulfill the requirements
On the Process Level: ECO is unsure about the
level of trust regarding the collaboration with
software providers (e.g. they speak different
languages and have different business goals).
They need a consistent and transparent multiple
risk management plan (regarding the comparison
and the balancing of the risks of the involved
software providers and their own risks).
On the Service Level: Regarding the barrier
proper boundaries between components’: ECO's
custom made examination systems are in different
business domains in different ways connected to the
internal/external examination database systems. E.g.
in the finance domain their custom made system is
connected to external examination databases (which
means: NO collaboration with the provider), in the
energy domain their custom-made system is
connected to an internal examination database
(managed by themselves in intensive collaboration
with a provider).
Further: a software provider (B) is hosting the
custom-made examination system of ECO. But there
are currently no SLAs, e.g. regarding availability
and performance of these systems. So, ECO is being
held responsible in case an examination system goes
down (‘Deficiencies of partner's practices).
On the Data Level: Regarding the barrier ‘Data
sharing’: examination candidates, e.g. from Bank
firms in the Finance domain, have to fill in their
personal data (incl. identity number) in case they are
going to do an assessment (exam). These data are
then becoming available to respectively: the
examination institutes, ECO, the software providers
and DEKRA. Currently a sound data security
program (rules, restrictions) is being redeveloped
regarding the storage and the management of these
Although the case study was descriptive and
qualitative the application of the proposed CIBF
(Conceptual Interoperability Barriers Framework)
has resulted in the identification of the
organizational entities involved in the multi-
organizational software development process and the
conceptual interoperability barriers at the different
levels (business, process, service and data).
The conceptual barriers could be identified
explicitly during the interviews, and consensus could
be reached on their importance and/or relevance. As
such the results offer a sound basis for more in-
depth, and preferably quantitative, case study
research for a further operationalization of the CIBF
The paper has characterized and identified a wide
selection of conceptual interoperability barriers,
taking them from relevant scientific articles on
enterprise interoperability. The most cited
interoperability frameworks; LISI, IDEAS,
ATHENA, E-health and the European
interoperability framework provided the most
conceptual barriers. Further work on developing
barriers and developing formal measures for
interoperability completed the set of conceptual
Coinciding barriers were grouped and eventually
classified by interoperability concern as defined in
the Enterprise Interoperability Framework by
Interop. The main barriers were the following.
Business level: Mission, vision, business objectives,
business strategy, linguistics, corporate culture and
relationships with stakeholders. Process level:
Process definition (semantics), process
representation (syntax) and connections between
business processes. Service level: Service definitions
(semantics) and service representations (syntax).
Data level: Data terminology definitions
(semantics), data structuring (syntax) and the data
restriction rule.
With the four levels of concern as a basis, a new
conceptual barriers framework was developed. It
included the general conceptual barriers to enterprise
interoperability, and introduced the concepts of
horizontal and vertical interoperability. Concepts at
the same level of abstraction in two organisational
entities need to be similar in semantics and syntax if
they are not to be barriers. This is the horizontal
direction. Apart from that, concepts also need to be
interoperable along a vertical dimension because
they are interrelated by default. Data is used by
Services to support processes that carry out the
business of an enterprise, so different semantics
and/or syntax would cause interoperability problems
within the organisational entity. The last element
added was the expressivity, i.e. how information is
communicated for understanding.
The proposal has been validated in a case study
of multi-organizational software development at the
business network of DEKRA Certification.
Identification is a required step towards removing
these barriers. We need to identify the problem with
the aim of being able to tackle it
Future research lines can be to analyze how the
interoperability levels of concern identified in the
framework relate to maturity levels of
interoperability, identify whether horizontal and
vertical interoperability barriers are interrelated and
thus affect each other.
Alonso J., I. Martínez de Soria, L. Orue-Echevarria and
M. Vergara (2010), Enterprise Collaboration Maturity
Model (ECMM): Preliminary Definition and Future
Challenges. Enterprise Interoperability IV, Part VII,
ATHENA. (2010). ATHENA interoperability framework.
Retrieved November 2012, from ATHENA European
Integrated projects:
Boza A., Cuenca L., Poler R., Michaelides Z. (2014) The
interoperability force in the ERP field. Enterprise
Information Systems pp 1-22
C4ISR, (1998). Architectures working group: levels of
information systems interoperability (LISI) [online].
Available from:*hamil
Cuenca L., Boza A., Ortiz A., Trienekens J.J.M. (2014)
Business-IT alignment and service oriented
architecture. A proposal of a service-oriented strategic
alignment model. ICEIS 2014 Proceedings of the 16
International Conference on Enterprise Information
Systems vol. 3, pp. 490-495
Chen, D., Doumeingts, G.,& Vernadat, F. (2008).
Architectures for enterprise integration and
interoperability: past, present and future. Computers in
Industry 59, pp. 647-659.
Chen D., N. Daclin Framework for enterprise
interoperability. Interoperability for Enterprise
Software and Applications, I-ESA05 (2005), pp. 77–88
Ducq Y., David Chen, Guy Doumeingts (2012). A
contribution of System Theory to Sustainable
Enterprise Interoperability Science Base. Computers in
Industry, Elsevier, 2012, 63 (8), pp.844-857
Ford T., et al. (2007) The Interoperability Score.
Proceedings of the 5th Annual Conference on Systems
Engineering Research. Hoboken, N.J., March 14-16,
Ford T., et al. (2008) Measuring System Interoperability:
An i-Score Improvement. Proceedings of the 6th
Annual Conference on Systems Engineering Research.
Los Angeles, CA, April 4-5, 2008
Guedria A (2012) THESE Contribution to Enterprise
Interoperability Maturity Assessment
Grefen, Paul W. P. J.; Dijkman, Remco M.. Hybrid
Control of Supply Chains: a Structured Exploration
from a Systems Perspective. International Journal of
Production Management and Engineering, [S.l.], v. 1,
n. 1, p. 39-54, jul. 2013. ISSN 2340-4876. Available
at: <
view/1544>. Date accessed: 23 Feb. 2014.
Hegeman J. and Cuenca L. (2013) Identification and
modeling of conceptual barriers in interoperability.
Cigip – Internal report.
Interop NoE. (2006). Deliverable DI.2 Enterprise
Interoperability - Framework and knowledge corpus –
Advanced report. Retrieved November 2012, from
ISO. (2000). ISO 15704:2000 Industrial automation
systems - Requirements for enterprise-reference
architectures and methodologies. Retrieved Nov. 2012,
from Int. Org. for Stand.:
Jardim-Goncalves R., Grilo A., Agostinho C., Lampathaki
F., Charalabidis Y.(2013) Systematisation of
Interoperability Body of Knowledge: the foundation
for Enterprise Interoperability as a science. Journal
Enterprise Information Systems - Information Systems
for Enterprise Integration, Interoperability and
Networking: Theory and Applications 7(1), February
2013, 7-32.
Lezoche M., Esma Yahia, Alexis Aubry, Hervé Panetto,
Milan Zdravković (2012), Conceptualising and
structuring semantics in cooperative enterprise
information systems models, Computers in Industry,
63(8), 775-787
Li, V., Liu, K. and Liu, S. (2013) Semiotic
interoperability- a critical step towards systems
integration. In: International Conference on
Knowledge Discovery and Information Retrieval and
the International Conference on Knowledge,
Management and Information Sharing, 19 - 22
September 2013, Vilamoura, Algarve, Portugal, pp.
Mohtashamia M., Marloweb T., Kirovac V. & Deekd
F.(2006) Risk Management for Collaborative Software
Development Information Systems Management
Volume 23, Issue 4, 20-30
Morris E., Levine L., Meyers C., Place P., and Plakosh D.
System of Systems Interoperability (SOSI), Final
Report. Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, PA, 2004
NEHTA (2005), Towards an Interoperability Framework,
Version 1.8, August 21, 2005.
Panetto, H. (2007). Towards a classification framework
for interoperability of enterprise applications.
International Journal of Computer Integrated
Manufacturing, Vol. 20, No. 8, pp. 727 – 740.
Shishkov B., M. Sinderen and A. Verbraeck (2009),
Towards flexible interenterprise collaboration: a
supply chain perspective, pp.513-527 In proceeding
of: Enterprise Information Systems, 11th International
Conference, ICEIS 2009
Sterling Commerce (2010), Optimize and Transform Your
Business Collaboration Network, Sterling Commerce
white paper.
Sun H.H., S. Huang and Y. Fan (2007), SOA-Based
Collaborative Modeling Method for Cross-
Organizational business Process Integration, LNCS
4537, pp 522-527
Ullberg J., David Chen, Pontus Johnson, Barriers to
Enterprise Interoperability, Proceedings of IFIP 5.8
workshop IWEI 2009, Lecture Notes in Business
Information Processing (LNBIP), Vol. 38, 2009, pp.
Vargas A., Boza A., Cuenca L., Scala I. (2013) Inter-
Enterprise Architecture and Internet of the Future. 4th
Doct. Conf. on Computing, Electrical and Industrial
Systems (DoCEIS’13) IFIP AICT 304, pp25-32
Vargas A., Cuenca L., Boza A., Scala I., Moisescu
M.(2014) Towards the development of the framework
for inter sensing enterprise architecture. Journal
Intelligent Manufacturing DOI: 10.1007/s10845-014-
Vernadat, F. (2010). Technical, semantic and
organizational issues of enterprise interoperability and
networking. Annual Reviews in Control 34, pp. 139-
Yahia, E., Aubrey, A., & Panetto, H. (2012). Formal
measures for semantic interoperability assessment in
cooperative enterprise information systems.
Computers in Industry 63, pp. 443-457.