Barriers to enterprise interoperability

Barriers to Enterprise Interoperability Johan Ullberg1, David Chen2, and Pontus Johnson1 1 Industrial Information and Control Systems, KTH - Royal Institute of Technology, 10044, Stockholm, Sweden {johanu,pj101}@ics.kth.se 2 IMS/LAPS, University Bordeaux 1, 351, Cours de la liberation, 33405 Talence cedex, France [email protected] Abstract. Interoperability is a key feature for enterprises in today’s competitive environment. Fundamental interoperability problems are however still not well understood. Within the scope of the Framework for Enterprise Interoperability (FEI) originally proposed by INTEROP NoE and now moved to ISO standardization process, this paper tentatively identifies and categorizes a set of interoperability barriers. Barriers to interoperability are defined as incompatibility between two enterprise systems. A list of interoperability barriers is presented and these barriers are then mapped to the FEI and illustrated with examples. The most significant dependencies between barriers are also tentatively defined and presented. Keywords: Framework for Enterprise Interoperability, interoperability barrier, interoperability concern, interoperability dependency. 1 Introduction Interoperability development has been approached from many different points of view and perspectives, such as computer science, collaboration in the frame of networked enterprise, etc. However fundamental interoperability problems are still not well understood and they are only fragmentally considered and studied. This paper proposes to identify interoperability problems through the concept of barrier and to tackle interoperability development by a problem driven approach. The research assumptions are as follows: 1. Enterprises are not interoperable because there are barriers to interoperability that obstruct exchange of information and services. 2. Barriers are incompatibilities of various kinds and can be found at various levels and domains of an enterprise. 3. Incompatibilities have as source the heterogeneity between the actors that are to interoperate. Whenever there is heterogeneity in two related systems, there is a risk of interoperability problems. 4. Barriers can be specific linked to a specific application; however there exist generic barriers which are common in all situations of non interoperability. R. Poler, M. van Sinderen, and R. Sanchis (Eds.): IWEI 2009, LNBIP 38, pp. 13–24, 2009. © IFIP International Federation for Information Processing 2009 14 J. Ullberg, D. Chen, and P. Johnson Based on the assumptions made, the research in Enterprise Interoperability domain consists in elaborating solutions to remove barriers (i.e. incompatibilities between systems or components of systems that are concerned by interoperations). The objective of this paper is to contribute to a better understanding of interoperability problems by identifying and structuring barriers to interoperability under the guidance of an interoperability framework. Recently several initiatives on interoperability have proposed interoperability frameworks to structure issues and concerns in quite different ways. The European Interoperability Framework in the eGovernment domain [1] defines three types of interoperability: semantic, technical and organizational. A similar approach was also proposed in e-Health interoperability framework [2] which identified three layers: organizational, informational and technical interpretabilities. In manufacturing area the IDEAS interoperability framework [3] defines three main layers (Business, Knowledge and ICT) with two additional vertical dimensions (Semantics and Quality attributes). More recently the ATHENA Interoperability Framework (AIF) proposes to structure interoperability issues and solutions at the three levels: conceptual, technical and applicative [4]. This paper adopts the Framework for Enterprise Interoperability [5] which was initially proposed within the INTEROP DI and now under the process of standardization (CEN/ISO 11354). This framework covers the main issues identified in the previously mentioned frameworks and focuses on the problem dimension of interoperability. The objective is to tackle interoperability problems through the identification of barriers which prevent interoperability to occur. The remainder of this paper is structured as follows: The introduction to the field of interoperability in this section is in the next section followed by a brief introduction to the Framework for Enterprise Interoperability. In section 3 the main contribution of the paper is presented, a set of barriers and their mapping into the framework. The internal relationships between these barriers are then elaborated in section 4 followed by a conclusion of the paper in section 5. 2 The Framework for Enterprise Interoperability The Framework for Enterprise Interoperability defines the three basic dimensions as follows: • • • Interoperability concerns which defines the content of interoperation that may take place at various levels of the enterprise (data, service, process, business) i.e. the level at which the interoperation occurs. Interoperability barriers which identifies various obstacles to interoperability in three categories (conceptual, technological, and organizational), i.e. the type of obstacle to interoperability. Interoperability approaches which represents the different ways in which barriers can be removed (integrated, unified, and federated). Barriers to Enterprise Interoperability concern 15 PROBLEM SPACE approach SOLUTION SPACE barrier concern Problem : Barrier x Concern Solution : Approach x Barrier x Concern barrier Fig. 1. The relation between the problem and solution space of the framework The first two dimensions: Interoperability concerns and Interoperability barriers constitute the problem space of enterprise interoperability, see Fig. 1. The intersection of an interoperability barrier and an interoperability concern is the set of interoperability problems having the same barrier and concern. The three dimensions together constitute the solution space of enterprise interoperability. The intersection of an interoperability barrier, an interoperability concern and an interoperability approach is the set of solutions to overcome an interoperability barrier at a level of concern, using a specific approach. Three categories of barriers are defined: conceptual barriers (syntactic and semantic incompatibilities), technological barriers (additional incompatibility due to the use of technology), and organizational barriers (related to the incompatibilities of method of work, organization structure, etc.). These barriers can exist at four different levels of concerns: data, service, process and business levels. Fig. 2 shows the interoperability framework in its simplified form with only the first two dimensions defining the problem space. Iop barriers Iop concerns CONCEPTUAL TECHNOLOGICAL ORGANISATIONAL BUSINESS PROCESS SERVICE DATA Fig. 2. Interoperability Framework (here only the first two dimensions) 16 J. Ullberg, D. Chen, and P. Johnson The interoperability framework also aims at structuring interoperability solutions according to their ability to remove the barriers. This is important for retrieval and reuses the existing knowledge. For example, PSL (Process Specification Language) allows removing the conceptual barrier (syntactic and semantic barriers) for process interoperability using a unified approach. 3 Identifying the Barriers to Interoperability Although the dimensions of the framework are well defined, see section 2, the actual barriers and solutions are still not yet explicitly identified. This paper sets out to detail the barriers at the different levels of concerns, give a brief description of each barrier and provide an example of how this barrier could occur. An ID is given to each barrier allowing to categorize the barriers according to the framework. This ID is constructed according to the following syntax: <type of barrier>’/’<type of concern>’-‘< number within this category>, where the types are identified by the first letter in their respective names. For instance, O/P-2 is the second organizational barrier at the process level. The description of barrier is expressed as the heterogeneity (or difference of things) considered as the source of incompatibilities (barriers). Table 1. List of the barriers with ID, name and a brief description Id Name C/D-1 Data content Description Coverage, i.e. content, of the respective data representation C/D-2 Data syntax Heterogeneous data format and structure C/D-3 Data semantics Data meaning disagreements C/S-1 Service content Differences in the coverage, i.e. content, of the services offered C/S-2 Service syntax Language/formalism syntax used to describe the services C/S-3 Service semantics The meaning of services descriptions C/P-1 Process content Coverage, i.e. content, of the processes C/P-2 Process syntax Process description language grammar and graphical representation C/P-3 Process semantics The meaning of the processes description C/B-1 Visions, strategies & Culture Differences in the respective companies goals, views, etc. C/B-2 Business syntax Format, template or model used for describing enterprise business C/B-3 Business semantics Meaning of terms used to express business issues T/D-1 Exchange format Protocol or format available to exchange information T/S-1 Service granularity Definitions of what constitutes the services, i.e. interface problems Barriers to Enterprise Interoperability 17 Table 1. (continued) T/P-1 Process behavior T/B-1 Degree of computerization T/B-2 IT requirement fulfillment O/D-1 Information ownership O/D-2 Classified information O/S-1 Resource control O/P-1 Business process behavior O/B-1 Legislation O/B-2 Organization structure O/B-3 Methods of work Order of operations in the computerized processes How much of data, services and processes that are automated in IT The ability of IT to support the requirements of the business The structures for assigning rights to data Differences in which information that is to be regarded as classified with respect to the collaboration partner The allocation of resources, technical as well as non technical. Order of operation in business processes The legislative requirements that influence different actors. How enterprises are organized on a high level High level differences regarding how work is performed in the organizations The remainder of this chapter provides explanation and examples of barriers listed above. The examples are elaborated within the context of two retail organizations E1 and E2 that want to interoperate in order to cover a larger market both in terms of geographical coverage and type of merchandise. 3.1 Conceptual Barriers The conceptual barriers are mainly concerned with the syntactic and semantic incompatibilities of information to be exchanged. These problems concern the modeling at the high level of abstraction as well as the information level [6]. Generally speaking the conceptual barriers can be classified into three different types, see Fig. 3. Fig. 3. The three main types of conceptual barriers: content, syntactic and semantic barriers 18 J. Ullberg, D. Chen, and P. Johnson Table 2. Different types of semantic conflicts, (1) same term with different definitions and (2) different terms with the same definition, adopted from [7] D1=D2 D1≠D2 T1=T2 Conflict of type 1 No conflict T1≠T2 No conflict Conflict of type 2 The content barrier is related to the coverage of the models within the enterprises, and heterogeneity would correspond to some concepts of one of the companies that do not exist in the other company. Syntactic barriers are concerned with the language used to express models and the semantic barriers with the meaning of the terms used. On the data level the C/D-1 relates to difference in the content of data stored by the enterprises. For example, E1 uses the social security number for identification of their customers whereas E2 uses a customer ID and thus does not have social security number stored regarding their customers. E1 also encode their customers’ names using just a “name” field containing the concatenation of the given name and surname. E2 on the other hand uses two fields, one “name” field containing the given name and one “surname" field containing the surname. This corresponds to the barrier C/D-2 (data syntax barrier). Turning to the data semantic barrier (C/D-3), with the assumption that a concept C=(T,D) consists of a term, T and a definition D, two cases of barriers are identified, cf. Table 2: (1) the same term is used with different meanings (definitions), (2) the same concept (equal definitions) is named with different terms. This view is an aggregation of the six semantic problems as outlined in [7]. Data semantic barrier is the most frequently encountered interoperability problem. For example, the enterprises E1 and E2 both use the term “Shipped” to refer to items that are sold and will be delivered to the customer. E1 however, use this term to refer only to the items actually in transit, i.e. items that have left the premises of E1 and are on their way to the customer. E2 have a wider meaning and regard an item to be shipped as soon as it’s sold, regardless if the actual shipping has commenced. E1 and E2 also use the terms “invoice” and “receipt” respectively to refer to the same item, i.e. the customers’ proof of purchase. At the service level, the same problem of content, syntax and semantics occur. The content barrier (C/S-1) occurs if for example E1 defines the service “pay by check” but E2 doesn’t accept payment through checks. Regarding the syntax of services (C/S-2), the choice of language to describe the services is an important question, E1 use a more formal language that stipulates that the specification of a service as structured information, using fields like “name”, “input”, “output”, “operations”. E2 on the other hand use unstructured descriptions of their services, with just paragraphs of text describing the same information as contained in E1s descriptions. Just as in the case of data, the semantics of the services (C/S-3) is concerned with the meaning of terms used for different services, one example could be that E1 and E2 both use the service “register monetary payment” but E1 refers to any form of direct payment whereas E2 only to payment by cash. At the process level, different process content (C/P-1) may lead to incompatible process collaboration. For example E2 does not work with installments and thus does not have a process for evaluating a customer’s credit rating and updating these Barriers to Enterprise Interoperability 19 ratings, something done in E1 where installments are a frequent means of payment. The syntax barrier (C/P-2) is mainly concerned with the use of different process modeling languages (for example, UML and BPMN). This syntax barrier is the main problem in exchanging process models between companies and to relate them together to build collaborative processes. Finally the semantic barrier at process level (C/P-3) refers to the meaning of the terms used to name and describe processes and subprocesses. For example E1 uses the term “procurement” to refer to exactly the same process as E2 have named “acquisitions” and that the process “claims management” exists in both E1 and E2 and deals with return of faulty goods, however the individual steps in this process are different in the respective companies. Regarding conceptual barriers at the business level, C/B-1 (different strategy and vision) exists if one company adopts a Low cost strategy consisting in selling the product by lowering costs and maximizing income (by increasing volume), while another company focuses on aiding the customer to increase the added value in the customers organization. Differentiation in this way usually includes the act of getting involved in your customer’s processes [8]. Even if C/B-1 corresponds to the content issue of the conceptual barriers, there is still however the matter of communicating this content between the enterprises, if different languages are used to encode vision, goals. For example if one uses natural language in policy documents whereas the other one uses the modeling notation Business motivation model [9], this will lead to the C/B-2 syntactic barrier. The semantic problem (C/B-3) also occurs at business level. For example E1 and E2 use the term “leading” differently in statements such as “We will be the leading supplier of industrial tools on the US market”. E1 interprets ‘leading’ as the supplier with the largest turnover whereas E2 interprets it as having the most advanced tools on the market. 3.2 Technological Barriers The technological barriers are concerned with the use of computer or ICT (Information and Communication Technology) to communicate and exchange information [6]. Barriers in the technological domain at the data level (T/D-1) are encountered when it is impossible to exchange data files or access to the database of a third system. This may occur when two systems don’t share an exchange format, for example the ERP system of E1 has the options of using an internal proprietary data format or a XML based industry standard. E2 on the other hand is only able to exchange information in an EDI based format such as UN/EDIFACT. Moreover since different versions of the same exchange format might be incompatible it’s important to specify the exchange format in a manner so that the compatibility is ensured (i.e. including version number etc.). This barrier could be further broken down into the different types of conceptual barriers described above, see C/D-1, 2 and 3. Enterprises may also define their services with different degrees of granularity leading to an interoperability barrier (T/S-1). For example E1 might have an order system with the services “add item” (corresponding to adding a row on the order) and “update stock” (which corresponds to reducing the number shown as available in stock). E2 could have defined their services to one single “register row” which performs both operations. Even though the actual actions might be exactly the same, i.e. adding an item to the order always follows by a reduction in stock and there are no 20 J. Ullberg, D. Chen, and P. Johnson conceptual differences between the systems, there will still be a barrier in terms of the defined interfaces of the respective systems. Within the technological domain at the process level the barrier process behavior is concerned with incompatibilities of process execution tools to work together. The barrier, T/P-1, is not specifically coupled with the use of paradigms such as SOA/Workflows although the name might indicate so – the order in which operations are performed in systems have always been of high importance. This barrier is very similar to the O/P-1 barrier in the organizational domain. In E1 the process of registering a sale, and thus the operations of the system that supports this task, is to first take the customer information and then to register the items whereas E2 might have defined the same process in the opposite order, i.e. register the items first and then taking the customers details. At the business level, barrier T/B-1 refers to differences in degree of computerization. One company may for example have decided and implemented a fully computerized invoice process so that once an order is sent the invoice is sent as well. Another company on the other hand chooses a manual process where each order is audited by personnel that then manually enter the invoices in the billing system. This is essentially a difference in the requirements posed on IT. Related to the matter of requirement is the barrier T/B-2 that is concerned with how well IT actually supports the requirements of the organization. Even if the requirements of the business on IT are matched between the interoperating organizations it’s not necessary the case that the ability of the respective IT organizations to fulfill these requirements are equal. This will primarily become a barrier to interoperability as the cooperation between the enterprises unfold, typically problems relating to a joint decision to change the cooperation in some manner and this affects IT. If the enterprises decide to create a joint shop, for instance on the web, this will pose new requirements on IT and a discrepancy in the ability to fulfill these requirements will become a barrier. This can be seen as a somewhat coarse black box view of this fairly complex issue of matching IT and business, and is also somewhat related to the concept of B-ITa, see for instance [10] for more information about B-ITa in collaborative networked organizations. 3.3 Organizational Barriers The organizational barriers are concerned with the incompatibilities of organization structure and management techniques implemented in two enterprises [6]. Generally speaking, different ways of defining and assigning responsibility and authority result in different organizations which may raise problems from the interoperability point of view. At the data level different structures for data or information ownership (O/D-1) is an organizational barrier. For example if E1 only allows changes in customer information to be performed by customer support whereas E2 allows the same changes from both customer support and sales. Generally there are four different access rights for data, these are Create, Modify, Access and Remove, in the above example Customer support of E1 assigned C, M & R to customer support and A to both customer support and sales. In E2 on the other hand both customer support and sales were assigned the whole set of C, M, A & R. Another problem relating to the data level is differences in the amount of information each partner is willing to share, O/D-2. Barriers to Enterprise Interoperability 21 E1 could benefit greatly from information on previous sales in order to improve the joint marketing but E2 have a policy stating that such information must not leave the company. Regarding the service level, O/S-1, E1 have an organizational policy where, in the case of workforce resources, the resources themselves determine if they are available to perform a task and usage of IT resources are decided by the IT department. E2 on the other hand have a policy where the head of each department is responsible for allocating the time of the employees and the IT resources are owned by the business rather than the IT department and the resources are thus allocated by the head of the business department. Collect customer information Collect information on the issue Collect information on the issue Collect customer information E1 E2 Fig. 4. An example of incompatibility in the order of business process execution, O/P-1 The organizational barrier at the process level, O/P-1, is concerned with the behavioral aspects of the processes in the enterprises. In E1s customer service department all information about the customer is collected before information about the customer’s problem is attained, the order of the same process in E2 use the opposite order, see Fig. 4. E1, being listed on NASDAQ need to be compliant with the Sarbanes-Oxley Act while E2 that is listed on the Swedish stock exchange and by that is required to comply with the Swedish Code of Corporate Governance. These two codes of conduct are somewhat heterogeneous thus leading to a legislative barrier, O/B-1. The organizational structures of the enterprise, O/B-2, is also of importance to the ability to interoperate, if one enterprise is organized in terms of a functional organization with for instance a head of the sales department whereas the other defines a matrix organization where the employees working with sales have two managers. For the respective managers to find their counterpart in the other organization could be difficult. Differences in organizational structure will most likely also lead to differences in methods of work which is the next and final barrier, O/B-3. One example of this barrier is when one company require that working hours shall be seven hours a day and forty hours a week (five hours on Saturday), whereas the other company stipulates eight hours a day and forty-four hours a week (four hours to be dealt at anytime at the workplace) [8]. 4 Relationships between the Barriers Many of the barriers described in section 3 are in some way related to each other. The most obvious relationship is those defined by the categorization of barriers in the two 22 J. Ullberg, D. Chen, and P. Johnson dimensions “barriers” and “concerns”, e.g. all conceptual barriers are related and all process level barriers are related. This section will elaborate on how barriers are affected by other barriers rather than covering these basic relationships, as long as the basic relationships don’t coincide with dependencies. The dependencies will be presented in models, the corresponding metamodel is very simple, with just one entity, the barrier, and one relationship, the affect relationship illustrated by an arrow indicating that the source barrier affects the target barrier. For readability reasons the barriers and their relationships have been divided into two clusters, the first contains primarily conceptual barriers and the second primarily the organizational and technical barriers. Between these two clusters only one relationship exists and in order to cover this relationship the barrier business process behavior exists in both models. The model containing most of the conceptual barriers is shown in Fig. 6. Perhaps most noticeable in this model is the set of double headed arrows between the different levels of concerns (data, service, process, business) of the same type of barrier (content, syntax, semantics). These dependencies correspond to the idea that what has been conceptually agreed or defined at a level of concern would affect what will be agreed or defined at the adjacent levels and the heterogeneities would follow the same pattern. For each given situation only one of the directions exist, which one is dependent on whether the enterprises define their content, syntax and semantics bottomup (i.e. starting at the data level and working their way up) or top-down. Fig. 5. First part of dependency structure mainly covering the conceptual barriers Barriers at the data models content, syntax and semantics would also affect the exchange format since the data being exchange is based on the data model. Differences in the process content could influence the behavior of the business processes and service content heterogeneities often lead to interface problems, as described by the service granularity barrier. Turning to the rest of the barriers and their relationships, cf. Fig. 7, recall that the barrier business process behavior is the link from the previous model. In this model one double headed arrow exists as well, linking business process behavior to system behavior. Just as before only one of the directions is valid for each case corresponding Barriers to Enterprise Interoperability 23 to whether the enterprise have a policy of altering the systems to conform to the business or if the business adopts the behavior of the system. Barriers at the business process behavior could depend on differences in the high level methods of work. The methods of work in turn can mainly be affected by barriers relating to organization structure, vision, strategy and culture as well as legislative differences. The vision, strategy and culture barrier could be claimed to, at least indirectly, influence most of the other barriers, however the most direct affect is that on organization structure, classified information and finally IT requirements fulfillment. The last B-ITa related barrier in turn affects the degree of computerization. Since the organization structure often defines responsibilities within the organization both the information ownership and resource control barriers are affected by the organization structure barrier. Furthermore, controlling resources often lead to controlling information as well and thus there is a dependency between these barriers. Finally the information classification barrier could, apart from what was described before, also be affected by legislative differences and differences in information ownership. Fig. 6. Dependencies between barriers primarily from the organizational and technical domain 5 Conclusion This paper set out to identify the set of interoperability barriers that obstruct the interoperation between enterprise systems. The list presented is not exhaustive and needs to be further completed and refined. Incompatibility resulting from heterogeneity of system elements is considered as a key concept to identify barriers and to understand various problems of interoperability. Solutions to improve interoperability are under constant development, but it’s not until the problem space is exhaustively identified 24 J. Ullberg, D. Chen, and P. Johnson and clearly defined that it’s possible to assure that the available solutions really mitigate all the barriers. Well defined problems (i.e. the barriers) can also aid in efficient development of solutions to these problems. The conceptual barriers are the most important ones because they are concerned with the presentation and representation of concepts to use for enterprise business and operations. Technological barriers are additional barriers stemming from existing incompatible information technologies. Organizational barriers are also additional barriers due to particularly incompatible human behaviors. The barriers are not independent and the most important dependencies between barriers are also shown in the paper. Future work is to validate the proposed list of barriers through case studies and elaborate an interoperability maturity model based on the concepts of barriers identified. References 1. EIF: European Interoperability Framework, White Paper, Brussels, 18 (Feburary 2004), http://www.comptia.org 2. NEHTA: Towards an Interoperability Framework, Version 1.8, August 21 (2005) 3. IDEAS: IDEAS Project Deliverables (WP1-WP7), Public reports (2003), http://www.ideas-roadmap.net 4. ATHENA: Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications, FP6-2002-IST-1, Integrated Project (April 2003) 5. Chen, D., Daclin, N.: Framework for Enterprise Interoperability. In: EI2N 2nd International Workshop on Enterprise Integration, Interoperability and Networking, in Second International Conference I-ESA 2006, France (2006) 6. Chen, D.: Framework for Enterprise Interoperability. In: 8th Congrès International de Génie Industriel (CIGI 2009), Bagnères de Bigorre, France (2009) 7. Zouggar, N., Vallespir, B., Chen, D.: Semantic Enrichment of Enterprise Models by Ontologies-based Semantic Annotations. In: International Workshop on Enterprise Interoperability (IWEI), Munich (2009) 8. Guedria, W., Naudet, Y., Chen, D.: Contribution of System Theory to develop Enterprise Interoperability. In: 8th Congrès International de Génie Industriel (CIGI 2009), Bagnères de Bigorre, France (2009) 9. Object Management Group (OMG), Business Motivation Model (BMM) Specification (August 2008), http://www.omg.org/spec/BMM/1.0/ 10. Santana Tapia, R., Daneva, M., van Eck, P., Wieringa, R.: Towards a Business-IT Alignment Maturity Model for Collaborative Networked Organizations. In: International Workshop on Enterprise Interoperability (IWEI), Munich (2009)