1Institute of Architecture of Application Systems, University of Stuttgart, Germany2Institute for Parallel and Distributed Systems, University of Stuttgart, Germany

firstname.lastname@informatik.uni-stuttgart.de

Identifying Relevant Resources and Relevant Capabilities of Informal Processes

C. Timurhan Sungur1, Uwe Breitenbücher1, Oliver Kopp2, Frank Leymann1, Andreas Weiß1

These publication and contributions were presented at ICEIS 2017ICEIS 2017 Web site: http://www.iceis.org/

© 2017 SciTePress. Personal use of this material is permitted. However,permission to reprint/republish this material for advertising orpromotional purposes or for creating new collective works for resale orredistribution to servers or lists, or to reuse any copyrighted componentof this work in other works must be obtained from the SciTePress.

@inproceedings{Sungur2017,author = {C. Timurhan Sungur and Uwe Breitenb{\"u}cher and Oliver Kopp and

Frank Leymann and Andreas Wei{\ss}},title = {{Identifying Relevant Resources and Relevant Capabilities of

Informal Processes}},booktitle = {Proceedings of the 19th International Conference on Enterprise

Information Systems (ICEIS 2017)},year = {2017},month = {April},pages = {295--307},publisher = {SciTePress}

}

:

Institute of Architecture of Application Systems

Identifying Relevant Resources andRelevant Capabilities of Informal Processes

C. Timurhan Sungur1, Uwe Breitenbucher1, Oliver Kopp2, Frank Leymann1, and Andreas Weiß1

1Institute of Architecture of Application Systems, University of Stuttgart, Germany2Institute for Parallel and Distributed Systems, University of Stuttgart, Germany

firstname.lastname@informatik.uni-stuttgart.de

Keywords: Informal Processes, Unstructured Processes, Resource Discovery, Capability Discovery, Relevant Resources,Relevant Capabilities

Abstract: Achieving goals of organizations requires executing certain business processes. Moreover, the effectivenessand the efficiency of organizations are affected by how their business processes are enacted. Thus, increasingthe performance of business processes is in the interest of every organization. Interestingly, resources andtheir capabilities impacting past enactments of business processes positively or negatively can similarly havea positive or a negative impact in their future executions. Therefore, in our former work, we demonstrateda systematic method for identifying such resources and capabilities of business processes using interactionsbetween resources of business processes without detailing the concepts required for this identification. Inthis work, we fill this gap by presenting a conceptual framework including concepts required for identifyingresources possibly impacting business processes and capabilities of these resources based on their interactions.Furthermore, we present means of quantifying the significance of resources and their capabilities for businessprocesses. To evaluate the identified resources and capabilities with their significance, we compare the results ofthe case study on the Apache jclouds project from our former work with the data collected through a survey. Theresults show that our system can estimate the actual values with 18% of a mean absolute percentage error. Lastbut not least, we describe how the presented conceptual framework is implemented and used in organizations.

1 INTRODUCTION

During their lifetime, organizations typically workto reach better states than their current ones, e.g.,a more profitable state, a more knowledgeable state,and a more competitive state. To reach these desiredstates, organizations set and achieve their organiza-tional goals [Etzioni, 1964]. Achieving these goalsrequires organizations to conduct a set of value addingactivities in a certain order forming business processesof that organization. Documenting business processessupports humans when executing these processes, au-tomating parts of executions, and improving these, asmany of these business processes are executed repeat-edly. In case business processes contain repetitiveactivities among different process enactments, busi-ness experts can document these repeating activitiesin business process models using activity-oriented ap-proaches [Leymann and Roller, 2000, Weske, 2010].These approaches enable modeling, executing, and im-proving business processes based on their activities.As activities and the order of them, i.e., the structure of

processes, do not change in different executions, busi-ness process models can be used to prescribe their exe-cution. In contrast to such structured processes, thereare business processes which do not follow a clearlydescribed sequence of activities, i.e., the activities andtheir execution order are not or only less structuredin advance and evolve during execution. Thus, eachexecution is different from others. Different businessprocess modeling and execution approaches have beenproposed to deal with semi-structured and unstructuredprocesses [Dustdar, 2004, Moody et al., 2006, Her-rmann and Kurz, 2011, Sungur et al., 2014]. Semi-structured and unstructured processes typically involveactivities for creating specific, individual knowledgeon runtime. Due to strongly varying ways to achievesuch goals, modeling unstructured processes basedon activities typically does not increase the perfor-mance of these processes. Based on these proper-ties, different works named these processes differently,such as ad-hoc processes [Dustdar, 2004], unstruc-tured processes [Di Ciccio et al., 2015], declarativeflows [van der Aalst et al., 2009], and informal pro-

Figure 1: A simplified informal process model for a bugfixing process.

cesses [Sungur et al., 2014]. In the following, we referto them as “informal processes”.

Organizations desire to increase their performance,such as turnover, by improving the performance oftheir business processes. Increasing performance ofactivity-oriented processes has been on the focus ofthe research community for a long time [van der Aalst,2016]. However, there is a lack of detailed systematicapproaches for improving a business process contain-ing negligible amounts of repeated activities sharedamong its executions. Improving the performance ofunstructured processes involves allocating relevant ca-pabilities provided by relevant resources. Documentedresources are resources, whose participation in infor-mal processes is already known and documented. Forinstance, an informal process for developing a open-source software is initiated with a Git repository. Inthis case, the Git repository is a documented resourcedue to being prescribed upon the initialization. Rele-vant resources are resources that interact with docu-mented resources and other relevant resources in thecourse of an informal process. For instance, each pullrequest reviewer of a documented Git repository partic-ipating in an informal process is relevant resource dueto interactions with a documented resource. Likewise,a relevant capability is a capability of a relevant or adocumented resource of an informal process. Obvi-ously, including certain relevant resources and capa-bilities in informal processes may increase their per-formance, such as including a person making frequentcontributions in an open-source software developmentproject. Thus, it is in the interest of organizationsto efficiently find appropriate relevant resources andcapabilities for enactments of such processes to opti-mize their executions. Unfortunately, this cannot bedone a priori at design time since informal processesstrongly vary from enactment to enactment [Di Ciccioet al., 2015]. Interestingly, previous enactments of

such processes may give hints on appropriate relevantcapabilities and resources that can be used.

In our previous work [Sungur et al., 2016], wehave demonstrated the extended Informal Process Ex-ecution (InProXec) method enabling the identificationof relevant resources and relevant capabilities on acase study. Identified relevant resources and relevantcapabilities are presented to business experts as rec-ommendations at modeling time to enforce their deci-sion making processes with the information gatheredfrom enactments of informal processes. Consequently,these recommendations do not target at providing aruntime support for human actors. In this work, wecomplement this demonstration with the conceptualfoundations. Therefore, we present the following con-tributions: (i) a conceptual framework for identifyingrelevant resources and capabilities to support businessexperts during modeling (Sect. 4), (ii) steps requiredfor enabling the generation of recommendations forinformal processes using the conceptual frameworkpresented (Sect. 4.1), and (iii) steps required for gener-ating recommendations for informal processes usingthe conceptual framework (Sect. 4.2). In the follow-ing sections, we firstly present a motivating scenario(Sect. 2). After presenting the scenario, we recap theInProXec method (Sect. 3). Then, we present the con-tributions of this paper in Sect. 4. Finally, we presentrelated work in Sect. 5 and conclude in Sect. 6.

2 MOTIVATING SCENARIO

The motivating scenario is based on the Apachejclouds project (https://jclouds.apache.org/) that ex-poses typical characteristics of how people work. Thehigh-level goal of this project is developing Java li-braries that unify access to functionalities of vari-ous cloud service providers. To achieve this goal,project members create an open-source project, inwhich as many contributors as possible are desired.As there are different cloud service providers in themarket, the project is divided into sub-projects to in-tegrate these different providers. Thus, different de-velopers are experienced and responsible for differ-ent sub-projects. As the project is an open-sourceproject, external contributors, i.e., people who are notpart of the core project team, also participate in thedevelopment. For instance, to integrate OpenStack(https://www.openstack.org/), members of the Open-Stack project create a sub-project implementing vari-ous APIs in Java, e.g., APIs for storage services. Suchexternal experts contribute valuable knowledge aboutthe project parts, e.g., the computational service APIof OpenStack. Assigning the right resource to the right

Figure 2: A view on real world entities of interest.

job will likely increase the efficiency of the processsuch as assigning a developer of the OpenStack stor-age API to a process of fixing a bug of the OpenStackstorage API will reduce the time needed. Moreover,certain types of interactions between resources implytypical relevance relationships between them, e.g., a“commit” interaction implies a relevance relationshipbetween the developer and the Git project containingthe source of OpenStack storage API. Thus, this devel-oper is a relevant resource for the respective process.

During the lifetime of the software developmentproject, there are sub-processes that are executed re-peatedly, such as reviewing code and fixing bugs. Eachsuch sub-process represents an example for an infor-mal process, as they involve activities for creatingspecific, individual knowledge at runtime. In case onecapability is used during one instance of these repet-itive executions, it is likely that it will be used in alater execution, too. Thus, such a capability can beconsidered as relevant for that specific process and theexplicit inclusion of it can increase the efficiency of aprocess. The sub-process of reviewing code contribu-tions of external committers requires a coordinationcapability, i.e., coordinating people during this revi-sion process. In case this coordination capability isused by one of the documented resources during theenactment of sub-processes, this will imply that thiscapability can be relevant for the future executions,too. As a result, including such a relevant capabilityprovided by a resource will most likely increase theefficiency of future executions of the same process.In this work, we present a conceptual framework foridentifying relevant capabilities and resources by ana-lyzing on interactions and capabilities of documentedresources.

3 FUNDAMENTALS

In the following paragraphs, we first describe the Infor-mal Process Essentials (IPE) approach [Sungur et al.,2014]. Hereafter, we describe the four-phased Infor-mal Process Execution (InProXec) method [Sunguret al., 2015a, Sungur et al., 2016] enabling the usage

of the IPE approach in organizations. In Fig. 2, werecap a formal model including real world entities andtheir relationships used in the InProXec method. Allconcepts illustrated in Fig. 2 are based on our previouswork [Sungur et al., 2014, Sungur et al., 2015a, Sun-gur et al., 2015b, Sungur et al., 2016]. We introducedthe concept of relevance relationships in our previ-ous work [Sungur et al., 2016] but we did not detailthese. In the current work, we present a conceptualframework generating relevance relationships.

Business processes have three dimensions: what,who, and which [Leymann and Roller, 2000]. Thedimension “what” denotes activities of business pro-cesses conducted by actors represented by the dimen-sion “who”. To conduct activities, actors of businessprocesses exploit other organizational resources, i.e.,the dimension “which”. In case of informal processes,activities are typically not predictable during model-ing time due to the dominant change in activities atruntime. Moreover, modeling activities of informalprocesses is in many cases more costly than the perfor-mance increase provided by modeling. Thus, the IPEapproach focuses on modeling and automatically allo-cating required resources of informal processes, i.e.,the two dimensions “who” and “which”, to supportactors of processes and to reproduce desired outcomesof business processes. To model these two dimensions,business experts include resource definitions requiredin informal process models, as illustrated in Fig. 2.Each resource definition represents an organizationalresource such as human resources, material resources,information resources, and IT resources. For instance,a resource definition can represent a human resourceconducting required activities and a Git repository sup-porting these activities. As shown in Fig. 2, insteadof directly referring to resources required in infor-mal processes, business experts can model capabil-ities required in informal processes. Organizationalcapabilities represent abilities to perform a produc-tive task using organizational resources. To guide re-sources during process enactments towards desiredoutcomes, business experts specify intentions of in-formal processes. Each intention describes desiredoutcomes of informal processes, e.g., a Java librariesthat unify access to functionalities of various cloudservice providers is the desired outcome of the moti-vating scenario. Furthermore, intentions enable track-ing the progress of informal processes, such as twointentions completed out of three intentions implyinga certain degree of the progress in an informal process.Resource definitions, capabilities, and intentions arestored in informal process models, as illustrated inFig. 2. A simplified example informal process modelof a process aiming at fixing a bug in the motivating

scenario is shown in Fig. 1 with its resource defini-tions, capabilities, and the target intention. For fur-ther details about the approach, we refer the readersto [Sungur et al., 2014]. To enable the applicationof the IPE approach in organizations, we presentedthe InProXec approach [Sungur et al., 2015b]. In aprevious work [Sungur et al., 2016], we demonstratedthe application of an extended version of the InProXecapproach to identify relevant resources and relevantcapabilities of the motivating scenario. This previouswork focuses on the validation of the extended methodand does not describe the new concepts needed for theidentification of relevant resource and relevant capabil-ities, which we address in the current work. Next, wegive an overview of the InProXec method with fourphases shown in Fig. 3.

Integrate Resources of Informal Processes (P1).The first phase of the InProXec method has three ob-jectives: (i) making resources required visible in mod-eling environments of informal processes, (ii) enablingthe automated allocation of these resources during in-formal process model initialization, and (iii) enablingthe generation of recommendations for informal pro-cesses. We have detailed means of achieving the ob-jectives (i) and (ii) in our previous work [Sungur et al.,2015b]. In the current work, we present the means ofachieving the objective (iii) in Sect. 4.1. The phase P1is a setup phase involving software development activi-ties and must be initially executed before other phases.The Informal Process Essentials (IPE) approach fo-cuses on modeling and automatically allocating ac-tors and supporting resources of actors. Therefore,modeling environments of informal processes needto present business experts available actors and sup-porting resources of actors, i.e., resources of interest.Presenting resources from different resource domainsrequires understanding domain-specific resource defi-nitions and transforming these into resource definitionsof modeling environments of informal processes. Tomake organizational resources available in modelingenvironments of informal processes, technical expertsdevelop software components called domain managers(the first objective of P1).Definition 1 (Domain Manager (DM)). Domain man-agers are software components transforming domain-specific resource representations into resource defini-tions of modeling environments of informal processes.

For instance, a domain manager of IT resourceswill create resource definitions for a new Git reposi-tory and for existing ones. After implementing domainmanagers, technical experts develop execution envi-ronment integrators to enable the automated allocationof resources for intentions of informal processes (thesecond objective of P1).Definition 2 (Execution Environment Integrator

(EEI)). Execution environment integrators are soft-ware components capable of executing life-cycle op-erations such as allocating and releasing resourcesduring the enactment of an informal process.

During resource allocations, EEIs convert resourcedefinitions into resource instances containing instancedescriptors. Each resource instance represents aunique allocated resource. We refer to resource defini-tions and instances in the following as resources if itcauses no confusion. Resource definitions are a partof informal process models and are initialized uponinitialization of the models. During initialization of aninformal process model, a software component calledan Informal Process Essentials runtime allocates allresources using available EEIs.Definition 3 (Informal Process Essentials (IPE) Run-time). Informal Process Essentials runtimes are soft-ware components managing life-cycles of informal pro-cess instances using available execution environmentintegrators for each modeled resources definition.

IPE runtimes correspond to business process ex-ecution engines of structured processes. We assumethat before applying the InProXec method an IPE run-time already exists. Initializing an informal processmodel successfully results in an informal process in-stance. Informal process instances contain resourceinstances. During enacting informal processes, newintentions can emerge. These new intentions can beaddressed with an updated set of allocated resourceinstances. Thus, the resources represented in infor-mal process models and instances can vary. A validanalysis on resources of informal processes should notonly consider resources addressed in informal processmodels but, rather, all resources in informal processinstances of the process model. We refer to informalprocess models and instances in the following as in-formal processes as long as no confusion is possible.To address the third objective of P1, i.e., enabling thegeneration of recommendations for informal process,technical experts develop software components capa-ble of analyzing interactions of resources participatingin informal processes and deriving recommendationsfrom these interactions. Informal process recommen-dations include (i) relevant resources and capabilitiesof informal process models and (ii) new informal pro-cess models containing these identified resources andcapabilities. For this analysis, technical experts de-velop software components collecting interactions ofresources participating in informal processes. More-over, they create software components capable of in-terpreting these interactions and generating informalprocess recommendations. Business experts exploitthese recommendations to model more effective andefficient informal process models during the phase P2,as presented in Fig. 3.

Figure 3: Phases of the InProXec method and its enabling system.

Model Informal Processes (P2). The main objec-tive of this phase is creating informal process modelsachieving organizational intentions. For this purpose,business experts model organizational capabilities pro-vided by organizational resources, so that they canadd these into informal process models. For instance,they specify a Java development capability providedby a set of human resources. Hereafter, they specifyintentions of informal processes such as fixing a bugin a software library. To specify the means of achiev-ing these intentions, business experts define informalprocess models using the resources integrated in P1.After creating models, business experts initialize cor-responding process models as described in P3.

Execute Informal Processes (P3). This phase hasthe objective of initializing informal process modelsand achieving organizational intentions specified inP2. First, business experts select appropriate informalprocess models based on the present organizationalcontext. Upon an initialization request, the IPE run-time uses EEIs to allocate resources documented ininformal process models. For instance, they send aninvitation for participation to human resources definedin the respective informal processes. In case they agreeon the participation, they are considered to be allocated.Another example of a resource allocation is creatinga new Git repository on GitHub for an informal pro-cess. Allocating all resources specified in an informalprocess instance converts the state of the instance intoachieving, i.e., achieving intentions of the respectiveinformal process. During the state achieving, actorsof informal processes work towards the intentions ofinformal processes using other supporting resources

collaboratively. As shown in Fig. 2, collaborationsresult in interactions containing information about ac-tual executions of informal processes. After achievingintentions of informal processes, actors or businessexperts stop informal process instances. Hereafter, theemployed IPE runtime deallocates resource instancesusing available EEIs.

Generate Informal Process Recommendations (P4).The objective of this phase is generating informalprocess recommendations from interactions occurringamong resources of informal processes. These recom-mendations include resources and capabilities possiblyrelevant for informal process models and new infor-mal process models using these relevant resources andcapabilities. The starting point of generating recom-mendations are the resources instances documented ininformal process instances, as shown in Fig. 3. Thus,we start by defining “documented resources”.Definition 4 (Documented Resource). A documentedresource of an informal process model is a resourceinstance allocated on purpose for an instance of theprocess model during the process initialization or theprocess enactment.

In other words, a documented resource is not lim-ited to the resources represented in informal processmodels but, rather, they include all allocated resourcesduring the course of different process enactments. Doc-umented resources provide a basis for identifying rel-evant resources of informal processes. Furthermore,the definition of relevant resources is built on top ofdocumented resources:Definition 5 (Relevant Resource). A relevant resourceof an informal process is a resource instance interact-

Figure 4: An illustration of generating informal process recommendations.

ing directly or indirectly with a documented resource.Indirectly means that there is an interaction path froma documented resource including other resources untilthe relevant resource is interacted with.

In Fig. 4, we present two informal process in-stances E1 and E2. According to the definition ofdocumented resources, all resources in two circlesare documented resources, i.e., R1 – R10. Moreover,all resources communicating with these are relevantresources, such as R15. By communicating with the rel-evant resource R15, the resource R14 becomes relevant.To define relevant capabilities, we exploit relevant re-sources, as follows:

Definition 6 (Relevant Capability). A relevant capa-bility of an informal process is an existing or a derivedcapability of a relevant or a documented resource.

In Definition 6 existing capabilities refer to mod-eled capabilities of resources during P2. For instance,in Fig. 4, C1 is a relevant capability as it is a capa-bility of both R15 and R5. The derived capabilitiesare capabilities created using different properties ofresource interactions, such as type and frequency ofan interaction. An example of such a capability isa coordination capability derived using reviews of apull request, which are interpreted as coordinationof pull requests of a software project. To fulfill theobjective of generating informal process recommenda-tions, relevant resources and relevant capabilities areneeded to be identified. Therefore, during P4, softwarecomponents built in P1 collect interactions of relevantresources and, hereafter, interpret these interactions toassign different degrees of relevance for relevant re-sources and capabilities. Using these assigned degrees,software components built in P1 create informal pro-cess model recommendations. Informal process modelrecommendations contain relevant resources and capa-bilities found previously and are based on the originalinformal process model. Next, we present a concep-

tual framework (Sect. 4) for enabling the generationrecommendations for informal processes (Sect. 4.1)and generating the recommendations (Sect. 4.2).

4 CONCEPTUAL FRAMEWORKFOR GENERATING INFORMALPROCESSRECOMMENDATIONS

In this section, we present key concepts used to gen-erate informal process recommendations. Interactingresources build a unweighted bi-directional resource-interaction graph where resources are nodes of thegraph and interactions are the edges connecting thesenodes, as shown in Fig. 4. The shortest path betweentwo resources in a graph is the path with the least num-ber of edges connecting the two resources. In a graph,the distance between two resources is the number ofedges in the shortest path connecting these. Based onthis distance definition, we define the distance of arelevant resource as follows:Definition 7 (Distance of a Relevant Resource). Thedistance of a relevant resource to a documented re-source is the number of edges in the shortest pathconnecting these resources.

In Fig. 4, the distance of R14 is 2 due to the inter-actions between R7/R15 and R15/R14. According toDefinition 7, the documented resource used to identifya relevant resource is the starting point for calculatingthe distance of a relevant resource. As shown in Fig. 3,we initially exploit information available in interac-tions to identify relevance relationships containing rel-evant resources and relevant capabilities. Therefore,resource interactions over different mediums need tobe investigated, e.g., physical interactions, emails, Gitcommits, and Wiki edits. To collect interactions of a

documented resources, we employ resource analyzers:

Definition 8 (Resource Analyzer). Resource analyz-ers are software components mapping resource in-stances to a set of interactions of a certain type oc-curred in a certain time span.

Technical experts create resource analyzers to en-able the generation of informal process recommenda-tions, as detailed in Sect. 4.1. Resource analyzers areused to collect interactions of documented and relevantresources recursively, i.e., they collect first resources indistance 1 and, then, 2 until the given distance. More-over, they collect interactions in certain time spans tolimit the collected interactions to the interactions hap-pened during executions of informal processes. Forinstance, a resource analyzer of a GitHub repositorycan collect interactions of the last three months fromthis repository to identify developers working on itduring execution of a bug fixing process spanning theprevious three months. Hereafter, each of the devel-opers found can be further investigated with their cor-responding resource analyzers to collecting furtherinteractions resolving in additional relevant capabili-ties and relevant resources, such as additional GitHubrepositories. Each interaction collected by resourceanalyzers contains a relevant resource and relevant ca-pabilities of an informal process model. To associatethese relevant resources and capabilities with informalprocess models, relevance relationships are used.

Definition 9 (Relevance Relationships). A relevancerelationship specifies the degree of relevance of a re-source or a capability with an informal process model.

A relevance relationship is considered as an asso-ciation with informal process models, because theserelationships rely on interactions of documented andrelevant resources of informal process models. Thedegree of the relevance of a resource or a capabilitydepends on different factors such as (i) the type, the fre-quency, and contents of an interaction, (ii) the degreeof relevance of a relevant resource providing a relevantcapability, and (iii) the distance of a relevant resource.Thus, each relevance relationship contains the degreeof a relevance derived using interactions, i.e., the cor-relation coefficient of the relevance relationship. Arelevance relationship implies either (i) a positive rele-vance, (ii) an irrelevance, or (iii) a negative relevance,that is (i) a positive correlation coefficient, (ii) a zerocorrelation coefficient, and (iii) a negative correlationcoefficient, respectively. A positive relevance meansthat a resource definition should be included in an in-formal process model. An irrelevance means that theconsidered resource has no impact on the informalprocess. In contrast, a negative relevance means, aresource definition should not be included in a process

model. To generate recommendations for informalprocesses (Sect. 4.2), relevance relationships are iden-tified. Thus, there is a need for a means of determiningrelevance relationships using existing entities such asinteractions or other relevance relationships. There-fore, we employ relevance mappers:Definition 10 (Relevance Mapper). Relevance map-pers are software components enriching a set of rele-vance relationships using (i) interactions collected byresource analyzers and (ii) existing relevance relation-ships identified by other relevance mappers.

For instance, a relevance mapper converts an inter-action between a Git repository and a developer intoa relevance relationship containing the relevant Gitresource with a positive correlation coefficient. In casesuch a relevance relationship is already present, therelevance mapper updates the correlation coefficientof the corresponding relevance relationship. Technicalexperts build these relevance mappers to enable thegeneration of recommendations for informal processes,as shown in Fig. 3 and detailed in Sect. 4.1.

To calculate the correlation coefficients of rele-vance relationships, we created the following require-ments: A relevance mapper can calculate the correla-tion coefficient of a relevance relationship using dif-ferent information sources, such as interaction types,interaction contents, and identified relevance relation-ships. For instance, a commit interaction implies ahigher relevance in a development project than anemail interaction (the type of an interaction). More-over, the number of lines committed is also impor-tant during the calculation of correlation factors (thecontents of an interaction). Thus, such different in-formation sources should have effect in the calculatedcorrelation coefficients (Rq1). Furthermore, differentinformation sources can imply the relevance or theirrelevance of the same relevant resource or the samerelevant capability. For instance, multiple commitsmade by the same developer will increase the rele-vance of the respective developer. Thus, the resultingcorrelation coefficient of relevant resource or a rele-vant capability should represent an aggregated valuecalculated based on different information sources (R2).Typically, relevant resources with a larger distanceare less relevant for a specific informal process. Forinstance, in an informal process a Git repository isincluded. Moreover, this Git repository is updated by arelevant human resource, who works on another repos-itory, which is less relevant than the human resourceused to identify the latter repository. Thus, relevantresources with a larger distance and their relevant ca-pabilities should be less relevant (Rq3).

Based on these requirements, we designed the func-tion presented in Equation (1) within the range of

R. The function maps either a relevant resource ora relevant capability (rc) based on the interactions(I) and relevance relationships (R) to a new correla-tion coefficient (cc(rc, I [R)). The function iteratesthrough interactions and relevance relationships andrelies on other functions depending on an interactionor a relevance relationship, that are, a relevance fac-tor (rFactor(rc, ir)) and the distance (d(rc, ir)) of therelevant capability. Consequently, the value of thecorrelation coefficients depend on interactions and rel-evance relationships (I [R) of a relevant resource orrelevant capability (rc) given.

cc(rc, I [R) = Âir2I[R

rFactor(rc, ir)d(rc, ir) (1)

where cc(rc, I [ R) 2 R, rFactor(rc, ir) 2 R, andd(rc, ir) 2 Z+.

To align the variable impact of different types of in-teractions or relevance relationships used to calculatea new correlation coefficient, we use the function rel-evance factor (rFactor(rc, ir)). Interestingly, contentsof interactions or relevance relationships can be consid-ered during the calculation of values of rFactor(rc, ir)for each interaction or relevance relationships, too.As a consequence of considering contents, an interac-tion or a relevance relationship can map to a relativelysmaller or a larger value. For instance, a relevancemapper of a GitHub interactions can analyze collectedinteractions representing issues in the time span ofan informal process instance. Furthermore, the rele-vance mapper can map to a higher or a smaller valuebased on the contents of issues, such as by doing atopic analysis and matching these with intentions of aninformal process instance [Li and Yamanishi, 2003].Consequently, different issues created out of the scopeof an informal process instance are eliminated. Suchinteractions typically exist within the interactions con-taining unstructured text resulting in ambiguous in-terpretations. In contrast, the meaning of structuredinteractions is typically unambiguous and representstypically a certain productive or unproductive activ-ity, such as a Git commit interaction. In relevancerelationships, we represent (i) resources conductingproductive and unproductive activities and (ii) capa-bilities of these resources with different correlationcoefficients. Moreover, based on the sign of a rFactor,the next calculated value of a correlation coefficient iseither higher or lower. To this end, a negative relevancefactor will imply unproductive activities deduced usingcertain types of interactions or relevance relationships,such as spam emails. Thus, the equation satisfies Rq1.Furthermore, the summation of calculated values foreach different interaction or relevance relationship re-sults in a correlation coefficient representing differentthese. Consequently, the equation fulfills Rq2. More

distanced relevant resources and their capabilities re-sult in a smaller correlation coefficient and, thus, areless relevant using the variable (d(rc, ir)) in the equa-tion. Consequently, Rq3 is satisfied.

In our previous work [Sungur et al., 2016], wepresented a case study validating the conceptual frame-work presented here using the Apache jclouds projectdescribed in the motivating scenario. Thereby, we usedour implementation of the framework1 for generatingrelevance relationships and new informal process mod-els based on the relationships. During the generation ofrelevance relationships, we validated that the equationdoes not depend on the order of interactions given bymaking multiple runs on the same interaction sets withdifferent orderings. Furthermore, recently, we evalu-ated the equation presented in Equation (1) empiricallyby comparing the correlation coefficients of the rele-vance relationships of resources generated in the casestudy with a set of correlation coefficients collected ina survey with 13 experienced GitHub users.

The experience of the participants on using GitHubin our survey varies between 6 months to 72 monthswith an average of 34 months. We provided eachparticipant numbers and types of interactions of 21resources identified in our case study. For instance,we presented a GitHub user with 10 commits and 2pull requests. More specifically, we presented 1069interactions in 8 different types collected during ourcase study distributed to 21 different resources. Fur-thermore, each expert evaluated each resource withthe same interactions twice to be able to check thequality of given answers. Based on this list and on theexperience of participants, we asked each participantto assign an integer value between 1 (not relevant) and5 (relevant) for each resource listed. Consequently, inour comparison we had to map from the automaticallygenerated values onto the scale of 1 to 5, as the actualvalue of the positive correlation coefficient is in rangeof R. Different interpretations of different types ofinteractions result in a standard deviation between 0and 0.19 for the values of different resources assignedby participants. Moreover, the statistical correlationcoefficient between the automatically generated valuesand the average of the user assigned values is 0.93meaning that the generated results and collected re-sults have a strong linear positive correlation. Individ-ually considered, the statistical correlation coefficientbetween the generated values and each data set pro-vided by each participant vary between 0.79 and 0.98.Furthermore, the root mean square error and mean ab-solute percentage error values [Armstrong, 1978] are0.62 and 18%, respectively.

1https://gitlab.com/timur87/informal-process-recommender

cc(rc,ir)

0

1,25

2,5

3,75

5

RelevantResources

Automa.callygeneratedvaluesfromthecasestudymappedtotherange[1,5]Averageofthedatacollectedinasurvey

Figure 5: Comparison of correlation coefficients derived by experienced GitHub users and generated automatically.

Fig. 5 presents a comparison of the generated val-ues and the average of the values provided by partic-ipants. Moreover, the results differ at certain points.This is firstly because of the assigned relevance fac-tors (rFactor(rc, ir)) representing the increase rate ofcorrelation coefficient per interaction did not meet theconsensus of the participants, which can resolved bychanging the assigned relevance factors. Secondly, theresults provided by human resources are positive inte-gers between 1 and 5 resulting in a lower precision. Incontrast, the correlation coefficient generated based onthe conceptual framework is with a higher precision.

Relevance relationships are already recommenda-tions by themselves through presenting relevant ca-pabilities and resources and their degree of relevanceduring P2. Using relevance relationships, its possibleto create informal process model recommendations,that is, new informal process models based on relevantresources and capabilities. For instance, in case a rel-evance relationship with a correlation coefficient 0.9between a developer and an informal process modelexists, an informal process model recommendationcontains this relevant resource. As presented in Fig. 3,to automate generating informal process model recom-mendations from relevance relationships, we introducethe concept of informal process model recommenders,which are developed during P1 of our method (Fig. 3).Definition 11 (Informal Process Model Recom-mender). An informal process model recommendergenerates a new informal process model using rele-vance relationships.

During P2, generated recommendation models arepresented to business experts. Finally, we introduce theconcept of informal process recommenders orchestrat-ing resource analyzers, relevance mappers, and infor-mal process model recommenders to generate informalprocess recommendations.Definition 12 (Informal Process Recommender). Aninformal process recommender generates informal pro-cess recommendations, i.e., relevance relationshipsand informal process model recommendations, usingresource analyzers, relevance mappers, and informalprocess model recommenders.

Figure 6: Detailed steps of enabling the generation of rec-ommendations for informal processes.

In the following subsections, we describe necessarysteps for enabling the generation of recommendationsfor informal processes (Sect. 4.1) and generating rec-ommendations for informal processes (Sect. 4.2) usingthe conceptual framework in organizations.

4.1 Enabling the Generation ofRecommendations for InformalProcesses using the ConceptualFramework

This section presents the additional steps executed inFig. 6, i.e., I2 – I6, after executing the existing step I1to achieve the objective of enabling the generation ofrecommendations for informal processes of the phaseP1 of the InProXec method. As organizations are liv-ing organisms, resources playing a role in informalprocesses change continuously. Thus, steps presentedin this section can be executed repeatedly during thelifetime of an organization to adapt newly emergingintentions of informal processes. We validated the fol-lowing steps in the context of a case study presentedin our former work [Sungur et al., 2016].

Identify Involved Resources and Services (I1): Atfirst, business experts and technical experts identifypossible actors of informal processes and their sup-porting resources in the context of organizational in-tentions using their experience on the past and presentinformal processes. They work together, as both or-ganizational knowledge of business experts and ITknowledge of technical experts are required. Addi-tionally, they can make interviews with human actorsof informal processes to identify further resources in-volved in informal processes, if it is needed.

Identify Relevant Interactions and their Services(I2): Using the resources determined in I1, technicalexperts and business experts identify resource inter-actions providing information about the relevance ofresources and their capabilities, i.e., relevant inter-actions, in the context of organizational intentions.Finding relevant interactions is followed by identify-ing services capable of delivering these interactions,e.g., GitHub and MediaWiki services.

Develop Resource Analyzers (I3): To generate rec-ommendations for informal processes (Sect. 4.2), ini-tially, interactions containing documented and relevantresources should be collected. To collect interactionsidentified previously in I2, technical experts create re-source analyzers. Resource analyzers use the selectedinteraction services such as the GitHub service fromI2 to collect interactions containing documented andrelevant resources. Moreover, each resource analyzerconverts different addressing schemes used in differentkinds of interactions into a system-specific format ofthe corresponding execution environment of informalprocesses. Each resource analyzer typically addressesa certain type of resources, such as human resources,and a certain interaction service, such as GitHub toassign a single responsibility to each analyzer.

Develop Relevance Mappers (I4): After having amechanism to collect interactions using resource ana-lyzers, technical experts proceed with developing ser-vices for interpreting these interactions. Depending onthe selected resources in I1, selected interactions in I2,and their services, technical experts develop relevancemappers to generate relevance relationships containingrelevant resources and relevant capabilities.

Develop Informal Process Model Recommenders(I5): Additionally, to automate creating informal pro-cess model recommendations, technical experts candevelop informal process model recommenders, whichincorporate relevance relationships to provide im-proved informal process models containing relevantresources and capabilities. During this step, techni-cal experts define a specific threshold value to elim-inate certain relevant resources and capabilities. Forinstance, involving a contributor who made just onecommit, i.e., having a low correlation coefficient, canbe more costly than the value he adds. This thresholdis set for eliminating such cases.

Register Developed Services (I6): After creatingresource analyzers, relevance mappers, and informalprocess model recommenders, technical experts regis-ter these to an informal process recommender (Defini-tion 12) to enable an automated discovery (I6). Con-sequently, the infrastructure is ready to generate therecommendations in P4.

Figure 7: Generating recommendations for informal pro-cesses.

4.2 Generating Recommendations forInformal Processes using theConceptual Framework

Generating recommendations for informal processeshappens first after executing the steps described previ-ously. The steps shown in Fig. 7 are executed by aninformal process recommender automatically duringP4 of the InProXec method. As resources of the re-spective informal process may not be accessible afterits finalization, this phase needs to be executed beforefinalizing informal process instances. We validated thepresented steps in the context of a case study presentedin our former work [Sungur et al., 2016].

Aggregate Resources of Informal Process Instances(D1): As shown in Fig. 7, the generation process isinitiated with an informal process model and its corre-sponding instances. In case multiple informal processinstances are provided as input, a merger componentaggregates all documented resources contained in dif-ferent process instances. Duplicate resource instancesare eliminated to avoid extra computational effort, thatis collecting the same interactions more than once forthe same resource instance.

Analyze Documented Resources (D2): After the ag-gregation, the set of documented resources go throughresource analyzers developed during I3 to collect therelevant interactions identified in I2, such as Git com-mits and pull requests.

Find Relevance Relationships (D3): After collect-ing interactions in D3, relevance mappers created inI4 derive relevance relationships containing relevantresources and relevant capabilities. Derived relevancerelationships are passed through relevance mappersiteratively. Thus, in case relevance mappers deduce aspecific relevance relationship more than once, they

update the correlation coefficient of the relationship.Generate Informal Process Model (D4): The out-

put of D3 is a set of relevance relationships, as pre-sented in Fig. 7. Afterwards, the business expert caneither decide to stop with identified relevance relation-ships or to continue with automatic generation of an in-formal process model recommendation. Informal pro-cess model recommenders exploit relevance relation-ships to generate a new informal process model, i.e.,an informal process model recommendation, based ona provided informal process model.

In P2, business experts can use either (i) generatedrelevant resources and relevant capabilities containedin relevance relationships or (ii) generated informalprocess model recommendations. The first option pro-vides business experts more flexibility and the secondone has the advantage of causing less effort as it re-duces the steps to be taken by business experts in P2.Although informal process model recommendationsmay reduce the effort of business experts, they needto be assessed by business experts before they can beused. Thus, in both cases business experts evaluategenerated recommendations.

5 RELATED WORK

The approach presented has commonalities with Ex-pert Finding Systems (EFS) [Schall, 2009,Balog et al.,2006], as EFSs typically address finding the right peo-ple for certain topics. In the context of our work, theconcept of resource differs and is not restricted to hu-man resources, i.e., experts. Thus, our approach doesnot only recommend experts but also other support-ing relevant resources, e.g., a specific Wiki resource.Begel et al. [Begel et al., 2010] present a frameworkcalled Codebook creating a graph of interrelated re-sources using interactions of people, work items, files,and source code. Although Codebook is capable offinding different type of interrelated relevant resources,the framework does not address the degree of resourcerelevance and relevant capabilities. Dorn et al. [Dornet al., 2011] proposed a skill-dependent recommenda-tion model for finding experts with a better connectiv-ity and matching skills. In this work, we also rely oninteractions between resources to make recommenda-tions. However, we do not specify how the correlationamong resources are calculated, but rather we leavethat as an extension point depending on the contextof the problem and specific resource interactions. Asfuture work, we will exploit existing research in thesearea, such the work of Dorn et al. [Dorn et al., 2011]and the work of Campbell et al. [Campbell et al., 2003],to improve relevance mappings.

The method presented makes no assumptions onthe existence of reusable structured activities or a busi-ness process execution engine executing these activi-ties defined in an automated fashion. In case structuredactivities and a business process engine are present inthe environment, business process mining approachescan be exploited to improve business process execu-tions [van der Aalst, 2016]. Different approachesprovide recommendations for future resource alloca-tions of business processes using event logs of pro-cess executions [Arias et al., 2016, van der Aalst andSong, 2004, Yang et al., 2012]. These approaches fo-cus on interactions between allocated resources andbusiness process execution engines. In contrast, ourapproach focuses on every meaningful resource inter-action including interactions with business process exe-cution engines. Our approach provides no replacementfor such activity-oriented approaches, but it standsrather complementary. Dorn and Dustdar [2011] pre-sented an activity recommendation system relying onmessage-exchanges for unstructured processes. Fur-thermore, Folino et al. [Folino et al., 2014,Folino et al.,2015b, Folino et al., 2015a] present means of identify-ing activities of informal processes using a clusteringbased discovery approach on event logs.

Vasconcelos et al. [Vasconcelos et al., 2001]present necessary elements and their relationships tomodel organizational goals, resources, processes, andtheir associations. However, their work does not aimat improving these processes but enables traceabilitybetween goals, processes, and resources. AdaptiveCase Management [Herrmann and Kurz, 2011] andCase Handling [van der Aalst et al., 2005] offer thenotion of case to avoid context tunneling and rigid ac-tivity structures. During the execution of a case, actorscan collect relevant information in a case and reusethis information in the future. Using the case data, thedocumented information and actors can be captured.In contrast, the concept of resource in our approach ismore generic enabling the identification of any kind ofrelevant resources.

6 CONCLUSION AND OUTLOOK

In this work, we presented a conceptual framework foridentifying resources and capabilities that may be rele-vant for future executions of business processes. Iden-tified resources and capabilities are associated withvalues representing their degree of relevance to busi-ness processes. To evaluate our approach, we con-ducted a survey and compared the collected data in thesurvey with the automatically generated results. More-over, we presented steps for enabling the generation

of recommendations for informal processes and neces-sary steps involved during the automated generationof recommended resources and capabilities.

In the future, we will investigate further empiricalevaluation methods for the system presented, such asthe application of recall and precision metrics fromthe field of information retrieval. Moreover, we willdevelop additional interaction interpreters based onexisting approaches, such as expert finding systems.We will additionally present the implementation of newtypes of resources that are allocated during enactmentsof business processes in an ad-hoc fashion based onemerging requirements of human actors.

ACKNOWLEDGMENTS

This work has been partially supported by GraduateSchool of Excellence advanced Manufacturing Engi-neering (GSaME), DFG Cluster of Excellence in Sim-ulation Technology (EXC 310/2), and SmartOrchestra(Research Grant 01MD16001F, BMWi).

REFERENCES

Arias, M. et al. (2016). A framework for recommendingresource allocation based on process mining. In BPM2015, number 256 in LNBIP. Springer.

Armstrong, J. S. (1978). Long-range Forecasting: FromCrystal Ball to Computer. John Wiley & Sons Inc.

Balog, K., Azzopardi, L., and de Rijke, M. (2006). Formalmodels for expert finding in enterprise corpora. InSIGIR ’06, pages 43–50. ACM.

Begel, A., Khoo, Y. P., and Zimmermann, T. (2010). Code-book: discovering and exploiting relationships in soft-ware repositories. In ICSE ’10, volume 1, pages 125–134. ACM.

Campbell, C. S., Maglio, P. P., Cozzi, A., and Dom, B.(2003). Expertise identification using email communi-cations. In CIKM ’03, pages 528–531. ACM.

Di Ciccio, C., Marrella, A., and Russo, A. (2015).Knowledge-intensive processes: Characteristics, re-quirements and analysis of contemporary approaches.JoDS, 4(1):29–57.

Dorn, C. and Dustdar, S. (2011). Supporting dynamic,people-driven processes through self-learning of mes-sage flows. In CAiSE 2011, volume 6741 of LNCS,pages 657–671. Springer.

Dorn, C., Skopik, F., Schall, D., and Dustdar, S. (2011).Interaction mining and skill-dependent recommenda-tions for multi-objective team composition. DKE,70(10):866 – 891.

Dustdar, S. (2004). Caramba—a process-aware collaborationsystem supporting ad hoc and collaborative processesin virtual teams. DPD, 15(1):45–66.

Etzioni, A. (1964). Modern Organizations. Prentice Hall.

Folino, F., Guarascio, M., and Pontieri, L. (2014). Miningpredictive process models out of low-level multidimen-sional logs. In CAiSE 2014, pages 533–547. Springer.

Folino, F., Guarascio, M., and Pontieri, L. (2015a). Min-ing multi-variant process models from low-level logs.In BIS 2015, volume 208 of LNBIP, pages 165–177.Springer.

Folino, F., Guarascio, M., and Pontieri, L. (2015b). On thediscovery of explainable and accurate behavioral mod-els for complex lowly-structured business processes.In ICEIS 2015, pages 206–217. SCITEPRESS.

Herrmann, C. and Kurz, M. (2011). Adaptive case manage-ment: Supporting knowledge intensive processes withit systems. In S-BPM ONE 2011, volume 213 of CCIS,pages 80–97. Springer.

Leymann, F. and Roller, D. (2000). Production Workflow:Concepts and Techniques. Prentice Hall PTR.

Li, H. and Yamanishi, K. (2003). Topic analysis using afinite mixture model. IPM, 39(4):521 – 541.

Moody, P., Gruen, D., Muller, M., Tang, J., and Moran, T.(2006). Business activity patterns: A new model forcollaborative business applications. IBMSJ, 45(4):683–694.

Schall, D. (2009). Human Interactions in Mixed Systems -Architecture, Protocols, and Algorithms. PhD thesis,TU Wien.

Sungur, C., Dorn, C., Dustdar, S., and Leymann, F. (2015a).Transforming collaboration structures into deployableinformal processes. In ICWE 2015, volume 9114 ofLNCS, pages 231–250. Springer.

Sungur, C. T., Binz, T., Breitenbucher, U., and Leymann, F.(2014). Informal Process Essentials. In EDOC 2014,pages 200–209. IEEE.

Sungur, C. T., Breitenbucher, U., Leymann, F., and Wet-tinger, J. (2015b). Executing informal processes. IniiWAS ’15, pages 54:1–54:10. ACM.

Sungur, C. T. et al. (2016). Identifying relevant resources andrelevant capabilities of collaborations - a case study. InEDOCW 2016, pages 1–4. IEEE.

van der Aalst, W. (2016). Process Mining: Data Science inAction. Springer.

van der Aalst, W., Pesic, M., and Schonenberg, H. (2009).Declarative workflows: Balancing between flexibilityand support. CSRD, 23(2):99–113.

van der Aalst, W. and Song, M. (2004). Mining socialnetworks: Uncovering interaction patterns in businessprocesses. In BPM 2004, volume 3080 of LNCS, pages244–260. Springer.

van der Aalst, W., Weske, M., and Grunbauer, D. (2005).Case handling: a new paradigm for business processsupport. DKE, 53(2):129 – 162.

Vasconcelos, A. et al. (2001). A framework for modelingstrategy, business processes and information systems.In EDOC 2001, pages 69–80.

Weske, M. (2010). Business Process Management: Concepts,Languages, Architectures. Springer.

Yang, H., Wen, L., Liu, Y., and Wang, J. (2012). An approachto recommend resources for business processes. InOTM 2012, volume 7567 of LNCS, pages 662–665.Springer.