A systematic literature review on the architecture of business process management systems

(1)

ContentslistsavailableatScienceDirect

Information Systems

journalhomepage:www.elsevier.com/locate/is

A systematic literature review on the architecture of business process management systems

Shaya Pourmirza

^∗

, Sander Peters, Remco Dijkman, Paul Grefen

Eindhoven University of Technology, PO Box 513, 5600 MB Eindhoven, The Netherlands

a rt i c l e i n f o

Article history:

Received 11 January 2017 Revised 30 January 2017 Accepted 31 January 2017 Available online 1 February 2017 Keywords:

Business process management system Workﬂow management system Information systems architecture Systematic literature review

a b s t r a c t

Duetothehighcomplexityofmodern-daybusiness,organizationsareforcedtoquicklyadapttoawide rangeofcutting-edge developments. These developmentsinﬂuence the structureand behavior of the business processesthatrepresent thework and oftheBusinessProcessManagement Systems (BPMS) thatsupportthem.Consequently,thearchitectureofBPMShaschangedalotoverthepasttwodecades.

However,thereisnosystematicoverviewoftheresearchdoneinthisareasincetheWorkﬂowreference model ﬁrstset the standard forBPMS architecturein 1995.To bridgethisgap, thispaperpresents a SystematicLiteratureReview(SLR)ofBPMSarchitectures, byanalyzing41primarystudiestakenfrom agrosscollectionof608researchpapers.TheBPMS architecturesthatservedasprimarystudieswere comparedwithrespecttothereferencearchitecturethattheyarebasedon,thelevelofelaboration at whichtheyaredescribed,thearchitecturalstylesthattheyuse,themeanswithwhichtheyareevaluated, andthefunctionalitythattheysupport.Theresultingcomparisonprovidesanoverviewofandinsights intothecurrentbodyofknowledgeonBPMSarchitectures.

1. Introduction

BusinessProcessManagementSystems(BPMS)areinformation systems that interpret business processes to ensure that the ac- tivitiesspecified therein areproperly executed andmonitored by an organization [1].Such systemshave seensignificant industrial adoption and, therefore, their architectures are rapidly evolving in order to fulfill ever-expanding business requirements. Conse- quently, the architecture design ofBPMSs hasbecome an impor- tantdevelopmentactivityintheresearchcommunity[2–12].

ThestudyofexistingarchitecturesofBPMSscanprovideause- fulaccountofhowsuch systemsshould bestructuredinorderto supporttheintendedfunctionalities.Therefore,thispaperprovides acomprehensiveoverviewofthestate-of-the-artbysurveyingex- isting Business Process Management System(BPMS) architectures andsystematicallyidentifying,classifyingandanalyzingthem.For thispurpose,aSystematicLiteratureReview(SLRmethodologywas used, because that provides a means of identifying, interpreting and evaluating the existing body of knowledge in a speciﬁc research discipline [13,14]. In particular, since we seek to provide

∗ Corresponding author.

E-mail addresses: [email protected] , [email protected] (S. Pourmirza), [email protected] (S. Peters), [email protected] (R. Dijkman), [email protected] (P. Grefen).

insight into existing BPMS architectures, our studyis considered amappingstudy(a.k.a.scopingstudy)[15].Assuch,thisSLRcon- tributestoresearchintheareabyprovidingastructuredandcom- prehensiveoverviewofavailableBPMSsarchitecturesandbyiden- tifyingfutureresearchopportunities.

Against this background, the remainder of this paper is or- ganized into four sections as follows. Firstly, Section 2 presents thereview protocolthat wasemployed asa basis forconducting oursurvey. Secondly,Section 3 discusses theevaluation method- ology that was used for classifying and analyzing the selected studies. Subsequently, Section 4 reports on the obtained results.

Then, Section 5 presents some possible research directions and, Section6concludesthepaper.

2. Reviewprotocol

The review protocol, used to conduct our SLR study,speciﬁes the researchquestions (Section 2.1) as well asthe search protocol (Section 2.2) and the selection criteria (Section 2.3), which were employedtoselectrelevantprimarystudies.

Inordertoensurethequalityofthestudy,theguidelinespro- posed in [13,15–17] were followed. Accordingly, the involved re- searcherswere organizedinto two groups, namelya review team andan evaluation team.The reviewteam,whichconsistedoftwo http://dx.doi.org/10.1016/j.is.2017.01.007

(2)

researchersinthedomainofBusinessProcessManagement(BPM), wasresponsiblefor:

– formulatingtheresearchquestions, – developingthereviewprotocol,

– searchingandselectingtheprimarystudies, – developingaclassiﬁcationframework,

– extractingdatafromtheselectedprimarystudies,and – synthesizingandreportingtheoutcomesofthereview.

Theevaluationteam,whichconsistedoftworesearchersinthe domainofBPM andinformationsystemarchitecture,wasresponsiblefor:

– evaluatingtheresearchquestions, – evaluatingthereviewprotocol,

– evaluatingthefinallistoftheselectedprimarystudies, – evaluatingthefinalclassificationframework,and – evaluatingthefinalcontentofthisresearch.

2.1.Researchquestions

This SLR study set out to acquire knowledge about existing BPMSarchitectureswithintheresearchcommunities.Thisgoalcan beachievedby answeringthefollowing centralresearch question (RQ).

RQ Whichrelevantprimarystudieswerepublishedinthearea of BPMSarchitecture?

Inordertoproperlyassesstherelevanceofprimarystudies,we decompose the central research questioninto ﬁve sub-questions.

Inparticular,thesesub-questionsinvestigatethedesign,evaluation and provided functionalities of the architectures in the selected primarystudies.

Thefirstresearchsub-questionseekstofindthefoundation(i.e., whereisthestartingpoint)forthedesignanddevelopmentofthe identifiedarchitecturesintheprimarystudies.Thus,RQ1hasbeen formulatedasfollows:

RQ1Towhatextentwerethearchitecturesin theprimarystudies builtuponexisting(reference)architectures?

The second andthird research sub-questions are used to an- alyze the structure of theidentiﬁed architecturesin the primary studies(i.e.,howthesearchitectureshavebeenpresented).Tothis end, RQ2examines the level ofdetail that has beenprovided by theidentiﬁed architecturesin the primary studies. Thus, this re- searchsub-questionhasbeenformulatedasfollows:

RQ2Towhatextentwerethearchitecturesin theprimarystudies elaborateduponintermsofdetailsandtechnologies?

RQ3 exploresthe high-level decisiondecisions that have been madetodescribetheoverallstructure(i.e.,thearchitecturalstyle) oftheidentiﬁedarchitecturesintheprimarystudies.Thus,thisre- searchsub-questionhasbeenformulatedasfollows:

RQ3Whicharchitecturalstyleshavebeenfollowedbythearchitec- turesintheprimarystudies?

Thefourthresearchsub-questionfocusesonhowtheidentiﬁed architectures in the primary studies have been evaluated. Thus, RQ4hasbeenformulatedasfollows:

RQ4Howwerethearchitecturesintheprimarystudiesevaluated?

Finally,theﬁfthresearchsub-questionconsidersthefunctional- itiesthat areaddressedby theidentiﬁed architecturesinthepri- marystudies.Therefore,RQ5hasbeenformulatedasfollows:

RQ5 Which main functionalities havebeen addressed in the pri- marypublications?

2.2. Searchstrategy

The main strategy employed in our SLR studywas to find as manyscientificpublicationsaspossibleand, subsequently,there- sultswerenarroweddownby applyingpredefinedcriteria.Inthis section,thesearchstrategy,usedtoidentifythepreliminarysetof primary studies, is discussed. We, firstly, provide a set of search strings inSection 2.2.1,and, then, we presentthe search sources (i.e.,on-linedatabases)thatwere employedtoconductthesearch inSection2.2.2.

2.2.1. Searchstrings

The ﬁrst action in the search strategy was formulating a set of search strings. In order to develop the search strings we fol- lowedtheguidelinessuggestedbyKitchenhametal.[17]and,consequently:

(i) theterms“BPMS” and“architecture” werederivedfromthe researchquestionsasthemainsearchtermsinthisstudy;

(ii) “BusinessProcessManagementSystem”,“workﬂowmanage- ment system”, “orchestration execution system” “choreography executionsystem” were utilized asalternative terms (i.e.,alternativespellingortechnicalsynonyms)for“BPMS”;

(iii) the Boolean AND was used to connect the search terms identiﬁed in step (i) in order to narrow down the search results (e.g., we employed “BPMS” AND “architecture” as a groupofsearchstringsinourstudy);

(iv) theBooleanORwasusedtoincorporatealternativetermsin step(ii)inordertoprovidea widerrangeofsearchresults (e.g.,“BPMS” OR“Business ProcessManagementSystems”was employedasapartofthesearchstringsinthisstudy);

All the mentioned alternative terms instep (ii),in construct- ing the ﬁnal search strings, were shortened in order to retrieve as many results as possible. Forexample, the term, “system” was removed fromthe end of the alternatives. The term, “workﬂow”

wasusedinsteadof“workﬂow(management)system” sinceithas beenusedtorefer tothesameconceptintheliterature, whereas

“business process” and “Business Process (management) System”

refertodifferentconcepts(i.e.,businessprocess,usually,hasbeen used to refer toa business process model andnot business pro- cesssystem).WherecomplexBooleansearchstringswerenotsup- ported by a database, a designated search string was used for that database. These guidelines, thus, ledto the following search strings:

ST1(“architecture”AND“bpm”)OR

ST2(“architecture”AND“businessprocessmanagement”)OR ST3(“architecture”AND“workﬂow”)OR

ST4(“architecture”AND“orchestration”)OR ST5(“architecture”AND“choreography”)

Itshouldbe notedthat asynonymfortheterm,“architecture”

(i.e., system structure) was not considered since no results were found forthe constructed search strings with the term, “system structure” instead of “architecture” (e.g., “system structure” AND

“bpm”).

2.2.2. Searchsources

The second action in the search strategy was choosing the search sources.This actionallows other researcherstoobtain the same search outcome asthat which we gatheredfrom themen- tionedsearchstrings.Basedon[18]and[19],scientiﬁcsearch en- ginesandindexingsystemsintheﬁeldofcomputerscience were usedaspreliminarysources.Table1showsthedatabasesthatwere consideredinthesearchstrategy.

(3)

Table 1

Utilized electronic databases.

Database Institution Abbr.

ACM Digital Library ACM ACM

IEEE Xplore IEEE IEEE

SciVerse Scopus Elsevier ELSV

SpringerLink Springer SPRG

Web of science Thomson Reuters ISI

Thesedatabaseswerechosen sincetheyreasonablycovermost ofthe scientiﬁcpublications(e.g.,journalpapers,conference proceedings andworkshop papers) in theﬁeld ofcomputer science.

Asalsosuggestedby[20],thesedatabasesguaranteetoprovidethe conﬁdencelevelforinclusionofalltherequiredprimarystudies.

2.3. Selectioncriteria

The aim of the selection criteria was to identify the relevant primary studiesthatadequately providedanswersto theresearch questions. Therefore,according tothese criteria, the obtainedre- sultswerenarroweddownbyexcludingthestudiesthatwerenot relevant to the research questions. As suggested in [21], the se- lectioncriteriaconsistedofa setofinclusioncriteriaandaset of exclusioncriteria.Theinclusioncriteriawerefurtherclassiﬁedinto threeclasses:

(i) assess-ability criteria, which measured whether a primary studywasavailableforfurtherassessments;

(ii) paper speciﬁcation criteria, which measured whether the meta-informationofaprimarystudy(i.e.,title,authors,jour- nalorconference,publication yearandcitation)weresatis- factory;and

(iii)content criteria, which measured whether the content of a primarystudyaddressedtheresearchquestions.

Thecompletesetofcriteriadeterminingtheinclusionorexclu- sionofprimarystudiesarepresentedinTable2.

IC-A1 andIC-A2 aretheprimaryrequirements.IC-A1only con- sidersprimarystudiesthatincludeon-lineaccessiblefull-textver- sionsandIC-A2onlyacceptspublicationsthathavebeenfullywrit- teninEnglish.Thenextfourinclusioncriteria(IC-P1toIC-P4)consider the meta-information concerning a study. IC-P1 simply ac- ceptspublicationsthatfullycontainonegroupofsearchstringsin theirtitles.Contrarytoexpectations,twopublicationsappearedin the searchresults fromtheWeb ofScience,whiletheir titlesdid not fully meet the search strings’ requirements and hence IC-P1 wasemployedtoremove them.IC-P2onlyallowsprimary studies thathavebeenpublishedinpeer-reviewedscientiﬁcjournals,con- ferences orworkshops. IC-P3 measures whether astudy wasdu- plicated.Tothisend,theduplication-measure,accordingtoKofod–

Petersen’ssuggestion[22],wasdeﬁnedasfollows:

– ifaprimarystudywiththesamenameandfromthesameau- thorshasbeenindexedinmorethanone source,they willbe consideredasonestudy;and

– if morethanone primary studyfromthesameauthorson an approximately the same topic have been published, only the mostrecentonewillbeincluded.

Finally, IC-P4 measures whether a primary study passes the time-citationcriterion.AspointedoutbyMeho[23],citationanal- ysishas beenused oftenoverthe pastthree decades toevaluate andquantifytheimportanceofscientiﬁcresearch.Itmeasuresthe qualityofarticlesontheassumptionthatinﬂuentialresearchstud- iesarecitedmorefrequentlythanothers.However,citationanaly- sis,solely,doesnotconsiderthepublicationdatewhichmayaffect this analysisasrecent articlesare likely to havea lower citation

number.In orderto mitigate thislimitation, the publication date wascombinedwiththecitation analysis.Consequently,thetime- citationmeasurewasdeﬁned,onthebasisofFig.1,asfollows.

– If astudy hasbeenpublishedsince 2010, it willdirectly pass the time-citation criterion (i.e., recentarticles will not be as- sessedbasedontheirnumberofcitations).

– Ifa studyhasbeenpublishedbetween2010 and2000,it will only passthe time-citationcriterion when itsnumber ofcita- tion(atthetimeofsearch)isequaltoorgreaterthanthemin- imumnumberofcitationoftheaveragenumberofcitationsfor allpublicationsinthisperiod(i.e.,33.12)andtheaveragenum- berofcitationsforthepublicationyear.Forexample,consider- ingthepublicationsthathavebeenpublishedin2000,theyare onlyincludediftheircitationnumbersarehigherthan33(i.e., min(33.12, 139.1)), while forpublicationsthat have beenpub- lished in2002,theyareonly considerediftheircitationnum- bers are higher than 11(i.e., min(33.12, 11.6)).The reasonfor splittingthisperiodinto10individual groupsisthat,asshown inFig.1,thestandarddeviationoftheaveragenumberofcita- tionsperyearinthisperiodisveryhigh.

– Ifastudyhasbeenpublishedbefore2000,itwillonlypassthe time-citationcriterionwhenitsnumberofcitationsisequalto orgreaterthantheaveragenumberofcitationsofallthepub- lications before 2000 (i.e., an article that has been published before 2000 is onlyincluded when its number of citations is higher than 34). As shown in Fig. 1, the standard deviation in this period is approximately one third of the average and, therefore, based on the so-called three-sigma rule of thumb [24], it suggests that data in this period are distributed nor- mally.Withfurtherinvestigation,itisrealizedthattheaverage numberofcitationsperyearinthisperiodareconsistentwith anormaldistribution(P=0.83),wherethenormaldistribution hasanaveragevalueof34.161andastandarddeviationof14.8 and,therefore,thiswholeperiodisconsideredtogether.

The ﬁrst content inclusion criterion, IC-C1, aims to consider studies that propose an architecture for a BPMS(thus if the title ofaprimarystudycomprisesof“BPMS” and“architecture” butno architectureisactuallypresentedinthepaper,itwillbeexcluded fromthe study). The second content inclusion criterion, IC-C2, is alsodeﬁnedbecause comparingvarious architectureswithdiffer- entapplicationdomain requirementsis,indeed,not an easy pro- cessand, therefore,only the domain-independentcomponents of theselectedBPMSarchitecturesareconsidered.

If a study does not meet any one of above-mentioned criteria, it will be excluded and, subsequently, other criteriawill not be evaluated. Primary studies which pass theseinclusion criteria are, nevertheless, subjectto further assessments on the basis of twoadditionalexclusioncriteria.Thefirstexclusioncriterion,EC1, excludesall primary studies that onlypropose a specific compo- nentofaBPMS(e.g., ifa publicationmeets allthe inclusioncrite- riabutitonlypresentsanarchitecturefortheWorkflowdefinition tools it will be excluded fromthis study). There is an exception forthiscriterion;ifaprimarystudyonlyproposesanarchitecture fortheWorkflowenactment(i.e.,theBPMSengine)component, it will not be excluded from the study. Finally,the very last selec- tioncriterion,EC1,excludesall primarystudies thatonlypropose non-functionalrequirements(e.g.,performanceorreliability)since, althoughnon-functionalrequirementsarecritical,thefocusofthis investigation is mainly on the functional components of a BPMS architecture.

2.4.Conductingthereview

Inthis section, we presentthe steps and intermediate results thatleadtoselectingtheﬁnalsetofprimarystudies.

(4)

Table 2

Inclusion/Exclusion criteria utilized for the SLR study.

Criteria Description

Assess-ability IC-A1 Is the full-text of study digitally accessible?

Inclusion criteria IC-A2 Has the study been written in English?

Paper speciﬁcation inclusion criteria IC-P1 Does the study’s title comply with the search strings?

IC-P2 Has the study been published in a scientiﬁc peer-reviewed source?

IC-P3 Does the study meet the duplication measure?

IC-P4 Does the study meet the time-citation measure?

Content inclusion criteria IC-C1 Has the study proposed an architecture for a BPMS?

IC-C2 Has the study included domain-independent BPMS components?

Exclusion criteria EC1 Has the architecture proposed a speciﬁc component for a BPMS? ^∗ EC2 Has the study only proposed non-functional requirements for a BPMS?

Fig. 1. Average number of citation per year over time.

To begin this selection procedure, we searched for papers whosetitles containeda certain group of search strings in order tofinda set ofpotential relevantprimary studies. Atotal of608 studiesweretakenfromthefivescientificdatabases.Wedesigned adatabasetostoretherelevantbibliographyinformationfromthe primary studies. This bibliographic information consisted of the followingattributes:

– electronicdatabase,whichindicatedthedatabasethateachpri- marystudywasretrieved from;thevaluesforthisﬁeld came fromTable1,

– title,whichindicatedthetitleofeachprimarystudy, – authors,whichindicatedtheauthorsofeachprimarystudy, – year, which indicated the year that each primary study was

published,

– source, which indicated the journal, conference or workshop whereeachprimarystudywaspublished,

– citation,whichindicated thenumberofcitations foreach pri- marystudy.

We then employed a developed program¹ to import the bib- liographies as well as the numbers of the citations for the 608 found studies into the database. To this end, for each primary study,we extracteditsbibliography fromthesearchsources (e.g., IEEEXplore)andits numberofcitations fromGoogleScholar.We used Google Scholarto obtain a faircomparison among the primary studies since the number of citations for the same article maydifferinvarioussources,and– appropriately– alltheprimary studies are available in Google Scholar.In addition, because this numbercanchangequicklyoverashortperiod,weretrievedthese numbersforalltheselectedprimarystudiesatthesametime.

Having ﬁlled the database, we ran a script to determine the duplicated primary studies in the database. This action was not onlybasedonthepublications’titlesbutalsoweconsideredother availableinformation,suchasgroupsofauthors(cf.SelectionCrite-

1The source code of this program is available at https://github.com/shoopi/

BPMS-Architecture-Survey

rionIC-P3).We,furthermore,rananotherscripttoapplythetime- citationmeasure(cf.SelectionCriterionIC-P4).Afterhavingunder- takenthesetwosteps,thenumberofselectedprimarystudiesre- ducedto301and135respectively.Fig.2showsthedistributionof theselectedprimarystudiesafterapplyingthetime-citationcrite- rionoverthesearchperiod.Then,

weextractedthefulltextof128relevantprimarystudies(7ar- ticles were not available due to the University’s License).Among theselectedprimarystudies,two paperswerewritteninadiffer- entlanguage (i.e.,oneGerman andone Chinese)andtwo articles had been added to the database but their titles did not include any of the search string groups. Consequently, we manually ex- cludedthesefourstudiesfromthedatabaseduetoIC-P1andIC-P2. Additionally, 6 papers had been published in non-peer-reviewed sources(e.g.,magazines)andthesewereexcluded aswell.Finally, the review team members individually read all the 118 selected primarystudiesandcriticallyassessedtheirrelevanceaccordingto the contentinclusion andexclusioncriteria(i.e., IC-C1,IC-C2,EC1 andEC2).Havingdiscussedtheresultsthatwereobtained,thereview teamagreed on41primary studies thatwere considered to beappropriatefortheﬁnalinclusion.Table3showstheresultsof ourselectionprocedure.

3. BPMSarchitectureclassiﬁcationframework

Thissection presents a frameworkto classify the BPMS architectures fromthe 41primary studies. Thisframework covers ﬁve aspects,namely:RootArchitecture,LevelofElaboration(LoE),Archi- tecturalStyle, EvaluationMethod and SupportedFunctionality.Each oftheseﬁveaspects aimsatprovidingtheresults relatingto one oftheresearchsub-questions (i.e.,RQ1toRQ5).Theseaspects are furtherdescribedintherestofthissection.

3.1. Rootarchitecture

Theﬁrstaspectinourclassiﬁcationframeworkisrootarchitec- ture.Thisaspectisintroducedto representwhethertheproposed

(5)

Fig. 2. Before and after applying the time-citation criterion.

Table 3

Final results of the primary study selection procedure.

Criteria Reviewer 1 Reviewer 2 Selected

Excluded by IC-C1 68 72 68

Excluded by IC-C2 2 7 3

Excluded by EC1 6 5 5

Excluded by EC2 1 1 1

Total Excluded 77 85 77

Total Included 41 33 41

architecture ina primary studyis built upon other proposed architectures.Wehavedeﬁnedtwoclassesfortherootarchitecture aspect,namely:ReferenceArchitectureandConcreteArchitecture.

Since no commonly accepted definition of the term software referencearchitecture exists [25], wehave adoptedthedefinition ofreferencearchitecture givenin[26],whichintroducesthiscon- cept asa predefinedguideline(i.e.,an abstractblueprint[27]) for the architecture of a particular domain (e.g., in our case BPMS), wherethestructures,respectiveelementsandtherelationshipamong theelementsprovideatemplateforconcretearchitectures.

A concrete software architecture presents the structure of a softwaresystemintermsoffunctionalcomponentsandtheinter- relations among them for a specific system. In many cases, con- cretearchitecturesaredesignedinordertofulfillthebusinessre- quirements ofa singleorganization; however,thesearchitectures canalsobedesignedinanorganization-independentmanner[27]. Consequently,referencearchitecturestypicallyaimatproviding high-level design principles that can be reused in multiple situ- ationsin a specificdomain [25] whileconcrete architecture aims atdepictingthefunctionalstructure ofasystemthat maynot be reusableforotherarchitectures.Ideally,aconcretearchitecturecan bedesignedbasedononeormorereferencearchitectures.

Firstly, weconsider thefollowingthree referencearchitectures inourframework.Then,weaddedadditional(reference) architectures,whentheprimarystudieshavebeenbuiltaccordingtoother (reference)architectures.

3.1.1. WfMCreferencemodel

The first discussions regarding reference architecture for a Workflow management system emerged during the 1990s when the Workflow Management Coalition (WfMC) put forward the Workflow reference architecture [28] in 1995. In this document the authorpresenteda referencearchitecture forWorkflow man- agementsystems byidentifying theircharacteristics, byproviding a commonterminologyandby introducingthe necessarycompo- nentsforWorkflowmanagement systems.Thisreferencearchitec- tureisshowninFig.3.

3.1.2. Mercuriusreferencearchitecture

Three years later, Grefen and Remmerts de Vries presented a new referencearchitecture fora full-fledged Workflow system, called Mercurius [3]. This reference architecture proposed sup- portingheterogeneousenvironmentsandmobileWorkflowclients

Fig. 3. The workﬂow reference model by WfMC (adapted from [28] ).

Fig. 4. Mercurius workﬂow reference architecture(adapted from [3] ).

alongsidethefunctionalitythatwasofferedin[28].TheMercurius referencearchitectureisshowninFig.4.

3.1.3. S3referencearchitecture

Thelast decadehasseen a growing trendtowards developing moreﬂexibleandagileinformationsystemsinordertoovercome therapidchangesin technologiesaswell astodealwiththedy- namismissuesinnewbusinessenvironments.Service-OrientedAr- chitectureplaysanimportantroleinaddressingtheseissues.Aref- erencearchitectureforsuchsystemshasbeenproposedbyArsan- janietal.[29],calledService-OrientedSolutionStack(abbreviated asS3).TheS3providesacomprehensivearchitecturaldeﬁnitionof aService-OrientedArchitecture(SOA)throughninelayers.Thisref- erencearchitectureconsistsofarchitecturalbuildingblocksandthe relationshipsamongtheblocks,therelationshipsamongthelayers, interaction patterns,and architectural decisions.One can employ

(6)

Fig. 5. Reference model and logical layers in S3(adapted from [29] ).

Fig. 6. The Level of Elaboration (LoE) Cube.

allthese elementstocreate aSOA solution. Thisreferencearchi- tecturehasbeenalsoconsideredinthisstudysincewehaveintro- ducedtwo technical synonymsfor BPMS with regard to Service- Oriented Architecture(SOA). In particular, we have employed or- chestrationand choreography (execution systems) as alternatives inoursearchstrings(cf.Section2.2).TheS3referencearchitecture isshowninFig.5.

3.2.LevelofElaboration(LoE)

The second aspect inourclassiﬁcation frameworkis theLevel of Elaboration (LoE). This aspect facilitates a comparison among the selected architectures by positioning them into a three- dimensionalcube[27],calledtheLoEcube(Fig.6).Thiscuberep- resentsthedimensionswithrespecttowhichan architecturecan be elaborated in more orless detail. The dimensions of the LoE cube are: the Aggregation dimension, the Abstraction dimension andthe Realization dimension are presented in theremainder of thissection.

3.2.1. Aggregationdimension

The termaggregation hasbeen usedto define thelevel ofde- tailinaninformationsystemarchitecturewithregardtothenum- ber of recognized components [27]. Based on this definition, an architecture, at the highest level of aggregation, presents a sys- temasasingleblackboxwhilean architectureatthelowest level ofaggregationillustrates asystemwithverysmallidentifiedsub- components.Wehave furtherdivided theaggregationdimension, basedontheaspect frameworkforinformationsystems[30],into twosub-dimensions,namely(i)thesystem-aggregationand(ii)the data-aggregation.

Fig. 7. Example of architecture at the zero level and the ﬁrst level of system aggregation.

System-Aggregation Dimension (S-AG). The system-aggregation di- mensionaimsatpositioningarchitecturesintheLoEcubeinterms of the granularitydecomposition of their functional components.

Based on thearchitecture that we have reviewedandalso based on the granularity levels that have been used in presenting the Workflow reference model and Mercurius reference architecture, we have identified five distinct levels for the system-aggregation dimension.

S-AG(0). Anarchitectureatthislevelofthesystem-aggregationdi- mensiondepictsa BPMSasablackbox.Ifan architectureconsists ofacomponentthat isinthisgranularity level,e.g.,labeledwith Business Process Management System or similar terms(e.g., Work- ﬂowmanagementsystems),wewillpositionitattheS-AG(0)level ofsystem-aggregation.

S-AG(1). Anarchitectureatthislevelofthesystem-aggregationdi- mensionshowsahigh-level architecturalviewofthecomponents of a BPMS that are derived based on the high-level business requirements and the relationships among them. Architectures at thislevelare comparablewiththeWorkflow referencemodel(as shown in Fig. 3) which includes: (i) Workflow enactment services orWorkflowengines,(ii)processdefinitiontools,(iii)Workflowclient applications,(iv)administrationandmonitoringtools,(v)invokedap- plications, and(vi) otherWorkflow enactmentservices. If an archi- tectureconsistsofcomponentswithasimilar granularitylevelas mentionedintheWorkflowreferencemodel,wewillpositionitat theS-AG(1)level ofthesystem-aggregation dimension.Fig.7 de- pictsthedistinctionbetweenS-AG(0)andS-AG(1)levels.

S-AG(2). Anarchitectureatthislevelofthesystem-aggregationdi- mensiondisplays an architecturalview on theemployed compo- nentsofaBPMS inmoredetail.This levelcanbe seenasa view insidethecomponentsthat areidentiﬁedattheS-AG(1)level.Ar- chitecturesatthislevelarecomparablewithMercurius(asshown inFig.4),inwhichtheWorkﬂowenactmentservermoduleincludes theWF² ServerEngine,theWFClient Interfaceandplatforminter- facemodulessuchas:AS/OS/DBMSInterfaces.Ifanarchitecturecon- sistsofcomponentswithasimilargranularitylevel,wewillposi- tion itat the S-AG(2)level ofthe system-aggregation dimension.

Fig.8illustrates thedifferencesbetweenS-AG(1)andS-AG(2)levels.

S-AG(3). Anarchitectureatthislevelofthesystem-aggregationdimension illustrates an architectural view on the functional sub- components of a BPMS that are derived based on the low-level

2Workﬂow

(7)

Fig. 8. Example of components at the ﬁrst and second level of system aggregation.

Fig. 9. Example of components at the second and third level of system aggregation.

requirements.Thislevelcanbe seenasaview insidethecompo- nentsthatareidentiﬁedattheS-AG(2)level.Architecturesatthis level are comparablewith Mercurius [3], in which theWf Server EnginemoduleincludestheActionExecutor,theAction Synthesizer, the Event Analyzerandthe Event Receptor.If an architecture con- sistsofcomponentswithasimilargranularity level,wewillposi- tionitattheS-AG(3)levelofsystem-aggregationdimension.Fig.9 showsthedistinctionbetweenS-AG(2)andS-AG(3)levels.

S-AG(4). Finally, an architecture at this level of the system- aggregationdimensionprovidesaverylow-levelarchitecturalview onthefunctionaldetailedsub-componentsofaBPMS.Weonlyob- served one architecture at thislevel, where a componentat the S-AG(3)levelwasbrokendownintoinnercomponents.

Data-Aggregation Dimension (D-AG). The data-aggregation dimension aims at positioning architectures in the LoD cube in terms ofthegranularity decompositionoftheirdata-basedcomponents.

Based on the architecture that we reviewed, we have identiﬁed fourdistinctlevelsforthedata-aggregationdimension.

D-AG(0). Anarchitecture at thislevelof thedata-aggregation dimension depicts no specific data-related component in a BPMS architecture since, atthis level, the whole systemis represented asablackboxand, thus,nospecificationdata-relatedcomponent is expected. However, some architectures at lower levels of the system-aggregationdimensionmayalsohavenoexplicitindication of anydata-related componentsalthough data are implicitlyconsidered.AnexampleofthislevelistheWorkflowreferencemodel [28]which is positioned at the S-AG(1) for the system-aggregation dimensionbutattheD-AG(0)levelofthedata-aggregationdimension. In summary, if an architecture has no explicit data-related components – nevertheless, data are implicitlyconsidered in the

Fig. 10. Example architecture at the zero level and the ﬁrst level of data aggregation.

Fig. 11. Example of components at the ﬁrst and second level of data aggregation.

architecture– wewill still positionitatthe D-AG(0)level ofthe data-aggregationdimension.

D-AG(1). An architecture atthislevel ofthe data-aggregationdi- mensionshowsahighlevelarchitecturalviewofthedata-related components ofa BPMS which can usually be depictedvia a few Database Management System(DBMS) components. Architectures atthislevelarecomparablewithMercuriusatitsGlobalWorkﬂow ManagementSystemarchitecture,whichincludes:aDBMScompo- nentaswell astwo DataStore data-related components.Ifanar- chitectureconsistsofdata-relatedcomponentswithasimilargran- ularity level,wewill positionitatthe D-AG(1)levelof thedata- aggregationdimension.Fig.10depictsthedistinctionsbetweenthe D-AG(0)andD-AG(1)levels.

D-AG(2). An architecture atthislevel ofthe data-aggregationdimension displays an architectural view on the employed data- relatedcomponents ofa BPMS in more detail. This level can be seen as a view inside the components that are identiﬁed at the D-AG(1)level.ArchitecturesatthislevelarecomparablewithMer- curius atthe detailed architecturesof inner components such as the Workﬂow enactment server architecture, which includes: a Process Data, a Production Data andan Application Data. Ifan ar- chitectureconsistsofdata-basedcomponentswithasimilargran- ularity level,wewill positionitatthe D-AG(2)levelof thedata- aggregation dimension. We observed three architectures at this level,wherea componentattheD-AG(2)level wasbroken down intoinner components.Fig.11illustrates thedifferencesbetween theS-AG(1)andS-AG(2)levels.

D-AG(3). Finally, an architecture at the ﬁne-grained level illus- tratesanarchitecturalviewontheentitiesthatareusedinaBPMS.

Architectures at this level are comparable with the agent-based cross-organizational Workﬂow architecture [31] which includes a classdiagramforaprocessspeciﬁcationwithasetofentitiessuch asaRole,aDataFlowandanEventGrouping.Ifanarchitecturepro- videsan Entity Relationship Diagram(ERD) ora ClassDiagram of its entities, we will position it at the D-AG(3) level of the data- aggregationdimension.Fig.12 showsthe distinctionbetweenthe D-AG(2)andD-AG(3)levels.

3.2.2. Abstractiondimension(AB)

Thetermabstractionhasbeenusedtodeﬁne thelevelofcon- cretenessinaninformationsystemarchitecturewithregardtothe softwarebuildingblocks[27].Basedonthisdeﬁnition,anarchitec- tureatthehighestlevelofabstractionpresentsroughinformation aboutthecomponentsthereinwhilean architectureatthelowest

(8)

Fig. 12. Example of components at the second and third level of data aggregation.

Fig. 13. Example of components at the ﬁrst, second and third level of abstraction.

level of abstractionillustrates concrete information for the com- ponentstherein (i.e.,ﬁnal decisionaboutthe products withtheir versions).Based on the architecturesthat we have reviewed,we haveidentiﬁedthreedistinctlevelsfortheabstractiondimension.

AB(1). An architecture atthis level of the abstractiondimension showsvery-highleveldetailsconcerningthecomponentsthatcon- stitutea BPMS architecture.Anarchitecture isatthislevelofab- straction,ifforthecomponentsthereinnoinformationaboutspe- cificsoftware products isprovided. Architectures atthislevelare comparable with the Workflow reference model which includes theprocessdefinitiontoolscomponent.Ifanarchitectureconsistsof componentswitha similar abstractionlevel asmentioned inthe Workflowreferencemodel,wewillpositionitattheAB(1)levelof theabstractiondimension.

AB(2). An architecture atthis level of the abstractiondimension displaysdetailsconcerningthecomponentsthatconstituteaBPMS architecture. An architecture is at this level of abstraction, if for eachcomponentthereinsome informationabouta familyofsoft- waremodulesorafamilyoftechnologiesareprovided.Asoftware familyisdefinedasasetofsystemswithcommonhigh-levelfunc- tionalitiesbutwithpossiblydifferentvariations[32].Architectures atthis level are comparable withthe architecture that has been proposed in[33] for aSecure BPMS inService-Oriented Environ- mentswhich includes theBusiness ProcessModeling and Transfor- mationcomponents.Comparingthesecomponentswiththeprocess definitiontool,itcanbeseenthatthecomponentsatAB(2)provide more concrete information (i.e., the term, tool, is more abstract thantheterm,modelingandtransformation).Ifanarchitecturecon- sistsofcomponentswithasimilarabstractionlevelasmentioned in [33], we will position it at the AB(2) level of the abstraction dimension.Thefirsttwo columnsinFig.13depictthedistinction betweentheAB(1)andAB(2)levels.

AB(3). Finally, an architecture at this level ofthe abstraction dimension provides low-level details concerning the components thatconstituteaBPMSarchitecture.Anarchitectureisatthislevel of abstraction, if for the components therein some information aboutspeciﬁcsoftware modules ortechnologiesare provided.Ar- chitecturesatthislevelare comparablewiththearchitecturethat has been proposed in [34] for a new web service composition techniquewhich includes the BPEL Editor component. This component shows that the Web Services Business Process Execution Language(WS-BPEL)istheonlymodeling languageforthemodel- ing componentwhich wasidentiﬁed at theAB(2) level. Ifan ar- chitectureconsistsofcomponentswithsimilarabstractionlevelas

Fig. 14. Example of components at the different levels of the realization dimension.

mentionedin[34],wewillpositionitattheAB(3)leveloftheab- straction dimension.The second twocolumns inFig.13 illustrate thedifferencebetweentheAB(2)andAB(3)levels.

3.2.3. Realizationdimension(RE)

The term, realization, has been used to define the level of business-orientation in an information system architecture [27]. Based on this definition,an architecture atthe first level of the realizationdimensionpresentsbusiness goalsthatneedtobeful- filled(i.e.,whatwewanttoachievewiththesystemdescribedby anarchitecture)whileanarchitectureatthefourthlevelofthere- alizationdimensionillustratestechnologiesthatenablesthefulfill- ment of the business goals (i.e., how we want to achieve things withan architecture). Based on[27] we have identified fourdis- tinctlayersfortherealizationdimension.

RE(1). An architecture at this level of the realization dimension only illustrates the business requirements that can be addressed by thearchitecture. Incontrastto theother threelevels, howre- quirementscan actually be metisout ofthe scopeof thisarchi- tecture.Architecturesatthislevelofrealizationaredesignedtobe usedbydomainexperts.Weobservednoarchitectureatthislevel ofrealizationamongthearchitecturesthatwereviewed.

RE(2). An architecture at this level of the realization dimension displaysmoredetailonthebusiness requirementsratherthanon the technologies. Architectures atthislevel ofrealization are de- signedtobeusedbybothdomainexpertsandinformationsystems developers.Thesearchitecturesarecomparablewiththearchitec- turethathasbeenproposedin[10]foranewBPMSthatintegrates bothgoal-andactivity-basedperspectivewhichincludesthe(Busi- ness)GoalWorkﬂow Enginecomponent. Ifan architectureconsists of components with a similar realization level as mentioned in [10],wewillpositionitattheRE(2)leveloftherealizationdimension. We observed three architectures atthis level of realization amongthearchitecturesthat wereviewed.Theﬁrst twocolumns inFig.14depictthedistinctionbetweentheRE(1)andRE(2)levels.

RE(3). An architecture at this level of the realization dimension showsmoredetailaboutthetechnologiesratherthanbusinessre- quirements. Incontrast to the previous levels, thislevel includes averyhigh-levelview ofthebusinessrequirements.Architectures at this level of realization are designed to be used by both in- formationsystemsdevelopersanddomainexperts.Thesearchitec- tures arecomparablewith theWorkﬂow referencemodel[28].If an architecture consists ofcomponents witha similar realization level asmentioned in[28],we will position itat the RE(3)level oftherealizationdimension.Themajorityofthearchitecturesthat wereviewedarepositionedatthislevelofrealization.Thesecond andthirdcolumnsinFig.14illustratethedifferencesbetweenthe RE(2)andRE(3)levels.

RE(4). Finally, an architecture at this level of the realization dimension provides details concerning with how business requirements can be achieved in terms of using existing technologies.

Architectures at this level ofrealization are designed to be used

(9)

by informationsystems developers. These architecturesare com- parablewiththearchitecturethathasbeenproposedin[35]fora newdynamicPeer-to-Peer(P2P)BPMS whichincludescomponents thathavebeendesignedbasedontheconceptsoftheWebWork- ﬂow Peer Directory(WWPD)and, thus, itis onlyfocused on how

‘sharing process models among all Workﬂow participants’ (as a mainbusinessrequirement)canbeachievedintermsofusingthe WWPD (as an existing technology). If an architecture consistsof componentswitha similarrealizationlevelasmentionedin[35], wewillpositionitattheRE(4)leveloftherealizationdimension.

ThelasttwocolumnsinFig.14showsthedistinctionbetweenthe RE(3)andRE(4)levels.

3.3. Architecturalstyle

Thethirdaspectinourclassificationframeworkisarchitectural style.This aspectisintroduced torepresenthigher-level architec- turaldesigndecisionsthathavebeenmadetodescribetheoverall structure ofan architecture. Accordingto thedefinition proposed by Taylor etal. [36], architectural style is a set ofdesign decisions andconstraints that comprises the styleof an architecture, aswell asthebeneficial qualitiesinduced bythesedecisions and constraints.Consequently,thearchitecturalstyleaspectinourclas- sificationframeworkprovides thehigh-level designdecisions(and constraints) regarding the style of BPMS architectures. Based on [36] and [27],wehaveadoptedtwomainclassesofarchitectural style:Component-BasedStyleandLayeredStylesincethesetwohave beenmainlyusedinthe41primarystudies.

3.3.1. Component-basedstyle

The component-based style deﬁnes structure of an architecture by clustering coherent functionalities into components and encapsulating these functionalities by providing Application Pro- grammingInterfaces(APIs)that canbeusedbyothercomponents.

This enforces high cohesion within andlow couplingamong the identified componentsinanarchitecture.Therefore,thisstylecan increase the modifiability of an architecture which is defined by Fielding astheease withwhicha change canbe madeto an architecture [37]. In addition, the component-based style provides autonomytoa greatdegree inthesensethat theidentified components therein can freely make use of each other. However, as suggested in [36], thislack of restriction in the structure of the component-basedstylemayleadtoahighlycomplexarchitecture and,thus,hasanegativeeffectonthescalabilityofanarchitecture (which isdefined by Fielding asthe ability of an architecture to support largenumbers ofcomponents,orinteractions amongthe components,withinanactiveconfiguration[37]).

If an architecture has been designed based on the above- mentioned characteristics, we will position it inthe Component- Based Style class of the architectural style aspect in our framework. Inthesame way,theWorkﬂow referencemodel,asshown inFig.3,ispositionedinthisclassofarchitecturalstyle.

3.3.2. Layeredstyle

The layered style deﬁnes the structure of an architecture by distinguishing functionalities into an ordered sequence of layers, whereby each layer offers services (e.g., by providing APIs) that can be employed by the components residing in the above layers.TherearetwomaindesignsofLayeredStyle:(i)StrictLayering (alsoknownasLinearLayering)and(ii)LooseLayering(alsoknown asAcyclicLayering).Inastrictlayeringstyle,alayercanonlymake use ofthelayer directlybelow itwhile,in aloose layering style, a layercanmakeuseofall thelayers belowit (i.e.,it canbypass some layersbelow).Thisarchitecturalstyleoffersaveryclearde- pendency structure since the lower layers are independent from

theupperlayers. Therefore,theupperlayers canevolve indepen- dentlyfromthelowerlayers aslongastheinterfacesemantics is unchangedand,thus,itcanbothimprovethemodiﬁabilityandthe scalability of an architecture. However, as suggested in [36], the strictlayering maycauseadecreaseinthe performanceofa system.

If an architecture has been designed based on the above- mentionedcharacteristics,we willpositionitintheLayeredStyle classofthearchitectural styleaspectinourframework. Itshould be noted, however,that ifa combinationof thesetwo styles has beenused (i.e., using a component-basedstyle combined witha layered style resulting in a stratified component-based architecture [27]), we will also position this architecture in the Layered Styleclassofthearchitecturalstylesincelayeredarchitecturespro- videmorestructure.Inthesameway,[9]and[38]arepositioned inthisclassofarchitectural style.In[9]theauthors proposedan architecturedesignofadistributedBPMSinwhichtheseparation oftheprocess logic (in one layer)and theapplicationlogic (in a layerabove) can improvethe flexibility andscalability ofthe re- alizedBPMS. In[38] theauthorsproposed an extended BPMSar- chitecture, inwhich aservicecontracting a layer,servicebinding layerandaserviceinvocationlayerhavebeenusedtoenableflex- ibility by dynamically binding activities to their implementations atruntime.

Considering the layered architecture, since we are also inter- ested in the rationale that underlies the structure and design of theconstituentlayers,wefurtherclassiﬁedthisstyleintotwosub- classes: (i) the Object-Oriented Web Workﬂow Peer Directory(SoC) layering design principle, and (ii) the Client-Server Layering designprinciple.Theformerdesignprinciple,makesaseparationbe- tweenthe presentationlayer(i.e.,(graphical)userinterfaces), the logic/businesslayer(s), andthe persistentlayer (i.e., dealingwith data)whilethelatterdesignprinciplemakesadistinctionbetween theproviderofresourcesandservices(i.e.,calledserver),andthe consumerofthatresourcesandservices(i.e.,calledclient).

3.4.Evaluationmethods

The fourthaspect in our classiﬁcation framework is the evaluation method.Thisaspectis introducedto representthewayin whichselectedarchitectureshavebeenevaluated.Consideringthe 41 selectedprimary studies,we have only identiﬁed 2classes of theevaluationmethod:ImplementationandCaseStudy.

3.4.1. Implementation

Implementationisdefinedastheprocessoftransitingandmap- pingdesigndecisionsintospecificimplementationconstructs(e.g., softwarecomponents)[36].Thesedesigndecisionsareusuallyde- scribedbythesoftwarearchitectures(e.g.,inaformalarchitecture descriptionlanguage). Therefore,successfulsoftwareartefacts ap- pearasconsequencesofwell-designedsoftwarearchitectures.Im- plementationisparticularlyusefulinevaluatingtheapplicabilityof asoftwarearchitectureand,thus,ithasbeenusedinmanyarticles asanevaluationmethodsuchas[39]wheretheauthorsdesigned, implemented,deployedandevaluated theSwinFlow-Cloud Work- flowprototypebasedontheAmazonWebServicescloud.

3.4.2. Casestudy

In some studies, case studies have been designed to quantify the appropriateness of software architectures. Often, these case studies aim at measuring particular aspects of software systems such asevolution orperformance. Therefore, ifarticles haveem- ployedacasestudytoevaluatetheirdesignedarchitecture,wewill positiontheminthisclass ofevaluationmethodinourclassiﬁca- tion framework. We also include simulation, which requires pro- ducinganexecutablemodelfor(partof)agivensystemthatisof

(10)

Table 4

Summary of selected BPMS surveys.

PS Y C DB S ST RA S-AG D-AG AB RE STL LYR EVL

[42] 2015 7 ELSV J ST3 – 0 0 1 4 C N/A –

[43] 2015 0 SPRG C ST5 – 1 1 3 4 C N/A IMP

[44] 2014 3 SPRG J ST3 – 2 1 1 3 C N/A IMP

[12] 2014 0 ACM C ST3 – 2 0 3 3 C N/A IMP

[45] 2014 0 IEEE C ST3 – 2 1 1 3 L SoC IMP

[11] 2014 0 ACM C ST3 [28] 2 1 1 4 L SoC IMP

[39] 2013 3 SPRG C ST3 [28] 2 1 1 3 L C-S IMP

[46] 2013 1 IEEE C ST3 – 1 1 1 3 C N/A IMP

[47] 2013 0 IEEE C ST3 – 2 1 1 3 L C-S CS

[10] 2012 3 SPRG W ST3 [28] 2 3 1 2 C N/A IMP

[48] 2012 3 ACM C ST3 [28] 1 0 1 3 L SoC IMP

[9] 2012 3 IEEE S ST3 – 2 1 2 4 L C-S –

[40] 2011 15 IEEE C ST3 – 2 0 2 4 C N/A CS

[33] 2011 5 IEEE C ST2 [28] 2 0 2 3 L other –

[49] 2011 4 ELSV J ST2 – 2 1 2 3 L SoC –

[50] 2011 0 IEEE C ST3 [28] 4 1 2 3 C N/A IMP

[6] 2010 24 SPRG J ST1 – 1 1 1 3 C N/A CS

[7] 2010 16 SPRG C ST2 – 3 0 2 3 C N/A CS

[4] 2010 11 ELSV J ST3 – 2 1 1 4 C N/A CS

[51] 2010 11 ELSV J ST3 [28] 1 0 1 4 C N/A CS

[8] 2010 9 IEEE C ST1 – 1 0 2 4 L SoC IMP

[5] 2010 5 ACM W ST3 – 1 1 1 3 C N/A IMP

[52] 2010 1 ELSV W ST3 [28] 2 0 2 4 L SoC IMP

[34] 2010 0 IEEE C ST3 – 1 1 3 4 L SoC –

[53] 2009 97 IEEE J ST3 [3,28] 3 1 3 4 L SoC IMP

[54] 2008 73 ISI J ST3 – 4 1 3 4 C N/A IMP

[55] 2007 137 ELSV J ST2 – 2 2 2 3 C N/A IMP

[56] 2005 117 ACM C ST5 – 1 0 3 4 L SoC IMP

[57] 2005 95 ELSV J ST3 [28] 2 0 1 4 C N/A IMP

[58] 2004 170 ACM W ST3 – 3 3 3 4 L SoC IMP

[35] 2004 94 ELSV J ST3 [28] 2 0 2 4 C N/A IMP

[59] 2004 50 SPRG C ST3 [28] 2 2 1 3 L SoC IMP

[60] 2004 43 ACM S ST3 – 2 1 2 3 L SoC –

[38] 2003 38 ELSV J ST3 [28] 2 1 1 3 L SoC –

[31] 2002 39 IEEE W ST3 [61] 3 3 3 4 C N/A –

[62] 20 0 0 1889 ISI C ST2 – 2 1 1 3 L other –

[3] 1998 63 ELSV J ST3 [28,63] 3 2 2 3 L SoC –

[64] 1997 131 IEEE W ST3 – 2 1 1 3 L SoC IMP

[65] 1995 249 SPRG C ST3 [28] 2 1 1 2 C N/A –

[63] 1995 72 SPRG C ST3 – 2 1 1 2 L SoC –

[66] 1994 53 IEEE C ST3 – 1 0 2 4 C N/A –

particularinterest[36],inthisclassinourframework.Inthesame way,Barrettetal.whoproposedacloudWorkﬂowschedulingap- proachbasedonaMarkovDecisionProcess[40]andsubsequently employedCloudsim[41]tosimulatefourseparatedatacenters in fourgeographiclocations,ispositionedinthisclassinourclassiﬁ- cationframework.Inparticular,Barrettetal.designedacasestudy inordertoevaluate(i)thecostsavingsoftheirapproach,and(ii) thevariable workload ontheir system (i.e.,loadvariance)when theamountofdataincreasesacrossthesystem.

4. Results

This section presents theresults that were obtainedfrom our SLRstudyinrelationtoeachoftheresearchquestions.Table4pro- videsasummaryoftheselectedprimarystudies(cf.Section2)on thebasisoftheclassificationframework(cf.Section3).ThisTable consistsof 14columns in whichthe first 6 columns are usedto specifythe selectedprimary studies,andtherestshow ouranal- ysisbasedonthe classificationframework. Foreach entryinthis table:

– thePScolumnprovidesareferencetothebibliographyofapri- marystudy,

– theYcolumnshowsitspublicationyear, – theCcolumndisplaysitsnumberofcitations,

– the DBcolumn refers to its publication source,and its values areACMforACMDigitalLibrary,IEEEforIEEEXplore,ELSVfor

Scopus,SPRGforSpringerLink, and, ﬁnally,ISIforWebofSci- ence,

– theScolumnexpressesthepublicationsourcetypeanditsval- uesareJforJournal,Cforconferenceproceeding,WforWork- shop,andSforSymposium,

– theSTcolumndenoteswhichgroupofsearchstringswasused toﬁndtheprimarystudyanditsvaluesareST1for“BPM”,ST2 for“BusinessProcessManagement”,ST3for“Workﬂow”,ST4for

“Orchestration” and,ﬁnally,ST5for“Choreography”,

– the RA columns investigates which Root Architecture (if any) hasbeenusedbytheprimarystudy,

– the System-Aggregation Dimension (S-AG), the Data- Aggregation Dimension (D-AG), the Abstraction Dimension (AB)andtheRealizationDimension(RE)columnsareemployed topositiontheprimarystudyintotheLoEcube,

– the STL columns looks into the Architectural Style that has beenemployed by the primary studyandits values are Cfor Component-BasedStyleandLforLayeredStyle,

– the LYR columns further analyzes the layering rationale that has been used by the primary study and its values are C- S for Client-Server design principle, SoC for Object-Oriented basedSeparationofConcern designprinciple,andnotapplica- ble(N/A)ifthearchitectureisnotlayered,andﬁnally

– theEVLexploresthe3.4(ifany)thathasbeenemployedbythe primary study,anditsvaluesare IMPforImplementationand CSforCaseStudy

(11)

Fig. 15. Distribution of all the studies in comparison with the selected studies over the years.

Fig. 16. Ratios of the selected studies to all the studies over the years.

4.1. SelectedprimarystudiesonBPMSarchitecture

Themainresearchquestionthatneedstobeanswerediswhich relevantprimarystudieshavebeenpublishedintheareaofBPMSar- chitectureandwhereweretheypublished?

From the 608 primary studies, which were obtained by our search,weidentiﬁed301originalprimarystudies(i.e.,afterremov- ingduplicatedarticles)and,subsequently,41studiestobeconsid- eredforourSLRstudyafterapplying theinclusion andexclusion criteria. The linechart inFig. 15compares the distributionof all theoriginalandselectedprimarystudiesovertheyears.Basedon thischart,nosubstantialdifferencesbetweenthethreegraphscan be seen in terms oftheir trends. The dotted chart in Fig.16 depicts theratioofselectedstudies toallthe publishedstudies per year.Intotal,weselectedapproximately7%ofarticlesfromwhich 1994hasthehighestproportionat33%while1996,1999,2001and 2006 havethe lowestproportionat0%. Thisfact alsoproved the reliabilityofourinclusionorexclusioncriteria(cf.Section2.3).

Inaddition, theOriginalPrimary Studiestrendline(the orange trendline) in Fig. 15 reveals that there was a gradual growth in the number of publications between1994 and 2005 in the ﬁeld ofBPMSarchitectureresearch(asshownbytheorangetrendline).

However, after2005thisresearchcontinuedatafairly evenlevel until there was a marked increase in 2009. One reason for this sharprisemaybetherenewedinterestofresearchersintheﬁeld ofprocessenactmentinfrastructureaspointedoutbyvanderAalst [67]inthisyear.Since2011,again,therehasbeenaevensituation inthenumberofpublishedarticles.Fig.15onlycontainsdataup until2014becauseweconductedoursearchinJuly2015and,thus, for2015weonlyobtainedthestudiesthathavebeenpublishedin theﬁrsthalfofthisyear.Althoughthesestudiesarenotshownin Fig.15,weincludedtheminourSLRanalysis.

Among all the selected primary studies, three were published in proceedings of the Business Process Management (BPM) Con-

ference, two were publishedin proceedings of the Web Services Conferenceandthe samenumber waspublishedinthe Informa- tionandSoftwareTechnology(IST)Journal.ThebarchartinFig.17 illustrates the distribution of the selected primary studies over theyearsinterms oftheirpublications’source.Overall, itcanbe seenthat48.78%oftheselectedprimarystudieswerereportedin Conferenceproceedingswhichfall aboveJournalpublicationsand Workshopproceedingswhichpublished34.15%and14.63% ofthe selectedprimary studiesrespectively.Wealsoincluded onestudy (i.e.,2.44% ofthepopulation)that waspublishedina symposium onDistributedComputing.

Altogether,allthe41selected primarystudiesproposed anarchitecture for a whole BPM system orat least forthe Workflow Enactment Service (Engine) component. In order to properly answer the main research question, we decomposed that into five sub-questions.The next sectionswill provide answers tothe five sub-questionsby furtherinvestigatingthe contentofthe selected architecturesaccordingtothedevelopedBPMSarchitectureclassi- ficationframework(cf.Section3).

4.2.Usedrootarchitectures

The ﬁrst research sub-question that needs to be answered is towhatextentthearchitecturesintheselectedprimarystudieswere builtuponotherexistingarchitectures?Thedevelopedclassiﬁcation framework seeks to provide an answer to this question by in- troducingtheRootArchitecture aspect.Accordingly,we presented threereferencearchitectures:theWfMCReferenceModel[28],Mer- curiusReference Architecture[3]andS3 ReferenceArchitecture[29]. However,contrarytoourexpectations,themoststrikingobserva- tionemergingfromTable4isthat themajority(i.e.,around60%) oftheselectedprimary studieshavebeencomposedfromscratch (i.e.,notbasedontheexistingarchitectures).