# A Process Interoperability Method for SMEs

Lei Wu, Xiangxu Meng, Cuiling Liu, Chengwei Yang, Shijun Liu

► To cite this version:

Lei Wu, Xiangxu Meng, Cuiling Liu, Chengwei Yang, Shijun Liu. A Process Interoperability Method for SMEs. 3rd IFIP Working Conference on Enterprise Interoperability (IWEI), Mar 2011, Stockholm, Sweden. pp.50-60, 10.1007/978-3-642-19680-5_6. hal-01572105

HAL Id: hal-01572105

https://inria.hal.science/hal-01572105

Submitted on 4 Aug 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
A Process Interoperability Method for SMEs

Cuiling Liu, Chengwei Yang, Shijun Liu, Lei Wu and Xiangxu Meng

School of Computer Science and Technology, Shandong University
Jinan, China
{sdling_0402, yangchengwei2006}@163.com
{lsj, i_lily, mxx}@sdu.edu.cn

**Abstract.** This paper starting with the present status of enterprise interoperability, focuses on enterprise interoperability of SMEs (Small and Medium-sized Enterprises), and based on a SMEs oriented framework of enterprise interoperability proposes an approach of process level interoperability. The approach appropriate for SMEs mainly solves two types of interoperability involving processes' interior in the process level. Life cycle of process level interoperability is redesigned and reorganized. In each phase of the life cycle a comprehensive solution is given. In final, this paper gives a case study to describe and enhance the approach.

**Keywords:** Enterprise interoperability, SMEs, process interoperability

# 1 Introduction

In modern enterprise computing environments, interoperability is a common issue caused by many factors such as heterogeneous systems, different organizational forms and diverse business processes. To gain more benefits and reach a common enterprise goal, enterprise interoperability has become a significant strategy for enterprises. In this context, many investigations concerning enterprise interoperability are done. The LISI (levels of information systems interoperability) approach with the goal of providing a maturity model and a process for detecting joint interoperability needs, evaluating the capability of the systems to meet those needs, and selecting pragmatic solutions and a transition path for achieving higher states of capability and interoperability for the US Department of Defense (DoD), was developed by C4ISR Architecture Working Group (AWG) during 1997 [1]. Other frameworks such as the IDEAS interoperability framework [2], the European Interoperability Framework (EIF) [3] and the ATHENA interoperability framework (AIF) [4] also have deep influence. But, a maturity framework particularly focusing on SMEs is still needed. All over the world, the proportion of SMEs in the whole enterprises is quite large. In this complex context, this paper reviews a SMEs oriented framework of enterprise interoperability. Based on the SMEs oriented framework, the main work of process level interoperability is elaborated, and an application about the traditional textile industry in China is given in this level as a case study.
The rest paper is organized as follows. Section 2 explains several related definitions and works about the thesis in this paper. Section 3 reviews the idea of a SMEs oriented framework of enterprise interoperability. According to the framework and relationships between levels, an approach of SMEs oriented process level interoperability is proposed in section 4. Then, the process level interoperability is designed at the background of the SMEs cluster as a case study in section 5. Finally, section 6 concludes the whole paper and looks forward to the future work.

## 2 Related Works

Before entering the main topic, we have the need of interpreting some concepts and definitions about interoperability and process interoperability. Generally speaking, according to [5, 6], the ability of multiple system entities to understand each other and to use functionalities of each other by properly communicating and exchanging information is seen as interoperability. In the procedure of interoperability, the incompatible and heterogeneous features of multiple entities are covered, which becomes the goal of interoperability research. When interoperability is proposed in the enterprise computing environments, with the background of enterprise, it evolves enterprise interoperability.

Interoperability or the capability to interact and collaborate can be identified into three forms from [7, 8]. The three forms are respectively named as integrated, unified and federated interoperability, which depends on the location of the information used for reaching interoperability. In the integrated form, interoperability methods concern the internal implementation of software components. For the unified form of interoperability, a common meta-information entity is shared by each participant of interoperability. One kind of meta-information entity called standards has applied in the traditional industry for interoperability. However, the ambiguity and slow development of standardization make it unsuccessful in modern software engineering. The other kind of meta-information entity is explicitly shared meta-information which uses a specific modeling language to be defined and uses computing platform independent notations to illustrate components' features and interrelations. Compared with the previous two interoperability forms, federated interoperability form makes use of negotiation mechanisms, model verification and monitoring of service behavior referring on interoperability contract to work. The property of no common meta-information entity decides the necessity of a shared meta-model and meta-information management.

A process describes the collaboration of mutual or automated activities which have a common blueprint [9]. A process uses a meta-model to define the concepts and notations about process description and activities expression. Besides, a process model limits detailed process steps which a process instance relies on in execution. Process interoperability should contain control and synchronization to make sure that processes can interwork with other ones.

Considering process level interoperability for SMEs, an approach using E-mails communication to realize process interoperability is given in [10, 11]. In this approach, process interoperability is subdivided into one Build-Time component and four Run-Time components. The Build-Time component is a process of
configuration, which requires that each SME must initialize its own processes based on the Reference Model Directory and store the processes in the Enterprise Process Repository. The four Run-Time components include detecting, tracking, assisting and advising. But, the approach uses a same process meta-model to define all the process models in SMEs and takes more attention to the composite application of processes. The authors in [12] propose a solution in interoperability of Process-Sensitive Systems (PSSs). The main idea of the solution is a virtual PSS independent of PSSs used to guarantee interoperability. The solution is efficient but costs much. In this paper, the sufficient use of existing resources and low cost are taken into consideration. Based on an integral SMEs oriented interoperability framework, a method of the process level taking more attention to interoperation involving processes' interior is proposed.

## 3 SMEs Oriented Interoperability Framework

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Five Levels' SMEs Oriented Interoperability Framework.</figcaption></figure>

As shown in Fig. 1, a five levels' framework of enterprise interoperability is proposed for SMEs. It contains data level, service level, process level, business level and presentation level. Based on the former fundamental interoperability forms, interoperability of each aspect in each level resorts to appropriate fundamental interoperability form, which we name as a mixed interoperability method used in the framework.
In the data level, interoperability commits to solving the incompatibility of different data models and query languages. Data from various heterogeneous data sources which may be established on different DBMS even OS will be used to exchange by the guarantee of data interoperability. Participants of interoperability can remain the differences, but a shared meta-model is needed. Service Data Objects (SDO) [13, 14] is a specification for a programming model that unifies data programming across data source types, provides robust support for common application patterns, and enables applications, tools, and frameworks to more easily query, view, bind, update, and introspect data. In the procedure of implementing data interoperability, combination with SDO is a good selection in technology. Data interoperability is established with a mechanism supporting data transformation between senders and receivers, which provides convenience for other levels efficiently.

Service level interoperability refers to discover, composite different kinds of
application functions or services for well collaborative work. SCA (Service
Component Architecture) provides model for both service composition and service
encapsulation, including reuse of existent function in SCA composite component [15,
16]. So, SCA can be selected as the service level interoperability technology.

The goal of interoperability in the process level is to make various processes work together. Interoperability of the process level is classified into two types in accordance with the interoperability scope. One is interoperability between processes independent of each other, which can be considered as interoperability between activity nodes not belonging to a common process. The other is interoperability between processes and their sub processes, and the interoperation points locate processes' abstract activity nodes which are related to the start and end activity nodes of sub processes. The details of process interoperability will be discussed in section 4.

Interoperability for the business level is on the standpoint of organization and company, and it deals with the interoperation barriers causing by diverse business rules, policies, strategies, legislation and culture. Business level interoperability is established by negotiation mechanism and monitoring facilities, which makes use of a federated analogous interoperability form. Considering interoperability of the business level, the circumstance of virtual enterprise and dynamic alliance can be considered. Due to the framework based on SMEs cluster, a domain ontology can be modeled by UML according to [17].

In interoperability, it needs flexibility, adaptability and agility in the presentation aspect to own well designed and harmonious presentation. In the light of the significance of presentation, interoperability of presentation is listed independently as the top level. Interoperability in this level emphasizes on integration more, especially a type of loosely coupled integration. Referring to [18], Widget Model can be used as a reference solution in technology. But Widget can't invoke remote resource. A modified Widget uses both local resource and remote resource in the process of across enterprise interoperability.

The process level's relationships with other levels will be explained explicitly.
Firstly, the data level provides a comprehensive support for all the interoperation in
the process level. Exchanging message meaningfully of processes is contributed to
the incompatible data processing in the data level. Secondly, a process can be seen as
a sequence of services. So processes have the ability of controlling multiple services
work together for one common aim, and services are instantiation of process activities. In final, relationship with business level is discussed. Frankly speaking, the relationship is obvious. Business can directly impose constraints on process modeling. In this way, process models perform as business's formalization. Something still needing to be elaborated is that generally interoperability in any level or between any levels can't lack the support of the data level. So the data level can be seen as a basic level. However, the presentation level plays a role of showing all the understood information and can be considered as an encapsulation of other levels.

# 4 SMEs Oriented Process Interoperability

In this paper, we divide activity nodes of a process model into two types: abstract activity nodes and detailed activity nodes. Abstract activity nodes mean that they do not directly control activity services and they must be instantiated by other processes. In contrary to abstract activity nodes, detailed activity nodes must straightly invoke and control activity services.

To implement interoperability of the process level, a SMEs oriented process interoperability tool across enterprises is needed. It should contain process meta-model ontology, process activity analysis, interoperability point testing/sub process detecting and interoperability connection control. Here, the definition of interoperability point is limited to process activity nodes. Life cycle of SMEs oriented process interoperability includes two phases: Built-Time and Run-Time. In the Built-Time phase, the main task is finding interoperability points. Compared with the Built-Time phase, the Run-Time one mainly deals with establishing interoperation connection, interoperation and releasing interoperation. The following subsections will give a detailed description of the two phases.

## 4.1 Built-Time

Process meta-model ontology, process activity analysis and interoperability point testing/sub process detecting will perform in the phase. The information used in the whole process level generally can be divided into two types: requested information and responded information. Process activity analysis is used to identify requested and responded information for all the activity nodes including start and end of process models. For two activity nodes, if one's requested information is corresponding to the other's responded information partly or completely, interoperability point testing can decide that interoperability exists between them. Sub process detecting also makes use of relation about requested and responded information. If one abstract activity node's requested and responded information of a process are consistent with start node's requested information and end node' responded information of a common process, the latter process can be use as a sub process to instantiate the abstract activity node of the former process. Besides, decisions of information consistency need the semantic support of the data level. Process meta-model ontology is used in the mapping of process meta-models in diverse process definition languages and engines. With the help of process meta-model ontology, the quantity of nodes in
interoperability points testing reduces largely, and the efficiency of interoperability points testing improves.

In interoperability between processes independent of each other, essentially finding interoperability point is a procedure of process activity analysis and interoperability point testing. Considering process interoperability with sub process, an abstract activity node using a sub process should detect, activate and monitor an appropriate sub process. When the selected sub process could not execute activities for the abstract activity node, the abstract activity node has the capability of finding a substitute solution. Sub process detecting is used in this kind of interoperability with respect to process activity analysis.

## 4.2 Run-Time

<figure><img src="image_3.png" /><figcaption>Fig. 2. Process Level Interoperability.</figcaption></figure>

Interoperability connection control is used in the Run-Time phase for establishing interoperation connection, interoperation and releasing interoperation connection. In interoperability between processes independent of each other, two partners wanting to establish business relation respectively submit own process model to the process interoperability tool for interoperability point testing. After obtaining results, the two partners confirm the interoperability to establish a special interoperability connection. The meaning of the connection is to open process engine's certain function to each other for certain process instances in certain activity nodes. For example, in certain process instances A' (relying on process A) and B' (relying on process B) which belong to two different enterprises, activity A'.a of A' can use remote process engine function to signal an activity B'.b of B' in a special situation. Process instances end and the corresponding interoperability connection is released. Process interoperability with sub process is similar to the former one. Nevertheless, the abstract activity starts
a certain instance of the selected sub process, and the instance's ending of the selected sub process signals the abstract activity.

The method of process interoperability for SMEs is illustrated by the Fig. 2. In Fig. 2, process A and process B in the top level denote the interoperability between processes independent of each other, and process A and process C in two diverse levels denote the interoperability between processes and sub processes. Finally, in order to improve efficiency, process activity analysis is done only one time before a new process model executing in process engine and the analysis results are saved for all the use.

# 5 Case Study and Analysis

Nowadays, there are many small and medium enterprises in the textile industry of China. These enterprises limited by scale and funds are still in the primary stage of information, which makes them at the disadvantage in the competition. The original purpose of this research is to help these enterprises in the textile industry of China improve efficiency in enterprise management and collaboration.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Process Model of Enterprise A.</figcaption></figure>

A business scene is described as follows. When a textile enterprise A receives a new order, it firstly does a checkup for the new order. If the new order does not pass the checkup, the enterprise will send a refusal to the source of the order and the process is ended. Otherwise, the enterprise will send an acceptable reply to the order source and then contract with it. After the contract becomes effective, enterprise A begins to produce. Before producing products, the number of cloth in storage is checked. If cloth used in this order is enough, the cloth can be removed from the
storage and be made into products. When the products are finished, they will be
stored into the storage and then be sent. Later, enterprise A receives a goods arrival
reply and goes into the phase of financial settlement. After financial settlement, the
whole process comes to a finished end. There is also another situation that the cloth is
not enough for the order. In this situation, enterprise A will decide to whether the
cloth is produced by itself according to its own production capability and assignment
quantity. If it can finish the cloth producing by itself, materials out of storage will be
weaved into cloth. Then the cloth is stored in the storage for the use of producing
products. If enterprise A can't finish the preparation of the cloth, it will send a cloth
order to an enterprise B which is eager to producing cloth for A. After receiving an
acceptable reply, enterprise A reaches a cloth agreement with enterprise B. When the
cloth produced by enterprise B arrives, the production will be continued. Besides, the
procedure of producing products in enterprise A includes five phases: cutting, sewing,
testing, packaging and boxing. Compared to enterprise A, enterprise B has a simple
way of business. After contracts become effective, enterprise B will directly begin to
produce and then send goods. Finally, enterprise B does financial settlements.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Sub Process Model of Enterprise A (left) and Process Model of Enterprise B (right).</figcaption></figure>

Based on the illustration of business scene, the global business of enterprise A can be modeled as a process model A shown in Fig. 3. In the same way, the business of producing product for enterprise A can be modeled as a sub process model A.1 shown in Fig. 4 (left), and the business of enterprise B can be modeled as a process model B shown in Fig. 4 (right). From the perspective of the process level, interoperability between process A' (relying on process model A) and process B' (relying on process model B) is interoperability between processes independent of each other: interoperability between process A' and sub process A.1' (relying on process model A.1) belongs to process interoperability with sub process used. The application implementation is based on a modified JBPM engine. Though a common process engine is used, process A', sub process A.1' and process B' use different versions to be modeled. After making process model A and B as input of process interoperability tool for interoperability point testing, confirm interoperability in certain instance A'-1 and B'-1. Then interoperability configuration in A' and B' can be showed like below.
```xml
<task g="503,88,160,52" name="sending cloth order" >
  <interoperability>
    <local-instance>A'-1</local-instance>
    <inter-instance>B'-1</inter-instance>
    <service>
      http://... /manageB/services/ProcessManager?wsdl
      <interface>signal</interface>
    </service>
    <activity>recerving new order</activity>
    <variable>cloth order</variable>
  </interoperability>
  <transition to="receiving reply"/>
</task>
<state g="673,210,169,52" name="receiving reply" >
  <transition name="accepted reply" to="cloth contracting" g="-43,-5"/>
  <transition name="refusal reply" to="sending cloth order" g="-9,-10"/>
</state>
...
<task g="117,177,133,52" name="confirming acception" >
  <interoperability>
    <local-instance>B'-1</local-instance>
    <inter-instance>A'-1</inter-instance>
    <service>
      http://... /manageA/services/StateManager?wsdl
      <interface>complete</interface>
    </service>
    <activity>
      recerving reply
      <outcome>accepted reply</outcome>
    </activity>
  </interoperability>
  <transition to="contracing"/>
</task>
<task g="299,14,127,52" name="confirming refusal" >
  <interoperability>
    <local-instance>B'-1</local-instance>
    <inter-instance>A'-1</inter-instance>
    <service>
      http://... /manageA/services/StateManager?wsdl
      <interface>complete</interface>
    </service>
    <activity>
      recerving reply
      <outcome>refusal reply</outcome>
    </activity>
  </interoperability>
</task>
```
<transition to="end1"/>
</task>

## 6 Conclusion

In this paper, we have reviewed a five levels SMEs oriented framework of enterprise interoperability. Interoperability of data level, service level, business level and presentation level is described in summary. Based on the whole framework, a process interoperability method for SMEs is proposed, and it focuses on two types of process interoperability. One is interoperability between processes independent of each other. The other is interoperability between processes and their sub processes. To cover the two type process interoperability, a SMEs oriented process interoperability tool across enterprises is designed and partly implemented. Moreover, an application of the textile industry in China is supported by the tool. However, both the approach and the application decrease the processing of semantic interoperability. So, in the future, we want to do some work about semantic interoperability for supporting SMEs oriented process level interoperability. Besides, the SMEs oriented process interoperability tool still have many disadvantages in design and implementation, which needs a long term hard work.

**Acknowledgments.** The authors would like to acknowledge the support provided for the project by the National Natural Science Foundation of China (60703027), the National High Technology Research and Development Program of China (2009AA043506), the China Postdoctoral Science Foundation (20090451313) and the Natural Science Foundation of Shandong Province (ZR2009GM028).

## References

1. The C4ISR Architecture Working Group (AWG) (CAWG): Levels of Information Systems Interoperability (LISI). (1998)

2. IDEAS: Interoperability Development for Enterprise Application and Software—Roadmaps, Annex 1—Description of Work. (2002)

3. EIF: European Interoperability Framework, White Paper. Brussels (2004)

4. Guglielmina, C., Berre, A.: ATHENA, "Project A4" (Slide Presentation). In: ATHENA Intermediate Audit, Athens (2005)

5. Konstantas, D.: Object oriented interoperability. In: ECOOP '93 - Object-Oriented Programming: 7th European Conference. LNCS 707, pp. 80--102. Springer, Verlag GmbH. (1993)

6. Chen, D., Vernadat, F.: Enterprise interoperability: a standardization view. In: K. Kosanke, et al. (eds.) Enterprise Inter-and-Intra Organizational Integration, pp. 273--282. (2002)

7. ISO: ISO 14258 – Concepts and rules for enterprise models. In: ISO TC184 SC5WG1. (1999)

8. David Chen, Guy Doumeingts, Francois Vernadat: Architectures for enterprise integration and interoperability: past, present and future. J. Computers in Industry 59: 647--659 (2008)
9. Conradi, R., Fernstrom, C., Fuggetta, A., Snowdown, B.: Towards a Reference Framework for Process Concepts. In: 2nd European Workshop on Software Process Technology, Trondheim (1992)

10.Burkhart, T., Werth, D., Loos, P.: Realizing process interoperability using E-Mail communication. In: 1st International Conference on the Applications of Digital Information and Web Technologies, pp. 579--583. IEEE Press, Ostrava (2008)

11.Burkhart, T., Werth, D., Loos, P.: Process interoperability through proactive e-mail annotations. In: 2nd International Conference on the Applications of Digital Information and Web Technologies, pp. 175--180. IEEE Press, London (2009)

12.Establier, J., Barghouti, N.S.: Interoperability and distribution of process-sensitive systems. In: International Symposium on Software Engineering for Parallel and Distributed Systems, pp. 103--114. IEEE Press, Kyoto (1998)

13.Service Data Objects Specifications, http://www.osoa.org/display/Main/Service+Data+Objects+Specifications

14. SDO Resources, http://www.osoa.org/display/Main/SDO+Resources

15.Service Component Architecture Specifications, http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications

16.SCA Resources, http://www.osoa.org/display/Main/SCA+Resources

17.Haiying Che, Marco Mevius, Yanbing Ju, Wolffried Stucky, Ralf Trunko: A Method for Inter-organizational Business Process Management. In: IEEE International Conference on Automation and Logistics, pp. 354--358. IEEE Press, Jinan (2007)

18.Yongsheng Ma, Gang Chen, Georg Thimm: Change propagation algorithm in a unified feature modeling scheme. J. Computers in Industry. 59, 110--118 (2008)