Ea Article (1)

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 b

a LGIPM: Laboratoire de Ge´nie Industriel et Production Me´canique, ENIM/Universite´ de Metz, Ile du Saulcy, F-57045 Metz Cedex, France 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 interoperability 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: [email protected]. 1367-5788/$ – see front matter # 2007 Elsevier Ltd. All rights reserved. doi:10.1016/j.arcontrol.2007.03.004

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 information and knowledge. The main challenge is operations optimization via co-decision, co-ordination, and even negotiation 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.

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 socalled 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 technological 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., information 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 enactment, 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 integration 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 performing 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

139

Fig. 1. Integration levels.

 Data integration: In the 1980s, it was assumed that at the heart of integration were common, possibly distributed, interconnected 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 computerintegrated 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 originally 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

(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 timecritical 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 architecture 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

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.1. Enterprise architectures 4.3. Enterprise modeling for SOA Architecture is foundational for managing modern enterprises and planning enterprise integration. An enterprise architecture (EA) framework is an organized collection of ingredients (tools, methodologies, modeling languages, models, 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

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), scheduled 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 ITbased 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 callcenter 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

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

Fig. 2. Process_Customer_Order example.

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, personnel 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 OpenView 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 serviceoriented 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 messageoriented 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 communications 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 huband-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 interoperability 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 communicating 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. Ontologybased 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 communication 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 interacting 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 organizations 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 realworld 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: Functional 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 Integrated 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 methodology, 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 considerations: A holistic perspective as shown by the Purdue enterprise reference architecture. In Proceedings of the 4th international conference on enterprise 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 Academic 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 Language. 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. Franc¸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 administrator in the IT Directorate. His research work deals with enterprise architectures, 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 ‘‘Integrated 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.