Decision-Making Approach for an IoRT-Aware Business Process Outsourcing

Abstract

In the context of Industry 4.0, IoRT-aware BPs represent an attractive paradigm that aims to automate the classic business process (BP) using the internet of robotics things (IoRT). Nonetheless, the execution of these processes within the enterprises may be costly due to the consumed resources, recruitment cost, etc. To bridge these gaps, the business process outsourcing (BPO) strategy can be applied to outsource partially or totally a process to external service suppliers. Despite the various advantages of BPO, it is not a trivial task for enterprises to determine which part of the process should be outsourced and which environment would be selected to deploy it. This paper deals with the decision-making outsourcing of an IoRT-aware BP to the fog and/or cloud environments. The fog environment includes devices at the edge of the network which will ensure the latency requirements of some latency-sensitive applications. However, relying on cloud, the availability and computational requirements of applications can be met. Toward these objectives, we realized an in-depth analysis of the enterprise requirements, where we identified a set of relevant criteria that may impact the outsourcing decision. Then, we applied the method based on the removal effects of criteria (MEREC) to automatically generate the weights of the identified criteria. Using these weights, we performed the selection of the suitable execution environment by using the ELECTRE IS method. As an approach evaluation, we sought help from an expert to estimate the precision, recall, and F-score of our approach. The obtained results show that our approach is the most similar to the expert result, and it has acceptable values.

1. Introduction

In the last years, the world has seen a trend toward the incorporation of some emerging technologies, such as the IoT and robotics. In fact, this incorporation gives birth to the newest technology called the internet of robotic things (IoRT). The IoRT is defined as a cooperation between IoT and robotic technologies to increase the automation level. This technology has several advantages, noted as, for example, the machine-to-machine (M2M) communication. It managed to sweep several fields, such as the business process (BP). Thus, the business managers try to take advantage of the IoRT via its integration within the classic BP, which gives a new process generation called IoRT-aware business processes (IoRT-aware BPs) [1]. This integration will allow business managers to automate their process.

However, the IoRT-aware BPs need costly execution due to the high amount of data to be transferred in the network. Toward these issues, the enterprises attempt to apply a variety of process strategies and solutions. The outsourcing of the (BPs) called business process outsourcing (BPO) is one among the relevant existing strategies that aim to save cost, speed up production, and enhance the enterprise performance. This explains the increasing number of enterprises that have adopted the outsourcing strategy using different environments.

Among the externalized environments, the cloud is considered the most adopting one. According to the National Institute of standards and Technology (NIST) [2], the cloud is defined as a pay-as-you-go model that allows on-demand network access to a set of computing resources. It is characterized by its higher storage capacity and availability [3]. Moreover, it allows the enterprises to scale their services, which are gradually done, according to customer demand. Therefore, outsourcing processes to the cloud is a reasonable choice.

Despite its advantages, the cloud is not recommended for latency-sensitive applications, such as IoT applications (e.g., health care, smart home, and smart agriculture). This is due to the high latency added by network connections to data centers [4]. Toward this issue, fog computing emerged as a new paradigm to perform latency-sensitive applications. As defined by the OpenFog Consortium (OFC) (https://www.iiconsortium.org/pdf/OpenFog_Reference_Architecture_2_09_17.pdf, accessed on 5 May 2022), fog computing extends the cloud capabilities at the edge of the network. It includes devices, located in close proximity to the end devices, which are responsible for intermediate computation and storage between IoT and the cloud [5]. In the context of outsourcing IoRT-aware BPs, the fog provides interesting external service suppliers.

During the outsourcing of an IoRT-aware BP to the fog and/or cloud environments, the business experts must address several issues to correctly choose which parts of the processes are dedicated to be outsourcing and which adequate environment should be selected. This explains why the decision-makers within the enterprises spend about 80% of their time to decide on the suitability process parts that should be outsourced and its adequate environment [6]. Consequently, to make a properly outsourcing decision, the business experts must identify a set of criteria related to the outsourcing decision of each process part.

Our extensive literature exercise revealed that most of the existing approaches deal mainly with the decision-making of traditional BPs, such as [7,8,9,10,11,12,13]. Some recent works have addressed the decision-making of the BPs that embedded only the IoT technology (e.g., [14,15,16]). More research on the outsourcing of IoRT-aware BPs, on the other hand, is required. In addition, most existing approaches use the task as a unit to make their decision, which takes more time. Additionally, the literature review shows that most current approaches use fuzzy as an MCDM method, even though their results could be better because the fuzzy method relies heavily on inaccurate inputs. Based on the studied works, we note that in most cases, the approaches do not consider methods to generate the feature weights. In fact, the automatic generation weights allow the experts and decision-makers to increase the robustness of their MCDM method results following an automatic, logical, and systematic weight calculation. Furthermore, most outsourcing solutions consider the cloud environment to externalize business activities. However, few of them propose outsourcing the process to the fog environment despite its relevance.

Therefore, to close these gaps, we propose a decision-making approach for the BPs that integrates both IoT and robots in addition to classic BPs. In our approach, we consider fog and cloud environments to take advantage of their benefits, especially for the processes that are sensitive to latency. During this work, we looked at the main parts of BPO and came up with a list of criteria that must be looked at when an IoRT-aware BP is outsourced. This identification takes into account process, fog, and cloud requirements. Furthermore, we use single entry single exit (SESE) (https://eprints.qut.edu.au/70726/7/70726.pdf, accessed on 7 May 2022), rather than the task, to accelerate the outsourcing decision. Moreover, we applied the method based on the removal effects of criteria (MEREC) to automatically generate the identified criteria weights. ELECTRE IS uses the generated weights to select the adequate environment for the process outsourcing goal.

The remainder of the paper is organized as follows: Section 2 depicts the related work. Section 3 details our approach. The implementation, assessment, and result of the proposed approach are illustrated in Section 4. Section 5 targets the validation and robustness of our proposal. Finally, Section 6 summarizes our work and highlights its future directions.

2. Related Work

In the BP context, the outsourcing of a process allows business managers to enhance the performance of their enterprises, speed, and reduce production costs. Consequently, several researchers seek to outsource the process to external suppliers. We intend, in this section, to overview some of the existing approaches that deal with the process outsourcing.

To perform the review of the existing approaches, we considered a set of relevant criteria, as they are detailed in what follows:

• Business type: Presents the type of the outsourced BP. This criterion lets us distinguish the most considered process type that is used in the outsourcing operation. A process can be a classic BP or a process that is automated via the embedding of one or more technologies, such as IoT, robots, and so forth.
• MCDM method: Designates the multi-criteria decision-making method used to achieve the process-outsourcing decision. This criterion allows us to identify the most considered method to accomplish the process-outsourcing goal.
• Granularity: Gives the processing granularity (unit) that is considered during the process outsourcing. Indeed, it can be a task, a SESE (sub-process), and so forth. The task presents the smallest unit that can be taken into account during the process of outsourcing, while the SESE presents a set of tasks.
• Externalized environment: Refers to external suppliers that are used to execute such process task/SESE fragments to allow the enterprises to gain in productivity, costs, and performance. We are interested in this work in the cloud environment that is characterized by its storage capacity and availability. Moreover, the fog environment provides relevant capabilities to execute latency-sensitive applications.
• Weight method: A MCDM aims, generally, to evaluate a set of alternatives regarding a set of criteria. This evaluation is based on weights which allow the decision-makers to express their preference in terms of the importance of criteria. This criterion refers to the methods that are used to generate the weight used for the MCDM methods.
• Used properties: Presents a set of properties that are considered to achieve the process outsourcing decision. In this work, we realized an in-depth overview of the literature to identify the most considered proprieties for the outsourcing of a BP. Therefore, we distinguished the cost, security, availability, and latency proprieties. Indeed, the cost presents an ascertainment of the cost savings of the business managers. Security is among the most prominent proprieties that may prohibit enterprises from outsourcing to an external provider. This is caused by the fact that the supplier’s service has to control outsourced activities, particularly those that deal with customers’ personal information [6]. The availability propriety designates the time for which the task/SESE needs to be executed. However, latency is among the considered proprieties that correspond to the needed time to transfer data from the source to the external environment execution via the network.

Table 1 and Table 2 classify some of the surveyed works that deal with the process outsourcing, according to the different identified criteria.

Table 1. Comparison of the studied approaches based on a set of criteria (Part 1).

Year	Paper	Externalized Environment		BP Type	MCDM Method	Weight Method
		Cloud	Fog
2019	[7]	√	-	Classic BP	-	-
2021	[8]	√	-	Classic BP	-	-
2019	[9]	√	-	Classic BP	AHP	-
2021	[14]	√	√	IoT-aware BP	-	-
2019	[15]	√	√	IoT-aware BP	-	-
2020	[16]	√	√	IoT workflow	fuzzy logic	-
2021	[17]	-	-	Classic BP	-	-
2021	[10]	-	-	Classic BP	-	-
2021	[11]	-	-	Classic BP	-	-
2021	[18]	√	-	Classic BP	-	-
2020	[19]	√	-	Classic BP	-	-
2020	[12]	√	√	Classic BP	-	-
2019	[13]	√	-	Classic BP	-	-
2021	[20]	√	-	Classic BP	-	-
2022	[21]	√	-	Classic BP	-	-
2021	[22]	-	-	-	fuzzy set	-
2021	[23]	-	-	-	fuzzy set	-
2019	[24]	-	-	-	fuzzy set	-
2022	[25]	-	-	-	fuzzy set	-
2019	[26]	-	-	-	fuzzy set	-

Table 2. Comparison of the studied approaches based on a set of criteria (Part 2).

Paper	Used Properties				Granularity
	Cost	Security	Availability	Latency
[7]	√	√	√	-	Task
[8]	√	-	-	-	Task
[9]	√	√	-	-	Task
[14]	√	√	-	-	Task
[15]	√	-	-	-	Task
[16]	-	-	-	-	-
[17]	√	-	-	-	Task
[10]	√	-	-	-	Task
[11]	√	-	-	-	Task
[18]	√	-	-	-	Task
[19]	√	-	-	-	Task
[12]	√	-	-	-	-
[13]	-	-	-	-	Task
[20]	-	-	-	-	SESE
[21]	√	-	√	-	Task
[22]	√	-	-	-	-
[23]	√	-	-	-	-
[24]	√	-	-	-	-
[25]	√	-	-	-	-
[26]	-	-	-	-	-

Back to Table 1, we note that most of the studied approaches deal with the outsourcing of the classic BP. Nonetheless, new paradigms, such as IoT and robots, seem to be relevant for automating the BP via the elimination of human intervention. For example, Refs. [14,15] propose an architecture to support the outsourcing of the IoT-aware BP. Furthermore, we notice, from Table 1, that several of the studied approaches [7,8,9,13,18,20,21] are limited to the cloud environment to ensure the outsourcing of the process. However, the cloud is not recommended for latency-sensitive applications, such as IoT applications (e.g., health care, smart home, and smart agriculture). This is due to the high latency added by network connections to data centers [4]. We also notice that there is a lack of approaches that deal with the MCDM methods, despite their ability to decide on a set of alternatives according to a set of criteria. Moreover, we notice from this table that in most cases, the approaches that deal with the MCDM methods [9,15,16] do not take into account the weight generation method to automatically generate weights.

Back to Table 2, we note that most of the existing approaches (e.g., [7,8,9,21]) outsource the BP at the task level. However, in [20], the authors target the process outsourcing via the outsourcing of a set of sub-process (SESE) fragments rather than a task. Indeed, outsourcing the BP based on its sub-processes fragments allows, on one hand, to accelerate the outsourcing operation, and on the other hand, it allows to save the process workflow between tasks.

In summary, we denote from this comparison that the studied approaches deal mainly with the outsourcing of the classic BPs. Among these approaches, there are those that are limited to the cloud environment for outsourcing BPs. Moreover, applying the outsourcing in the smallest unit, which is the task, may be costly for the outsourcing operation and it cannot preserve as much of the process workflow between tasks. Furthermore, several of the studied approaches do not consider the MCDM during the process outsourcing decision, despite its ability to evaluate a set of alternatives regarding a set of criteria. The MCDM process can support decision-making by helping to structure the problem and offering all involved actors a common language for discussing and learning about the problem [27]. It has also the potential to enhance transparency and the analytic rigor of decisions regarding other optimization methods. Otherwise, the approaches that deal with the outsourcing of the BP using the MCDM techniques do not consider methods for the automatic generation of weights for the used criteria. Indeed, the weights allow the decision-makers to express their preference in terms of the importance of criteria during the evaluation of a set of alternatives.

To close the gaps mentioned above, we propose a decision-making approach for outsourcing the IoRT-aware business process divided into a set of SESE fragments. The SESE deals with a closed block that groups one or more tasks, and it is characterized by its properties, inputs, and outputs. It guarantees the speed of the outsourcing operation and allows the business managers to preserve the process workflow within the process as much as possible. Furthermore, we seek to benefit from the fog and cloud environments to outsource these fragments if they are sensitive to latency or require high computing capacity. During our proposal, we chose ELECTRE IS as a MCDM method to achieve our goal. It is one of the widespread MCDM selection methods characterized by its ability to manage the heterogeneity of types of criteria (e.g., cost and latency). Moreover, our approach is based on the automation of the values of the weights using the MEREC method, which shows its ability, reliability, and relative effectiveness.

3. Outsourcing of IoRT-Aware Business Process

In this section, we start with the identification of a set of criteria that are useful for making the right outsourcing decision. After that, we present the used environment to accomplish the outsourcing goal. Finally, we detail the used method for the proposed outsourcing approach.

3.1. Outsourcing Criteria

Our approach allows the outsourcing of some parts of the IoRT-aware BP, either to fog and/or cloud environments as an external supplier. To decompose the process to a set of parts (sub-processes), we applied the RPST (refined process structure tree) method that divides a process to a set of fragments named single entry single exit (SESE) fragments, preserving as far as possible the workflows of the BP. To properly outsource the SESE fragments, it is useful to specify their requirements that are considered input for the outsourcing decision. In this setting, we identified a set of criteria that seem to be relevant for the BP outsourcing for both fog and cloud. In what follows, we detailed these criteria.

3.1.1. Cost

Saving cost is among the attractive factors that encouraged the enterprises to outsource their process to external providers. In [6], the authors argued that process outsourcing is guided mainly by overhead costs, where the processes are selected by ascertaining how much money they may save. In this setting, we aim to consider the cost of the SESE fragments that relies on the estimation of process task cost $Cost\left(a_i\right)$ (see Equation (4)). This latter is calculated according to its execution cost ($EC$), storage cost ($SC$), and transfer cost ($TC$) (see Equations (1)–(3)). Equation (7) estimates the cost of a SESE, which is expressed on percentage. The $spec\_cost\left(SESE\right)$ represents the business manager’s expected cost for a SESE. Indeed, $Cost1\left(SESE\right)$ presents the cost of SESE tasks that are inserted on a sequence, parallel (AND), and inclusive (OR) patterns (see Equation (5)). In fact, a sequence pattern shows the order of flow elements within the process where each element has one input and one output (https://www.omg.org/spec/BPMN/2.0/PDF, accessed on 13 June 2022). The parallel pattern is used to synchronize and create parallel flows within a process. However, the inclusive pattern presents both parallel and alternative paths within the process. These patterns directly influence the process cost estimation, where we suggest, in our proposal, to additionally calculate how much those patterns tasks cost. However, $Cost2\left(SESE\right)$ gives the cost of SESE tasks that are inserted on an exclusive (XOR) pattern. This pattern presents alternative paths within a process flow. For this pattern kind, we consider the minimum cost to estimate the SESE cost (see Equation (6)).

$$Ex\_Cost\left(a_i\right)=[EC\left(P_{a_i}\right)\times size\left(a_i\right)]\times loopMax\left(a_i\right)$$

(1)

$$St\_Cost\left(a_i\right)=[SC\left(P_{a_i}\right)\times size\left(a_i\right)]\times loopMax\left(a_i\right)$$

(2)

$$Tr\_Cost\left(a_i\right)=[TC\left(P_{a_i}\right)\times size\left(a_i\right)]\times loopMax\left(a_i\right)$$

(3)

$$Cost\left(a_i\right)=(Ex\_Cost\left(a_i\right)+St\_Cost\left(a_i\right)+Tr\_Cost\left(a_i\right)$$

(4)

$$Cost1\left(SESE\right)=\sum _{a_i\in SESE}\left(\sum _{\begin{array}{c}Pattern\{seq,\\ AND,OR\}\end{array}}Cost\left(a_i\right)\right)$$

(5)

$$Cost2\left(SESE\right)=\sum _{a_i\in SESE}(\sum _{\begin{array}{c}Pattern\left\{XOR\right\},\\ p=1\end{array}}^{p=nb\_pattern}min\left(\sum _{k=1}^{n}Cost\left(a_{ipk}\right)\right))$$

(6)

$$Cost\left(SESE\right)=\left[\right(Cost1\left(SESE\right)+Cost2\left(SESE\right))\times 100]/spec\_cost\left(SESE\right)$$

(7)

3.1.2. Security

Implies the security level which is required for a SESE to accomplish its execution. According to [6], security is among the most prominent criteria that may prohibit enterprises from outsourcing to an external provider. This is caused by the fact that the supplier’s service has to control outsourced activities, particularly those that deal with customers’ personal information. To identify the threats, we used the Cloud Security Alliance (CSA) that allows the identification of the critical security cloud threats. These threats may also concern the fog environment. To estimate the security value of a SESE fragment, we start first at the estimation of the security value for a process task $Sec\left(a_i\right)$ (see Equation (10)) that is calculated according to the number of the environment $Env$ protection $nb\_CorrectedTH$ and the number of the threats $thr$ that exist $nb\_ExistenceTH$ (see Equations (8) and (9)). Based on the $Sec\left(a_i\right)$ of tasks values that constitute a SESE, we proposed Equation (11) to estimate the SESE security value $Sec\left(SESE\right)$, which is expressed in percentage.

$$ExistenceTH(th{r}_k,a_i)⟶\{0,1\}$$

(8)

$$CorrectedTH(En{v}_j,th{r}_k)⟶\{0,1\}$$

(9)

$$Sec\left(a_i\right)=(nb\_CorrectedTH\left(a_i\right)\ast 100)/nb\_ExistenceTH\left(a_i\right)$$

(10)

$$Sec\left(SESE\right)=max(Sec\left(SESE\left(a_i\right)\right)$$

(11)

3.1.3. Availability

Relying on the time for which IoRT-aware BP tasks need to be executed (i.e, $Uptime\left(a_i\right)$) and the $Downtime\left(a_i\right)$ that implies the execution of a task. Several tasks require being available for a long period, which promotes its outsourcing to an environment that ensures a higher availability value, such as the cloud. Toward the estimation of the availability value for a SESE fragment, we start by the estimation of the task availability value $Ava\left(a_i\right)$ using its $Uptime\left(a_i\right)$ and $Downtime\left(a_i\right)$ (see Equation (12)). Then, we proposed Equation (13) to achieve the availability value for a SESE $Ava\left(SESE\right)$.

$$Ava\left(a_i\right)=[Uptime\left(a_i\right)/(Uptime\left(a_i\right)+Downtime\left(a_i\right))]\times 100$$

(12)

$$Ava\left(SESE\right)=max\left(Ava\left(SES{E}_{ai}\right)\right)$$

(13)

3.1.4. Latency

Latency corresponds to the needed time to transfer data from the source to the external environment execution, via the network. It is worthy to consider the latency as one among the IoRT-aware BP outsourcing criteria since this process is constituted by the IoT and robotic technologies that are sensitive to latency. In this work, we performed a thorough literature study, where we noticed that the latency of a task $Lty\left(a_i\right)$ is calculated using its size $size\left(a_i\right)$ and the bandwidth $\left(b\right)$ value (see Equation (14)). However, to estimate the latency value for a SESE $Lty\left(SESE\right)$, we propose Equation (17). It is based, on one hand, on the latency value for the SESE tasks that are inserted on a sequence, AND, and OR patterns (see Equation (15)), and on the other hand, on the latency value of the tasks that are inserted on a XOR pattern (see Equation (16)).

$$Lty\left(a_i\right)=size\left(a_i\right)/b$$

(14)

$$Lty1\left(SESE\right)=\sum _{\begin{array}{c}{a}_i\in SESE\\ Pattern\{seq,\\ AND,OR\}\end{array}}(Lty\left(a_i\right)\times loopMax\left(a_i\right))$$

(15)

$$Lty2\left(SESE\right)=\sum _{\begin{array}{c}{a}_i\in SESE\\ Pattern\left\{XOR\right\},\\ p=1\end{array}}^{p=nb\_pattern}min(\sum _{k=1}^{n}Lty\left(a_{ipk}\right)\times loopMax\left(a_{ipk}\right))$$

(16)

$$Lty\left(SESE\right)=\left[\right(Lty1\left(SESE\right)+Lty2\left(SESE\right))\times 100]/business\_lty\left(SESE\right)$$

(17)

3.2. Characteristics of Fog and Cloud Environments

To make an appropriate decision for the outsourcing of the IoRT-aware BP, there is a need for an in-depth analysis of fog and cloud environment characteristics. In this setting, we carried out a thorough study in the literature to determine the main features of these environments with respect to the identified criteria. According to [5], we note that the cloud environment is characterized by its highest availability thanks to its data centers. In addition, it has a low-security level and high latency due to the far distance between the end-user devices. The higher latency value can increase the transfer cost which increases the cost. The fog has a high-security level with the lowest latency value, thanks to its proximity to the end-user devices compared to the cloud. Hence, the lowest latency makes the process cost less expensive. We also noticed, in our study, that the fog has low availability value due to its dynamicity. Nonetheless, the duality of the fog and cloud environments has medium security, availability, latency, and cost values. Moreover, it is necessary to note that during the outsourcing of an IoRT-aware BP, the business managers may choose to keep the core of their process without outsourcing if the process tasks require a higher security level.

3.3. Outsourcing Decision-Making

We presented in an earlier sub-section, the main criteria for the outsourcing of the IoRT-aware BP to the fog and/or cloud environments, which are considered an input of our outsourcing decision-making approach. We present in this sub-section the adopted method to generate weights for the used criteria and for the outsourcing of decision-dmaking.

3.3.1. Automatic Generation of Weights

Multi-criteria decision-making (MCDM) is a branch of operations research (OR) that aims, generally, to evaluate a set of alternatives regarding a set of criteria. This evaluation is based on weights which allow the decision-makers to express their preference in terms of the importance of criteria. During our proposal, we aim to avail from the MCDM methods to propose a decision-making approach for the outsourcing of an IoRT-aware BP to the fog and/or cloud environments. In this setting, we use the method based on the removal effects of criteria (MEREC) to generate the weights of our identified criteria [28]. This method helps the experts and decision-makers to raise the robustness of their MCDM method results following an automatic, logical, and methodical weights calculation [28]. In addition, MEREC shows its stability, reliability, and relative effectiveness in differentiating criteria weights compared to other weight-calculation methods, such as CRITIC (criteria importance through inter-criteria correlation) [28].

3.3.2. Multi Criteria Decision Method

Our approach aims to select for each SESE the suitable execution environment. In this setting, we avail from the ELECTRE IS method to achieve our goal. It is among the widespread MCDM selection method which is characterized by its ability to manage the heterogeneity type of criteria (e.g., cost and latency) [29]. It is qualified by its ability to scale the criteria heterogeneity, where it does not require data normalization [29]. Moreover, among the attractive benefits of the ELECTRE IS, we cite its introduced thresholds, which are respectively the indifference threshold (Q), preference threshold (P), and veto threshold (V) that aim to improve the selection results regarding other selection methods. These thresholds respect the condition presented in Equation (18).

$$V\ge P\ge Q$$

(18)

ELECTRE IS is based on the concordance C between alternatives (see Equation (19)), where k presents the sum of the criteria weights and c presents the local concordance index for a criterion.

$$C(a,b)=\left\{\begin{array}{c}0,\mathrm{if}\exists |g_j\left(bj\right)-g_j\left(a_i\right)\ge V_j\hfill \\ \sum _{1\le j\le n}{k}_j{c}_j(a,b)/\sum _{1\le j\le n}{k}_j,\mathrm{otherwise}\hfill \end{array}\right.$$

(19)

4. Implementation, Experimentation and Results

In this section, we intend to implement and experiment with the proposed IoRT-aware BP outsourcing decision-making method. During the implementation of our approach, we used the Java environment to develop both the MEREC and ELECTRE IS methods. However, during the experimentation of our proposal, we used an IoRT-aware BP on the agriculture field that we developed under the eclipse modeling framework (EMF) using the BPMN 2.0 modeler plug-in which is an open-source eclipse editor [30]. In what follows, we detail our decision-making approach implementation. Afterward, we present the proposed experimentation.

4.1. Implementation

During the implementation of our decision-making approach, we start with the weights generation using the MEREC method. The MEREC method is based, initially, on a decision matrix that shows the scores of each execution environment (alternative) regarding the identified property as presented in Table 3. For the cost, security, and availability properties, we use 1, 0.8, 0.5, and 0.1 to express respectively the very high, high, medium, and low scores. Nonetheless, for the latency property, we use 1, 0.5, 0.2, and 0.1 to designate, respectively, high, medium, low, and not applied scores. To achieve the MEREC implementation goal, we used the eclipse tool, which is an open-source software development project. This implementation gives 0.22 as a weight value for the cost property, 0.22 for the security property weight. As well, we obtain 0.22 and 0.34 as weight values, respectively, for availability and latency properties (see Figure 1).

Table 3. Proposed decision matrix for MEREC method.

	Cost	Security	Availability	Latency
Cloud	1	0.1	1	1
Fog	0.5	0.8	0.5	0.2
Cloud&Fog	0.8	0.5	0.8	0.5
Local	0.1	1	0.1	0.1

Figure 1. IoRT-aware BP outsourcing interface using ELECTRE IS.

To select the suitable environment execution for a SESE that has its specific cost, security, availability, and latency values, we implemented an interface that is depicted in Figure 1 using the eclipse tool. This interface allows the users to express the SESE requirements in the intention to select its adopted environment execution.

4.2. Experimentation and Results

To better test our approach functionality, we conducted two experiments applied to an IoRT-aware BP in the agriculture field (see Figure 2). The used process presents an example of an IoRT-aware BP of a smart irrigation management system that intends to boost nutrient and water-use efficiency. Indeed, the process starts with the capture of temperature and soil moisture values using two sensors: capture temperature, and capture soil moisture. The captured values are stored using storage temperature value, and storage soil moisture value. Afterward, irrigation and grep decision-making is made through make irrigation and grep decision. In this setting, the process was finished either if there is no need for irrigation; otherwise, an irrigation request is launched called request launch irrigation, which activates an actuator to start the irrigation launch irrigation. Simultaneously, request picking weeds is launched, where it activates the robot to start the picking of weeds with launch picking weeds.

Figure 2. IoRT-aware business process on agriculture field composed by 14 SESE fragments.

Using the RPST technique, we divided the process into a set of SESE fragments, where each SESE has its own requirements in terms of cost, availability, security, and latency.

During our work, we dealt with the process presented in Figure 2, where we used it in two different scenarios that have their specific SESE property values. The first one is based on the property values that are presented in Table 4, whereas the second is based on the SESE property values detailed in Table 5. In addition, these tables give an expert outsourcing result for each SESE. The expert has high expertise that allows it to assess the outsourcing of the SESE according to its cost, security, availability, and latency values.

Table 4. Expert results for the outsourcing of each SESE according to cost, security, availability, and latency values for the first IoRT-aware BP scenario.

SESE Fragments	Properties Values	Expert Result
SESE1	Cost: 69%, Sec: 24%, Ava: 53%, Lty: 12%	Cloud&Fog, Cloud, Fog
SESE2	Cost: 55%, Sec: 21.7%, Ava: 45%, Lty: 19%	Cloud&Fog, Cloud, Fog
SESE3	Cost:32%, Sec: 18.7%, Ava: 35%, Lty: 11.8%	Cloud&Fog, Cloud, Fog
SESE4	Cost: 50%, Sec: 9%, Ava: 58%, lty: 25%	Cloud&Fog, Cloud
SESE5	Cost: 45%, Sec: 25%, Ava: 13.4%, lty: 17.99%	Cloud&Fog, Fog
SESE6	Cost: 30.2%, Sec: 13.1%, Ava: 39.8%, Lty: 14%	Cloud&Fog, Cloud, Fog
SESE7	Cost: 27.82%, Sec: 55.8%, Ava: 0.002%, Lty: 10.02%	Fog
SESE8	Cost: 71%, Sec: 10%, Ava: 72.3%, lty: 44%	Cloud
SESE9	Cost: 72%, Sec: 19.3%, Ava: 75%, lty: 31.2%	Cloud
SESE10	Cost: 21.2%, Sec: 69%, Ava: 0.009%, Lty: 12%	Fog
SESE11	Cost: 13%, Sec: 45.7%, Ava: 10.1%, Lty: 29%	Fog
SESE12	Cost: 2%, Sec: 71%, Ava: 9.9%, Lty: 0.001%	Local
SESE13	Cost: 10.01%, Sec: 52.8%, Ava: 29.8%, Lty: 29.9%	Fog
SESE14	Cost: 2%, Sec: 27%, Ava: 9.9%, Lty: 0.001%	Local

Table 5. Expert results for the outsourcing of each SESE according to cost, security, availability, and latency values for the second IoRT-aware BP scenario.

SESE Fragments	Properties Values	Expert Result
SESE1	Cost: 80%, Sec: 45%, Ava: 70%, Lty: 10%	Cloud
SESE2	Cost: 90%, Sec: 80%, Ava: 30%, Lty: 12%	Cloud
SESE3	Cost:40%, Sec: 18.6%, Ava: 33%, Lty: 10%	Cloud&Fog, Cloud, Fog
SESE4	Cost: 90%, Sec: 10%, Ava: 50%, lty: 30%	Cloud&Fog, Cloud
SESE5	Cost: 20%, Sec: 50%, Ava: 0.8%, lty: 8%	Fog
SESE6	Cost: 21%, Sec: 45%, Ava: 2%, Lty: 30%	Fog
SESE7	Cost: 54%, Sec: 25%, Ava: 17%, Lty: 15%	Cloud&Fog
SESE8	Cost: 70%, Sec: 65.8%, Ava: 80%, lty: 20 %	Cloud
SESE9	Cost: 92%, Sec: 33%, Ava: 87%, lty: 27.9%	Cloud
SESE10	Cost: 87.6%, Sec: 45%, Ava: 60%, Lty: 12%	Cloud
SESE11	Cost: 27.7%, Sec: 12%, Ava: 40%, Lty: 12%	Cloud&Fog, Cloud, Fog
SESE12	Cost: 2%, Sec: 79%, Ava: 92%, Lty: 0%	Local
SESE13	Cost: 8%, Sec: 83%, Ava: 75%, Lty: 0.1%	Local
SESE14	Cost: 12%, Sec: 55.6%, Ava: 27%, Lty: 12%	Fog

4.2.1. Experimentation 1

Our first experimentation aims to compare the effectiveness of our proposed approach regarding other selecting methods. To achieve this end, we chose to compare our method regarding ELECTRE I, ELECTRE Iv, and PROMETHEE I. ELECTRE I, applied only on numerical properties. ELECTRE Iv is presented as an improvement of ELECTRE I by adding the Veto threshold [29]. However, PROMETHEE I is based exclusively on a concordance analysis [29]. During this experimentation, we involved an expert to compare the correspondence between the approach’s results and the expert one. In this setting, we used the Jaccard measure [31], which is calculated using Equation (20).

$$(x,y)=\frac{|x\cap y|}{|x\cup y|}$$

(20)

Figure 3 displays the comparison result of our proposed method regarding other selection methods, based on the property values that are presented in Table 4. We denote from this figure that our proposed method has the closest result to the expert one, regarding ELECTRE I, ELECTRE Iv, and PROMETHEE I methods. In other words, the result generated by our method is the most similar to the expert result. This is explained, on one hand, by the use of indifference, preference, and veto thresholds that aim to improve the selection results. On other hand, our proposed approach is based on the use of an automatically generated weight method. Indeed, the use of the MEREC method to generate the properties’ weight raises the robustness of our proposed method to generate correct results.

Figure 3. Distance of our approach result compared to other approaches results and expert one (scenario 1).

Nonetheless, Figure 4 displays the comparison result of our proposed approach regarding other selection methods, based on the property values that are presented in Table 5, we notice from this figure that our approach gives the closest result to the expert one rather than the other ELECTRE I, ELECTRE Iv, and PROMETHEE I methods. Therefore, this result boosts the fact of the used thresholds and the MEREC method.

Figure 4. Distance of our approach result compared to other approaches’ and expert results (Case 2).

4.2.2. Experimentation 2

During the second evaluation, we intend to compare the results of our approach based on MEREC weights with the use of some other weight values (see Table 6). More precisely, we intend, in this experimentation, to compare our approach based on the MEREC method regarding weight values presented in cases 1, 2, and 3 ( see Table 6), where each case specifies the values of the weights for the used criteria. This comparison is based on the estimation of precision, recall, and F-score values of the first scenario (see Figure 5) and the second one (see Figure 6).

Table 6. Cost, security, availability, and latency weight values.

Properties’ Weight	Our Approach	Case 2	Case 3	Case 4
Cost weight	0.22	0.01	0.08	0.1
Security weight	0.22	0.65	0.15	0.5
Availability weight	0.22	0.13	0.4	0.3
Latency weight	0.34	0.21	0.37	0.1

Figure 5. Precision, Recall, and F-score estimation metrics based on criteria values of Table 4.

Figure 6. Precision, Recall, and F-score estimation metrics based on property values of Table 5.

Figure 5 illustrates the estimation of the precision, recall, and F-score values of our approach for the first scenario. During this scenario, we notice that the precision of our approach reaches 0.87%, and the recall is equal to 0.96%, while the F-score estimates 0.91%. However, in the second scenario (see Figure 6), our approach reaches 0.89%, 0.94%, and 0.91% as the precision, recall, and F-score values, respectively.

We denote from Figure 5 and Figure 6 that our approach based on the MEREC method has the highest precision and recall values for both scenarios. Therefore, these figures show the reliability and the relative effectiveness of our approach in differentiating properties compared to other weight values.

5. Validation and Robustness

This section is dedicated to appreciating the validation and robustness of the proposed IoRT-aware BP outsourcing approach based on the ELECTRE IS method. Therefore, to perform this goal, we choose to compare our approach regarding the outsourcing method published in [16]. In their proposal, the authors took into account a set of six criteria, which are frequency, sensitivity, freshness, time, volume, and criticality, to perform the outsourcing of a goal of a thing to the fog and cloud (see Table 7). The frequency criterion refers to the data transfer rate from the thing to fog/cloud nodes, while the sensitivity refers to the nature of data exchanged between things and fog/cloud nodes. The freshness means how important data exchanged between things and fog/cloud nodes should be recent. The time criterion represents the latency delay that results from processing data at the thing until they are transferred to fog/cloud nodes. The volume criterion refers to the amount of data that tasks produce and outsource to fog/cloud nodes. However, the criticality criterion implies how important data tasks are concerning fog/cloud nodes’ demands. In summary, the considered criteria focus on the data outsourcing from the thing to the fog and/or cloud nodes concerning different aspects (e.g., location, time, and application needs).

Table 7. Data-recipient selection criteria and interaction forms (HR: highly recommended, R: recommended, NR: not recommended, NA: not applicable) [16].

Criterion	Features	T → C	T → F	T → C/F	T → C → F	T → F → C
Frequency	Continuous stream	NR	HR	NA	NR	R
	Regular stream
	Short gaps	NR	HR	NA	NR	HR
	Long gaps	R	R	R	R	R
Sensitivity	High	NR	HR	NA	NR	HR
	low	R	R	R	R	R
Freshness	Highly important	NR	HR	NA	NR	R
	lowly important	R	R	R	R	R
Time	Real-time	NR	HR	NA	NR	HR
	Near real-time	R	HR	HR	R	HR
	Batch-processing	HR	NR	NA	R	NR
Volume	High	HR	HR	NA	NR	R
	Low	NR	HR	NA	NR	R
Criticality	Highly important	HR	HR	HR	HR	R
	Lowly important	NR	HR	NA	NR	HR

During their proposal, the authors adopted fuzzy logic as one of the MCDM techniques to select the adequate data recipient (e.g., fog only, cloud only, and fog/cloud). The authors justified their choice by the ability of fuzzy logic to handle the conflicting variables and the uncertainty degree of some criteria.

Throughout this section, we intend to compare the results of our approach based on the ELECTRE IS method to the proposal in [16]. Therefore, we applied their approach to the agriculture scenario presented above (see Figure 2), which constitutes a set of tasks. Based on their proposal, the result of the outsourcing is illustrated in Table 8. The table shows a mismatch between an expert’s expected results and the obtained ones in most cases. For instance, the task 10 approach, which has a regular stream with short gap frequency, very high sensitivity, low freshness, and real-time streaming with a very low volume and criticality, gives fog and fog/cloud as a result. At the same time, the expert estimates to keep this task locally.

Table 8. Comparison between expert’s expected results and the obtained ones for the outsourcing of an IoRT-aware BP using the approach in [16].

Fragments	Frequency	Sensitivity	Freshness	Time	Volume	Criticality	Approach Result	Expert Result
Task1	Regular stream long gaps	Medium	low	Near real time	high	high	Cloud, Fog, Fog/Cloud	Cloud, Fog/Cloud
Task2	Regular stream long gaps	Medium	low	Near real time	around medium and high	high	Cloud, Fog, Fog/Cloud	Cloud, Fog/Cloud
Task3	Regular stream long gaps	very low	very low	Real time	very high	high	Cloud, Fog, Fog/Cloud	Fog, Cloud, Fog/Cloud
Task4	Regular stream long gaps	Medium	very high	Real time	Low	Low	Fog, Fog/Cloud	Fog
Task5	Regular stream short gaps	high	Very high	Real time	High	Very low	Fog, Fog/Cloud	Cloud, Fog/Cloud
Task6	Regular stream short gaps	very low	Very low	Real time	Very low	Very high	Fog, Fog/Cloud	Fog, Cloud
Task7	Regular stream short gaps	Medium	low	Near real time	Low	Very low	Cloud, Fog, Fog/Cloud	Fog/Cloud
Task8	Regular stream short gaps	high	Medium	Real time	Low	Very low	Cloud, Fog, Fog/Cloud	Fog
Task9	Regular stream long gaps	high	Medium	Near Real time	Very high	Medium	Cloud, Fog	Fog/Cloud, Cloud
Task10	Regular stream short gaps	Very high	Low	Real time	Very low	Very low	Fog, Fog/Cloud	Local
Task11	Regular stream short gaps	high	High	Near Real time	Very low	Medium	Fog, Fog/Cloud	Local, Fog
Task12	Regular stream long gaps	Medium	High	Real time	Medium	Low	Fog, Fog/Cloud	Fog

To perform the comparison goal, we estimated the precision, recall, and F-score values using the details presented in Table 8 and the IoRT-aware BP scenario details presented in Table 4. The precision is the percentage of correctly classified predictive positive task samples. The recall refers to the rate of positive task samples that are correctly classified, while the F-score presents a measure that combines precision and recall [32].

During this evaluation, we notice that the precision value reaches 0.75%, and the recall is equal to 0.51%, while the F-score estimates 0.60% (see Table 9). Therefore, we deduce from this comparison that our proposal is more robust and relatively effective compared to their approach. The precision value of our approach reaches 0.87%, the recall is estimated to be 0.96%, and the F-score is equal to 0.91% (see Figure 5). The disparity obtained at the precision, recall, and F-score values can be explained by the set of the considered criteria for each approach, where the approach published in [16], focused on the data exchange and did not consider the cost and security requirements of fog/cloud nodes.

Table 9. Precision, recall, and F-score estimated values for the tasks of the first IoRT-aware BP scenario using the approach in [16].

Fragments	Precision	Recall	F-Score
Task1	1	0.66	0.79
Task2	1	0.66	0.79
Task3	1	1	1
Task4	1	0.5	0.66
Task5	0.5	0.5	0.66
Task6	0.5	0.5	0.5
Task7	1	0.5	0.66
Task8	1	0.33	0.49
Task9	0.5	0.5	0.5
Task10	0	0	0
Task11	0.5	0.5	0.5
Task12	1	0.5	0.66
Whole IoRT-aware BP	0.75	0.51	0.60

On the other hand, we are aware that our proposal has some flaws that should be fixed in future work. Our proposal needs to consider the human side involved in the administration and commitment processes. Each business depends mainly on the knowledge of its staff. Its employees’ capacity to meet its needs and accomplish its strategic goals determines whether the company succeeds or fails. Moreover, our proposed outsourcing approach is limited to design time execution. However, a business process is likely to be modified at runtime due to the dynamicity of IoT and robot devices. Therefore, it seems to be relevant to consider the scheduling of the process outsourcing. Indeed, the scheduling consists of planning the process outsourcing to allow the business managers to achieve their goals whenever the fog/cloud is available.

6. Conclusions

The outsourcing of an IoRT-aware BP to the fog and/or cloud environments presents several advantages to the enterprises, as it allows them to save their cost, and focus on their core competence. It consists of deploying partially or totally the process in an external execution environment. Despite these advantages, the outsourcing of an IoRT-aware BP is not a trivial task. Therefore, there is a crucial need in the decision-making outsourcing to determine which part of the process should be outsourced and which environment would be selected to deploy it. Toward these objectives, we identified in this paper a set of criteria for the IoRT-aware BP outsourcing in fog and/or cloud environments. In addition, we used the ELECTRE IS method based on the MEREC method for the weight generation to select the suitable environment for each SESE.

We also aim to propose a framework to take into account the human side involved in the administration and commitment process for the outsourcing decision of a BP. Moreover, we seek, in the future, to enhance our proposal by scheduling the process outsourcing to consider the dynamic changes of the IoT and/or robot devices, thereby allowing the business managers to achieve their goals in time.