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.

1 INTRODUCTION

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

521

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.

2 THEORETICAL FOUNDATION

To explain the phenomena of non-interoperability

that can be observed in various situations, the

following hypotheses can be made (Ducq et al,

2012).

 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

situations.

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

observable.

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

barriers.

3 CONCEPTUALIZATION

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

organization.

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

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

522

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.

4 LITERATURE REVIEW

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

interoperability”.

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

other:

ConceptualInteroperabilityBarriersFramework(CIBF)-ACaseStudyofMulti-organizationalSoftwareDevelopment

523

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)

5 ANALISYS

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

Interoperability

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

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

524

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

well.

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

syntaxes.

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

ConceptualInteroperabilityBarriersFramework(CIBF)-ACaseStudyofMulti-organizationalSoftwareDevelopment

525

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.

Concerns

Conceptual barriers to

interoperability

Reference

Business

Mission, vision

Business objectives,

Business strategy

Linguistics, Corporate

culture

Relationships with

stakeholders (customers,

suppliers, government, etc.)

Vernadat, 2010

Interop, 2006

Chen et al., 2008

Ullberg et al., 2009

Process

Process definition

(semantics):

-procedures, resources,

inputs, outputs

Process representation

(syntax):

-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

Service definition

(semantics):

-name, description, purpose

-procedures, norms, rules,

references

Service representation

(syntax)

Interop, 2006

Chen et al., 2008

Ullberg et al., 2009

Data

Semantics (disjoint,

intersect, include, equal)

Data characteristics

(definition and structuring)

Data description rule

Yahia, 2012

Ullberg et al., 2009

6 CONCEPTUAL

INTEROPERABILITY

BARRIERS FRAMEWORK

(CIBF)

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

column.

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

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

526

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

objectives.

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 APPLICATION TO THE

PROCESS OF

MULTI-ORGANIZATIONAL

SOFTWARE DEVELOPMENT

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

removed.

We can classify the problems identified in multi-

organizational software development through the

proposed CIBF in section 6 as follow:

ConceptualInteroperabilityBarriersFramework(CIBF)-ACaseStudyofMulti-organizationalSoftwareDevelopment

527

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

resources

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

components

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

Netherlands.

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,

certification),

 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

databases.

 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.)

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

528

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

of DEKRA.

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

data.

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

framework.

8 CONCLUSIONS

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

barriers.

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

ConceptualInteroperabilityBarriersFramework(CIBF)-ACaseStudyofMulti-organizationalSoftwareDevelopment

529

(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.

REFERENCES

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,

429-438

ATHENA. (2010). ATHENA interoperability framework.

Retrieved November 2012, from ATHENA European

Integrated projects: http://athena.modelbased.net/

framework.html

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: http://www.eng.auburn.edu/*hamil

ton/security/DODAF/LISI.pdf

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,

2007

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: <http://polipapers.upv.es/index.php/IJPME/article/

view/1544>. Date accessed: 23 Feb. 2014.

doi:http://dx.doi.org/10.4995/ijpme.2013.1544.

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

www.interop-vlab.eu: http://interop-vlab.eu/ei_public_

deliverables/interop-noe-deliverables/di-domain-intero

perability/di-2-enterprise-interoperability-framework-

and-knowledge-corpus/

ISO. (2000). ISO 15704:2000 Industrial automation

systems - Requirements for enterprise-reference

architectures and methodologies. Retrieved Nov. 2012,

from Int. Org. for Stand.: http://www.iso.org/iso/

home/store/catalogue_tc/catalogue_detail.htm?csnumb

er=28777

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

ICEIS2015-17thInternationalConferenceonEnterpriseInformationSystems

530

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.

508-513.

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.

13-24.

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-

0901-z

Vernadat, F. (2010). Technical, semantic and

organizational issues of enterprise interoperability and

networking. Annual Reviews in Control 34, pp. 139-

144.

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.

ConceptualInteroperabilityBarriersFramework(CIBF)-ACaseStudyofMulti-organizationalSoftwareDevelopment

531