-Most complex Business Processes (BPs) these days are enacted in a social and organizational context, where technical components along with social actors as well as their dependencies and interactions are integral parts of the BP. Despite this, most available BP approaches either simply ignore the social and organizational aspects of the BP, or they superficially consider them neglecting core aspects such as social trust and dependency. This leaves a BP subject to different kinds of social and organizational vulnerabilities that might impact or even abort the BP enactment. Therefore, capturing the social and organizational context of the BP is essential to detect and address such vulnerabilities. To tackle this problem, we propose an approach for designing SocioTechnical BPs (STBPs) that can be used for modeling the BP of concern as well as its social and organizational context. The proposed approach relies on a goal-based approach for capturing the social and organizational context of the BP, and on a workflow approach for capturing the control-flow among its activities. Index Terms-Socio-Technical Business Process, BP, WF-nets, Goal Model, Requirements engineering.
I. INTRODUCTION
Similar to current Socio-Technical Systems (STS), most
complex BPs these days are executed in a social and
organizational context, where technical components and social actors
(humans), as well as their social dependencies and interactions
should be considered integral parts of such BP [
Two main research tracks might tackle this problem:
1- Social Business Process Management (SBPM) [
A main advantage of goal-based approaches is their ability
for capturing the rationale behind a system-to-be/BP.
Moreover, they have been proposed as a potential solution for
integrating social actors along with their needs within a BP,
which can enhance/improve the correctness, completeness, and
usefulness of the BP model [
On the other hand, we have several BP approaches (e.g.,
Petri nets, WF-nets) that offer concrete semantics for capturing
the control-flow among activities of a BP, but offer no
semantics for capturing the social and organizational context where
BPs are enacted. To this end, an approach for designing
SocioTechnical BP (STBP) can be developed depending on a
goalbased approach for capturing the social and organizational
context of the BP, then, on a Workflow approach for capturing
the control-flow among the activities of the resulting goal
model (i.e., leaf goals). The proposed approach is inspired by
an earlier work that proposed a framework, namely
Workflownet with Actors (WFA-net), which integrates the concept of
social actor and its Information Quality (IQ) requirements into
a BP design [
The rest of this paper is organized as follows; Section II discusses the baseline for designing STBPs. In Section III, we present our approach for designing STBPs, and we illustrate its utility by applying it to create a STBP abstracted from the medical domain in Section IV. Section V discusses findings and lessons learned, and we conclude the paper in section VI.
As mentioned in the previous section, the STBP should be
able to capture the control-flow of the BP of concern and the
social and organizational context where it is enacted.
Therefore, the main existing BP approaches have been surveyed to
identify the best BP language that can be adopted to develop
a STBP that satisfies the previously mentioned requirements.
Although there exist plenty of BP modeling languages in the
literature, they can be broadly classified into four main classes:
Activity-driven approaches [
These approaches can model how, what, and when activities of a BP are required, yet none of them can adequately capture the social and organizational context of a BP, which can be solved by adopting a goal-based approach. However, as previously mentioned, exiting goal-based approaches cannot appropriately capture the control-flow among their goals. Therefore, we adopted an activity-oriented approach to tackle this problem as such approaches propose concrete semantics for capturing a control flow among the activities of a BP. More specifically, the approach is built by adopting a goal-based approach for capturing the social and organizational context of the STBP, and an activity-oriented approach for capturing the control flow among the leaf goals of the resulting model. In the following section, we describe how the approach can be used for designing a STBP.
The process underlining the approach for designing a STBP (shown in Figure 1) consists of four main phases: 1- eliciting stakeholder’ requirements; 2- capturing the social and organizational context of the STBP by modeling the stakeholders’ requirements in their social and organizational context relying on a goal-based modeling approach; 3- capturing the controlflow of the desired STBP that starts by extending the semantics of WFA-net to accommodate social actors and their requirements, which have been identified in the previous phase. Then, maps leaf goals of the goal-based model into activities of the WFA-net to represent the STBP of interest. 4- analyzing and verifying the correctness of the resulting STBP. Each of these phases is described in the rest of this section:
1. Eliciting stakeholder’ requirements aims at discovering, acquiring, and analyzing the requirements of the stakeholders by adopting at least one of the existing elicitation techniques (e.g., interviews, questionnaires, task analysis, scenarios, prototyping, etc.). This phase is very important to understand whether existing goal-based approaches can be used to model the stakeholders’ requirements or they need to be extended with new specialized constructs for capturing such requirements. More specifically, numerous goal-based modeling languages have been proposed for capturing various kinds of requirements (e.g., security, privacy, safety, etc.). If none of them can capture the stakeholders’ requirements, the closest language can be adopted and extended to appropriately capture the stakeholders’ requirements of concern.
2. Capturing the social and organizational context of the STBP. After adopting an existing goal-based approach or extending one, we use it to model the stakeholders’ requirements in their social and organizational context. To simplify the presentation of the approach, we adopt a goal-based modeling language that offers the essential modeling construct.
Figure 2 shows a partial diagram of a patient treatment process scenario represented with a generic goal-based modeling language. The language propose primitives for modeling actors of the system in terms of agents (e.g., Dr. Mary) and roles (e.g., Patient, Physician) they are playing. Goals represent actors’ strategic interests (e.g., G1. “Treat illness”), and they can be refined through and/or-decomposition into finer sub-goals (e.g., G1. is refined through or-decomposition into G1.1 and G1.2). Refining a root-goal into sub-goals through and-decomposition implies that all sub-goals need to be achieved to achieve the parent goal. While refining them through or-decomposition implies achieving any of them is enough to achieve the parent goal.
Goals1 can produce and/or consume information/resource.
For example, G1.1.1 produces “Appointment request”, and G1.1.2 need to consume “Appointment confirmation”. Dependency allows actors to depend on one another for the fulfillment of goals (e.g., the patient depends on Dr. Mary for G1.1.3 achievement), and provision models information/resource transmission between actors (e.g., the Receptionist provides the patient with “Appointment confirmation”). Finally, trust/distrust captures the actors’ expectations in one another regarding their delegated entitlements and authorities. For example, the patient trusts Dr. Mary for the achievement of the delegated goal G1.1.3.
Most goal-based approaches (e.g., i* [
3. Capturing the control-flow of the desired STBP. We start by discussing how the semantics of WFA-net can be defined/extended to integrate social actors and their requirements, which have been identified in the previous phase. Then, we discuss mechanisms for identifying building blocks (S3.1) that we use for mapping leaf goals of the goal-based model into activities of WFA-net to represent desired STBP (S3.2). Workflow net with Actors (WFA-net)2. The semantics of the activities of the WFA-net should be designed in a way that reflects the semantics of a goal of the adopted/developed goalbased model. In this paper, a goal needs an actor to achieve it, and may produce and/or consume information/resources. Therefore, an activity T of a WFA-net (shown in Figure 1Several recent i* based approaches and in order to simplify their modeling languages have omitted the used of the task construct since leaf goals are fine enough to be operationalized.
2WFA-net has been originally developed by extending the semantics of WF-net to integrate social actors and their IQ requirements, yet its semantics can be modified to consider any kind of requirements D
T 1. Eliciting stockholders' requirements Extend the goalbased-ml if needed 2. Capturing the social and organizational context of the STBP 2.1. Actor modeling 2.2. Goal modeling 2.3. Info/resource modeling 2.4. Dependency modeling 2.5. Trust modeling yes no
needs refinement? 3) is described by an actor that is responsible (res) for its achievement, and may include sets of information/resources that the activity produces (prd) and/or consumes (con).
The WFA-net configuration can be defined to capture the control-flow, which consists of a marking and an activity state that can be evaluated either to true (>) or false (?). An activity of a WFA-net might be enabled at a configuration iff the activity is enabled at a marking (activity flow), and the activity state is evaluated to true (>), which means that the requirements are achieved, i.e., the corresponding leaf goal in the goal-based model is achieved. More specifically, the responsible actor has the capability to achieve the activity/goal, has all the information/resources required by the activity, and is trusted for achieving the activity in case such activity is delegated to him. If all of these conditions hold, the activity state is evaluated to true (>), otherwise, it is evaluated to false (?). Concerning T2: Receive treatment in hospital in Figure 3, if the medical specialist (i.e., the responsible (res) actor) cannot achieve the activity/goal, she/he is not trusted for achieving it, or the patient’s medical records were not provided to her/him, the state of T2 will be evaluated to false (?), otherwise, it will be evaluated to true (>).
When an activity is enabled, it may fire and its firing may enable a set of successor configurations. In addition, the S
T1: Request appointment res: patient prd: appointment request
P1
T3: Secure appointment res: patient con: appointment confirmation T2: Receive treatment in hospital res: a medical specialist con: patient’s medical records
P2 P3 P4
P9
E Legend S start position E end position
ID: Activity_Name a position res: actor
prd: info/resource arc con: info/resource Fig. 2. A partial goal model concerning a patient treatment process Fig. 3. A partial WFA-net concerning a patient treatment process reachability property for WFA-net has been defined to check whether some configuration (e.g., c0 ) can be reached from another one (e.g., c). Finally, the soundness property for WFAnet can be defined to verify whether the final configuration of a WFA-net is reachable from any configuration.
Mapping goal-based model into WFA-net. The rules and constraints that can be used to guarantee a correct mapping of goal-based models into WFA-net are described as follows:
Building blocks (shown in Figure 4 - right ) are used to identify constructs of the goal-based model that can be mapped into activities of WFA-net. The main idea of identifying building blocks is guaranteeing that no key organizational nor social aspects will be lost during the mapping process. Three rules for identifying building blocks have been defined: (1) A goal that is not and/or-decomposed of or into any other goal is considered as a building block that can be mapped into an activity of WFA-net. (2) A goal that is and-decomposed is considered as a building block in terms of all its subgoals, which are mapped into sequencing activities. Mapping these sub-goals into sequencing activities is derived from the semantics of the and-decomposition relationship, and mapping them into sequencing activities of WFA-net implies that all of them should be achieved. (3) A goal that is or-decomposed is considered as a building block in terms of its all subgoals, which are mapped into parallel activities of the WFAnet. Similarly, the mapping of the or-decomposed sub-goals into parallel activities is derived from the semantics of ordecomposition relationship, which implies that it is enough to achieve any one of these parallel activities in the WFA-net.
Consistency constraints are used to assure a correct mapping between building blocks and activities of WFA-net. Three consistency constraints have been defined: (1) No goal is allowed to be mapped unless it can be considered as a complete building block. (2) Mapping is allowed for leaf goals only, i.e., root-goals are only mapped in terms of their sub-goals. (3) No information/resource is allowed in the WFA-net unless the goal that produces it, is already represented in the WFAnet. This enables for analyzing the provenance/availability of information/resource to the consuming activity.
Sequencing constraints are used to assure an appropriate ordering of the activities of WFA-net. Two sequencing constraints have been defined to guarantee that: (1) Activities of WFA-net should be consistent with their sequencing order in their building blocks, and (2) If an activity depends on the outcome of another one, it should appear after the latter.
Refinement constraints are used to guarantee a correct sequencing of the activities and places of a WFA-net. Two refinement constraints have been defined: (1) No two consequent places can exist in WFA-net without an activity separating them, and (2) No two consequent activities can exist in a WFA-net without a place separating them.
4. Analyzing and verifying the correctness of the resulting STBP. After mapping leaf-goals of the goal model into activities of the WFA-net, we will have the STBP we desire. However, we cannot rely only on the model to perform any kind of analysis without a formal representation of its semantics. Therefore, a formal framework that offers a formalization of the modeling concepts needs to be developed. Such framework can be built based on a formal language (e.g., Disjunctive Datalog), and should enable for transforming all constructs of the graphical model (e.g., actor, goal, activities, etc.) into their corresponding formal predicates. This allows for deducing new knowledge (facts) from the predicates based on already defined reasoning axioms (rules), and for performing the required analysis to verify the WFA-net model. In particular, a set of properties of the design can be defined to specify constraints that all of them should hold to consider the model correct and consistent.
Such properties can be mainly derived from the semantics of the goal-based model for analyzing the social and organizational context of STBP, and from the semantics of the WFAnet for analyzing the control-flow and information/resourceflow of the STBP. For example, we can define properties to verify a correct mapping of the STBP activities such as only leaf goals are allowed to be mapped, the Start and End positions of the STBP are connected with at least one activity, the End position of the STBP can be/is reached, etc. We can also define properties to verify whether an activity consumes all information/resource it requires, i.e., the actor who is responsible for achieving such activity have access to the required information/resource(s). Moreover, we can define properties to verify whether the responsible actor can achieve the activity/goal, or if the responsible actor is trusted for achieving the activity, in case there is a dependency for such activity/goal, etc. Additionally, we can define a property to verify whether an activity is not prevented from being fired. IV. ILLUSTRATING THE APPLICABILITY OF THE PROPOSED
APPROACH
In this section, we illustrate the utility of the proposed approach by applying it to create an STBP concerning a patient treatment process. Following the process underlying our approach (shown in Figure 1), we start with eliciting stakeholder’ requirements phase. For our simple scenario, the patient only needs to treat his illness, which can be done either by visiting his physician’s office or going to the hospital. If he wants to visit the physician’s office, he needs to contact the receptionist to get an appointment. On the other hand, the receptionist needs to check physicians’ availability and manage medical visits. Finally, physicians aim at treating their patients.
During the second phase of the approach, the social and organizational context of the STBP need to be captured, which can be done relying on a goal-based modeling language. A partial goal model representing the patient treatment process is shown in Figure 4. In which, we can identify Jack that plays a Patient role, and aims for G1. Treat illness, which is refined through or-decomposition into G1.1 Receive medical treatment in doctor office and G1.2 Receive medical treatment in hospital. G1.1 is further refined through and-decomposition into G1.1.1
G1.1 Receive medical treatment in doctor office and
G1. Treat illness or
G1.2 Receive medical treatment in hospital
Jack Request medical appointment, G1.1.2 Secure medical appointment, and G1.1.3 Analyze health situation3. Moreover, G1.1.1 produces Appointment request, and G1.1.2 needs to consume Appointment confirmation.
Lara plays a Receptionist role, and aims at G2. Manage appointments that needs to consume Appointment request that should be provided by Jack. G2. produces Appointment confirmation, which should be provided to Jack. G1.1.3 is delegated by Jack to Lara, who in turn, need to delegate it to a physician. Lara delegated G1.1.3 to Dr. Bob. Finally, Jack trusts Dr. Mary and distrusts Dr. Bob concerning his medical analysis.
The third phase of the approach starts when the goal model 3due to space limitation, we do not refine G1.2 does not need refinement anymore. Since the adopted goal model does need to be extended as it captures all the properties we need in our scenario, we can start identifying building blocks that can be mapped into the STBP. G1. and its subgoals can be considered as a building block. Also, G2. can be considered as a building block since it is not and/ordecomposed of or into any other goal. G1. can be captured by modeling all of its subgoals, namely G1.1 and G1.2. Since these two goals are or-decomposed from G1., they should be mapped into two parallel activities when mapped into the STBP. Similarly, G1.1 can be captured by modeling all of its subgoals, and as they are and-decomposed from G1.1, they should be mapped into parallel activities when mapped into the STBP.
Considering the third consistency constraint, we need to map G.2 into an activity of the STBP as G1.1.2 consume information produced by G.2. Moreover, the sequencing constraints require us to map G.2 into an activity that appears before the activity representing G1.1.2. For the same reason, G1.1.1 should appear before G.2 in the STBP as the last consumes information produced by the first. After considering the refinement constraints, we will have the STBP shown in Figure 4, where G1.2, G1.1.1, G2, G1.1.2, and G1.1.3 are mapped into T1, T2, T3, T4 and T5 respectively.
After mapping the leaf-goals of the goal model into activities of the desired STBP, we can analyze and verify the correctness of such STBP. However, the analysis will detect that the current STBP will be prevented from reaching its end position as T5 will be prevented from firing as Dr. Bob is not trusted by Jack to achieve G1.1.3. Accordingly, the state of T5 will be evaluated to false (?). This situation can be corrected by either delegating G1.1.3 from Lara to Dr. Mary, or delegating it from Dr. Bob to Dr. Mary. This will change the responsible actor of this goal/task from Dr. Bob to Dr. Mary, which is trusted by Jack. Thus, T5 will fire and the end position can be reached. These modifications are marked with dotted lines in Figure 4.
While developing this approach, several challenges have been faced. The main challenges are summarized along with findings and lessons learned as follows:
Modeling the STBP. 1- Adopting an i* based language
[
Adopting two layers of abstraction. Capturing the social and organizational context of the STBP, and the control flow among its activities at two different levels of abstraction offers several advantages: 1- modeling and verifying the goal-based model allows for detecting and resolving any vulnerability at the social and organizational level before modeling the desired STBP; 2- relying on a verified goal model, one can model and analyze almost any STBP without influencing the base goal model; 3- most of the properties of the design can be derived either from the semantics of the goal-based model or the WFA-net model. For example, most of the properties for the satisfaction of requirements can be derived from the goal-based model semantics, while most of the properties for the control and information/resource flow can be derived from the WFAnet semantics; and 4- allows for extending the goal-based modeling language to accommodate almost any type of requirements. Then, easily reflecting such extensions into the WFA-net.
We introduced an approach for designing Socio-Technical
BPs (STBPs) that relies on a goal-based approach for capturing
the social and organizational context of the STBP, and on a
workflow approach for capturing the control-flow among its
activities. The approach is inspired by earlier work
(WFAnet [
The authors would like to thank Prof. Kuldar Taveter for his comments, useful feedback and discussions. The research reported in this publication has been funded by the IT Academy program of the European Social Fund.