Architectures for enterprise integration and interoperability: Past, present and future

Computers in Industry 59 (2008) 647–659

Contents lists available at ScienceDirect

Computers in Industry journal homepage: www.elsevier.com/locate/compind

Architectures for enterprise integration and interoperability: Past, present and future David Chen a,*, Guy Doumeingts b, Franc¸ois Vernadat c a

IMS-LAPS, University Bordeaux 1, 351 Cours de la liberation, 33405 Talence Cedex, France ADELIOR France, GFI Group, 12 rue Rouget de Lisle, 92442 Issy-les-Moulineaux Cedex, France c LGIPM, University of Metz, Ile du Saulcy, F-57045 Metz Cedex 1, France b

A R T I C L E I N F O

A B S T R A C T

Article history: Accepted 1 December 2007 Available online 22 May 2008

The paper defines and clarifies basic concepts of enterprise architectures. Then an overview on architectures for enterprise integration developed since the middle of the 1980s is presented. The main part of the paper focuses on the recent developments on architectures for enterprise interoperability. The main initiatives and existing works are presented. Future trends and some research issues are discussed and conclusions are given at the end of the paper. ß 2008 Elsevier B.V. All rights reserved.

Keywords: Enterprise architecture Enterprise integration Interoperability Networked enterprises Enterprise modelling

1. Introduction In the current industrial and economic context, enterprise systems need to be constantly and smoothly re-engineered to respond to changing market demand and technological evolution. Enterprise architecture, considered as the foundation of enterprise systems engineering, has emerged as a ‘tool’ to help stakeholders to manage system engineering and changes. It is not only an IT issue, but first of all a strategic and organizational challenge. However, enterprise architecture is a challenging but still confusing concept. Compared to other fields, for example the construction industry, architecture has been used in the design and construction of all size buildings. Architects use standard symbols that can be recognized and understood by all members of their industry to carry out the construction work. The enterprise engineering community, which is much younger, has never experienced the advantage of this type of ‘‘time tested’’ structure. Instead, since its beginning, many heterogeneous architecture proposals have been developed. They are often overlapping approaches and the underlying concepts are not explicitly defined. Similarities and differences between enterprise architectures cannot be perceived by users; and this

* Corresponding author. E-mail addresses: [email protected] (D. Chen), [email protected]fi.fr (G. Doumeingts), [email protected] (F. Vernadat). 0166-3615/$ – see front matter ß 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2007.12.016

creates obstacles for its correct understanding in industry and finally its acceptance and use. The lack of a generally agreed terminology in this domain is also a bottleneck for its efficient application. The aim of the paper is to review enterprise architectural developments started since the beginning of the 1980s. Section 2 of the paper gives basic definitions, reviews architecture concepts and brings necessary clarifications. Section 3 presents an overview on the past developments on architectures for enterprise integration. Recent researches of developing frameworks for enterprise interoperability are presented in more details in Section 4. Based on the review, trends and some research issues are discussed in Section 5. Conclusions are drawn in Section 6. 2. Basic concepts and definitions Definitions on enterprise, enterprise integration, enterprise interoperability and enterprise architecture are first given. Then, necessary clarifications around the concept of enterprise architecture are presented. 2.1. Basic definitions 2.1.1. Enterprise According to ISO 15704, an enterprise is one or more organizations sharing a definite mission, goals and objectives to offer an output such as a product or a service [1]. This broad

648

D. Chen et al. / Computers in Industry 59 (2008) 647–659

definition also covers the extended enterprise (long term integration of suppliers and customers) and virtual enterprise (more oriented to interoperability of dynamic networked enterprises). The virtual enterprise (VE) has a dynamic and less stable nature than the extended enterprise. The idea is to put together capabilities and competencies coming from different enterprises but no node in the network plays a central role. This is a cluster or temporary association of existing or newly created business entities offered by several companies to form a new viable business entity to satisfy a timely market need. An example has been the company that built the Channel Tunnel in Europe (now dismantled). The extended enterprise (EE) has usually at the heart of its organization a large final assembly plant or a service company procured by its suppliers (1st tier suppliers, 2nd tier suppliers) and serviced by its engineering units, sales units, banks, etc. The idea is to provide the central node with all materials, skills, competencies, knowledge and capabilities it requires at the right time. Material flows are usually optimized in just-in-time (JIT) mode. This is the case of the car industry, aerospace industry, naval industry, semiconductor industry, etc. Researches on enterprise architectures are mainly concerned with the manufacturing systems and their control systems of the enterprise. 2.1.2. Enterprise integration Enterprise integration is the process of ensuring the interaction between enterprise entities necessary to achieve domain objectives [2]. Enterprise integration can be approached in various manners and at various levels [3], for example: (i) physical integration (interconnection of devices, NC machines. . . via computer networks), (ii) application integration (integration of software applications and database systems) and (iii) business integration (co-ordination of functions that manage, control and monitor business processes). Some other approaches also consider: (1) integration through enterprise modeling (for example through the use of a consistent modeling framework) [4] and (2) integration as a methodological approach to achieve consistent enterprise-wide decision-making [5]. 2.1.3. Enterprise interoperability Definitions on interoperability have been reviewed in [6,7]. Generally speaking, interoperability is the ability for two systems to understand one another and to use functionality of one another. The word ‘‘inter-operate’’ implies that one system performs an operation for another system. From the computer technology point of view, it is the faculty for two heterogeneous computer systems to function jointly and to give access to their resources in a reciprocal way. In the context of networked enterprises, interoperability refers to the ability of interactions (exchange of information and services) between enterprise systems. Interoperability is considered as significant if the interactions can take place at least on three different levels: data, services and processes, with a semantics defined in a given business context [8]. 2.1.4. Integration vs. interoperability Broadly speaking, interoperability has the meaning of coexistence, autonomy and federated environment, whereas integration refers more to the concepts of coordination, coherence and uniformization. From the point of view of degree of coupling, ‘tightly coupled’ indicates that the components are interdependent and cannot be separated. This is the case of a fully integrated system. ‘Loosely coupled’ means that the components are connected by a communication network and can interact; they can exchange services while continuing locally their own logic of operation. It is the case of interoperability, which equates to loose

integration. Thus two integrated systems are inevitably interoperable; but two interoperable systems are not necessarily integrated [9]. Another point of view is given by ISO 14258 [10]. Two systems are considered as Integrated if there is a detailed standard format for all constituent components. Interoperability is more related to the Unified approach where there is a common meta-level structure across constituent models, providing a means for establishing semantic equivalence or the Federated approach where models must dynamically accommodate rather than having a predetermined meta-model. 2.1.5. Enterprise architectures According to ISO 15704 [1], an architecture is a description of the basic arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity). Usually, architecture has various meanings depending on its contextual usage [11]: (1) a formal description of a system at component level to guide its implementation; (2) the structure of components, their interrelationships and the principles and guidelines governing their design and evolution over time; (3) organizational structure of a system or component. Generally speaking, an enterprise architecture (EA) should be organized in a way that supports reasoning about the structure, properties and behavior of the system. It defines the components that make up the overall system and provides a blueprint from which the system can be developed. The concept of architecture is closely related to engineering. Architecture allows managing complexity and risks due to various factors such as technology, size, interface, context and stakeholders. Designing large-scale systems (like enterprise) requires that the study starts at highlevel abstractions to ensure global consistency. It means that a mechanism is needed to organize and represent enterprise systems at sub-system and module levels. This concerns the current state (or AS–IS model) of the system as well as the desired or reengineered state (or TO–BE model) and the definition of the migration path or transformation program to go from the AS–IS state to the TO–BE state. Another adjacent concept to EA is enterprise modeling (EM). EM describes the EA from various viewpoints in detail to allow specifying and implementing the systems. EA is not an executive entity. In other words, EA amplifies significant characteristics or features of a system; while enterprise models describe and specify in detail the system. 2.2. Basic concepts of enterprise architectures 2.2.1. Enterprise architecture as a ‘skeleton’ Like in civil engineering, EA aims at creating a vision of the future system. This vision is represented as a high abstraction level solution that lays down the foundation for design. It is a kind of ‘skeleton’ focusing on essential features and characteristics of the system. Strengths and weaknesses can be then more easily detected and analyzed. On the other hand, usually engineering design is divided in preliminary and detailed designs. Preliminary design is also called architecture design. During the preliminary design phase, only solution types are defined. Working on highlevel solutions also facilitates the use of design principles which is another adjacent research subject. The software engineering community also considers that architecture is the fundamental organization of a system embodied in its components, their relationships to one another and to the environment and the principles guiding its design and evolution [12]. Enterprise architecture is seen as a complementary architecture to software architecture, to document system-wide organization and business context in which software operates.

D. Chen et al. / Computers in Industry 59 (2008) 647–659

2.2.2. Various types of enterprise architectures According to the IFAC–IFIP Task Force [13] and ISO 15704 [1] there are two types of architectures that deal with enterprise integration: System architectures (sometimes referred to as ‘‘Type 1’’ architectures) that deal with the design of a system, e.g. the system part of an overall enterprise integration; Enterprisereference projects (sometimes referred to as ‘‘Type 2’’ architectures) that deal with the organization of the development and implementation of a project such as an enterprise integration or other enterprise development program. In other words, Type 1 architecture represents system or sub-system in terms of its structure and behavior. Type 2 architectures are actually frameworks aiming at structuring concepts and activities/tasks necessary to design and build a system. For example, the Zachman Framework is a Type 2 architecture. Some other works make distinction between conceptual and technical architectures. The conceptual architecture is derived from business requirements; and are understood and supported by senior management. The technical architecture provides the technical components that enable the business strategies and functions. Sometimes conceptual architecture is also called functional or business architecture; and technical architecture, ICT architecture. 2.2.3. Enterprise architecture vs. stakeholders expectations Enterprise architecture at high level of abstraction is a means of communication with and among stakeholders. It allows representing stakeholders’ expectations in terms of features of enterprise system rather than documenting detailed requirements on functions, data or resources that will be specified in the later stage. The role of the architect is to address concerns, show how these concerns and the requirements are going to be addressed, and document the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders. Without the architecture, it is highly unlikely that all the concerns and requirements will be considered and met [11]. More generally, enterprise architectures must show properties that can be verified with respect to user needs (e.g. open or closed architecture, interoperable or not, centralized or decentralized, etc.). It must be simple so that business people can easily understand, check, analyze, discuss in a ‘language’ shared at the corporate level. 2.2.4. Architecting principles Architecting principles are rules to be used when elaborating enterprise architectures. Architecting principles may be generic, i.e. apply to all enterprises (reflecting some best practices) or specific (reflecting a level of consensus among the various elements of a particular enterprise, and form the basis for making future decisions). To date, there are not sound scientific principles for elaborating enterprise architectures. Some practical principles can be found in the literature for instance in Open Group [11,14] and in Government of Canada’s Federated Architecture [15], Cockburn [16] and Malan and Bredemeyer [17]. More generally speaking, when developing an EA, the principle of fitness-forpurpose should be followed. It means that the architecture should be developed only to the point at which it is fit for purpose. Another adjacent subject is architectural decisions, i.e. decisions to be taken to arrange architecture in a way rather than another way. Architectural decisions are those that must be made from an overall system perspective. According to Bass et al. [18], these decisions identify the system’s key structural elements, and their relationships, and they define how to achieve significantly architectural requirements. Indeed, enterprise engineering involves many decisions, some are architectural, and most of

649

them are not. The rationale is to show how the decisions are architectural. Malan and Bredemeyer [19] points out that if you can achieve the requirement by deferring the decision to a lower level, it is not architecturally significant, and the decision is not an architectural one. 3. Historical development: architectures for enterprise integration This section gives a brief overview on the past developments on architectures for enterprise integration. Most of EAs for enterprise integration developed so far are Type 2 architectures. These architectures structure concepts, principles and tasks for integrated enterprise modeling and engineering. They do not deal with the representation of how a specific enterprise is effectively structured or operated. In other words, they are not representation of operational processes, data, organizational structure etc. Rather, they define the concepts or modeling constructs (i.e. object classes) that are necessary to describe enterprise systems so that models achieved are consistent and easily integrated. 3.1. Early initiatives on enterprise architectures During the 1980s, a lot of research has been carried out in Europe and USA to develop enterprise architecture frameworks. Among them the most known are: the Computer Integrated Manufacturing Open System Architecture (CIMOSA) [20] that coined the term enterprise architecture, the Purdue EnterpriseReference Architecture (PERA) [21], the GIM architecture [22] and ARIS [23]. These Type 2 architectures are mainly elaborated along the system life cycle to show what has to be done to model, design and implement an integrated enterprise system. The Zachman Framework [24] is another example of such initiatives. It structures various enterprise modeling and engineering concepts according to the perspectives of various stakeholders involved in the enterprise engineering. This is because different stakeholders use different levels of abstraction to consider an enterprise and expect different deliverables. Comparing these architectures, CIMOSA and ARIS present strong similarity and are both process oriented approaches aiming at integrating functions by modeling and monitoring the action flow. GIM is based on the GRAI decision model where integration is seen as the coherence between global and local decision objectives. PERA and Zachman architecture do not provide any new modeling formalism but defined complex architecture frameworks. All these architectures are heterogeneous and complementary rather than contradictory. Redundancies and complementarities need to be identified and analyzed for possible harmonization. Some preliminary work has been done by the IFAC–IFIP Task Force in the middle of 1990s. 3.2. IFAC–IFIP Task Force on enterprise integration The IFAC/IFIP Task Force on architecture for enterprise integration has studied some existing architectures to propose harmonization. The result is a Generalized Enterprise-Reference Architecture and Methodology (GERAM) [13]. GERAM identifies, in its most important component called GERA (Generalized Enterprise Reference Architecture), the basic concepts to be used in enterprise engineering and integration. GERAM has been developed with the significant contributions from CIMOSA [20], the GRAI Integrated Methodology (GRAI/GIM) [22] and the Purdue Enterprise-Reference Architecture (PERA) [21]. Today GERAM has been moved to the standardization process (CEN and ISO). In [25], various architecture frameworks (PERA, CIMOSA, GRAI/GIM,

650

D. Chen et al. / Computers in Industry 59 (2008) 647–659

3.3. Standardization approaches

Fig. 1. Revised ENV 40003: modeling framework for enterprise integration [2].

Zachman, C4ISR/DoDAF) are shown in the light of GERAM to allow a deeper understanding of their contributions and therefore their correct and knowledgeable use. The work of IFAC–IFIP Task Force has made a considerable contribution to a better and deeper understanding of enterprise architecture. Nevertheless, the impact of GERAM at the industry level is not as significant as expected. One of the reasons is on the one hand the lack of industry involvement in the study and, on the other hand, the conceptual characteristics of the study.

Two main standardization bodies active to develop Type 2 architecture standards are: CEN TC310/WG1 and ISO TC184 SC5/ WG1. Main outputs achieved are: ISO 15704 [1] – Requirements for Enterprise Reference Architecture and Methodologies, and EN/ISO I9439 [2] – Enterprise Integration – Framework for Enterprise Modeling. EN/ISO 19439 has been developed on the basis of a European pre-standard ENV 40003 elaborated at the beginning of the 1990s by CEN TC310/WG1. It defines the generic concepts that are required to enable the creation of enterprise models for industrial business and constitutes a conceptual basis for modelbased enterprise engineering. Fig. 1 shows the revised version of the modeling framework. The EN/ISO 19439 is consistent with ISO 15704 and is considered as an implementation of the requirements defined in ISO 15704. The scope of ISO 15704 includes any type of manufacturing control mode while EN/ISO 19439 more specifically focuses on model-based and computer executable process monitoring and control. Nevertheless, the modeling framework is compliant with GERAM, which is described in the Annex to ISO 15704.Another approach developed by industrial standardisation bodies is the IEEE 1471 standard [12]. This standard is concerned with ‘‘Recommended Practice for Architectural Description of Software-Intensive Systems-Description’’. This recommended practice addresses the activities of creation, analysis and sustainment of architectures of software-intensive systems, and the recording of such architectures in terms of architectural descriptions. A conceptual framework for architectural description is established (see Fig. 2). The content of an architectural description

Fig. 2. IEEE1471-2000 conceptual framework.

D. Chen et al. / Computers in Industry 59 (2008) 647–659

is defined. Annexes provide the rationale for key concepts and terminology, the relationships to other standards and examples of usage. Although the approach is primarily concerned with software engineering, its architectural concepts apply to enterprise architecture as well. Another relevant piece of work is the Open Distributed Processing Reference Model, (RM-ODP) also known as ISO 10746. It was a joint initiative of ISO and ITU-T to develop a generic architecture for Open Distributed Processing (ODP). ODP combines the concepts of open systems and distributed computing, it has different ‘‘views’’, e.g. an ‘‘Enterprise Viewpoint’’ as well. A viewpoint (on a system) is an abstraction that yields a specification of the whole system related to a particular set of concerns. RM-ODP defines five viewpoints [26], each viewpoint of the Descriptive Model being supported by a language defined in the Prescriptive Model. The Prescriptive Model is made of two parts: (1) the definition of viewpoint languages and (2) an architectural framework for object interaction. The five viewpoints of ODP are: enterprise, information, computational, engineering and technology. Although considerable effort has been spent to develop standards on enterprise architectures, none of the four approaches presented above has reached a sufficient maturity and be recognized and accepted in industry. There was no collaboration between the three groups (ISO TC184/SC5, ISO/IUT-T and IEEE) elaborating the standards. Even if it seems difficult to merge these standards, it is however necessary to establish mapping between them in order to achieve certain interoperability between models and systems built using these standards. 3.3.1. Other relevant works Other significant pieces of work were developed in US: TOGAF, C4ISR (or DoDAF). TOGAF is developed by Open Group on Architecture Framework. It contains two main parts: The Architecture Development Method (ADM) and the Foundation Architecture with generic functions/services on which specific architectures and building blocks can be built [11]. The C4ISR architecture is developed by the C4ISR Architecture Working Group (AWG) to define a coordinated approach, i.e. a framework for Command, Control, Communication and Computer, Intelligence, Surveillance and Reconnaissance architecture development, presentation and integration [27]. It is also known as DoDAF (Department of Defense (DoD) Architecture Framework) providing a common approach for DoD architecture description development, presentation and integration for both war-fighting operations and business operations and processes [28]. In conclusion, enterprise architectures (Type 2) developed in the past reflect the background/competencies of their developers and the purpose for which they were elaborated: for example CIMOSA for computer integrated manufacturing, GRAI for production management and decision-making, PERA for system engineering, Zachman for information systems and DoDAF for military operations management and coordination [25]. For a better understanding of these approaches and comparison between them, it is necessary to map them to a unique reference architecture. The most suitable one available at the time being is the ISO 15704 developed on the basis of GERAM.

651

survey some recent interoperability frameworks. Generally speaking, the main purpose of a framework is to provide an organizing mechanism so that concepts, problems and knowledge on enterprise interoperability can be represented in a more structured way. It is a structure expressed in terms of diagrams, text and formal rules that relates the components of a conceptual entity to each other [2]. 4.1. LISI reference model In the field of enterprise interoperability, it is worth noting the first significant initiative: the LISI (levels of information systems interoperability) approach developed by C4ISR Architecture Working Group (AWG) during 1997. The purpose of LISI is to provide the US Department of Defense (DoD) with a maturity model and a process for determining joint interoperability needs, assessing the ability of the information systems to meet those needs, and selecting pragmatic solutions and a transition path for achieving higher states of capability and interoperability [29]. A critical element of interoperability assurance is a clear prescription of the common suite of requisite capabilities that must be inherent to all information systems that desire to interoperate at a selected level of sophistication. Each level’s prescription of capabilities must cover all four enabling attributes of interoperability known as PAID (see Fig. 3), namely: procedures, applications, infrastructure (hardware, communications, security and system services) and data. The LISI reference model also provides the common vocabulary and structure needed to discuss interoperability between systems. At each level, a word or phrase highlights the most important aspect of PAID needed to achieve that level. For example, a system targeting interactions with other systems working at Level 3 (domain level in an integrated environment) must build toward the specific set of capabilities that underlie the PAID thresholds of the LISI reference model at level 3 (domain level procedures, groupware applications, access to world wide networks and domain data models). Although each attribute (PAID) is significant and must be considered in defining a level of interoperability, the significance and relative impact of the contributions from each attribute varies by level [29]. Besides this LISI reference model, a LISI interoperability maturity model and a practical assessment process for determining the interoperability maturity level of a given system or system pair is also defined. For more detail, see [29]. The LISI approach, although built with generic concepts and models, is focused on developing interoperability in US military sector. However, it is also used as a basis to elaborate other interoperability maturity models such as for example organiza-

4. The present: recent researches on architecture for enterprise interoperability Since the beginning of 2000s, research on enterprise interoperability has been emerging. Most recent work on architecture development is concerned with the elaboration of an enterprise interoperability framework (Type 2 architecture). This section will

Fig. 3. LISI reference model.

652

D. Chen et al. / Computers in Industry 59 (2008) 647–659

tional maturity model [30] and enterprise interoperability maturity model [31]. 4.2. IDEAS interoperability framework The IDEAS interoperability framework (see Fig. 4) was developed by IDEAS project on the basis of ECMA/NIST Toaster Model, ISO 19101, ISO 19119 and augmented through the quality attributes [32]. The framework also intended to reflect the view that ‘‘Interoperability is achieved on multiple levels: interenterprise coordination, business process integration, semantic application integration, syntactical application integration and physical integration’’. In the business layer, all issues related to the organization and the management of an enterprise are addressed. Amongst others, they include the way an enterprise is organized, how it operates to produce value, how it manages its relationships (internally with its personnel and externally with partners, customers and suppliers). Interoperability at this level should be seen as the organizational and operational ability of an enterprise to factually cooperate with other enterprises. The business layer includes the decisional model, the business model and business processes. The decisional model of an enterprise defines what/ how decisions are taken and the degree of responsibility of each operating unit, role and position. The business model is the description of the commercial relationships between an enterprise and the way it offers products or services to the market. Business processes are the set of activities that deliver value to one’s customers [33]. The knowledge layer is concerned with acquiring, structuring and representing the collective/personal knowledge of an enterprise. It includes knowledge of internal aspects such as products, the way the administration operates and controls, how the

personnel is managed and so on, but also of external aspects such as partners and suppliers, laws and regulations, legal obligations and relationships with public institutions. Interoperability at knowledge level should be seen as the compatibility of the skills, competencies and knowledge assets of an enterprise with those of other enterprises. This layer addresses the methods and tools that support the elicitation, gathering, organization and diffusion of business knowledge within an enterprise. The Knowledge layer includes several models. The organizational model can define the roles within – for example – the internal organization, the value chain, a network of enterprises or a constellation. A skills-competency model defines the capability of an organization and of its employees to perform a certain job under certain working conditions. Enterprise’s knowledge assets are the capital of the organization formalized in terms of procedures, norms, rules and references. The ICT systems layer is concerned with the ICT solutions that allow an enterprise to operate, make decisions, exchange information within and outside its boundaries. The overall execution of the enterprise application will be orchestrated by the business process model identified in the top layer and formally (i.e. unambiguously) represented and stored in the middle (knowledge) layer. Interoperability at ICT systems level should be seen as the ability of an enterprise’s ICT systems to cooperate with those of other external organizations. It is concerned with the usage of ICT to provide interoperation between enterprise resources (i.e. software, machines and humans). The interoperation has to be established by the supply of information through inter- and intra-system communication. The ICT layer includes various areas such as solution management, workplace interaction, application logic, process logic and data logic. Solution management is about the tools and procedures required to administer an enterprise system. This includes role and policy management,

Fig. 4. IDEAS interoperability framework.

D. Chen et al. / Computers in Industry 59 (2008) 647–659

monitoring and simulation tools. Workplace interaction refers to the interaction of the human user with the system, which could be described through input, output and navigation. Application logic describes the computation carried out by an enterprise system to achieve a business result. Process logic is the order (i.e. step-bystep) in which an application (or a subset) is carried out. Data logic describes what data is required and produced by an enterprise system during its lifecycle. This includes repository services and content management. The semantic dimension cuts across the business, knowledge and ICT layers. It is concerned with capturing and representing the actual meaning of concepts and thus promoting understanding. The holistic perspective on interoperability requires considering semantics on each layer of an enterprise. For enterprises that want to collaborate with each other and that need interoperability on a specific layer, it is of prime importance to create a mutual understanding [33]. To ensure that semantics are exchangeable and based on a common understanding, ontology and annotation formalism for meaning can be used. Quality attributes is a supplementary dimension of the framework. Business considerations determine qualities that must be accommodated in a system. These qualities are over and above that of functionality, which is the basic statement of the system’s capabilities, services and behaviors. The considered attributes are: (1) security (data storage, transfer and protection etc.); (2) scalability; (3) portability (both data and applications); (4) performance; (5) availability and (6) evolution. It must be underlined that the achievement of any quality attribute will have an effect, sometimes positive and sometimes negative, on the achievement of other quality attributes [32]. The IDEAS interoperability framework is the first initiative carried out in Europe under FP5 (Fifth Framework Programme) to address enterprise and manufacturing interoperability issues. It is used as a basis to elaborate a roadmap served to build ATHENA Integrated Project and INTEROP NoE under FP6 (Sixth Framework Programme). The main drawback of the IDEAS interoperability framework is that it builds on the three relevant research domains (enterprise modeling, architecture and platform and ontology) contributing to develop interoperability rather than on the interoperability domain itself. An interoperability domain framework needs to be elaborated so that interoperability research issues can be precisely identified and structured. This point is addressed under INTEROP NoE (see Section 4.5). 4.3. ATHENA interoperability framework The ATHENA interoperability framework (AIF) [34] is structured into three levels and based on sources of results and usage of the framework (see Fig. 5). The Conceptual level is used for identification of research requirements and integrates research results of ATHENA R&D projects. The Applicative level integrates experience from R&D projects and technology testing in the pilot sites and is used for transfer of knowledge regarding application of integration technologies. The Technical level is used for technology testing based on profiles and integrates prototypes of R&D projects. The ATHENA interoperability framework and the IDEAS interoperability framework were considered complementary. At each level of AIF, one can use the IDEAS interoperability framework to structure interoperability issues into three layers (business, knowledge and ICT) and a semantic dimension. Comparing the AIF with ISO 15704 GERAM framework, Fig. 6 [35] shows a tentative mapping of GERAM components to the ATHENA interoperability framework (AIF). Reference architectures, methodologies, modeling languages and concepts as well as reference models are all conceptual

653

Fig. 5. ATHENA interoperability framework.

elements. They are used to build particular enterprise models of studied companies. Modeling tools are technology components which support the model construction. The ‘particular’ enterprise model(s) is a conceptual model(s) and is applicative in a particular domain. Enterprise models are then implemented in operational systems with enterprise modules (infrastructure for example) to support operational systems that perform daily enterprise operations. Both enterprise modules and enterprise operational systems are concrete technical (technological) elements. 4.4. Other relevant interoperability frameworks In parallel to the development of interoperability in enterprise and manufacturing areas, similar initiatives are also carried out in other fields such as for example eBusiness, eGovernment and eHealth areas. This section presents some of those interoperability frameworks which are considered generic enough and can apply to enterprise and manufacturing domains as well. 4.4.1. E-health interoperability framework The E-health interoperability framework [36] was developed by NEHTA (National E-Health Transition Authority) initiatives in Australia. The broad nature of an Interoperability Framework brings together organizational, information and technical aspects relating to the delivery of interoperability across health organizations (see Fig. 7). This breakdown of viewpoints has been adopted by AGIMO’s AGTIF and the European Interoperability Framework. It is also compatible with other approaches such as eGIF. The interoperability framework creates the structure and governs its evolution along with the interoperability layers it encompasses. It creates a separation of concerns amongst the

Fig. 6. Mapping GERAM framework to ATHENA interoperability framework.

654

D. Chen et al. / Computers in Industry 59 (2008) 647–659

Fig. 7. E-health interoperability framework.

framework layers and brings together expert panels to align and guide the layers.  Organizational interoperability creates cohesion amongst approaches to governance, finance, legislation and business processes.  Information interoperability owns the family of information building blocks from basic data type elements through to terminologies.  Technical interoperability combines all aspects of standards along with the broad architectural approach linking e-health services and information.

4.4.2. European Interoperability Framework (EIF) The European Interoperability Framework [37] [38] aims at supporting the European Union’s strategy of providing usercentred eGovernment services by facilitating, at a pan-European level, the interoperability of services and systems between public administrations, as well as between administrations and the public (citizens, businesses). This European Interoperability Framework is defined as the overarching set of policies, standards and guidelines, which describe the way in which organizations have agreed, or should agree, to do business with each other. An Interoperability Framework is, therefore, not a static document and may have to be adapted over time as technologies, standards and administrative requirements change. Fig. 8 provides an overview of the main aspects of the European Interoperability Framework which are considered. EIF provides recommendations and defines generic standards with regard to organizational, semantic and technical aspects of interoperability. It is worth noting that both EIF and E-health framework propose interesting categorization of interoperability from the point of view of interoperability aspects. These interoperability aspects (semantic, technical, organizational, etc.) reflect more interoperability issues or problems rather than levels of operational entities where interoperation take place by exchanging information. Consequently, a differentiation by complementary interoperability categorization is to consider that interoperation concerns different levels of the enterprise namely: data, service, process and business as proposed in ATHENA project and INTEROP NoE. 4.5. Enterprise interoperability framework developed within INTEROP NoE This section presents the enterprise interoperability framework developed within the frame of INTEROP Network of Excellence

Fig. 8. Overview of the European interoperability framework.

D. Chen et al. / Computers in Industry 59 (2008) 647–659

(NoE). The purpose of this framework is to define the research domain of enterprise interoperability and help to identify and structure the knowledge of the domain. It has been considered that enterprises systems are not interoperable because there are barriers to interoperability. Barriers are incompatibilities of various kinds and at various enterprise levels. The incompatibilities obstruct the sharing of information and prevent from exchanging services. There exist common barriers to all enterprises whatever the sector of activities and size. Developing interoperability means to develop knowledge and solutions to re-move the incompatibilities [39,40]. The approach adopted is to: (i) define the domain of enterprise interoperability through the elaboration of an interoperability framework using barriers-driven approach; (ii) identify and structure the knowledge (solutions) of the domain using the framework. The interoperability framework proposed is elaborated on the basis of concepts developed in some existing frameworks and models [37,38,41,32,33], focusing on those concepts most relevant to define the research domain of enterprise interoperability. 4.5.1. Interoperability barriers Three categories of barriers (conceptual, technological and organizational) are identified as follows:  Conceptual barriers: They are concerned with the syntactic and semantic differences of information to be exchanged. These problems concern the modeling at the high level of abstraction (such as for example the enterprise models of a company) as well as the level of the programming (for example XML models).  Technological barriers: These barriers refer to the incompatibility of information technologies (architecture and platforms, infrastructure, etc.). These problems concern the standards to present, store, exchange, process and communicate the data through the use of computers.  Organizational barriers: They relate to the definition of responsibility (who is responsible for what?) and authority (who is authorized to do what?) as well as the incompatibility of organization structures (matrix vs. hierarchical ones, for example).

4.5.2. Interoperability concerns Interoperations can take place at the various enterprise levels. Although the following categorisation is mainly given from a point of view of IT based applications, it applies to non-computerized systems as well. It is based on the ATHENA technical architecture [34].  The interoperability of data: It refers to make different data models and query languages working together. The interoperability of data deals with finding and sharing information from heterogeneous data sources, and which can moreover reside on different machines under different operating systems and data base management systems.  The interoperability of services: It is concerned with identifying, composing and making various applications function together (designed and implemented independently). The term ‘service’ is not limited to the computer based applications; but also functions of companies and networked enterprises.  The interoperability of processes: The aim is to make various business processes work together: a process defines the sequence of the services (functions) according to some specific needs of a company. In a networked enterprise, it is also necessary to study how to connect internal processes of two companies to create a common process.

655

 The interoperability of business: It refers to working in a harmonized way at the level of organization and company in spite of, for example, the different modes of decision-making, methods of work, legislations, culture of the company or commercial approaches so that business can be developed between companies. 4.5.3. Interoperability approaches Research on interoperability is not only a matter of removing barriers but also in the way in which these barriers are removed. According to [42] and ISO 14258 [10], there are three basic ways to relate entities (systems) together to establish interoperations:  Integrated approach: There exists a common format for all models. This format must be as detailed as models. The common format is not necessarily a standard but must be agreed by all parties to elaborate models and build systems.  Unified approach: There exists a common format but only at a meta-level. This meta-model is not an executable entity as it is in the integrated approach but provides a means for semantic equivalence to allow mapping between models.  Federated approach: There is no common format. To establish interoperability, parties must accommodate on the fly. Using a federated approach implies that no partner imposes its models, languages and methods of work. This means that they must share an ontology to map their concepts at the semantic level. 4.5.4. The enterprise interoperability framework Based on the basic concepts discussed above, the two basic dimensions of the proposed enterprise interoperability framework are shown Fig. 9: (i) enterprise dimension representing enterprise levels (interoperability concerns), (ii) interoperability dimension representing interoperability barriers. The intersection of a level category (row) and a barrier category (column) constitutes a subdomain. Thus, this Interoperability Framework defines the enterprise interoperability research domain by the set of subdomains which compose it. It can also be used to structure interoperability knowledge. A piece of knowledge is considered as relevant to interoperability if it contributes to remove at least one barrier at one level. Fig. 10 shows the interoperability framework with the conceptual interoperability barriers further detailed into syntax barrier and semantic barrier. It also shows the use of the framework to identify and categorize the knowledge. A piece of knowledge may concern more than one barrier and cover more than one level. For example, UEML V1.0 aims at removing syntactic barrier for enterprise model interoperability and covers all the four levels, while PSL (process specification language) contributes to

Fig. 9. The enterprise interoperability framework (two basic dimensions).

656

D. Chen et al. / Computers in Industry 59 (2008) 647–659

5. Future perspectives 5.1. Trends

Fig. 10. Use of the framework to define the domain and to structure knowledge.

remove both syntactic and semantic barriers but is limited to process level. The third dimension (interoperability approaches) is added to the two-dimensional framework (see Fig. 11). This third dimension allows categorizing knowledge and solutions relating to enterprise interoperability according to the ways of removing interoperability barriers. For example, PSL contributes to remove conceptual barriers (both syntax and semantics) at the process level through a unified approach. Compared to other interoperability frameworks, the INTEROP framework provides three explicitly defined interoperability dimensions (interoperability barriers, interoperability concerns and interoperability approaches) to allow defining interoperability research domain. Incompatibility is the fundamental concept used in defining the scope of interoperability domain. It is the obstacle to establish seamless interoperation. The concept ‘incompatibility’ has a broad sense and is not only limited to ‘technical’ aspect as usually considered in software engineering, but also ‘information’ and ‘organization’ and concerns all levels of the enterprise. Another fundamental consideration is the generic characteristic of the interoperability research. Indeed, there are generic problems and solutions regardless of the content of information exchanged between two systems. Concerning the future work on the interoperability framework, it is still necessary to better define the enterprise interoperability related concepts. Formal statements of interoperability domain and interoperability domain ontology are needed. Some initial work to elaborate ontology of interoperability has been performed within INTEROP NoE, but the development has not reached a sufficient maturity and further research is still required.

Fig. 11. Enterprise interoperability framework (three basic dimensions).

5.1.1. Model driven interoperability architecture Model driven architecture (MDA), initially proposed by OMG for software engineering, will continue its extension in two directions. On the one hand, its scope will cover the level of enterprise modeling for representing business user and interoperability requirements. On the other hand, it will address not only software engineering issues but also enterprise integration and interoperability engineering problematic. Within the frame of INTEROP NoE, research activities have been started on the development of a model driven interoperability (MDI) architecture based on MDA and enterprise interoperability concepts. The objective of this approach is to allow transforming automatically the models designed at the various abstraction levels of the MDA structure: CIM (computational independent model), PIM (platform independent model) and PSM (platform specific model), i.e. from the user to the execution level. These models will be designed in such a way that they are interoperable with models designed by another enterprise using the same MDI architecture. This research was also carried out under ATHENA Integrated Project. Some research actions beyond INTEROP and ATHENA are also foreseen, for example a joint collaboration project between France (LAPS, University Bordeaux 1) and China (Harbin Institute of Technology). A skeleton of this architecture is shown Fig. 12. One of the main challenges of the project is to define what is needed at the enterprise modeling level and the transformation of the enterprise model to the system model. It is worth mentioning NGOSS (New Generation Operations Software and Systems), which is a work program governed by the TeleManagement Forum (TMF). NGOSS provides a technology neutral architecture, which is based on five key principles: (i) separation of business process from component implementation, (ii) loosely coupled distributed system, (iii) shared information model, (iv) common communications infrastructure and (v) contract defined interfaces [43]. NGOSS architecture has been mapped to MDA of OMG. 5.1.2. Service oriented architecture for interoperability At a more IT-oriented level, in the ‘‘Roadmap to develop Enterprise Interoperability’’ elaborated by the European Commission [44], it has been considered that the past decade has seen

Fig. 12. Overview of the MDI architecture.

D. Chen et al. / Computers in Industry 59 (2008) 647–659

significant advances in Enterprise Interoperability. The ServiceOriented Computing paradigm and Service-Oriented Architectures (SOA) have emerged as a major evolutionary step, with Web Services, Grid Services and peer-to-peer (P2P) services comprising the major trends (Roadmap). Although SOA is providing the framework for integrated cross-company services or technical interoperability, it does not address the semantic interoperability problem. One future challenge is to develop Service-Oriented Architectures adopting a federated approach, i.e. allowing interoperability of services ‘on the fly’ through dynamic accommodation and adaptation. 5.1.3. Standardization Concerning the enterprise architecture (framework) for enterprise integration, some future works have already been planned at the standardization level. Collaboration is being set up between two standard working groups: ISO/IEC JTC1/SC7/WG42 for IEEE1471 (Recommended Practice for Architectural Description of Software-Intensive Systems-Description) and ISO TC184 SC5/ WG1 for ISO 15704 and its Annex on GERAM, to harmonize architectural concepts and possibly to merge the terminology of ISO 15704 and IEEE 1471. ISO 15704 revisions will start in 2007 taking into account EN/ISO 19439 (framework for enterprise modeling) and input from IEEE 1471 working group. ISO 14258 (concepts and rules for enterprise models) will be integrated in the revised version of ISO 15704. Concerning frameworks for interoperability, future work is to elaborate standards for enterprise interoperability. An ISO New Work Item Proposal (NWIP) to develop enterprise interoperability has been prepared and approved. This proposal is based on the main input from INTEROP Interoperability Framework. The objective is to define enterprise interoperability research domain and elaborate a series of standards for developing interoperability solutions using the three possible approaches (integrated, unified and federated). The NWIP mainly involves UK, France, US, China and Germany standardization organizations. 5.2. Some research issues 5.2.1. Developing Type 1 architectures The review of the past and recent enterprise architecture researches clearly shows the insufficient development of Type 1 architectures, in particular the reference architectures at higher abstraction level are needed. This would help reuse of mature architecture solution (types) to save time and cost while performing enterprise engineering and integration projects. Moreover, differentiations between various architectures in terms of properties and features also need to be explicitly identified so that comparison and choice can be more easily made at a high-level abstraction and early stage of design. 5.2.2. Architecture representation language To date, the architecture concept is not sufficiently exploited. One of the reasons is the lack of appropriate architecture representation formalism supporting the characterization of features and properties of enterprise systems at high abstraction level. Existing enterprise architecture proposals are represented in quite different ways. There is neither rigorous syntax nor semantics. Enterprise architecture language is a high level of abstraction language and aims at representing enterprise architectural structure, characteristics and properties at early stage of design. Enterprise architecture language is different from enterprise modeling language, which allows elaborating detailed models to specify systems.

657

5.2.3. Architecture design principles Existing architecture principles were not developed to a satisfactory level to allow bringing significant improvement to enterprise architecting. More research is needed in this area. Developing architecting principles can be bottom-up based on best practices, or top-down by studying some theoretical paradigms. Furthermore, available enterprise architectures lack justifications. It is difficult to know why an architecture is arranged in that way rather than another one. Within the frame of INTEROP, a research activity was initiated to develop architecture design principles and patterns for interoperability. This work needs to be continued in the future and extended. Principles and patterns for designing Type 1 architectures for various purposes (interoperability, flexibility, modularity, etc.) would allow to base future architecture development on a more scientific basis. 5.2.4. Architecture evaluation method As mentioned previously, past and existing enterprise architecture research and development suffer from the lack of method for evaluating architecture proposals. Evaluation criteria such as for example maturity, security, interoperability, modularity, robustness, openness, etc. that are used to characterize an architecture proposal need to be more precisely defined. One main challenge here is to define the concepts and to elaborate metrics allowing measuring different degrees of maturity, security, interoperability, etc. As presented in the previous section, architecture evaluation criteria are also related to architecture design principles. These criteria actually reflect possible architecture properties. Architecture may be designed to amplify one desired property and disgrace others considered not important for a particular enterprise. This research is also linked to the research on architecture representation language i.e. how to represent and characterise various properties mentioned above. Another issue is how to evaluate economic aspect of enterprise architecture. Most of existing enterprise architecture researches does not address the economic issue in the architecture design. However, economic benefits of enterprise architecture are as important as technical ones for a company. 5.2.5. Enterprise conceptual vs. IT architecture Past and recent developments show that there are actually two main research communities active in developing enterprise architectures from two different perspectives: information technology (IT) and enterprise modeling. The main problems raised are concerned with the different semantics and languages used. It is necessary to continue the effort of harmonization. This requires establishing collaboration between enterprise modeling communities developing business-oriented architectures and software engineering people working on the IT-oriented ones. From another point of view, enterprise architectures need to accommodate change, evolving with the application of new technologies and with the developments in the business environment. The continuous alignment of business architecture to IT architecture is one of the challenges to implement EA in industry and to manage changes. The MDA approach provides a unifying framework based on the model transformation approach. However, more joint research efforts are needed to develop a unified enterprise architecture (in particular with a unique semantics or ontology) allowing smoothly mapping between business and IT architectures. 5.2.6. Towards an ontology of enterprise architecture Enterprise architecture as a domain of research is a meta domain. The development of an ontology precisely defining

658

D. Chen et al. / Computers in Industry 59 (2008) 647–659

concepts and properties of enterprise architecture domain is a challenging task. However, this ontology is needed to allow a clear understanding of the universe of discourse in this domain and avoid multiple and sometimes redundant developments of architectural proposals. Enterprise architecture ontology also contributes to semantic interoperability between different enterprise architectures. The development of enterprise architecture ontology raises another issue concerning on the one hand defining enterprise ontology and, on the other hand, the architecture ontology. Some research works have been done to define enterprise ontology such as for example TOVE. No research work was reported so far to define architecture ontology. 6. Conclusions The paper has presented an overview on the development of enterprise architectures. The focus of the study is on those approaches defined at higher level of abstraction, which are independent from a specific technology for the implementation. Researches during the period of 1985–2000 are marked by the development of architectures for enterprise integration. Most of them are framework approaches (Type 2 architectures), i.e. architectures of enterprise engineering/integration projects rather than architectures of enterprise systems. Most of them aim at representing business user’s concerns with no direct link to IT implementation, except CIMOSA where the IIS (integrating infrastructure) has been proposed to implement enterprise model for enterprise operations monitoring and control. The main drawbacks of the historical developments in the past can be summarized as follows:  Insufficient development of Type 1 reference architectures for supporting preliminary design of enterprise systems.  Insufficient understanding of enterprise architecture concepts and lack of enterprise architecture ontology.  Absence of a scientific method to justify an enterprise architecture proposal and difficulty to evaluate and compare different architectures.  Inadequate means to represent and describe an enterprise architecture, no interoperability between various existing architectures.  Weak impact of enterprise architecture research in industry and insufficient maturity of standards on enterprise architectures. Recent works started at the beginning of the year 2000 and to date show a shift from architectures for enterprise integration to the development of framework for interoperability (including ebusiness and eGovernment related interoperability). A significant part of the research has been carried out in Europe within the frame of IST funded projects such as, for examples, IDEAS, ATHENA and INTEROP. Once again recent works focused mainly on frameworks for interoperability (Type 2 architectures). The research fails to define what should be an ‘ideal’ architecture for developing interoperable enterprise systems. Service-oriented architectures (SOA), Web services and Web-based technology platforms provide best hope at IT level and are reasonable solutions for technical interoperability (see for instance [45]), but high-level enterprise architecture for interoperability, addressing process, organization and business issues, is still missing. No consensus has been reached on the interoperability concepts or on an agreed global interoperability framework defining the interoperability domain. Lessons learnt from the past and present

researches on enterprise architectures can be summarized as follows:  Enterprise architecture development should have started by the elaboration of an agreed architecture representation language to avoid hazardous proposals.  Enterprise architecture should have addressed more on how to align of business strategy to technology for implementation, and not just focused on business or IT with separated research and development.  Enterprise architecture development should have also been carried out bottom up from best practices and not only the top down approach as most of the past works adopted.  The development of criteria and method for evaluating architectures should have an equal importance than developing various architectures themselves. Without a such method, it is difficult for industry to select and choose an architecture.  Last but not least, the simpler the architecture, the greater the chance that it will be understood and actually followed by developers. This point is especially important for SMEs.

Future research and development on enterprise architecture should be based on a rigorous and precise ontology definition of the set of concepts, relations and properties of enterprise architecture. There is also an important need to develop on the one hand an agreed architecture representation language and evaluation method/metrics so that architecture proposals can be properly described, assessed and compared and, on the other hand, architecture design principles and patterns for promoting proven and justified architectural solutions in industry. References [1] ISO 15704, Industrial Automation Systems—Requirements for Enterprise-reference Architectures and Methodologies, 2000. [2] EN/ISO I9439, Enterprise Integration—Framework for Enterprise Modelling, 2003. [3] F.B. Vernadat, Enterprise Modeling and Integration: Principles and Applications, Chapman & Hall, London, 1996. [4] D.N. Shorter, Requirements for enterprise model execution and integration services, in: N. Kosanke (Ed.), Enterprise Engineering and Integration: Building International Consensus, Springer-Verlag, Berlin, 1997, pp. 235–243. [5] G. Doumeingts, B. Vallespir, D. Chen, Decision modelling GRAI grid, in: P. Bernus, K. Mertins, G. Schmidt (Eds.), Handbook on Architecture for Information Systems, Springer-Verlag, Berlin, 1998. [6] D. Chen, F. Vernadat, Enterprise interoperability: a standardisation view, in: K. Kosanke, et al. (Eds.), Enterprise Inter-and-Intra Organisational Integration, Kluwer Academic Publishers, 2002, pp. 273–282 (ISBN 1-4020-7277-5). [7] D. Chen, F. Vernadat, Standards on enterprise integration and engineering—a state of the art, International Journal of Computer Integrated Manufacturing 17 (3) (2004) 235–253. [8] IDEAS, IDEAS Project Deliverables (WP1-WP7), Public Reports, 2003, www.ideasroadmap.net. [9] D. Chen, D. Doumeingts, European Initiatives to develop interoperability of enterprise applications—basic concepts, framework and roadmap, Journal of Annual reviews in Control 27 (3) (2003) 151–160. [10] ISO 14258, Industrial Automation Systems—Concepts and Rules for Enterprise Models, ISO TC184/SC5/WG1, April 14, 1999. [11] Open Group, TOGAF: The Open Group Architecture Framework, Document No. 1910, Version 6, December 2000. [12] IEEE 1471, Recommended Practice for Architectural Description of SoftwareIntensive Systems, 2000. [13] IFAC–IFIP Task Force, GERAM: Generalized Enterprise Reference Architecture and Methodology, Version 1.6.3, IFAC–IFIP Task Force on Architecture for Enterprise Integration, 1999. [14] Open Group, Architectural Principles, 2002. [15] GOC, Government of Canada, 2001, www.cio-dpi.gc.ca/fap-paf/documents/iteration/iterationtb_e.asp (effective link on June 12, 2007). [16] A. Cockburn, On the Interaction of Social Issues and Software Architecture, in: Communication of the ACM, vol. 39, no. 10, October 1996. Also at: http:// members.aol.com/acockburn/papers/softorg.htm (effective link on June 12, 2007).

D. Chen et al. / Computers in Industry 59 (2008) 647–659 [17] R. Malan, D. Bredemeyer, Software Architecture: Central Concerns, Key Decisions, Software Architecture, 2002 BREDEMEYER Consulting, 2002. [18] L. Bass, R. Clements, R. Kazman, Software Architecture, in Practice, AddisonWesley, 1997. [19] R. Malan, D. Bredemeyer, Less is more with Minimalist Architecture, IT Professional IEEE Computer Society, September/October 2002. [20] AMICE, CIMOSA—Open System Architecture for CIM, 2nd edition, SpringerVerlag, Berlin, 1993. [21] T.J. Williams, The Purdue enterprise reference architecture, Computers in Industry 24 (2/3) (1994) 141–158. [22] D. Chen, G. Doumeingts, The GRAI-GIM reference model, architecture and methodology, in: P. Bernus, et al. (Eds.), Architectures for Enterprise Integration, Chapman & Hall, London, 1996. [23] A.-W. Scheer, Business Process Engineering. Reference Models for Industrial Enterprises, 2nd edition, Springer-Verlag, Berlin, 1994. [24] J. Zachman, The Framework for Enterprise Architecture: Background, Description and Utility, Zachman Institute for Advancement, 1996, http://www.zifa.com (effective link on April 2007). [25] P. Bernus, L. Nemes, G. Schmidt (Eds.), Handbook on Enterprise Architecture, Springer-Verlag, 2003. [26] ISO/IEC 10746-1, Information Technology—Open Distributed Processing Reference Model, Overview, December 15, 1998. [27] C4ISR, Architecture Working Group (AWG), C4ISR Architecture Framework, Version 2.0, December 18, 1997. [28] DoD, DoD Architecture Framework Working Group, DoD Architecture Framework, Version 1.0, vol. 1: Definitions and Guidelines, February 9, 2004. [29] C4ISR, Architecture Working Group (AWG), Levels of Information Systems Interoperability (LISI), March 30, 1998. [30] T. Clark, R. Jones, Organizational Interoperability Maturity Model for C2, Department of Defense, Canberra, Australia, 1999. [31] ATHENA Integrated Project (507849), Framework for the Establishment and Management Methodology, Deliverable DA1.4, 2005. [32] IDEAS, 2002, Thematic Network, IDEAS: Interoperability Development for Enterprise Application and Software—Roadmaps, Annex 1—DoW, May 13, 2002. [33] ATHENA, Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications, FP6-2002-IST1, Integrated Project, 2003. [34] C. Guglielmina, A. Berre, ATHENA, ‘‘Project A4’’ (Slide Presentation), in: ATHENA Intermediate Audit, Athens, Greece, September 29–30, 2005. [35] D. Chen, T. Knothe, M. Zelm, ATHENA Integrated Project and the Mapping to International Standard ISO 15704, in: Proceedings of the International Conference on Enterprise Integration and Modeling Technology (ICEIMT’04), Canada, October 9–11, 2004, 2004. [36] NEHTA, Towards an Interoperability Framework, Version 1.8, August 21, 2005. [37] EIF, European Interoperability Framework, White Paper, Brussels, February 18, 2004. [38] EIF, European Interoperability Framework for PAN-European EGovernment Services, IDA Working Document, Version 4.2, January 2004. [39] D. Chen, M. Dassisti, A. Tsalgatidou, Interoperability Knowledge Corpus, Deliverable DI.1, Workpackage DI, INTEROP NoE, November 25, 2005. [40] D. Chen, N. Daclin, Framework for Enterprise Interoperability, IFAC TC5.3 Workshop EI2N06, Bordeaux, France, March 21, 2006. [41] ERISA, The European Regional Information Society Association, A Guide to Interoperability for Regional Initiatives, Brussels, September 2004. [42] C.J. Petrie (Ed.), Enterprise Integration Modeling, The MIT Press, Cambridge, MA, 1992. [43] The NGOSS Technology-Neutral Architecture, NGOSS Release 4.0, TMF053, TeleManagement Forum, January 2004. [44] EC, Enterprise Interoperability Research Roadmap, Final Version (V.4.0), July 31, 2006. [45] D.A. Chapell, Enterprise Service Bus, O’Reilly Media Inc., Sebastopol, CA, 2004.

659

David Chen (Ph.D.) is professor at University Bordeaux 1, researcher at IMS-LAPS (automatic control, productics, and signal processing). His research interests include enterprise modelling, enterprise integration and interoperability. He has been actively working in European research programme in the related areas, participating in several co-operation programmes between the European Union and China in the domain of Enterprise Integration. He is also involved in the standardisation activities. He is member of the European Standardisation Committee CEN TC 310/WG1 (system architecture), expert of IEC/ISO JWG15 (enterprisecontrol system integration) and ISO TC184/SC5/WG1 (modelling and architecture). He is also member of the IFIP WG5.12 (architecture for enterprise integration) and member of the IFAC WG5.3 (enterprise integration and networking). He has published more than 90 papers in international journals and conferences.

Guy Doumeingts is professor at the University Bordeaux 1, Past-Director of ‘‘Laboratoire d’Automatique, Productique Signal et Image’’ control theory and CIM and past-Head of GRAI. His main research topic this last 10 years is enterprise modelling. He has published more than 200 articles and 3 books in the domain of CIM and Production Management.

Franc¸ois 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 has deals with enterprise architectures, enterprise modelling and integration, information systems design and analysis, CIM and various aspects of industrial engineering (facility layout, performance evaluation, cost estimation, and competency modelling). He has lectured in many countries in Europe, North and Latin America, China, and North Africa. He has consulted several large and medium-sized companies in France and Canada (automotive industry, aeronautics industry, and software houses). 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.