In oducing a Mashup-Based App oach
o Design-Time Compliance Checking
in Business P ocesses
C is ina Cabanillas, Manuel Resinas, and An onio Ruiz-Co ´es
Uni e sidad de Se illa, Spain
{c is inacabanillas, esinas, a uiz}@us.es
Abs ac . Business p ocess compliance ies o ensu e he business p o-
cesses used in an o ganiza ion a e designed and execu ed acco ding o
he ules ha go e n he company. Howe e , he na u e o ules (ex-
p essed in na u al language) and he la ge amoun o elemen s ha can
be in ol ed in hem make hei ma e ializa ion and au oma ed checking
qui e difficul . Tha is why he exis ing suppo o compliance check-
ing is gene ally es ic ed o specific kinds o ules (e.g. ules affec ing
he con ol flow o he p ocess). In his pape , we in oduce compliance
mashups, and show how a mashup-based app oach can help sol e he
p oblem o ule specifica ion and checking a design ime. Some ad an-
ages o such an app oach a e ha : (i) any kind o ule can be specified,
which implies ha each use can speci y a ule acco ding o his/he in e -
p e a ion o he ule; (ii) building he compliance mashup is anspa en
o he o malism(s) used o implemen i , so diffe en echniques can be
used oge he ; and (i ) mashup componen s o pa s o hem can be
e-used. As an example we use his app oach o build mashups o spec-
i y and check ules ela ed o human esou ce managemen in business
p ocesses a design ime.
Keywo ds: Business p ocess compliance, ule specifica ion, compliance
mashup, na u al language disambigua ion, design- ime compliance
checking.
1 In oduc ion
Business p ocess (BP) compliance consis s o ensu ing he BPs used in an o -
ganiza ion a e designed and execu ed acco ding o he policies ha go e n he
company. Policies can be decomposed in o ules ha in oduce cons ain s ela -
ing o diffe en aspec s o he BPs, such as he execu ion o de o he ac i i ies
(i.e. con ol flow), he da a accessed and managed, o he people (a.k.a human
esou ces o jus esou ces ) ha pa icipa e in he p ocess.
This wo k has been pa ially suppo ed by he Eu opean Commission (FEDER),
Spanish Go e nmen unde he CICYT p ojec SETI (TIN2009-07366); and p ojec s
THEOS (TIC-5906) and ISABEL (P07-TIC-2533) unded by he Andalusian Local
Go e nmen .
M. Bajec and J. Ede (Eds.): CAiSE 2012 Wo kshops, LNBIP 112, pp. 337–350, 2012.
c
Sp inge -Ve lag Be lin Heidelbe g 2012
338 C. Cabanillas, M. Resinas, and A. Ruiz-Co ´es
Compliance can be checked a diffe en phases o he BP li ecycle [1], which
esul s in wo big compliance checking modali ies [2]. The mos p oac i e way o
check compliance is Fo wa d Compliance Checking (FCC), which can be di ided
in o wo sub-app oaches: Design-Time Compliance Checking (DTCC) and Run-
Time Compliance Checking (RTCC). DTCC is usually pe o med a e BP mod-
elling wi h he aim o ensu ing ha he p ocess is complian wi h he gi en ules
be o e i s execu ion, hus sa ing ime and effo o business analys s. An example
is ool OPAL de eloped by some esea che s om IBM Resea ch China, which
uses model-checking echniques o au oma ically e i y con ol flow- ela ed ules
in BP models [3]. Ne e heless, he e is a bunch o p oposals o deal wi h DTCC
based on di e se echniques. A common ea u e o mos o hem is ha hey
ely on anno a ed BP models o check compliance [4,5]. RTCC echniques check
ules a un ime, so i a ule is iola ed o some p oblema ic si ua ion a ises
while unning he p ocess we migh be able o sol e he p oblem on ime o a oid
ending in a non-complian s a e. This equi es some kind o so wa e o busi-
ness ac i i y moni o ing (BAM) in BP managemen sys ems (BPMS). Eu opean
P ojec COMPAS wo ked in his di ec ion [6]. Finally, Backwa d Compliance
Checking (BCC) ocuses on de e mining whe he pas ins ances o a BP we e
complian wi h ules om in o ma ion s o ed in his o y logs. The esul o BCC
helps s akeholde s o be p epa ed o audi s. P oM [7], a ool o p ocess mining,
con ains plugins o pe o m his kind o compliance checking, mos ly ocused on
con ol flow issues [8]. A summa y o ea u es ha should be conside ed when
de eloping a BP compliance managemen sys em (BPCMS) ha co e s all he
phases o he BP li e cycle was in oduced in [9].
In his pape we ocus on FCC, pa icula ly on DTCC. In DTCC, ules a e
checked agains BP models, which in ol es ansla ing hem in o a o mal lan-
guage ha can be au oma ically p ocessed. This is no an easy ask. I is widely
known ha he e is an impo an gap be ween BPs and ules indeed [10]. Di -
e en compliance ule modelling languages and ways o inse policy- ela ed
in o ma ion in BP models ha e been in oduced in he las yea s [11, 3, 12, 13],
bu he e a e impo an p oblems ha s ill emain pa ially unsol ed. The own
na u e o ules is a p oblem i sel , as policies a e desc ibed in na u al language,
which may be ambiguous. The e o e, wo o ganiza ions may implemen he same
ule in wo sligh ly diffe en ways, some imes olun a ily (i.e. o “business pol-
icy”), o he imes by chance (i.e. due o an unconscious diffe en in e p e a ion
o a misunde s anding o he ule). Fo ins ance, le us suppose we mus ulfill
he ollowing ule in ou o ganiza ion:
Rule 1: The e is a seg ega ion o du ies be ween he c ea ion o a hi ing esolu-
ion p oposal and i s p ocessing.
Seg ega ion o du ies (SoD) is a well-known au ho iza ion cons ain ha aims a
a oiding p oblems due o a conflic o in e es s in he execu ion o wo ac i i ies.
This is achie ed by dis ibu ing he esponsibili y o mo e han one esou ce
(e.g. oles, posi ions, pe sons). I we a e de eloping a ule modelling language,
In oducing a Mashup-Based App oach o DTCC in BPs 339
he SoD concep may be i sel an elemen o he language ha can be used o
s a e ules such as Rule 1. Howe e , by ac ing like ha we a e losing nuances
ha come om he human in e p e a ion o na u al language. Fo example, Rule
1 could lead o a leas wo diffe en implemen a ions:
–S ic . The business manage can assume ha , besides selec ing diffe en
oles o he wo asks, i is necessa y o gua an ee ha wo diffe en pe sons
unde ake he ac i i ies in o de o p e en he scena io in which he same
pe son plays he wo oles in ol ed and, hence, may execu e he wo ac i i ies
affec ed by he ule, which could esul in a conflic o in e es s.
–Sligh . Howe e , we may find an o ganiza ion in which people mus indica e
wi h which ole pe o m e e y ask and which does no ca e abou he same
pe son execu ing he wo ac i i ies in ol ed in a SoD as long as each ac i i y
is pe o med wi h a diffe en ole. In his case, he esul o he SoD checking
would be diffe en om ha o he p e ious implemen a ion.
Each piece o ou ule modelling language mus ha e an associa ed seman ics.
So, he ques ion is: which o he p e ious implemen a ions is co e ed by ou lan-
guage? Bo h? Taking in o accoun he whole po en ial in e p e a ion a iabili y
o na u al language would lead o complex languages, which in u n would de i e
in hei ha d unde s andabili y and use.
Ano he issue is how o deal wi h all he aspec s o he BPs ha can be affec ed
by ules (e.g. con ol flow, da a, esou ces, empo al cons ain s). The wide bunch
o possibili ies ega ding BP aspec s collabo a e in making i difficul o de elop
such a language. Fu he mo e, some ules in ol e mo e han one aspec . This,
oge he wi h he a o emen ioned in e p e a ion p oblem, gene a e a complex
and a ied casuis y ha makes i ha d o define a decla a i e domain-specific
language (DSL) exp essi e enough o add ess all kinds o ules. As a consequence,
mos o he echniques p oposed so a limi hei scope, e.g. o one o wo BP
aspec s, gi ing ise o many ad-hoc app oaches. The conclusions o a s udy we
ca ied ou on app oaches dealing wi h BP compliance can be ound in [14].
Besides, some echniques ely on one specifica ion o malism o ule defini ion
such as [13]. Howe e , one o malism usually allows only some ypes o checks, so
he en i e casuis y is no co e ed like ha . The mix u e o diffe en o malisms
would be necessa y.
Finally, pa s o some ules can be e-used in he defini ion o o he ules.
Conside ing his in ou ule modelling language would sa e effo o business
analys s o o he pe son in cha ge o modelling he ules o a company (e.g. a
compliance expe ). Some pa e n-based app oaches such as BPMN-Q [12] kind
o co e his issue. Howe e , he p oblem o he la ge casuis y is s ill la en .
We p opose mashups as a mechanism o p o ide an ope a i e specifica ion o
ules and check design- ime BP compliance. In his pape we will e eal how
his app oach allows us o add ess he a o emen ioned challenges and o e come
he a o emen ioned issues. Mashups a e easy o unde s and and use [15], and
hey can be implemen ed in many diffe en ways, e.g. by using common sp ead-
shee s [16]. Applied o policies, mashups le us handle diffe en in e p e a ions
340 C. Cabanillas, M. Resinas, and A. Ruiz-Co ´es
o na u al language by e-combining he mashup componen s used o speci y a
ule, hus dealing wi h na u al language ambigui y.
Fu he mo e, diffe en o malisms can be used oge he in a single mashup,
p o ided ha we ha e a eal way o connec he in o ma ion esul ing om
a echnique wi h he inpu o ano he app oach1. The e o e, he specifica ion
o ules by an end use may be independen o he unde lying o malism o
compliance checking. Besides, mashups offe , among o he in e es ing ea u es,
flexibili y, po abili y and e-usabili y, so ules al eady defined (o pa o hem)
can be sa ed and used la e o build o he mashups. The ac ha hey ha e
al eady been used o analysis pu poses in o he domains [17,18], mo i a ed us
o explo e hei applicabili y o check BP compliance ules.
Finally, no e ha , al hough he ocus o his pape is on DTCC, he idea
behind ou app oach can be applied o o he phases o he BP li ecycle and, as
a ma e o ac , we a e cu en ly wo king on ex ending he app oach o RTCC
and BCC.
The es o he pape is s uc u ed as ollows. In Sec ion 2 we in oduce
mashups and hei main ypes o componen s, accompanied by a gene ic ex-
ample. Sec ion 3 con ains an explana ion o ou p oposal, which is exemplified
by applying i o a specific kind o compliance ules in Sec ion 4. Finally, some
conclusions and a summa y o ongoing and u u e wo k a e p esen ed in Sec-
ion 5. To imp o e he unde s andabili y o he explana ions, and due o space
limi a ion, e e ences o ela ed wo k a e gi en h oughou he pape .
2 In oduc ion o Mashups
Mashups a e a ho concep in IT nowadays. A mashup is a da a-d i en wo k-
flow (a.k.a. da aflow) buil wi h in o ma ion om one o mo e da a sou ces,
and i is based on he e-use o con en s and unc ionali ies. Mashups we e de-
eloped o build new Web se ices o applica ions om exis ing da a in an
“easy” way, so he end use does no need o ha e specific echnical knowl-
edge, bu only knowledge o he p oblem domain [15]. They ha e al eady been
applied o add ess p oblems such as he analysis o molecula biology in bio-
in o ma ics [17] and he simplifica ion o pa ien managemen in hospi als [18],
and he e a e some mashup make s in he ma ke such as In el Mashup Make ,
Yahoo! Pipes o IBM Mashup Cen e . The Google App Engine also gi es sup-
po o he p e ious Google Mashup Edi o . The e is a la ge amoun o mashup
examples a ailable on he Web, e.g. mo e han 6,000 mashups can be ound a
h p://www.p og ammableweb.com/. Wi h ools such as Yahoo! Pipes anybody
can build and publish a mashup in he In e ne .
To show mashup appea ance and use we ha e c ea ed he mashup in Figu e
1. I e u ns he las 25 in e na ional news o he New Yo k Times and The
Aus alian digi al newspape s2. Any esea che could wan o ha e a simila
1The complexi y o a mashup is wi hin each componen , and he g ea es effo is pu
on how o in eg a e hem.
2I can be un a h p://pipes.yahoo.com/cabanillasmashups/wo ldnews.
In oducing a Mashup-Based App oach o DTCC in BPs 341
UI (ou pu )
News1,
News2,
…
News40
ge News()
OPERATOR
subse (25)
FILTER
The Aus alian
New Yo k
Times
ge News()
OPERATOR
union()
AGGREGATOR
delDuplica es()
OPERATOR
so ByDa e()
SORTER
N1, N2,
…
N63
News1, …, News 40,
N1, …, N63
News1, …, News 40,
N1, …, N63
News31, N20, N5,
N49, News2,
News26, N50, … N7
News31, N20, N5,
N49, News2, News26,
N50, … News14
Fig. 1. Mashup collec ing he las 25 wo ld news om wo digi al newspape s
mashup o be kep up o da e o his/he esea ch in e es s, e.g. a mashup ha
au oma ically places on a map he enue ci ies whe e he nex edi ions o his/he
a ou i e con e ences ake place.
As illus a ed in he figu e, mashup edi o s allow he defini ion o he da aflow
by connec ing wo main ypes o componen s: da a sou ces and flow componen s.
Da a sou ces ange om da a wa ehouses o URLs poin ing a RSS eeds o
any kind o accessible in o ma ion.
Flow componen s a e he elemen s in cha ge o ope a ing on da a, so hey all
ha e inpu and ou pu . The inpu da a hey ecei e can come om ano he mashup
componen o om a da a sou ce, and he las componen p o ides he in o ma ion
equi ed o he ou pu UI. Flow componen s can be gene ic-pu pose componen s
such as hose ha handle collec ions o elemen s o so o join hem, and domain-
specific (DS) componen s, which implemen unc ions specific o he p oblem do-
main, such as handling geog aphical loca ion da a o en ich Google Maps wi h ex-
e nal in o ma ion. Some equen ly used flow componen s include he ollowing:

342 C. Cabanillas, M. Resinas, and A. Ruiz-Co ´es
–Fil e s. They na ow down he flow o da a, suppo ing he ans o ma ion
o he in o ma ion.
–Agg ega o s. They join o g oup da a acco ding o some c i e ia.
–Ope a o s. They ex ac , elabo a e and ans o m he in o ma ion, cons i-
u ing a e y impo an pa o he ETL (Ex ac -T ans o m-Load) p o-
cess [19] da a mus unde go om he inpu o he mashup o he ou pu
UI. They ange om ope a o s ha implemen well-known unc ions such as
coun ,min,max and a e age (i.e. gene al-pu pose) o ope a o s ha handle
s ings o ex ac and builds geog aphical loca ion in o ma ion (i.e. domain-
specific).
–So e s. They e u n he same inpu da a bu in a specific o de .
Languages o mashup ep esen a ion, such as En e p ise Mashup Ma kup Lan-
guage (EMML)3, p o ide suppo o c ea e and use a leas he a o emen ioned
componen s and hey can usually be ex ended o include new DS componen s, i
equi ed. Fo insigh s abou how o build high-quali y mashups we ecommend
he eading o [20].
3 Mashups o BP Compliance Checking
We p opose he use o mashups as a language o p o ide an ope a i e specifica-
ion o ules and o que y BP models.
De ini ion 1. Acompliance mashup is an ope a i e DSL ha allows he in e-
g a ion o he e ogeneous da a sou ces and he specifica ion o compliance ules
o e subse s o he in o ma ion ha can be ex ac ed om hem.
In hem, he da a sou ces a e he eposi o ies whe e he o ganiza ion s o es
he diffe en models i uses, e.g. business p ocesses, o ganiza ional s uc u es,
da a and so on. Rega ding he flow componen s o he mashup specifica ion,
a se o bo h gene al-pu pose and DS componen s (fil e s, ope a o s, so e s,
e ce e a) may be necessa y o manipula e and ans o m he da a coming om
hese models. In pa icula , in he case o DS ope a o s, hese componen s will
encapsula e analysis ope a ions (o que ies) on models ha enable he c ea o
o he mashup o ex ac om he models he in o ma ion he/she needs o check
a compliance ule.
DS ope a o s can be implemen ed using diffe en analysis echniques. Fo
ins ance, BPMN-Q is a language aimed a que ying BP models ega ding con ol
flow and da a [21] (e.g. i e u ns in o ma ion on whe he an ac i i y is execu ed
be o e o a e ano he ac i i y). The e also exis mechanisms o analyse he da a
pe spec i e o BP models, as long as hese models ha e da a- ela ed in o ma ion
[22]. O he p oposals deal wi h esou ce analysis in BP models wi h esou ce
assignmen in o ma ion such as RAL o Business Ac i i ies. RAL is a DSL o he
ep esen a ion and analysis o esou ce assignmen s in BP models. The analysis
3h p://www.openmashup.o g/omadocs/ 1.0/index.h ml
In oducing a Mashup-Based App oach o DTCC in BPs 343
mechanism is p o ided by means o i s on ology-based seman ics [23]. Business
Ac i i ies a e a UML ex ension o in eg a e p ocess flows and p ocess- ela ed
RBAC models wi h esou ce- ela ed cons ain s. The iola ion o cons ain s
such as mu ual exclusion be ween ac i i ies can be de ec ed [24].
The se o a ailable DS ope a o s will depend on he kinds o checks we ha e
o pe o m o e he BPs o ou o ganiza ion. So, as a o emen ioned, some o
hem will implemen mechanisms o check o some da a- ela ed unc ionali y,
some o he s will be ocused on dealing wi h con ol-flow in o ma ion, and so on.
Finally, he da a sou ces and he flow componen s a e connec ed in a da aflow
o check o compliance ules.
As can be seen, building a mashup is no a ha d ask, assuming ha all
he logic wi hin he componen s is implemen ed. They hus allow us o e-use
exis ing solu ions, a oiding o e-in en he wheel.
4 Applying Mashups o Resou ce-Rela ed Compliance by
Design
We a e going o show how o build a mashup o speci y and check ules ela ed
o esou ce managemen in BPs a design ime. I is one o he aspec s usually
affec ed by ules nowadays, as we can find plen y o policies ha egula e esou ce
managemen in a company, o be named:
–SoD is well-known in financial accoun ing sys ems as a mechanism o p e en
om aud and e o . In IS, i helps educe he po en ial damage om one
pe son’s ac ions by dissemina ing he asks and associa ed p i ileges o a
specific BP among mul iple use s. A big pa o he Sa banes-Oxley Ac
(SOX)4is de o ed o manage in e nal con ol in IT, in which SoD is a key
concep .
–The Heal h Insu ance Po abili y and Accoun abili y Ac (HIPAA)5pays
special a en ion o who can do ce ain asks in o de o p ese e he p i acy
o confiden ial in o ma ion and o a oid audulen use o p i a e da a.
–Besides ules coming om well-known policies, each company has i s own
esou ce- ela ed business ules ha a e defined ad-hoc o i s BPs, e.g. o
s a e wha kind o esou ce (e.g. a ole o a specific pe son) is in cha ge o
each ask.
As a use case we will use a eal p ocess designed and u ilised in he Andalusian
Ins i u e o Public Adminis a ion (IAAP) ha ep esen s he p ocedu e o c e-
a e and p ocess a esou ce esolu ion p oposal o hi ing people. This p ocess
has a high use equency in he Andalusian Public Adminis a ion, which se es
o mo e han 8 million end use s. I has been modelled in BPMN o he ease
o unde s anding (c . Figu e 2). As depic ed in he model, once a d a o a e-
sou ce esolu ion p oposal is c ea ed, i is concu en ly sen o he Consul a i e
4h p://www.soxlaw.com/
5h p://www.hhs.go /oc /p i acy/
344 C. Cabanillas, M. Resinas, and A. Ruiz-Co ´es
IAAP
IAAP
C ea e a
esolu ion
p oposal
d a
Si g n , s o e
and no i y
esolu ion
Re i ew
esolu ion
p oposal
Analyse
epo s
In e nal
Reso l u i o n
Req u es
epo o
Consul a i e
Bo a d
Req u es
epo o
Legal
Depa men
Ex e n al
esolu ion
equi ed?
Recei e
ex e nal
esolu ion
Ex e n al
Reso l u i o n
Da a wa ehouse
Tech. LD
[Posi ion]
Tech. IAAP
[Posi ion]
Tech. CB
[Posi ion]
Tech. IAAP
[Posi ion]
Sec e a y
[Posi ion]
Reso l u i o n
P oposal
Reso l u i o n
P o p o s al
Reso l u i o n
P oposal
Req u es
ex e nal
esolu ion
Sec e a y
[Posi ion]
Rep o CB
Rep o LD
CONSULTATIVE BOARD
LEGAL DEPARTMENT
EXTERNAL COMMITTEE
No Yes
Fig. 2. Exce p o he p ocess o c ea e and p ocess a esou ce esolu ion p oposal
Boa d and o he Legal Depa men o i o be e alua ed. A e ecei ing bo h
e alua ions he IAAP analyses hem and decides whe he an ex e nal esolu ion
is equi ed. In ha case, a eques is sen o an ex e nal commi ee, which mus
c ea e and send a new esolu ion. O he wise, he esolu ion p oposal is e iewed
and changes a e applied o he ini ial d a . In any case, he documen s gene a ed
a e signed and a chi ed, and he esolu ion esul is app op ia ely no ified.
Since we ocus on esou ce- ela ed compliance checking, we mus be awa e
o he o ganiza ional s uc u e o he IAAP. Figu e 3 shows i ega ding Ad-
minis a i e Resou ce Managemen . The e a e h ee o ganiza ional uni s called
IAAP, Legal Depa men and Consul a i e Boa d, co esponding o diffe en
wo k eams. Eigh posi ions (Business Manage , Technician o he IAAP, Assis-
an o he IAAP, Sec e a y, Assis an o he Legal Depa men , Technician o
he Legal Depa men , Assis an o he Consul a i e Boa d, and Technician o
he Consul a i e Boa d), occupied by a o al o ele en people6(shown in whi e
dash-lined ec angles in he figu e), a e associa ed o hese uni s. Posi ions a e
connec ed o each o he o ep esen hie a chical ela ions be ween hem.
6Thei names ha e been changed o p i acy easons.
In oducing a Mashup-Based App oach o DTCC in BPs 345
IAAP Legal
Depa men
Consul a i e
Bo a d
Technician o
he IAAP
Technician o
he Legal
Depa men
Technician o he
Consul a i e Boa d
Sec e a y
Assis an o
he Legal
Depa men
Assis an o
he IAAP Assis an o he
Consul a i e Boa d
Alex
Lydia
Ca ol Sa m u el Anna
Daniel
Ch is
Diana
Lucas Da id
Business
Manage
Ma io
 
   
 
#

 !
 
 "

 !
#  
Fig. 3. Exce p o he o ganiza ional s uc u e o he IAAP
Figu e 2 also depic s he esou ce assignmen s o he p ocess ac i i ies. No e
ha assigning se e al esou ces o an ac i i y means any o hem can execu e i ,
e.g. ac i i y Re iew esolu ion p oposal can be done by a Technician o he IAAP,
a Technician o he Consul a i e Boa d o a Technician o he Legal Depa men .
Gi en his scena io we a e in e es ed in speci ying and checking Rule 2:
Rule 2: The c ea ion o he esolu ion p oposal d a and i s e ision a e he
e alua ions o he Consul a i e Boa d and he Legal Depa men ha e o be pe -
o med by diffe en oles.
The Business Manage o he IAAP would be e y in e es ed in knowing i Rule 2
is me gi en he cu en BP model and he o ganiza ional s uc u e in o de o do
he p ope changes be o e unning he p ocess, i necessa y. As we a e checking
he ule a design ime, some conside a ions ha e o be done. Specifically, we
should check ha gi en he cu en esou ce assignmen s o ac i i ies, he same
ole can ne e execu e he wo mu ual exclusi e ac i i ies. O he wise we can
conside he p ocess as non-complian because we canno ensu e he ule is
always ulfilled, ha is, i could be me o iola ed depending on he specific
esou ce alloca ion ca ied ou a un ime.
Figu e 4 defines Rule 2 ollowing he a o emen ioned conside a ion. In his
compliance mashup we ha e wo diffe en da a sou ces: (i) a eposi o y o
esou ce-awa e BP models, i.e. models en iched wi h esou ce assignmen s; and