Annual Reviews in Control 31 (2007) 137–145

www.elsevier.com/locate/arcontrol

Interoperable enterprise systems: Principles, concepts, and methods

F.B. Vernadat a,b
a
LGIPM: Laboratoire de Génie Industriel et Production Mécanique, ENIM/Université de Metz, Ile du Saulcy, F-57045 Metz Cedex, France
b
European Commission, Unit for e-Commission, Interoperability, Architecture and Methods, DG-DIGIT JMO C2/103, L-2920 Luxemburg, Luxembourg
Received 12 December 2006; accepted 5 March 2007
Available online 6 April 2007

Abstract
Interoperable enterprise systems (be they supply chains, extended enterprises, or any form of virtual organizations) must be designed,
controlled, and appraised from a holistic and systemic point of view. Systems interoperability is a key to enterprise integration, which recommends
that the IT architecture and infrastructure be aligned with business process organization and control, themselves designed according to a strategic
view expressed in an enterprise architecture. The paper discusses architectures and methods to build interoperable enterprise systems, advocating a
mixed service and process orientation, to support synchronous and/or asynchronous operations, both at the business level (business events, business
services, business processes) and at the application level (workflow, IT and Web services, application programs).
# 2007 Elsevier Ltd. All rights reserved.

Keywords: Enterprise integration; Enterprise architectures; Service-oriented architectures; Systems interoperability; Semantic interoperability

1. Introduction
Interoperable enterprise systems are central to enterprise
integration (EI). Indeed, they are essential components to build
agile organizations using a mixed service and process oriented
approach. Modern organizations, be they considered from the
intra or inter-organizational point of view, need to be made
interoperable both in terms of their business processes, their
applications or IT systems, and even their human resources to
face current business challenges (Vernadat, 2003, 2004).
Application integration has often been promised, but so far
never satisfactorily achieved. However, IT application inter-
operability is becoming a reality thanks to recent advances in
technology and standards. Many companies are getting away
from tight application-to-application interfaces and are
abandoning traditional enterprise application integration
(EAI) approaches that have resulted in too monolithic systems.
Instead, they are adopting more service-oriented, loosely
coupled, message-based, and asynchronous techniques.
For the single enterprise, integration means that it is
necessary to create a coherent information system architecture
in which the various administrative and business processes,
information stores, and systems are integrated so that they
E-mail address: Francois.Vernadat@ec.europa.eu.
appear seamless from the point of view of the individual user. In
other words, there is a clear need for an IT systems
interoperability platform if the goal is to achieve improved
efficiency and effectiveness of internal process and system
operations, timely procurements and fast product delivery, easy
and instant access to all required job-relevant information by
staff members, and enhanced reporting and monitoring
facilities at the administrative level.
For the networked enterprise facing global competition,
integration has another dimension. Networked organizations
are characterized by distributed control, inter-organizational
business processes (i.e., business processes that cross enterprise
boundaries and therefore do not belong to one enterprise),
various producer–consumer supply chains, and shared infor-
mation and knowledge. The main challenge is operations
optimization via co-decision, co-ordination, and even negotia-
tion mechanisms. The main advantage of the networked
organization is its flexible and dynamic structure (i.e., new
nodes can be added or removed to the network), which provides
the necessary agility to face changing economic conditions or
to implement new business strategies.
Agility requires interoperable enterprise systems, i.e.,
reconfigurable systems made of systems that can work together.
In this context, interoperability refers to the ability of a system
(or process) to use information and/or functionality of another
system (or process) by adhering to common standards.

1367-5788/$ – see front matter # 2007 Elsevier Ltd. All rights reserved.
doi:10.1016/j.arcontrol.2007.03.004
138 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
According to the European interoperability framework (EIF,
2004), interoperability can happen at three levels:
 technical level (i.e., data and message exchange);
 semantic level (i.e., information and service sharing);
 organizational level (i.e., business unit, process and people
interactions across organization borders).
Interoperability is only one of the many facets of enterprise
integration. EI concerns the cost-effective organization of a
business entity (single enterprise, networked enterprise, or
extended supply chain), its mission, vision and values, its
business processes and resources, understanding how they
relate to each other, and determining the enterprise structure so
as to efficiently and effectively execute enterprise objectives as
defined by the top management (AMICE, 1993; Kosanke &
Nell, 1997; Petrie, 1992; Vernadat, 1996; Williams, Bernus, &
Nemes, 1996).
The paper takes a holistic approach at interoperable
enterprise systems based on systems engineering principles.
More specifically, it first advocates a systemic approach based
on the concepts of events, services, and processes to build a so-
called service-oriented (enterprise) architecture. It then focuses
on IT systems interoperability aspects and standards required
for implementation.
2. Enterprise integration and interoperability defined
Enterprise integration occurs when there is a need in
improving interactions among people, systems, departments,
services, and companies (in terms of material flows, information
flows, or control flows). Enterprises typically comprise hundreds,
if not thousands, of applications (be they packaged solutions,
custom-built, or legacy systems), some of them being remotely
located. The situation gets even more complex with nowadays
frequent mergers, fusions, acquisitions, or new partnerships.
Integration of (inter- or intra-) enterprise activities has long
been, and often still is, confused with information systems
integration due to the bias of the computer science community.
While it is true that at the end of the day the prime challenge of
EI is to provide the right information at the right place at the
right time, business integration needs must drive information
integration. EI has therefore a strong organizational dimension,
in addition to its control/management dimension and techno-
logical dimension. In other words, integration needs must be
defined by business users, not by IT people!
From the IT standpoint, EI mostly means connecting
computer systems and IT applications to support business
process operations (Gold-Bernstein & Ruh, 2005; Hohpe &
Woolf, 2004). It involves technologies such as enterprise
portals, data replication, shared business functions (or remote
method invocation), enterprise service bus, distributed business
processes (or workflow systems), and business-to-business
integration.
From an organizational standpoint, EI is concerned with
facilitating information, control, and material flows across
organization boundaries by connecting all the necessary
functions and heterogeneous functional entities (e.g., informa-
tion systems, devices, applications, and people) in order to
improve communication (data and information exchanges at
system level), cooperation (interoperation at application level),
and coordination (timely orchestration of process steps at
business level) within this enterprise so that it behaves as an
integrated whole (Fig. 1) (Vernadat, 1996). It will, therefore,
enhance overall productivity, flexibility, and capacity for
management of change (i.e., reactivity). Li and Williams (2004)
provide a broader definition of EI stating that enterprise
integration is the coordination of all elements including
business, processes, people, and technology of the enterprise(s)
working together in order to achieve the optimal fulfillment of
the business mission of that enterprise(s) as defined by the
management.
A holistic approach to integration is therefore necessary that
takes into account the business strategy as defined from the
enterprise vision, the business process definition and enact-
ment, and the design and operation of interoperable enterprise
systems as supported by a relevant and efficient IT
infrastructure. A global framework for the assessment of EI
approaches and technologies has been proposed by Giachetti
(2004).
Enterprise integration can apply vertically or horizontally
within any organization. Vertical integration refers to integra-
tion of a line of business from its top management down to its
tactical planning and operation levels. Horizontal integration
refers to integration of the various domains (i.e., business areas)
of the enterprise or with its partners and environment.
Integration can range from loose to tight and full integration.
Full integration means that components systems are no more
distinguishable in the whole system. Tight integration means
that components are still distinguishable but any modification
on one of them may have direct impact on others. Loose
integration means that component systems continue to exist on
their own but can work as component of the integrated system.
Enterprise interoperability equates to loose integration. It
provides two or more business entities (of the same
organization or from different organizations and irrespective
of their location) with the ability of exchanging or sharing
information (wherever it is and at any time) and of using
functionality of one another in a distributed and heterogeneous
environment. It preserves component systems as they are. This
requires a fair amount of open standards (Chen & Vernadat,
2004).
Broadly speaking, interoperability is the ability of perform-
ing interoperation between two or more different entities (be
they pieces of software, processes, systems, business units,
etc.). Thus, Enterprise interoperability is concerned with
interoperability between organizational units or business
processes either within a large (distributed) enterprise or
within an enterprise network. Part of the challenge relies in
facilitating communication, cooperation, and coordination
among these processes and units as defined in Fig. 1.
The major principles and technological waves that have
prevailed in building integrated or interoperable enterprise
systems so far have been:
 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
Fig. 1. Integration levels.
 Data integration: In the 1980s, it was assumed that at the heart
of integration were common, possibly distributed, inter-
connected databases (as found in CAD, CAPP, PDM, MRP, or
CAM systems) and data exchange formats (IGES, STEP,
EDI, etc.). This was the technology used in computer-
integrated manufacturing (CIM).
 Object-oriented approaches and object request brokers
(ORBs): The universal description of any kind of entities
as object classes, encapsulating static object description as
properties and dynamic object behavior as methods together
with object class specialization/aggregation with property
inheritance, has been the second major principle. Together
with the client–server approach, this opened the door to open
systems and reusability. The object management group
(OMG) played a central role with the definition of common
object request broker architecture (CORBA) and its
associated interface description language (IDL) in the mid
1990s.
 Business process modeling (BPM) and process-oriented
approaches: When the real needs of enterprise integration
were better understood as being much more than just systems
and data integration with remote procedure calls or method
invocation (RPC/RMI), it became obvious that business
processes (i.e., the sequence of steps that govern enterprise
operations to achieve business objectives) had to be modeled,
re-engineered, controlled, and made interoperable. Thus, a
whole range of new approaches centered on business
processes, including workflow systems, emerged as origin-
ally suggested by the CIMOSA architecture for enterprise
integration in manufacturing (AMICE, 1993).
 Enterprise application integration (EAI): EAI takes advantage
of object-oriented technology, hub-and-spoke architectures
139
(e.g., OMG/CORBA, OSF/DCE, or MS/DCOM and OLE) as
well as BPM techniques to provide global solutions within the
enterprise for application integration (Linthicum, 2000). EAI
commercial platforms offer a wide range of built-in connectors
to different technologies (ERP systems, CRM systems,
database systems, CAD/CAM systems, etc.).
 Web services and service-oriented architectures (SOAs):
Since year 2000, service-oriented architectures represent a
new generation of IT system architectures taking advantage
of message-oriented, loosely coupled, asynchronous systems
as well as Web services (Herzum, 2002; Kreger, 2001; Khalaf
et al., 2004). SOAs provide business analysts or integration
architects with a broad abstract view of applications and
integration components to be dealt with as encapsulated and
reusable high-level services. This is further discussed in
Section 4.
3. What was wrong with CIMOSA, CORBA, and EAI?
The major advantage of ORB and EAI solutions is that,
thanks to the common object request broker or message bus, the
business logic is clearly separated from the integration logic. If
direct communication is required for synchronous and time-
critical applications, then remote procedure call (RPC) or
remote method invocation (RMI) solutions are usually
preferred. The use of shared databases and stored procedures
is another technical option for application exchanges.
The major problems with the CIMOSA integrating
infrastructure, CORBA, and EAI in general are
1 They heavily rely on specific or even proprietary standards
(IDL, message formats, connectors, RDBA, etc.).
140 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
2 They tend to create tightly coupled systems and monolithic
architectures. In other words, they can only ‘‘talk’’ to
themselves (i.e., the same technology). If something is
changed in the integrating infrastructure, the whole archi-
tecture falls apart.
3 They assume synchronous operation, i.e., all systems
involved in the communication must be up and running at
the same time.
4 They do not scale up well when the number of components to
be interconnected becomes significant.
Another solution is to build loosely coupled systems in
which applications supporting business processes, made of
services, exchange messages (in synchronous or asynchronous
mode) with neutral format using simple protocols (e.g., TCP/IP,
SMTP, HTTP, or XML/SOAP).
4. Service-oriented architectures
4.1. Enterprise architectures
Architecture is foundational for managing modern enter-
prises and planning enterprise integration. An enterprise
architecture (EA) framework is an organized collection of
ingredients (tools, methodologies, modeling languages, mod-
els, etc.) necessary to architect or re-architect whole or part of
an enterprise. For a given enterprise, the enterprise architecture
describes the relationships among the mission assigned to the
enterprise, the work the enterprise does, the information the
enterprise uses, and the physical means, human labor, and
information technology that the enterprise needs.
The prime advantage of an enterprise architecture is to
provide a common view (in the form of models) of what is
going on in the enterprise to relevant actors or shareholders of
the enterprise. The second decisive advantage of an EA is that it
provides a sound basis for the management of change that
occurs throughout the life cycle of the enterprise. Thus,
enterprise modeling (EM) is the prime ingredient of an
enterprise architecture framework because it is central to carry
out enterprise engineering and plan enterprise integration
(Bernus, Nemes, & Williams, 1996; Kosanke & Nell, 1997;
Petrie, 1992; Vernadat, 1996).
The IFAC-IFIP task force on architectures for enterprise
integration has defined two types of architectures: Type 1 and
Type 2 (Williams et al., 1996).
 Type 1 architectures are those which describe a particular
architecture or physical structure of some component or part
of the integrated system such as the computer system or the
communications system.
 Type 2 architectures are those which present a reference
architecture or structure of the project which develops the
integration program, i.e., those that illustrate the life cycle of
the project developing the integrated enterprise.
Well-known Type 2 architectures include CIMOSA, PERA,
GRAI, ARIS, or the Zachman Framework. The generalized
enterprise reference architecture and methodology (GERAM),
as proposed by the IFAC-IFIP task force, is a generalization of
those, covering the complete life cycle of an enterprise
(GERAM, 1997).
4.2. Service-oriented architectures (SOAs)
Service-oriented architectures are emerging as a new wave
for building agile and interoperable enterprise systems. It is
about designing and building IT-based business systems using
heterogeneous network addressable software components
(preferably over Internet). These interoperable standards-based
components or services (i.e., callable and reusable functions
accessible by their interface) can be directly invoked by
business users or executed as basic steps of business processes.
They can be combined and reused quickly to meet business
needs. They can be implemented as Web services or functions
of Web applications and, therefore, be located anywhere in the
organization or on the Web (Herzum, 2002).
4.3. Enterprise modeling for SOA
To architect an enterprise from a SOA perspective, three
main concepts are essential to model the organization behavior.
Namely these are: event, service, and process. Each of these
must then be understood and materialized at the business level
and at the application level.
At the business or organization level, the three concepts
will naturally be called business event, business service, and
business process. Concepts of business event and business
process (together with enterprise activity) have been
precisely defined in CIMOSA (Berio & Vernadat, 2001) or
in BPMN (BPMI, 2005) and are part of EN ISO 19440 (CEN/
ISO, 2005). In this paper, the concept of business service is
added.
4.3.1. Business event
A business event is a fact or happening that occurs in the
enterprise operations and triggers execution of action, i.e.,
either activating a single business service or an entire business
process. It corresponds to a change in the state of the enterprise
that must be responded. Business events can be solicited events
(e.g., requests or management orders), unsolicited events (e.g.,
machine breakdowns or exception handling requests), sched-
uled events (e.g., a timer or a specific clock time, a list of
scheduled orders), or synchronization events (e.g., start or end
of an activity).
4.3.2. Business process
A business process is a partially ordered sequence of steps
(e.g., human facing, application, machine, or human-based
activities) executed to perform some enterprise goals. Business
process execution is triggered by one or more event
occurrences. For instance, Process_Customer_Order can be
one of the business processes of the sales department. Business
process steps are either enterprise activities or business
services.
 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
4.3.3. Enterprise activity
An enterprise activity is an elementary step of a business
process. It is the locus of action and, therefore, transforms
inputs into outputs over time using resources to produce
expected results. Inputs, outputs, and resources are enterprise
objects. For instance, Collect_Order could be one of the first
activities of the Process_Customer_Order process.
4.3.4. Business service
A business service is a discrete piece of functionality that
appears to be atomic and self-contained from the point of view
of the service caller. It must be uniquely identified within the
enterprise and has a service owner. A business service can be
stateless (no memory of previous calls) or state-full (it
remembers previous states for previous calls). For instance,
Update_Customer_Address can be a stateless business service
offered by the customer relationship management (CRM)
department. In CIMOSA, business services correspond to IT-
based enterprise activities.
4.3.5. Nota Bene
 A business service can be used independently of anything
else (asynchronous execution). In this case, it is equivalent to
a business process comprising one step.
 A business service can be invoked to perform a given step of a
business process (synchronized action flow execution). In this
case, it is equivalent to an activity.
 A business service can be used by several processes.
 A business service can be made of other services.
 Service orchestration refers to some business behavior or
process in which all steps are business services.
In terms of implementation, a business service can either be
performed by a human agent (i.e., human action such as a call-
center service) or a technical agent. In the case of IT-based
services, they can be implemented as Web services.
4.4. An illustrative example
Let us consider a simple example within an on-line sales
company that takes orders via Internet directly from customers.
The order collection module on the company’s Internet website
Fig. 2. Process_Customer_Order example.
141
is a Web service that gets the full details about the order and
generates a business event of type New_Order_Arrival. Any
occurrence of this event will trigger an occurrence of the
business process called Process_Customer_Order (Fig. 2).
The Process_Customer_Order business process is made of
two enterprise activities (Collect_Order and Process_Order) and
one business service (Create Customer). The Collect_Order
activity is realized by a software application called Order_En-
try_System that has to perform three functional operations in
sequence (Seize order, Check order, and Check customer). These
are application functions that can be implemented as IT services
and orchestrated by the application logic. At the end of this
activity we either get the ‘new customer’ or the ‘known customer’
ending status. Branching in the process workflow is made
according to the ending status value obtained. If the order entry
system has detected that it is a new customer, the Create
Customer business service is called. In this case, it is executed by
an order entry clerk. If it is a known customer (already in the
customer database), the Process_Order activity is activated (also
made of three functional operations).
What makes the Create Customer service different from the
activities is that it can also be activated by the clerk at any
moment (i.e., asynchronously) without having to be part of a
business process (for instance, to manually create a new
customer entry in the database). Activities are always steps of
business processes. In this case, let us assume that this business
service is implemented as a Web service. It can be made of
lower level IT services.
5. Building interoperable enterprise systems
Once the business services and processes have been defined
and modeled, the enterprise activities have been specified and
implemented, and the functionality of applications has been
encapsulated in low level cooperating services, immediate
questions that come to mind from an implementer’s standpoint
include: How to interconnect services? How to orchestrate their
execution in an orderly fashion? How to synchronize
processes? How to control security? How to share data and
services with partners?
In practice, the following components appear to be essential
building blocks to build interoperable enterprise systems.
142 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
(1) Enterprise portals: These are Web gateways that provide
users with a single entry point to a large collection of
information sources and services organized by themes or
categories, the presentation of which can be personalized
according to user profiles or preferences (Wilkinson, Jawa,
Lange, & Raimer, 2000). A portal application is normally
used to pull data from multiple backend sources and present
it in a unified way via any Web browser. A portal is made of
a collection of pages. A page is divided into regions, which
can contain text, images, or portlets. A portlet is a portal
facility that provides access to some specific information
sources or applications (e.g., news feeds, databases,
backend systems, remote websites, etc.). Therefore,
applications can expose services, services can be mapped
to portlets and presented in portal pages, and users can
easily access services via the portal. The portal can also be
used as a user interface to any business process step.
Intranet portals will serve the needs of enterprise employee
staff while extranet or Internet portals can link the company
with customers or business partners using different sets of
services (Fig. 3).
(2) Single sign-on (SSO)/identity management: To avoid that
people have to login several times a day with different
usernames/passwords to different systems, a single sign-on
solution must be implemented for user authentication. User
authorization to access IT resources is usually a very
complex organizational problem because it concerns the IT
department, the human resources (HR) department, as well
as business departments. Access can depend on user roles,
user jobs/duties, or specific business rules. It is therefore
important to first establish the map of all administrative
processes (e.g., entry of new employees, departures,
mutations, access right delegation, etc.). Second, identity
attributes (e.g., first-name, family-name, function, person-
nel ID, organization unit, etc.) must be defined and stored in
the central user directory (LDAP). Then, user roles and
profiles can be defined and mapped with permissions to
access IT resources. Finally, workflow and business rules
implementing identity management processes must be put
in place. This is the role of identity management products
Fig. 3. Enterprise portals and services.
such as IBM’s Tivoli Identity Management, Oracle Identity
Management (ex-Oblix), Sun Identity Manager, HP Open-
View Identity and Access Management, or CA’s ETrust
Identity and Access Management (ex-Netegrity).
(3) Workflow engines: The automation of business processes
(even including human activities) and the orchestration of
the use of IT services supporting business services require
the use of a workflow engine in the case of well-structured
or semi-structured processes, i.e., processes for which
execution of the step sequence can be prescribed. In the case
of ill-structured processes, ad hoc solutions need to be
implemented or just leave IT services to be accessed
separately when needed. The workflow engine technology
is now very matured and many systems exist on the market
place (IBM, SAP, Oracle, BEA Systems, Ultimus, etc.).
(4) Service registry: A service registry is a metadata repository
that maintains a common description of all services
registered for the functional domain for which it has been
set up. Services are described by their name, their owner,
their service level agreement and quality of service, their
location, and their access method. It is used by service
providers to expose their services and by services users to
locate services. Universal description, discovery, and
integration (UDDI) is an XML-based registry for businesses
worldwide to list themselves on the Internet. Its ultimate
goal is to streamline online transactions by enabling
companies to find one another on the Web and make their
systems interoperable for e-commerce. UDDI is often
compared to a telephone book’s white, yellow, and green
pages. Within a company or within a network of companies,
a private service registry can be established in a similar way
than UDDI to manage all shared business and data services
used across the business units.
(5) Message and service buses—MOM/ESB: The key to
building interoperable enterprise systems and service-
oriented architectures that are reliable and scalable is to
ensure loose coupling among services and applications.
This can be achieved using message queuing techniques,
and especially message-oriented middleware (MOM)
products and their recent extension known as enterprise
service bus (ESB) (Hohpe & Woolf, 2004). Services and IT
applications exchange messages in a neutral format
(preferably XML) using simple transport protocols (i.e.,
XML/SOAP on TCP/IP, SMTP, or HTTP). A message-
oriented middleware is a messaging system that provides
the ability to connect applications in an asynchronous
message exchange fashion using message queues. It
provides the ability to create and manage message queues,
to manage the routing of messages, and to fix priorities of
messages. Messages can be delivered according to three
basic messaging models:
 Point-to-point model: in which only one consumer may
receive messages that are sent to a queue by one or more
producers;
 Publish-and-subscribe: in which multiple consumers may
register, or subscribe, to receive messages (called topics)
from the same queue.
 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
 Request/reply that allows reliable bidirectional commu-
nications between two peer systems.
An enterprise service bus goes beyond the capabilities of a
MOM. It is a standards-based integration platform that
combines messaging of a MOM, Web services, data
transformation, database access services, intelligent routing
of messages, and even workflow execution to reliably connect
and coordinate the interaction of significant numbers of diverse
applications across an extended organization with transactional
integrity. It is capable of being adopted for any general-purpose
integration project and it can scale beyond the limits of a hub-
and-spoke EAI broker. Data transformation is the ability to
apply XSLT to XML messages to reformat messages during
transport depending on the type of receivers that will consume
the messages (for instance, the ZIP code is a separate
information datum for one application while it is part of an
address for another one). Intelligent or rule-based routing is the
ability to use message properties to route message delivery to
different queues according to message content. Database
services simplify accesses to database systems using SQL and
Java database connectivity (JDBC). Common enterprise
integration patterns as used in practice with messaging
components have been thoroughly analyzed and described
by Hohpe and Woolf (2004).
6. Semantic interoperability
While MOM/ESB ensures message-enabled integration and
that application interoperability remains at the data and
syntactic level, semantic interoperability concerns data/
information integration and consistency. Semantic interoper-
ability is the ability to share, aggregate, or synchronize data/
information across heterogeneous information systems. In
other words, it is about making sure that the two commu-
nicating systems interpret the information the same way.
Considering the number of databases and information systems
in use in any large corporation and considering that information
meaning is context-dependent, one can realize the complexity
of the problem.
This is a hard problem and unfortunately there is no
packaged or out-of-the-box solution. It is up to each company,
once IT application interoperability is in place, to develop its
own strategy and solution for semantic data interoperability. A
first solution is to build shared metadata repositories that
describe the content and intent of data stored in the various
information systems used in the enterprise or by partner
companies.
Another solution is to build an ontology for enterprise
interoperability (Uschold, King, Moralee, & Zorgios, 1998;
Panetto, Whitmann, & Chatha, 2005). In IT terms, an ontology
is a specification of a conceptualization of the knowledge of
some specific domain. It is used to formally describe every
concept used in this domain as well as their relationships and
associations using axioms, predicates, and formulae. Upper
ontologies deal with universal concepts or micro-theories (of
time, cost, quality, etc.) while domain ontologies deal with
143
concepts specific to an application domain (e.g., power
electricity, geometrical features, customer relationships, etc.).
Ontology is used as a pivotal language to map concepts used
in one system with concepts of another system and resolve the
semantic impedance mismatch. It is probably one of the most
promising perspectives in research to use enterprise models in
an optimal way for enterprise architecture design. Ontology-
based semantic interoperability is a very active and long-term
research objective.
7. Essential standards
When dealing with enterprise architecture, enterprise
integration, and Interoperability, a certain number of standards
or standardization efforts need to be considered. They have
been surveyed in some depth by Chen and Vernadat (2004) and
Giachetti (2004).
Among these, a few essential standards that play a key role
in enterprise interoperability must be mentioned. These are1
(1) XML: The extended markup language is a standard and
widely used tagged language proposed and maintained by
the World Wide Web Consortium (W3C). It is intended to
be a universal format for structured content and data on the
Web. Its simple and open structure has revolutionized data,
information, and request/reply exchanges among computer
systems because XML messages can be handled by
virtually any transport protocol due to its alphanumeric
nature (W3C, 2000).
(2) BPMN: The business process modeling notation is a
graphical and semi-structured notation that provides
businesses with the capability of understanding their
internal business procedures in a graphical language. It
gives organizations the ability to communicate these
procedures in a standard manner. Furthermore, the
graphical notation facilitates the understanding of the
performance collaborations and business transactions
between the organizations. This ensures that businesses
will understand themselves and participants in their
business and will enable organizations to adjust to new
internal and B2B business circumstances quickly (BPMI,
2005).
(3) BPEL: The business process execution language is an
XML-based language designed to enable task-sharing for a
distributed computing – even across multiple organizations
– using a combination of Web services (BPEL is also
sometimes called BPEL4WS or BPELWS). It has been
written by developers from BEA Systems, IBM, and
Microsoft. BPEL specifies the business process logic that
defines a choreography of interactions between a number of
Web Services. The BPEL standard defines the structure,
tags, and attributes of an XML document that corresponds
to a valid BPEL specification (IBM, 2003).
(4) HTTP/HTTPS: Hypertext transfer protocol is the set of rules
for transferring files (text, graphic images, sound, video,
1
Text adapted from definitions provided by http://www.whatis.com/.
144 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
and other multimedia files) on the World Wide Web. HTTP
is an application protocol that runs on top of the TCP/IP
suite of protocols. Because of its ubiquity it has become an
essential standard for communications. HTTP 1.1 is the
current version (http://www.w3.org/Protocols/).
(5) SOAP: The simple object access protocol is a communica-
tion protocol and a message layout specification that defines
a uniform way of passing XML-encoded data between two
interacting software entities. SOAP has been submitted to
the World Wide Web Consortium to become a standard in
the field of Internet computing (W3C, 2002). It still lacks
security mechanisms for the transfer of sensitive data and
messages.
(6) WSDL: The Web service description language is a contract
language used to declare Web service interfaces and
access methods using specific description templates (W3C,
2001).
8. Research perspectives
Fundamentally, interoperability assumes trust among inter-
acting parties. You need to trust the quality of the service
provided by the service suppliers and you need to trust the
information accessed, especially if you need to combine this
service with other services to form an aggregated service.
Conversely, as a service provider, you need to trust consumers
of your services: you want to be sure that the consumer is the
one he pretends to be and you would like to be sure he will use
the service for the purpose it has been designed.
This raises a number of issues that still need to be completely
solved. Among these are
 secure networking, especially in the context of Web services;
 message logging from end to end in environments where
traceability is needed;
 user identification and identity federation across organiza-
tions or in networked organizations to allow multiple
identification methods to co-exist;
 transaction certification in networked organizations to
ascertain the services and messages exchanged;
 service composition or aggregation;
 service certification in the case of applicable legal obligations
to guarantee the correctness and integrity of the service;
 semantic interoperability and the development of related
ontologies, which is still an open domain both in terms of
description language, content, and usage.
9. Conclusion
The new economic order imposed by globalization is forcing
companies to change their strategic vision, to join forces by
creating highly skilled, competitive and reactive enterprise
networks, and to constantly adjust their objectives with
fluctuating market conditions. Enterprise integration, in its
broad sense, is one way to pursue this goal and support
management and control of these networked interoperable
enterprise systems. The paper advocates a service-oriented
architecture sustaining business process orchestration, this
architecture itself relying on an enterprise service bus.
Some golden rules for building interoperable enterprise
systems include:
 Place customers fully at the center of the architecture.
 Interoperability/EI is at least as much about people,
organization, and mission/strategies as it is about technology.
 Build open systems architectures relying on open and agreed
upon de facto standards.
 Achieve flexible operations, respecting enterprise diversity
(business, methods, culture, approaches, etc.).
 Give priority to continuous improvements using a maturity
model approach and a proven change management policy (do
not try to go right away to the ultimate goal but go
incrementally step by step—or ‘Think big, start small’).
 Focus on service definition, delivery, and quality level from
the beginning.
 Differentiate sequential operations (business processes) from
stand-alone operations (business services) according to real-
world needs to cater for process-driven versus event-driven
operations.
 Adopt as much as possible loosely coupled, message-based,
and asynchronous communication principles.
References
AMICE. (1993). CIMOSA: CIM Open System Architecture (2nd ed.). Berlin:
Springer-Verlag.
Berio, G., & Vernadat, F. (2001). Enterprise modeling with CIMOSA: Func-
tional and organizational aspects. Production Planning & Control, 12(2),
128–136.
Bernus, P., Nemes, L., & Williams, T. J. (Eds.). (1996). Architectures for
enterprise integration. London: Chapman & Hall.
BPMI. (2005). Business process modeling notation. http://www.bpmn.org/.
Chappell, D. A. (2004). Enterprise service bus. USA: O’Reilly Media Inc.
CEN/ISO. (2005). Enterprise integration—constructs for enterprise modelling,
prEN 19440, CEN/TC 310 and ISO/TC 184. London, UK: BSI Secretariat.
Chen, D., & Vernadat, F. (2004). Standards on enterprise integration and
engineering—A state of the art. International Journal of Computer Inte-
grated Manufacturing, 17(3), 235–253.
EIF. (2004). European interoperability framework, white paper. Brussels:
February 2004. http://www.comptia.org.
GERAM. (1997). Generalized enterprise reference architecture and methodol-
ogy, GERAM version 1.5. IFIAC-IFIP task force on enterprise integration.
Giachetti, R. E. (2004). A framework to review the information integration of
the enterprise. International Journal of Production Research, 42(6), 1147–
1166.
Gold-Bernstein, B., & Ruh, W. (2005). Enterprise integration: The essential
guide to integration solutions. Boston, MA: Addison–Wesley.
Herzum, P. (2002). Web services and service-oriented architecture. Executive
report vol. 4, no. 10, Cutter Distributed Enterprise Architecture Advisory
Service.
Hohpe, G., & Woolf, B. (2004). Enterprise integration patterns: Designing,
building and deploying messaging solutions. USA: Pearson Education Inc.
IBM. (2003). Business process execution language for Web services. http://
www.ibm.com/developersworks/library/ws-bpel/.
Khalaf, R., Curbera, F., Nagy, W., Mukhi, N., Tai, S., & Duftler, M. (2004).
Understanding Web services. In M. Singh (Ed.), Practical handbook of
Internet computing. Boca Raton, FL: CRC Press LLC.
In K. Kosanke & J. G. Nell (Eds.), Enterprise engineering and integration:
Building international consensusBerlin: Springer-Verlag.
 F.B. Vernadat / Annual Reviews in Control 31 (2007) 137–145
Kreger, H. (2001). Web services conceptual architecture (WSCA 1.0). NY, USA:
IBM Software Group, IBM, Somers.
Li, H., & Williams, T. J. (2004). A vision of enterprise integration considera-
tions: A holistic perspective as shown by the Purdue enterprise reference
architecture. In Proceedings of the 4th international conference on enter-
prise integration and modeling technology (ICEIMT’04).
Linthicum, D. S. (2000). Enterprise application integration. Boston, MA:
Addison–Wesley.
Panetto, H., Whitmann, L., & Chatha, K. A. (2005). Ontology for enterprise
interoperability in the domain of enterprise business modeling. In H. Panetto
(Ed.), Interoperability of enterprise software and applications (pp. 103–
113). London: Hermes Science Publishing.
In C. J. Petrie (Ed.), Enterprise integration modelingCambridge, MA: The MIT
Press.
Uschold, M., King, M., Moralee, S., & Zorgios, Y. (1998). The enterprise
ontology. The knowledge engineering review, 13(1), 31–89.
Vernadat, F. B. (1996). Enterprise modeling and integration: Principles and
applications. London: Chapman & Hall.
Vernadat, F. (2003). Enterprise modelling and integration: From fact modelling
to enterprise interoperability. In K. Kosanke, R. Jochem, J. G. Nell, & A.
Ortiz Bas (Eds.), Enterprise inter- and intra-organizational integration:
Building international consensus (pp. 25–33). Dordrecht: Kluwer Aca-
demic Press.
Vernadat, F. (2004). Interoperable enterprise systems: Principles, architectures
and metrics. In Proceedings of international conference on management
control and production logistics (MCPL’04) (Keynote paper).
Wilkinson, P., Jawa, N., Lange, P. B., & Raimer, A. (2000). Enterprise
information portal—a cookbook. IBM RedBooks.
Williams, T. J., Bernus, P., & Nemes, L. (1996). The concept of enterprise
integration. In P. Bernus, L. Nemes, & T. J. Williams (Eds.), Architectures
for enterprise integration (pp. 9–20). London: Chapman & Hall.
145
W3C. (2000). World Wide Web Consortium, XML: eXtensible Mark-up Lan-
guage. http://www.w3.org/xml.
W3C. (2001). World Wide Web Consortium, WSDL: Web Service Description
Language. http://www.w3.org/TR/wsdl.
W3C. (2002). World Wide Web Consortium, SOAP: Simple Object Access
Protocol. http://www.w3.org/TR/SOAP.
Prof. François B. Vernadat has been a research officer, first at the National
Research Council of Canada (NRCC), Ottawa, in the 1980s and then at the
Institut National de Recherche en Informatique et Automatique (INRIA),
France, in the 1990s. Since 1995 he has been a professor at the University
of Metz in automatic control and industrial engineering. At the end of 2001, he
joined the European Commission, DG Eurostat in Luxemburg, as an admin-
istrator in the IT Directorate. His research work deals with enterprise archi-
tectures, enterprise modeling and integration, information systems design and
analysis, CIM and various aspects of industrial engineering (facility layout,
performance evaluation, cost estimation, and competence modeling). He has
lectured in many countries in Europe, North and Latin America, China, and
North Africa. He is the author of over 250 scientific papers in journals,
conferences, and edited books. He is the author of the textbook ‘‘Enterprise
Modeling and Integration: Principles and Applications’’, co-author of the book
‘‘Practice of Petri nets in Manufacturing’’ and co-editor of the book ‘‘Inte-
grated Manufacturing Systems Engineering’’, all published by Chapman &
Hall. He is as an associate editor for Computers in Industry, International
Journal of Computer Integrated Manufacturing and International Journal of
Mechanical Production Systems Engineering, and is on the editorial board of
International Journal of Production Research and Robotics and CIM. He has
served as vice-chairman several technical committees of the IFAC, he is a
member of IEEE and ACM, has been chairman or vice-chairman of several
international conferences on industrial engineering and is on the editorial board
of several scientific journals.