Impact of Business Process Masking on Organizations’ Policies
Zakaria Maamar
1 a
, Amel Benna
2 b
, Hirad Rezaei
3 c
, Amin Beheshti
4 d
and Fethi Rabhi
3 e
1
University of Doha for Science and Technology, Doha, Qatar
2
Research Center for Scientific & Technical Information Algiers, Algeria
3
University of New South Wales, Sydney, Australia
4
Macquarie University, Sydney, Australia
Keywords:
Business Process, Masking, ODRL, Partnership, Policy.
Abstract:
To preserve their competitiveness, organizations that engage in partnership have the opportunity of masking
their business processes without undermining this partnership’s progress. Aggregation and abstraction corre-
spond to masking where the former groups activities together giving the impression of a limited number of
activities in a business process, and the latter makes some activities invisible since they are deemed not rel-
evant for partnership. Besides masking, organizations adopt policies to define permissions, prohibitions, and
obligations on business processes at run-time. This paper examines the impact of business process masking on
policies with focus on adjusting, dropping, and developing policies in Open Digital Rights Language (ODRL).
A system demonstrating this impact is also presented in the paper.
1 INTRODUCTION
In the literature, it is largely reported that organiza-
tions’ main assets are Business Processes (BPs). Ac-
cording to the activity-centric school for BP design, a
BP has a process model that consists of activities and
dependencies that connect these activities together.
Along with BPs, organizations define policies to guide
the completion of these BPs and comply with applica-
tion domains’ regulations. According to Weimer and
Vining, policies set principles, goals, and desired out-
comes for organizations (Weimer and Vining, 2017).
Besides dependencies that control the execution
progress of activities as prescribed in a process model,
BP designers could set additional controls on activi-
ties to define what is permitted to exercise on them
(e.g., execute twice a day), what must be exercised on
them (e.g., execute in return of payment), and what
cannot be exercised on them (e.g., execute after 5pm)
prior to instantiating their respective process models
at run-time. To package additional controls on ac-
tivities into policies, we resort to the Open Digital
Rights Language (ODRL, (W3C, 2018)) offering a
fine grained tracking in terms of who owns and ap-
a
https://orcid.org/0000-0003-4462-8337
b
https://orcid.org/0000-0002-9076-5001
c
https://orcid.org/0000-0002-8638-0280
d
https://orcid.org/2222-3333-4444-5555
e
https://orcid.org/0000-0002-5988-5494
proves to execute activities, for whom, for how much,
and for how long, how many activities must be ex-
ecuted in a period of time, what prohibits from ex-
ecuting activities, to cite just some. Briefly, ODRL
expresses that “something is permitted, forbidden, or
obliged, possibly limited by some constraints” (W3C,
2018). Although ODRL is meant for the digital-
content industry, we handle BPs’ activities as assets
in compliance with ODRL terminology.
Due to the sensitive nature of BPs being a
know how, organizations that engage in partnership
(e.g., Daiichi Sankyo and AstraZeneca in the biophar-
maceutical industry in 2020) adopt 2 techniques to
mask their BPs and hence, preserve their competi-
tiveness, for example (Kallel et al., 2021): aggrega-
tion technique groups activities together giving exter-
nal partners the impression of a limited number of
activities in a BP, and abstraction technique makes
some activities in a BP invisible to external partners
since these activities are deemed not relevant for part-
nership and/or are intended to be hidden to mitigate
privacy concern. In either technique, a BP’s process
model is adjusted impacting the existing policies that
control either the aggregated or the abstracted activ-
ities. This adjustment means that for instance, some
new policies will be defined (maybe on the fly), some
existing policies will be either dropped or merged,
cross-policy consistency will be checked out, etc. In-
deed, organizations set policies independently of any
plan of partnership in mind. In this paper, we exam-
Maamar, Z., Benna, A., Rezaei, H., Beheshti, A. and Rabhi, F.
Impact of Business Process Masking on Organizations’ Policies.
DOI: 10.5220/0013170700003928
In Proceedings of the 20th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2025), pages 359-366
ISBN: 978-989-758-742-9; ISSN: 2184-4895
Copyright © 2025 by Paper published under CC license (CC BY-NC-ND 4.0)
359

ine the impact of masking BPs on partnering organi-
zations’ policies. ODRL constructs like asset, policy,
and rule are deemed relevant for managing masked
activities, cascading masking impacts to policies, and
checking the consistency of impacted policies.
In Section 2, we discuss existing works and then
define ODRL and a case study. In Section 3, we
present the impact of BP masking on policies and
demonstrate this impact. Finally, in Section 4, we
conclude the paper and present future work.
2 BACKGROUND
This section is about related work on masking and
also briefly presents ODRL and a case study.
2.1 Related Work
In (Chika Eleonu, 2021), Chika Eleonu presents Ag-
gregate Metric Model (AMM) framework to evalu-
ate a corpus of BPs represented in different modeling
approaches. These approaches adopt the principle of
separation of concerns of models, make use of refer-
ence or base model for a family of BP variants, and
promote the reuse of model elements. Although the
author’s framework is not perfectly in-line with BPs
masking, selecting a modeling approach that handles
aggregation and/or abstraction could help “minimize”
the impact of this masking on existing policies.
In (Han et al., 2017), Han et al. advocate for task
abstraction and aggregation as a means for first, ob-
taining customized descriptions of a BP for different
users and second, deriving user interfaces of a BP re-
lated to participating users. In line with Section 1, pri-
vacy, confidentiality, and conflict of interest are some
of the reasons for abstracting and aggregating tasks.
In (Kallel et al., 2021), Kallal et al. examine the
impact of temporal constraint satisfaction on inter-
organizational BPs where these BPs would have been
subject to abstraction and/or aggregation. This impact
meant generating time-constrained views, analyzing
temporal consistency of these views, and addressing
any inconsistency violating temporal constraints.
In (Kammerer et al., 2022), Kammerer et al.
present Process Query Language (PQL) in the context
of Process-Aware Information Systems (PAISs). The
authors note that PAISs have become critical to many
organizations wishing to increase maintainability and
reduce costs of changes by separating process logic
from application code. PQL permits to create, query,
and update process models in a large size process
repositories enabling personalized views over these
models thanks to abstraction and aggregation tech-
niques. Kammerer et al. mention managers who pre-
fer an abstracted BP while process participants prefer
a detailed view of the process parts.
In (Reijers et al., 2009), Reijers et al. address the
high-number concern of process models that organi-
zations end-up managing over time along with how
to disclose them to a mixed audience of stakeholders
such as end-users and auditors. A potential approach
is process-model aggregation that takes advantage of
these models’ common constructs such as tasks and
decision controls. An aggregate model will, on top
of unique constructs, combine both models into one,
where the common constructs are considered only
once. As a result of applying aggregate models, fewer
process will be maintained and updates to common
constructs will only need to be performed once. Run-
ning queries over aggregated process models to ex-
tract common and/or unique constructs is also part of
Reijers et al.’s approach.
Contrasting the originality of our work to those
above, it is clear that none examines the impact of
BPs masking on policies controlling BPs in terms of
who owns and approves initiating them, for whom,
for how much, and for how long, how many must be
initiated in a period of time, what prohibits from initi-
ating them, etc. The works above acknowledge mask-
ing’ benefits to make complex process models easy to
maintain, but little is given about revisiting existing
policies and even developing new ones.
2.2 ODRL
ODRL provides a flexible and interoperable informa-
tion model, vocabulary, and encoding mechanisms to
specify how to control using assets. An asset is an
identifiable resource or a collection of resources such
as data/information, content/media, applications, and
services. ODRL policies refer to what is permitted,
prohibited, and obliged actions that stakeholders can,
cannot, and should exercise over assets, respectively.
2.3 Case Study
Our case study builds upon the work of Kallal et al.
who examined temporal consistency of inter-
organizational BPs (Kallel et al., 2021). When
a customer orders online, the seller Amazon, the
shipper FedEx, and the financial institution BankX
have their respective BPs intertwined/synchronized
exchanging messages according to items ordered,
delivery dates chosen, payment types selected, etc.
Fig. 1 captures this intertwine with emphasis on
activities that partners carry out and may not be
willing to let others know about them. For instance,
ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering
360

Figure 1: BPMN-based Amazon on-line shopping (Kallel et al., 2021).
compute price remains private offering Amazon a
competitive advantage despite the partnership with
FedEx and BankX.
In addition to BPs’ process models, Amazon,
FedEx, and BankX develop policies to control some
activities for various reasons such as budgetary, pri-
vacy, and ownership. For instance, ship products must
be executed by a level-3 staff, send bill is permitted
once every 2h during high-seasons, and make pay-
ment is prohibited from any delay upon item deliv-
ery. Before engaging in any partnership, Amazon,
FedEx, and BankX have the opportunity of masking
particular activities using aggregation and/or abstrac-
tion. This could result in defining new policies, drop-
ping some existing ones, combining existing ones as
well, etc. For instance, receive bill and make payment
are aggregated into a new activity calling for devel-
oping a new policy for this new activity and setting
new dependencies for this new activity with existing
pre- and post-conditions. And, send shipment details
is abstracted calling for revisiting its pre- and post-
dependent activities including probably their respec-
tive policies.
3 MASKING AND POLICIES
This section consists of 4 parts. The first part defines
masking. The second and third parts apply masking to
BPs. Finally, the fourth part implements the masking.
3.1 Foundations
Fig. 2 is about the respective outcomes of applying
abstraction and aggregation masking techniques to a
BP. A BP consists of activities, A
1,···,i, j
, and depen-
dencies between activities, {D
i, j
(A
i
,A
j
)}. We asso-
ciate each activity with an activity policy, AP
1,···,i, j
,
and each dependency with a dependency policy,
DP
i, j
(AP
i
,AP
j
), that captures case study-driven in-
teractions between A
i
/AP
i
and A
j
/AP
j
.
On the one hand, abstraction “hides” for instance,
A
i
/AP
i
in the BP raising questions about the impact
of this hiding on between {AP
i−1
} and AP
i
and be-
tween AP
i
and {AP
i+1
} based on dependencies ini-
tially associated with DP
{i−1},i
(AP
{i−1}
,AP
i
) and
DP
i,{i+1}
(AP
i
,AP
{i+1}
), respectively.
On the other hand, aggregation combines for in-
stance, A
i
/AP
i
and A
j
/AP
j
into A
i j
/AP
i j
in the
BP raising questions about this combination’s im-
pact on between {AP
i−1
} and AP
i j
and between
AP
i j
and {AP
j+1
} based on dependencies ini-
tially associated with DP
{i−1},i
(AP
{i−1}
,AP
i
) and
DP
j,{ j+1}
(AP
j
,AP
{ j+1}
), respectively. During ag-
gregation, it is deemed necessary to work out the de-
tails of A
i j
, AP
i j
, DP
{i−1},i j
(AP
{i−1}
,AP
i j
), and
DP
i j,{ j+1}
(AP
i j
,AP
{ j+1}
).
Let us define AP s and DP s. First, AP defini-
tion in terms of necessary ODRL constructs depends
on the case study’s requirements with focus on (i) the
construct asset that corresponds to an activity’s name
and (ii) the construct constraint that both corresponds
to a case study’s requirements and drives the imple-
mentation of the masking techniques. In ODRL, con-
straint (though optional) could be applied to 2 con-
structs namely, rule and action. When a constraint on
a triggered rule in an AP is satisfied, we declare the
successful completion of the rule and the AP .
Second, DP definition in terms of necessary
ODRL constructs depends on the types of dependen-
cies between activities in a BP’s process model. In the
literature, there exist several dependency types such
as those used to compose services namely, sequence,
choice, parallelism, and synchronization (Daoud
Impact of Business Process Masking on Organizations’ Policies
361

Abstracted business process
DP 
1,ij
A 
ij
Aggregated business process
Business process
DP 
i,j
DP 
1,j
A 
i
AP 
i
Masking
A 
1
AP 
1
A 
1
AP 
1
A 
j
AP 
j
A 
j
AP 
j
A 
1
AP 
1
A 
i
AP 
i
A 
j
AP 
j
AP 
ij
Legend
AP: activity policy
DP: dependency policy
Figure 2: Masking applied to a business process.
et al., 2021). Based on our previous work (Maamar
et al., 2022), we adopt service composition-based de-
pendency types and represent their respective DP s
in 2 stages. In the first stage, we define a DP rule-
composition DP
i, j
(AP
i
,AP
j
) to identify its assets,
AP
i
and AP
j
(Listing 1), and then, define additional
DP s (Listings 2 and 5), one per dependency type, that
inherit from the DP rule-composition.
Listing 1: Dependency policy rule-composition.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " @t ype ": " Se t ",
3 " uid " : " http : / /. ../ DP i_j : 0 1" ,
4 " p ermission ": [{
5 " uid " : " http : / /. ../ DP i_j rul e - comp ",
6 " ta rg et " :[ " ht tp : / /.../ DP / APi " ,
7 " ht tp : //.. ./ DP / AP j "] ,
8 " ac ti on " : " use"}]}
To illustrate, we present sequence- and choice-
based dependency policies, DP
seq
i, j
(AP
i
,AP
j
) and
DP
cho
i, j
(AP
i
,AP
j
), respectively. The former depen-
dency type, DP
seq
i, j
(AP
i
,AP
j
), means that rule
i
in
AP
i
and rule
j
in AP
j
should be triggered sequen-
tially, i.e., trigger(rule
i
≺ rule
j
). Based on some
ODRL constructs, we achieve rule sequencing as fol-
lows (Listing 2):
1. Make DP
seq
i, j
(AP
i
,AP
j
) inherit from
DP
i, j
(AP
i
,AP
j
) using inheritFrom (line 4).
2. Define a rule R (line 5) having Rulei jDP
i, j
as a uid (line 6), permission-with-duty as a
type (lines 5 and 9), and rule
j
as an asset (line 7).
3. Include the action trigger in R to exercise over
rule
j
(line 8).
4. Define the property duty in R , so the successful
completion of rule
i
can be declared. To this end,
include the action nextPolicy, the uid of AP
i
, and
the constraint event in this property (lines 13-15).
The constraint event specifies the triggering order
of rules, so that triggering rule
j
happens after suc-
cessfully completing rule
i
.
Listing 2: Sequence-based dependency policy.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " uid " : " http : / /. ../ Se qD Pij :0 2",
3 " ty pe " : " Agr ee me nt " ,
4 " i nh er it Fr om " : " ht tp : / /.../ DPi_j : 0 1" ,
5 " p ermission ": [{
6 " uid " : " http : / /. ../ ru les /D Pij " ,
7 " ta rg et " : " ht tp : / /.. ./ rules / A Pj / ru lej ",
8 " ac ti on " : " t rig ge r " ,
9 " du ty " : [{
10 " ac ti on " : " n ex tP ol ic y ",
11 " uid " : " http : / /. ../ po li ci es / A Pi ",
12 " c on st raint ": [{
13 " l ef tO pe ra nd " : " e ven t ",
14 " o per at or " : " lt " ,
15 " r ig ht Op er an d " : {" @id " : " od rl :
po li cy Us ag e "}}]}]}]}
To instantiate Listing 2, let us consider Fig. 1’s
receive shipment details and ship products. We
define first, a DP rule-composition to treat these
2 activities’ AP s as assets (Listing 3) and then,
DP
seq
receiveShipmentDetails,shipProducts
(...) to implement
the sequencing of the rules in their respec-
tive AP s (Listing 4). In this DP
seq
···
’s permission
rule (line 5), the action trigger (line 8) is exercised
over the asset shipProductsRule (line 7). The permis-
sion rule also has a duty property (line 9) to declare
the successful completion of receiveShipmentDetail-
sRule included in receive shipment details’s AP .
Thanks to the constraint in line 11, the sequencing
of triggering receiveShipmentDetailsRule then ship-
ProductsRule is achieved.
Listing 3: Instantiation of Listing 1.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " @t ype ": " Se t ",
3 " uid " : " htt p : //../ DP S hi pD et ail s_ Sh ip P ro du ct s : 01" ,
4 " p ermission ": [{
5 " uid " : " http : / /. ../
DP S hi pD eta il s_ S hi pP ro d uc ts Ru l ec om p " ,
6 " ta rg et " :[ " ht tp : / /.../ DP /
AP r ec ei ve Shi pm en tD e ta il s " ,
7 " ht tp : //.. ./ DP / A Psh ip Pr od uc ts " ] ,
8 " ac ti on " : " use"}]}
ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering
362

Listing 4: Instantiation of Listing 2.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " uid " : ". ../ S eq DP Shi pD et ail s_ Sh ip P ro du ct s : 0 2" ,
3 " ty pe " : " Agr ee me nt " ,
4 " i nh er it Fr om " : "/ D PSh ip De tai ls _S hi p Pr od uc ts :0 1 ",
5 " p ermission ": [{
6 " uid " : " htt p : // ... / DP Sh ip De t ai ls Sh ipP ro du ct s " ,
7 " ta rg et " :" http : //. ../ s hi pP ro du ct sR ule " ,
8 " ac ti on " : " t rig ge r " ,
9 " du ty " : [{
10 " ac ti on " : " n ex tP ol ic y ",
11 " uid " : ". .. / r ece iv eS hi p me nt De tai ls Ru le ",
12 " c on st raint ": [{
13 " l ef tO pe ra nd " : " e ven t ",
14 " o per at or " : " lt " ,
15 " r ig ht Op er an d " : {" @id " : " od rl :
po li cy Us ag e "}}]}]}]}
Regarding DP
cho
i, j
(A
i
,A
j
), it means that rule
i
in
AP
i
and rule
j
in AP
j
should be triggered inclusively;
i.e., trigger(rule
i
∨ rule
j
). Based on some ODRL con-
structs, we achieve rule choice as follows (Listing 5):
1. Make DP
cho
i, j
(AP
i
,AP
j
) inherit from
DP
i, j
(AP
i
,AP
j
) using inheritFrom (line 4).
2. Define 2 rules R and R
′
having R uleDP
i j
and
R uleDP
ji
as uids, obligation-with-consequence
as a type, and rule
i
and rule
j
as assets, respec-
tively (lines 5-11 and lines 12-17).
3. Define the property consequence in both R and
R
′
to handle, respectively, the exclusive non-
fulfillment of the obligation in a way that if
rule
i
is not triggered, then rule
j
will be trig-
gered (lines 10-11) and vice-versa (lines 16-17).
Should both obligations be fulfilled, then rule
i
and rule
j
will be triggered.
4. Include the action trigger in R to exercise over
either rule
i
or rule
j
(lines 8 and 11).
5. Include the action trigger in R
′
to exercise over
either rule
j
or rule
i
(lines 14 and 17).
Listing 5: Choice-based dependency policy.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " uid " : " http : / /. ../ Ch oR ul eD Pi j : 00 1 ",
3 " ty pe " : " agr ee me nt " ,
4 " i nh er it Fr om " : " ht tp : / /.../ DPi_j : 0 1" ,
5 " o bligation ": [
6 {" uid " : " http : / /. ../ rule 1/ Ch oR ul eD Pi j ",
7 " ta rg et " : " ht tp : / /.. ./ po li ci es / AP i / rulei " ,
8 " ac ti on " : " t rig ge r " ,
9 " c on se qu en ce " : [{
10 " ta rg et " : " ht tp : / /.. ./ po li ci es / AP j / rulej " ,
11 " ac ti on " : " t rig ge r "}]},
12 {" uid " : " http : / /. ../ rule 2/ Ch oR ul eD Pj i ",
13 " ta rg et " : " ht tp : / /.. ./ po li ci es / AP j / rulej " ,
14 " ac ti on " : " t rig ge r " ,
15 " c on se qu en ce " : [{
16 " ta rg et " : " ht tp : / /.. ./ po li ci es / AP i / rulei " ,
17 " ac ti on " : " t rig ge r "}]}]}
3.2 Masking Techniques
Post-Abstraction Analysis. Abstraction makes some
activities, e.g., A
i
, in a BP invisible. These activi-
ties either are deemed not relevant for exposure to
external partners or are hidden to address privacy
concern. Despite being invisible, abstracted activi-
ties are invoked when partnership is enacted at run-
time. By “dropping” A
i
from the BP, we create an
“artificial” (a) DP
a,seq
f i−1,i+1
(AP
i−1
,AP
i+1
) that (i) in-
herits from a new artificial DP
a
rule-composition
similar to Listing 1 (with AP
i−1
and A P
i+1
as as-
sets) and (ii) adopts a sequence dependency between
A
i−1
and A
i+1
by default as per the recommenda-
tion of Kallel et al. who refer to this dependency
as finish-to-start (Kallel et al., 2021). In line with
Kallal et al. who examined BPs masking/abstrac-
tion from a time perspective when they used a delay
period to hold on the abstracted activity before ex-
ecuting afterwards the non-abstracted activities, we
restrict our ODRL constraints on actions in APs to
time, only, and integrate the delay period into the
“artificial” dependency policy. Listing 6, that cor-
responds to DP
a,seq
i−1,i+1
(AP
i−1
,AP
i+1
), inherits from
DP
a
i−1,i+1
(AP
i−1
,AP
i+1
) rule-composition (line 4).
However, contrarily to DP
seq
···
(··· ,·· ·) in Listing 2,
the action trigger (line 9) to exercise on AP
i+1
’s
rule (line 7) is now constrained to delayPeriod
(lines 11-13) ensuring that A
i
’s time remains satisfied
at run-time (line 13).
Listing 6: Artificial sequence-based dependency policy for
abstraction.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " uid " : " http : / /. ../ SeqDPi - 1, i+ 1 ",
3 " ty pe " : " Agr ee me nt " ,
4 " i nh er it Fr om " : " ht tp : / /.../ DPi -1 , i+ 1",
5 " p ermission ": [{
6 " uid " : " http : / /. ../ ru les /R ule DPi - 1, i +1 ",
7 " ta rg et " : " ht tp : / /.. ./ rules / A Pi +1 / rule i +1 " ,
8 " ac ti on " : [{
9 " rdf : v al ue " : {" @id " : " o drl : t ri gg er "},
10 " r ef in ement ": [{
11 " l ef tO pe ra nd " : " d el ay Pe ri od " ,
12 " o per at or " : " eq " ,
13 " r ig ht Op er an d " : {" @v al ue " : " Ai Dur ", "
@t ype ": " xs d : du ra tion "}}]}] ,
14 " du ty " : [{
15 " ac ti on " : " n ex tP ol ic y ",
16 " uid " : " http : / /. ../ po li ci es / APi -1 ",
17 " c on st raint ": [{
18 " l ef tO pe ra nd " : " e ven t ",
19 " o per at or " : " lt " ,
Impact of Business Process Masking on Organizations’ Policies
363

20 " r ig ht Op er an d " : {" @id " : " od rl :
po li cy Us ag e "}}]}]}]}
To instantiate Listing 6, we abstract ship prod-
ucts; its execution duration could take 48hours,
for example. Listing 7 corresponds to
DP
a,seq
receiveShipmentDetails,noti f yCustomer
(AP
rec...
,AP
not...
)
that inherits from
DP
a
receiveShipmentDetails,noti f yCustomer
(AP
rec...
,AP
not...
)
rule-composition (line 4). Relying on
Kallel et al. (Kallel et al., 2021), delayPeriod is
set to 48h (line 13) so that ship products would
have enough time to be executed and notify cus-
tomer is not executed just after completing receive
shipment details.
Listing 7: Instantiated sequence-based artificial dependency
policy for abstraction.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " uid " : " htt p : // ... / Se qD Pr ec e iv eS hi p me nt De tai ls ,
no ti fyC us to me r ",
3 " ty pe " : " Agr ee me nt " ,
4 " i nh er it Fr om " : ". ../ D Pr ece iv eS hi pme nt De ta i ls ,
no ti fyC us to me r ",
5 " p ermission ": [{
6 " uid " : ". ../ R ul e DP re ce ive Sh ip men tD et ai l s ,
no ti fyC us to me r ",
7 " ta rg et " : " ht tp : / /.. ./ ru leN ot if yC us to m er " ,
8 " ac ti on " : [{
9 " rdf : v al ue " : {" @id " : " odrl : t ri gg er "},
10 " r ef in ement ": [{
11 " l ef tO pe ra nd " : " d el ay Pe ri od " ,
12 " o per at or " : " eq " ,
13 " r ig ht Op er an d " : {" @v al ue " : "4 8 ", "
@t ype ": " xs d : du ra tion "}}]}] ,
14 " du ty " : [{
15 " ac ti on " : " n ex tP ol ic y ",
16 " uid " : ". ../ A Pr ece iv eS hi p me nt De ta i ls " ,
17 " c on st raint ": [{
18 " l ef tO pe ra nd " : " e ven t ",
19 " o per at or " : " lt " ,
20 " r ig ht Op er an d " : {" @id " : " od rl :
po li cy Us ag e "}}]}]}]}
Post-Aggregation Analysis. Aggregation groups
activities, e.g., A
i
and A
j
, together giving partnership
partners the impression of a limited number of activ-
ities in a BP. To discuss BPs masking/aggregation’s
impact on policies, we consider additional activities,
A
i−1
and A
j+1
, as well as other necessary policies
namely, AP
i−1,i, j, j+1
, DP
i−1,i
(AP
i−1
,AP
i
),
DP
i, j
(AP
i
,AP
j
), DP
j, j+1
(AP
j
,AP
j+1
),
DP
seq|cho|...
i−1,i
(AP
i−1
,AP
i
), DP
seq|cho|...
i, j
(AP
i
,AP
j
),
and DP
seq|cho|...
j, j+1
(AP
j
,AP
j+1
). By aggre-
gating A
i
and A
j
into A
i j
, we create sev-
eral “artificial” activity and dependency poli-
cies namely, AP
a
i j
, DP
a,...
i−1,i j
(AP
i−1
,AP
i j
),
DP
a,...
i j, j+1
(AP
i j
,AP
j+1
), DP
a
i−1,i j
(AP
i−1
,AP
i j
),
and DP
a
i j, j+1
(AP
i j
,AP
j+1
). By analogy with BPs
masking/abstraction, we adopt first, ODRL temporal
constraints on actions in both A
i
’s AP
i
and A
j
’s
AP
j
and second, a sequence-based dependency
between A
i
and A
i j
and between A
i j
and A
j+1
. For the
sake of illustration, we also adopt a sequence-based
dependency between A
i
and A
j
to calculate A
i j
’s
execution duration that is the sum of A
i
’s and A
j
’s
respective execution durations (Dumas et al., 2013).
Durations for other dependency types like choice are
presented in (Dumas et al., 2013) as well. To define
necessary artificial policies, we proceed as follows:
- A P
a
i j
: we define AP
a
i j
by setting a DP rule-
composition DP
i, j
(AP
i
,AP
j
) as per List-
ing 1, a sequence-based dependency policy
DP
seq
i, j
(AP
i
,AP
j
) as per Listing 2, and the
policy itself as per Listing 8. In this listing, line 7
refers to the asset that is the aggregating activity’s
name, line 4 establishes the inheritance with
DP
seq
i, j
(AP
i
,AP
j
), and lines 11-13 are related to
the time constraint on the action trigger.
Listing 8: Artificial policy for an aggregating activity.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " uid " : " http : / /. ../ Ai jP ol ic y :00 1" ,
3 " ty pe " : " Agr ee me nt " ,
4 " i nh er it sf ro m ": " h ttp : //. ../ Se qD Pi j :0 2 ",
5 " p ermission ": [{
6 " uid " : " http : / /. ../ ru les /Aij Ru le " ,
7 " ta rg et " : " ht tp : / /.. ./ as set s / Aij " ,
8 " ac ti on " : [{
9 " rdf : v al ue " : {" @id " : " o drl : t ri gg er "},
10 " r ef in ement ": [{
11 " l ef tO pe ra nd " : " e la ps ed Ti me " ,
12 " o per at or " : " eq " ,
13 " r ig ht Op er an d " : {" @v al ue " : " Ai jD ur " ,
" @t ype ": " x sd : du ra ti on "}}]}]}]}
We now aggregate receive shipment details and ship
products into complete product shipment considering
the sequence-based dependency between these 2 ac-
tivities as well as their 48h and 4h respective exe-
cution durations, for example. Listing 9 corresponds
to A P
a
completeProductShipment
that instantiates Listing 8
where the execution duration is set to 52h (line 13).
Listing 9: Instantiated artificial sequence-based dependency
policy for aggregation.
1 {" @ co nt ex t ": " ht tp : // www .w 3 . org / ns / od rl . json ld " ,
2 " uid " : " htt p : // ... / DP co mp le tPr od uc tS h ip me nt :0 01 " ,
3 " ty pe " : " Agr ee me nt " ,
4 " i nh er it sf ro m ":" http : / /. ../
Seq DP re c ei ve Sh i pm en tDe ta il s Sh ip Pr o du ct :0 2" ,
5 " p ermission ": [{
6 " uid " : ". .. / c omp le te Pr o du ct Sh i pm en tR ule " ,
7 " ta rg et " : ". ../ c om pl et ePr od uc tS hip me nt ",
ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering
364

Figure 3: Aggregated receive order and confirm order AP s.
8 " ac ti on " :[{
9 " rdf : v al ue " : {" @id " : " o drl : t ri gg er "},
10 " r ef in ement ": [{
11 " l ef tO pe ra nd " : " e la ps ed Ti me " ,
12 " o per at or " : " eq " ,
13 " r ig ht Op er an d " : {" @v al ue " : "5 2 ", " @ty pe "
: " xs d: du ratio n "}}]}]}]}
- DP
a
i−1,i j
(AP
i−1
,AP
i j
) and
DP
a,seq
i−1,i j
(AP
i−1
,AP
i j
): are defined in com-
pliance with Listing 1 and Listing 2, respectively.
- DP
a
i j, j+1
(AP
i j
,AP
j+1
) and
DP
a,seq
i j, j+1
(AP
i j
,AP
j+1
): are defined in compli-
ance with Listing 1 and Listing 2, respectively.
3.3 Experiments
We present the experiments conducted to assess the
impact of masking techniques on BPs’ policies using
Section 2.3’s case study. The experiments, available
at Google Colab, assessed performance- and process-
based metrics in terms of process flow, policy consis-
tency, and computational resources. They were per-
formed on a Python-based ODRL policy engine com-
bined with a BPMN parser
1
, executed within Google
Colab. This one provides a cloud-based platform with
Python 3 support, backed by Google Compute En-
gine, which allows for code execution in virtualized
environments. The system ran on a free Colab session
with 12.7 GB of system RAM, 107.7 GB total disk
space (with 32.5 GB used), and a Python 3 Google
Compute Engine backend for the CPU.
In the aggregation scenario, we selected a
sequence-based dependency between receive order
and confirm order (Fig 1). The system generated the
necessary policies to reflect this aggregation. The
generated policies include:
• Data dependency-based rule composition com-
poses the rules of the individual activities being
aggregated, i.e., Listing 1.
1
https://pypi.org/project/bpmn-python.
• Sequence-based dependency policy defines the
sequence dependencies between the aggregated
activities, i.e., Listing 2.
• Aggregated activity policy in Fig. 3 represents the
aggregated activity as a single unit, i.e., Listing 8.
• Sequential dependency policies with the aggre-
gated activity in Fig. 4 define the links between
the aggregated activity and other activities in the
process, i.e., Listing 2.
• Message synchronization policies represent the
message that the aggregated activities receive and
transmit.
In the abstraction experiments, abstraction was
applied to activities such as send bill. We made the
following observations:
• Completion time: The time to generate abstracted
policies was minimal, with an average completion
time of 0.006 seconds. This demonstrates negligi-
ble delay in generating abstraction policies.
• Resource utilization: CPU usage during abstrac-
tion was minimal, with negligible changes ob-
served indicating that abstraction does not signif-
icantly strain computational resources.
• Policy complexity: Abstraction required a fixed
number of policies and rules, regardless of the
number of activities abstracted together. Specif-
ically, 3 policies and 3 rules per abstraction. This
demonstrates that abstraction maintains a low
level of policy complexity while effectively hid-
ing activities.
In the aggregation experiments, aggregation was
applied to activities like compute price, compute ship-
ment price, and prepare shipment. We made the fol-
lowing observations:
• Completion time: Aggregation required more
time than abstraction, with the average comple-
tion time increasing proportionally to the number
of activities aggregated. For example, aggregat-
ing 3 activities took on average 0.014 seconds.
This increase is due to the additional time required
Impact of Business Process Masking on Organizations’ Policies
365

Figure 4: Sequence-based DP s of the aggregated activities and prepare shipment AP s.
to create multiple policies and manage dependen-
cies.
• Resource utilization: Aggregation consumed
more CPU resources compared to abstraction due
to the increased number of policies generated.
Despite this, CPU and memory usage remained
within acceptable limits, indicating the system’s
efficiency in handling aggregated processes.
• Policy complexity: Aggregation led to an increase
in policy complexity, with the number of poli-
cies and rules significantly higher than in abstrac-
tion. Aggregating activities led to creating mul-
tiple policies, including rule composition policies
and dependency policies linking existing activities
to the aggregated activities. This reflects the addi-
tional complexity introduced by aggregation.
4 CONCLUSION
This paper examined the impact of BP masking tech-
niques on organizations’ policies that engage in part-
nership. We relied on ODRL to define policies that
control BPs’ activities and capture application do-
mains’ regulations. 2 techniques are adopted for
masking namely, abstraction and aggregation, that
impact the way policies are defined. Experiments
were conducted to demonstrate the technical doabil-
ity of adjusting, dropping, and/or developing policies
because of abstraction and aggregation. Unlike ab-
straction that introduced minimal delay and maintains
a low level of policy complexity, aggregation required
more time and generated a higher number of poli-
cies. In term of future work, we would like first, to
re-engineer masked BPs so that the steps of applying
abstraction and/or aggregation to unmasked BPs are
traced back, and, second, to analyze cross-policy con-
sistency when masking is applied to separate BPs.
REFERENCES
Chika Eleonu, H. (2021). Aggregate Metric Model for Eval-
uating Business Processes. Business Process Manage-
ment Journal, 27(2).
Daoud, M., El Mezouari, A., Faci, N., Benslimane, D.,
Maamar, Z., and El Fazziki, A. (2021). A Multi-
Model based Microservices Identification Approach.
Journal of Systems Architecture, 118:102200.
Dumas, M., La Rosa, M., Mendling, J., and Reijers, H.
(2013). Fundamentals of Business Process Manage-
ment. Springer.
Han, L., Zhao, W., and Yang, J. (2017). An Approach to-
wards Task Abstraction and Aggregation in Business
Processes. In Proceedings of ICWS’2017, Honolulu,
HI, USA.
Kallel, S., Cheikhrouhou, S., Maamar, Z., Guermouche,
N., and Jmaiel, M. (2021). From Generating Process
Views over Inter-Organizational Business Processes
to Achieving their Temporal Consistency. Computing,
103(7).
Kammerer, K., R
¨
udiger Pryss, R., and Reichert, M. (2022).
Retrieving, Abstracting, and Changing Business Pro-
cess Models with PQL. In Polyvyanyy, A., editor,
Process Querying Methods. Springer.
Maamar, Z., Faci, N., and El Haddad, J. (2022). Microser-
vices Deployment on a Multi-platform Ecosystem: A
Contract-Based Approach. In Revised Selected Papers
- ICSOFT’2022, Lisbon, Portugal.
Reijers, H., Mans, R., and van der Toorn, R. (2009). Im-
proved Model Management with Aggregated Busi-
ness Process Models. Data Knowledge Engineering,
68(2).
W3C (2018). ODRL Information Model 2.2. https://www.
w3.org/TR/2018/REC-odrl-model-20180215/. (Vis-
ited in January 2024).
Weimer, D. and Vining, A. (2017). Policy Analysis, Con-
cepts and Practice. Taylor & Francis Group, New
York.
ENASE 2025 - 20th International Conference on Evaluation of Novel Approaches to Software Engineering
366