Adopting Workflow Patterns for Modelling the Allocation of Data in

Multi-Organizational Collaborations

Ayalew Kassahun and Bedir Tekinerdogan

Information Technology Group, Wageningen University, Hollandseweg 1, Wageningen, The Netherlands

Keywords: Multi-Organizational Collaboration, Workflow Patterns, Data Flow, Data Allocation Viewpoint.

Abstract: Currently, many organizations need to collaborate to achieve their common objectives. An important aspect

hereby is the data required for making decisions at anyone organization may be distributed over the

different organizations involved in the collaboration. The data objects and the activities in which they are

generated or used are typically represented using business process models. Unfortunately, the existing

business process modeling approaches are limited in representing the complex data allocation dimensions

that occur in the context of multi-organization collaboration. In this paper we provide a systematic approach

that adopts workflow data patterns to explicitly model data allocations in multi-organization collaboration.

To this end we propose a design viewpoint that integrates business process models with well-known data

allocation problem-solution pairs defined as workflow data patterns. We illustrate the viewpoint using a

case study of a collaboration research project.

1 INTRODUCTION

Many organizations depend heavily on their

collaboration partners and have to align their

objectives with those of their partners. For instance,

companies collaborate in supply chains to bring their

products to end consumers (Lambert and Cooper

2000). Product attributes such as cost, quality and

timeliness are common objectives of all collaborating

partners (SCC 2012). In projects, likewise,

organizations have to collaborate to deliver the

products and services pledged in the project contract

(PMI 2013). An important aspect of collaboration

across multiple organizations is that the data needed

for making decisions along the collaboration process

might be distributed over the different organizations

involved. Having access to the required data is,

therefore, crucial.

Collaboration across organizations is typically

designed as a set of business processes. A business

process model (BPM) primarily specifies the flow of

activities (Davenport 1993; Van der Aalst et al. 2003;

Aguilar-Savén 2004) and is usually designed by a

domain expert (also called a business analyst, domain

consultant, etc.)

In designing a BPM a domain expert specifies not

only the flow of activities but also the data objects

produced or required by the activities of the BPM.

However, the scope of visibility of the data objects,

how the data objects are transferred from activity to

activity, how the visibility changes as the data objects

are transferred, and how the data objects are used in

making decisions usually remain implicit or

undefined. Within the context of individual

organizations this is less of a concern since data are

usually centrally managed. But, in multi-

organizational collaboration leaving the information

on the generation, usage, transfer and storage of data

implicit may render data unavailable and hamper the

execution and control of business processes. We refer

to these concerns data allocation concerns. To

support the understanding, communication and

analysis of data management in collaboration

business process models a data allocation design

abstractions are needed.

In this paper we provide an approach to explicitly

specify the allocation of data in multi-organization

collaboration based on workflow data patterns. To

this end we propose a design viewpoint that

integrates business process models with workflow

data patterns to address data allocation concerns. The

design viewpoint helps to understand the data

allocation concerns, supports the communication

among stakeholders, and help design data allocation

solutions.

110

Kassahun, A. and Tekinerdogan, B.

Adopting Workﬂow Patterns for Modelling the Allocation of Data in Multi-Organizational Collaborations.

DOI: 10.5220/0005975201100118

In Proceedings of the 5th International Conference on Data Management Technologies and Applications (DATA 2016), pages 110-118

ISBN: 978-989-758-193-9

The remainder of this paper is organized as

follows. Section 2 provides background information

on workflow data patterns. Section 3 presents an

industrial case study that demonstrates the data

allocation design viewpoint. Section 4 presents the

data allocation design viewpoint. In section 5 the

viewpoint is applied to the case. In section 6 the

related work is presented and in section 7 concluding

remarks are made.

2 WORKFLOW DATA PATTERNS

Workflow patterns are problem-solution pairs that

frequently occur in business process modeling

(Russell et al. 2006). Originally, workflow patterns

have been proposed to access the suitability of

workflow systems used in the context of individual

organizations. For that purpose more than a hundred

workflow patterns have been identified, categorized

and cataloged (van der Aalst and ter Hofstede 2011).

Workflow data patterns are well-known and recurring

data allocation concerns and the corresponding

solutions. Table 1 lists the forty workflow data

patterns identified by van der Aalst and ter Hofstede.

The workflow data patterns of van der Aalst and

ter Hofstede are categorized into four groups: data

visibility, data interaction, data transfer and data-

based routing. These groups are used in this paper as

the four dimensions of the data allocation concerns.

Data visibility dimension defines the scope of data

accessibility. In multi-organization collaboration

context the scope of the activity have to match with

the scope of the data needed to perform the activity at

hand or the decision to be made in the BPM. For

instance, data in the task scope are accessed only

within the execution of the given activity in the given

BPM instance, while data in the case scope can be

accessed by all activities of the particular BPM

instance. (Note: task refers to an instance of an

activity; and case refers to an instance of a BPM.) The

patterns are defined from the most restrictive scope

(task) to the least restrictive scope (environment).

Data interaction dimension defines how the

visibility of data changes as they are passed from one

activity to another. For instance, block task to sub-

process interaction means that the data passed from

the block task instance to the sub process instance are

shared by all activities of the sub process instance;

likewise task to task interaction means that data is

passed from one particular activity instance to

another activity instance only.

Data transfer dimension defines the mechanisms

of data interaction. Data transfer can be by value, by

reference, two-way copy (copy in/copy out), etc. Not

all data transfer mechanisms may apply to all

interactions.

Data-based routing dimension defines how data

are used to control the start and completion of

activity instances or how data are used as conditions

to influence the flow of activities.

In designing BPMs, domain experts must take

these four dimensions of data allocation into

consideration.

Table 1: Workflow data patterns.

Categories Patterns

Data Visibility

Task (1), Block (2), Scope (3), Multiple

Instance (4), Case (5), Folder (6),

Workflow (7), Environment (8)

Data Interaction

Internal Data

Interaction

Task to Task (9), Block Task to Sub-

Process (10), Sub-Process to Block Task

(11), To Multiple Instance Task (12),

From Multiple Instance Task (13), Case

to Case (14)

External Data

Interaction

Push from Task (15), Pull to Task (16),

Push to Task (17), Pull from Task (18),

Push from Case (19), Pull to Case (20),

Push to Case (21), Pull from Case (22),

Push from Workflow (23), Pull to

Workflow (24), Push to Workflow (25),

Pull from Workflow (26)

Data Transfer

Incoming By Value (27), Outgoing by

Value (28), Copy In/Copy Out (29), By

Unlocked Reference (30), By Locked

Reference (31), Input Transformation

(32), Output Transformation (33)

Data-based

Routing

Existence as Task Precondition (34),

Value as Task Precondition (35),

Existence as Task Postcondition (36),

Value as Task Postcondition (37), Event-

based Task Trigger (38), Data-based Task

Trigger (39), Data-based Routing (40)

The pattern names used by an der Aalst and ter Hofstede are

shorted for the sake of readability; the pattern ID’s (given

insides brackets) are, however, the same as those used by the

authors.

3 AN ILLUSTRATIVE CASE AND

PROBLEM STATEMENT

In this section we use a multidisciplinary

collaboration research case study to illustrative data

collaboration concerns.

3.1 Multi-Organisational Collaboration

in Research

Collaboration in a research project involves a number

of research organizations. The collaboration often

Adopting Workﬂow Patterns for Modelling the Allocation of Data in Multi-Organizational Collaborations

111

takes place as a temporary undertaking wherein one

of the collaborating organizations assumes the

project leadership responsibility. Projects are defined

by project plans which are often long running

business processes marked by milestones. Projects

have a number of deliverables. The process that leads

to a particular deliverable can be perceived as a

business process. A conceptual model of data sharing

in such a business process is depicted in Figure 1.

Business processes in research (and in many

knowledge intensive works in general) depend

heavily on data sharing, and thus, data allocation is a

major concern.

Figure 1: A conceptual model of a project collaboration.

3.2 Research Collaboration Case Study

In the following we elaborate on the data allocation

concern with the help of a specific scenario of a

multidisciplinary research project that was conducted

from 2004 to 2008. Hereby, four research

organizations had to address a water management

problem through a participatory process (Pahl-Wostl

and Hare 2004). Part of the project’s objective was to

design a water management planning process that

should consist of the following participatory

elements: identify the affected actors, with the actors

identify water management options and the criteria

(called indicators) with which to evaluate the options,

provide water management models to the actors with

which they gain insight into the impact of the options,

and finally let the actors select the most optimum

option or options with the help of the models.

A simplified BPM for identifying water-stress

mitigation options applied in one study location is

shown in

Figure

. The BPM consisted of four milestones:

(1) actors are identified, (2) domain ontologies are

defined, (2) options and indicators are elucidated and

(4) optimal option(s) are selected. In the first

milestone the actors were identified through a survey

questionnaire. The survey questions, the responses,

as well as the actors are the output data objects. In

the second milestone the options, indicators and the

ontology that describes the relationships among them

were identified by using fuzzy cognitive maps. In the

third milestone a virtual interactive model is

configured and run a number of times to provide

actors a deeper understanding on how the various

options impact the study area and how the impacts

are reflected as indicator values. Finally, in the four

milestones a multi-criteria analysis (MCA) model

was used to select the optimum option(s) that most

actors agree with. However, many details of how

data can be accessed, transferred, how the data

transfer affects data accessibility, and how data is

used to made decisions remained implicit. Similar

data allocation concerns occur also in many other

sectors such as food, health care and logistics.

Business Process for Selecting Water Management Options

Setup a

steering group

Research

organization 1

(Project leader)

Research

Organization 2

Research

Organization 3

Research

Organization 4

Configure

analytical model

Make a new

model run?

yes

Identify actors

Model Social

Cognitive maps

Organize

actors panels

MCDA

assessment

Run analytical

model

yes

Try a new

model?

Start MCDA

Options,

Indicators

ontologies

Options and

Indicators

elucidated

Start

modeling

Selected

options

Configuration

file

Simulation

outputs

Configuration

file

Indicator value

per option,

per actor

Questions,

responses and

actors

Run a new MCA

session?

yes

Configure MCA

Figure 2: A BPM for selecting options deliverable.

3.3 Problem Statement

A close analysis of the above and many other similar

cases shows that the lack of explicit data allocation

model is a major concern. In particular, we can

identify the following data allocations problems:

DATA 2016 - 5th International Conference on Data Management Technologies and Applications

112

• Difficulty in Defining the Scope of Data

In BPMs the scope of data required or produced is

usually not specified. In the BPM shown in Figure 2,

for instance, the options and indicators were required

throughout the execution of the BPM, while the

results of simulation model runs were needed only

with the particular activity instance and for the

particular organization. The data allocation was not

explicitly defined by domain experts but left to the

software engineers who had to deploy the required

software system but were not, in many cases, in a

position to decide on data allocation.

• Lack of a Common Data Allocation Model

Faced with the problem stated above, domain experts

and software engineers representing the various

project organizations came together to address the

problem. However, they lacked models with which

they can depict the problems and the solutions.

• Lack of Models for Redesigning Data Allocations

Generally, when the design of the current data

allocation is not satisfactory, a systematic approach

for redesign is required but is lacking.

In light of the above observations we formulate

the following research question: How to model the

allocation of data in multi-organizational

collaboration business processes?

4 DATA ALLOCATION DESIGN

VIEWPOINT

In software engineering the ISO/IEC/IEEE (2011)

standard provides a meta model and a template for

documenting software architecture. According to the

standard a design view is defined to represent design

concerns and decisions of a particular set of

stakeholders. Views addressing the same set of

concerns have to conform to a set of common

conventions called viewpoints. Based on Business

Process Model and Notation (BPMN, OMG 2011),

workflow data patterns and software system design

approaches we present in this section a data

allocation design viewpoint to address data allocation

concerns. We adopt and adapt the ISO/IEC/IEEE

template as shown in Table 2. The elements of the

template are described in the following sub sections.

4.1 Stakeholders

The relevant stakeholders in data allocation are

domain experts and software engineers that come

from the collaborating organizations. Domain experts

are concerned with the flow of activities and the data

required for executing them. Software engineers are

responsible for ensuring the desired data allocation is

realized in software systems. The data allocation

models are defined collaboratively by these two

stakeholders.

4.2 Elements

Three modelling elements are business process

models, data objects required in the business process

models, and the workflow data patterns. The business

process models are represented by a convenient

modeling notation (see section 4.4.1); data objects

are identified by their names; workflow data patterns

are described in detailed in the previously mentioned

reference.

4.3 Relations

We identify four relations as shown in Table 2. The

four relations are: (1) business process element to

organization, (2) business process element to data

object, (3) data object to software system, and (4)

software system to organization. These relations are

further elaborated in section 4.4.3.

4.4 Notations

The notation section provides how the elements and

relations are represented graphically. Two modelling

notations are used: BPMN and allocation tables.

Workflow data patterns are represented by a number

of attributes, however, only their ID’s are used here.

The notations are described below.

4.4.1 BPMN

To represent business process models we adopt the

BPMN (OMG 2011) modeling specification. BPMN is

widely used among domain experts, business analysts

and managers; it is also used software engineers.

BPMN models represent collaboration across business

units or organizations. BPMN also a simple data object

modeling construct. Messages and signals are also used

to represent the flow of data. Data objects are added as

annotations to activities. Messages and signals are used

indicate exchanges of information and

synchronizations. The details of data flow is often left

implicit or undefined (von Rosing et al. 2015).

4.4.2 Workflow Data Patterns

The workflow data patterns are originally defined in

the context of workflow software. They are described

Adopting Workﬂow Patterns for Modelling the Allocation of Data in Multi-Organizational Collaborations

113

in detail using a number of attributes. When used in

the context of multi-organizational collaboration the

following attributes are relevant: name, description,

example, motivation, overview, context, issues, and

animation. The implementation, solution and product

evaluation attributes are not considered relevant here

because these attributes represent the properties of

centralized (single-organization) workflow systems.

Table 2: Data allocation viewpoint documentation guide.

Viewpoint Element Description

Name Data Allocation Viewpoint

Stakeholders

•

Domain Experts

•

Software Architects

Elements

•

Elements from OMG’s BPMN 2.0 specification

•

Data objects

•

Workflow data patterns

Relations

•

Data identification – maps the elements of a BPMN model to organizations

•

Mapping workflow data patterns – maps the elements of a BPMN model to data objects

•

Data pattern allocation to – maps data objects to software systems

•

Data management allocation to – maps software systems and data objects to organizations

Notations a) BPMN*:

b) Allocation tables:

i) Allocating data to organizations: ii) Allocating data to workflow patterns

Organizations

BPMN

Activities

Data

Object

BPMN

Elements

… … …

iii) Re-allocating workflow data patterns: iv) Re-allocating data objects:

Workflow data

patterns

Software

system

Data

Object

From To

Software

system Data object Organization

… …

Properties of Elements See section 4.2

Properties of Relations See section 4.3

Constraints See section 4.4.3

Relation to other viewpoints BPMN 2.0 specification and workflow data patterns catalogue

Examples See section 5

* The list only widely used BPMN elements; for a complete list of BPMN elements refer to the OMG BPMN 2.0 specification (OMG

2011).

DATA 2016 - 5th International Conference on Data Management Technologies and Applications

114

4.4.3 Allocation Tables

Allocation tables (shown in Table 2b) define how the

four relations specified in section 4.3 are represented.

The first allocation table is used for identifying data

objects generated, used or transformed by

organizations. The cells of this table are filled with the

names of the data objects. The second allocation

table is used for identifying the workflow data

patterns that are applicable for the data object of

specific activities. The third allocation table is used to

allocate data objects to new workflow data patterns

and, thereby, also identify the software systems that

realize the new allocations. The fourth allocation table

is used to identify the organization responsible for the

software systems identified in the previous table.

4.5 Constraints

Constraints are aspects of modelling that need to be

enforced with respect to elements, relations and

notations. The most significant constraint to data

allocation viewpoint is that all data objects should at

least be associated with one workflow data pattern, a

BPMN activity, and an organization.

Figure 3: A process diagram representing the process of

data allocation modeling.

4.6 Method for Applying the Viewpoint

Figure 3 shows the method for applying the

allocation viewpoint. The process starts with the

domain expert defining the BPM in step 1. In step 2

the domain expert identifies the data objects involved

in each activity. In step 3 the domain expert and the

software engineers identify the workflow patterns

that best represent the present data allocation. In this

step they identify data allocation concerns that need

to be addressed. In step 4 they select new workflow

data patterns that address the data allocation

concerns. In this step they identify the software

requirements and responsibilities. In step 5 the data

allocation is evaluated. If after evaluation the new

data allocation seems unrealistic the steps 3, 4 and 5

are done again. It may take a few iterations before an

optimal data allocation is achieved.

5 APPLYING THE DATA

ALLOCATION VIEWPOINT

In this section we illustrate how the approach shown

in Figure 3 is applied in the case study described in

section 3.1. The first step of the approach is already

presented in

Figure

Table 3: Identifying input and output data objects

(a=actor(s), q=question(s), r=response(s), , o=options,

i=indicators, g=game configuration, v=value).

Organizations

BPMN

Elements

Research

organization 2

Research

organization 3

Research

organization 4

Setup steering group

Do survey a, q, r=f()

Organize actor panels

Model cognitive maps o, i=f(q, r)

Launch gaming

Configure model c=f(o, i)

Play games f(i, o)

Launch MCA

Configure MCA

Run MCA v = f(i,o)

In step 2 the data objects of each BPM activity

were identified using the first allocation table as

shown in Table 3. (For brevity only the most

significant data objects are included.) The cells show

Adopting Workﬂow Patterns for Modelling the Allocation of Data in Multi-Organizational Collaborations

115

the mapping of data inputs to data outputs for each

activity (row) of each organization (column). Data

inputs and outputs are presented as functions (f). The

arguments of f are the data inputs; the return values

are data outputs. For instance, the do survey activity

(which is shown as identify actors in Figure 2)

required no input data object but results in three

output data outputs. For more complex data inputs

and outputs data flow diagram (Larsen et al. 2012)

can be used instead.

Next, in step 3, the four dimensions of the data

allocation concerns which had been implicit in the

original BPM were made explicit with the help of the

second allocation table as shown in Table 4. Each

cell was assigned up to four workflow data pattern

slots. Each slot is separated by a vertical bar—one

workflow data pattern per slot from the four pattern

categories: patterns 1 to 8 for data visibility, 9 to 26

for data interaction, 27 to 33 for data transfer, and 33

to 40 for data routing.

Table 4: Mapping data to workflow data patters (numbers

match the workflow data pattern of Table 1: 1=Task,

2=Block, 5=Case, 9=Task-to-Task, 13=From-Multiple-

Insatnce, 27=By-Value-In, 28=By-Value-Out, 40=Data-

Based-Routing, config.=configuration).

Data

Object

BPMN

Elements

q=question

r=response

a=actor

o=option

i=indicator

v=value

c=config.

Setup steering group

Do survey 1|9|28 5

Organize actor panels

Model cognitive maps 5 1|9|28

Launch modeling

Configure model 1|9|27 2

Run model 5 1|9|27 28

New model run? 1|13|27|40

Launch MCA

Configure MCA 1|9|27 2

Run MCA 5 1|9|27 28

New MCA run? 1|13|27|40

Try a newmodel?

Table 4 can be described as follows: researchers

often manage data at each activity instance separately

(1); share data directly (9); send data by value (28)

and receive them by value (27). In some cases the

scope of data extends a few activities, as is the case

with configuration files (2). In some other cases data

is collected from multiple instances when activities

are executed in iteration (13). When iterations are

done routing at decision points is made based on data

stored externally (40).

After the current data allocations were made

explicit, the re-allocation was done in step 4 by

assigning data objects to different (better) workflow

data patterns using the third allocation table as shown

Table 5. Re-allocation is mainly motivated by the

availability of new and improved collaboration

software systems. As shown in the table the new

systems are shared knowledge and database systems.

Also in this step the fourth allocation table was used

to identify the responsible organizations that had to

provide the required software systems (Table 6). The

required database systems were made available by

two organizations; a new collaboration partner was

enlisted to provide the required KB system.

Table 5: Re-allocating workflow data patterns. (5=Case,

8=Enviroment, 15=Push-from-Task, 16=Pull-to-Task,

17=Push-to-Task, 18=Pull- from-Task, 19=Push-from-

Case, 20=Pull-to-Case, 27=By-Value-In, 28=By-Value-

Out, 29=Copy-In/Copy-Out).

Workflow patterns

Software system

Data object

From To

q=question 1|9|27,28 1|9|27,28

r=response 1|9|27,28 1|9|27,28

a=actor 5 8|15,16|29 KB

o=option 8|15,16|29 KB

i=indicator 8|15,16|29 KB

v=value 5|15,16|29 DB

c=config 5|19,20|29 KB

Table 6: Allocating data objects to organisations.

Software system

Data object Organizations

Project KB a, o, i, c ?

Shared DB1 v (model) 3

Shared DB2 v (MCA) 4

Last, in step 5, the new allocations were

evaluated. It turned out that some data objects

required broader scope and visibility. For instance,

indicator values (v) from model runs have to have

case (5) visibility; the indicators and options were

made public (environment visibility 8), etc.

6 RELATED WORK

Among business process modelers, BPMN is the de-

facto standard for modelling business processes

(Decker and Barros 2008; Chinosi and Trombetta

2012). It is also used to model cross-organizational

interaction as business process choreography model

DATA 2016 - 5th International Conference on Data Management Technologies and Applications

116

(Peltz 2003). Data objects are often added as

annotations. However, BPMN provides little

modelling support for data allocation.

Data flow diagrams and state charts (Harel 1987)

have been the main means of modeling data flow and

transformations in business process models. State

machines (OMG 2015) are used to model state, and

thus data, changes in business processes. Petri-nets

and Business Process Execution Language (BPEL)

provide modelling constructs for including data

aspects into business process models (Hinz et al.

2005). Recently, a fully data-centric business process

modeling approach is suggested (Hull 2008).

However, none of these approaches address data

allocation concerns that occur in a multi-

organizational collaboration sufficiently.

In software architectural design that usually

accompany business process modelling several

design viewpoints are suggested (Woods and

Rozanski 2005; Clements et al. 2010). Rozanski and

Woods, for instance, propose an architecture

framework consisting of seven different viewpoints,

namely, Functional, Information, Concurrency,

Development, Deployment and Operational, and

Context viewpoints. Their work does not, however,

include architecture perspective on analyzing data

allocation concerns.

7 CONCLUSIONS

Data allocation is an important concern when

designing collaboration business processes. It

appears that current business process modeling

approaches are limited in expressing all the four

dimensions of data allocation concerns we identified.

We showed how changes in data allocations captured

by the four dimensions documented as workflow data

patterns can be used data allocation concerns. In

future work we will extend apply the design

viewpoint to other real-life applications and

investigate ways to extend it.

REFERENCES

Aguilar-Savén, R. S. (2004). "Business process modelling:

Review and framework." International Journal of

Production Economics 90(2): 129-149.

Chinosi, M. and A. Trombetta (2012). "BPMN: An

introduction to the standard." Computer Standards &

Interfaces 34(1): 124-134.

Clements, P., F. Bachmann, L. Bass, D. Garlan, J. Ivers,

R. Little, P. Merson, R. Nord and J. Stafford (2010).

Documenting software architectures: views and

beyond, Addison-Wesley.

Davenport, T. H. (1993). Process Innovation:

Reengineering Work Through Information

Technology, Harvard Business School Press.

Decker, G. and A. Barros (2008). Interaction Modeling

Using BPMN. Business Process Management

Workshops: BPM 2007 International Workshops, BPI,

BPD, CBP, ProHealth, RefMod, semantics4ws,

Brisbane, Australia, September 24, 2007, Revised

Selected Papers. A. Hofstede, B. Benatallah and H.-Y.

Paik. Berlin, Heidelberg, Springer Berlin Heidelberg:

208-219.

Harel, D. (1987). "Statecharts: a visual formalism for

complex systems." Science of Computer Programming

8(3): 231-274.

Hinz, S., K. Schmidt and C. Stahl (2005). Transforming

BPEL to Petri Nets. Business Process Management:

3rd International Conference, BPM 2005, Nancy,

France, September 5-8, 2005. Proceedings. W. M. P.

Aalst, B. Benatallah, F. Casati and F. Curbera. Berlin,

Heidelberg, Springer Berlin Heidelberg: 220-235.

Hull, R. (2008). Artifact-Centric Business Process

Models: Brief Survey of Research Results and

Challenges. On the Move to Meaningful Internet

Systems: OTM 2008: OTM 2008 Confederated

International Conferences, CoopIS, DOA, GADA, IS,

and ODBASE 2008, Monterrey, Mexico, November 9-

14, 2008, Proceedings, Part II. R. Meersman and Z.

Tari. Berlin, Heidelberg, Springer Berlin Heidelberg:

1152-1163.

ISO/IEC/IEEE (2011). Systems and software engineering

-- Architecture description. ISO/IEC/IEEE Standard

42010:2011.

Lambert, D. M. and M. C. Cooper (2000). "Issues in

Supply Chain Management." Industrial Marketing

Management 29(1): 65-83.

Larsen, P. G., N. Plat and H. Toetenel (2012). "A Formal

Semantics of Data Flow Diagrams." Formal Aspects of

Computing 6(6): 586-606.

OMG (2011). Business Process Model and Notation 2.0

(BPMN 2.0).

OMG (2015). OMG Unified Modeling Language (OMG

UML): 752.

Pahl-Wostl, C. and M. Hare (2004). "Processes of social

learning in integrated resources management." Journal

of Community & Applied Social Psychology 14(3):

193-206.

Peltz, C. (2003). Web Services Orchestration and

Choreography. 36: 46-52.

PMI (2013). A Guide to the Project Management Body of

Knowledge (PMBOK) – Fifth Edition.

Russell, N., W. M. van der Aalst and N. Mulyar (2006).

"Workflow Control-Flow Patterns: A Revised View."

BPM Center Report BPM-06-22.

SCC (2012). Supply Chain Operations Reference Model

(SCOR): Revision 11.0.

van der Aalst, W. M. P. and A. ter Hofstede. (2011).

"Workflow Patterns. http://www.workflowpatterns.

com/." Retrieved December 23, 2015.

Adopting Workﬂow Patterns for Modelling the Allocation of Data in Multi-Organizational Collaborations

117

Van der Aalst, W. M. P., A. H. M. Ter Hofstede and M.

Weske (2003). Business Process Management: A

Survey. BPM 2003, International Conference on

Business Process Management, June 26-27, 2003,

Eindhoven, The Netherlands, Springer.

von Rosing, M., S. White, F. Cummins and H. de Man

(2015). Business Process Model and Notation—

BPMN A2 - Scheel, Mark von RosingAugust-Wilhelm

ScheerHenrik von. The Complete Business Process

Handbook. Boston, Morgan Kaufmann: 429-453.

Woods, E. and N. Rozanski (2005). Using Architectural

Perspectives. Software Architecture, 2005. WICSA

2005. 5th Working IEEE/IFIP Conference on.

DATA 2016 - 5th International Conference on Data Management Technologies and Applications

118