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 Workflow 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
Copyright
c
2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
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 Workflow 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
2
. 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
no
Identify actors
Model Social
Cognitive maps
Organize
actors panels
MCDA
assessment
Run analytical
model
yes
Try a new
model?
Start MCDA
no
no
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 Workflow 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
2.
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 Workflow 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 newmodel?
40
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 Workflow 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