EVALUATION OF INTER-ORGANIZATIONAL
BUSINESS PROCESS SOLUTIONS:
A CONCEPTUAL MODEL-BASED APPROACH
Johny Ghattas and Pnina Soffer
Management Information Systems
University of Haifa, Carmel Mountain 31905, Haifa, Israel
Email: GhattasJohny@gmail.com, SPnina@is.haifa.ac.il
ABSTRACT
Collaboration and coordination between organizations are necessary in today's
business environment, and are enabled by inter-organizational processes. Many approaches
for the construction of such processes have been proposed in recent years. However, due to
the lack of standard terminology it is hard to evaluate and select a solution that fits a specific
business scenario. The paper proposes a conceptual model which depicts the nature of
interaction between organizations through business processes under specific business
requirements that emphasize the privacy and autonomy of the participating organizations. The
model is generic, and relies on the Generic Process Model (GPM) framework and on Bunge's
ontology. Being generic and theory-based, we propose to use the model as a basis for
comparing and evaluating design and implementation-level approaches for interorganizational processes. We demonstrate the evaluation procedure by applying it to three
existing approaches.
Keywords: Inter-organizational processes, Business process design, Conceptual
model, RosettaNet, P2P, CWM, Privacy, Autonomy, Flexibility.
1. Introduction
Collaboration and coordination between organizations are considered necessary in a business
environment, where organizations focus on their competitive advantage and complement their
offering through partners and suppliers. Inter-organizational processes are the enabler of such
business environments.
Various mechanisms at various levels of detail have been proposed for achieving
interoperability or shared business processes among organizations. Most of them focus on
implementation details (e.g., [1]).
A key issue discussed in the literature with respect to inter-organizational processes is the
required balance between trust and control, visibility and privacy. Addressing this delicate
balance, solutions vary from complete central control to pure distribution. Various models
[2][3][4][5][6] are proposed, where an inter-organizational workflow is defined as part or as a
result of a contract between organizations.
The organizations are then contractually
committed to the defined workflow (or to a partial definition). Different levels of visibility of
a partner’s internal process by the other partners at run time are also proposed and supported.
In general, a high degree of central control and required visibility imposes constraints on the
internal operations of an organization, thus reduces its flexibility.
Given this variety of approaches, it is difficult to assess and evaluate which one is better
suited for a given situation. This difficulty is particularly severe considering the absence of a
standard vocabulary or set of concepts in this domain, so each solution has its own
terminology. Furthermore, going into implementation details and solutions, many of these
approaches do not rely on a theoretical basis or explicit requirements specified in business
terms. We claim that an implementation solution needs to rely on a solid conceptual model,
depicting the essence of shared business processes and needs the solution must realize. Such
model should enable the assessment of a proposed solution in terms of its completeness and
compliance with the behavior required in a specific situation.
This paper proposes a conceptual model of inter-organizational processes, which aims at
identifying the minimal definition required to enable a smooth operation of shared processes,
while allowing the partners a maximal degree of privacy and flexibility. The model, based on
the formal Generic Process Model (GPM) and Bunge’s ontology, is at a rather high level of
abstraction, and does not address implementation details. It includes a set of concepts which
are well-defined and generic, relating to a set of business-oriented requirements whose focus
is autonomy and privacy. As such, it can form a basis for evaluating implementation models
and solutions when such business requirements are due. The paper proposes such evaluation
2
procedure and demonstrates it with respect to three existing inter-organizational process
frameworks.
The remainder of the paper is structured as follows: The next section provides a literature
review to motivate this current work. Then a brief introduction to the main concepts of GPM
is made, as a basis for the presentation of inter-organizational process model. The following
section presents the use of our model as a benchmark for evaluating inter-organizational
process solution approaches, and demonstrates it with respect to three well-known
approaches. This evaluation is discussed and finally, conclusions are drawn.
2. Related work
The literature about business process modeling offers a rich variety of solutions for
implementing business processes within organizations and between organizations. The
proposed solutions differ from each other in the implementation details, in the scope of issues
addressed, and in the level of privacy and autonomy granted to the participating
organizations.
For example, [7] addresses interaction among workflows (both within and between
organizations). They suggest a mechanism for exchanging events between interacting
workflows. Their work provides a technical mechanism that allows workflow interactions,
and a means for specifying them in workflow models. Privacy and autonomy of the
organizations are enabled since the workflows interchange events and do not expose further
information. Another example is [8], who propose to model inter-organizational processes
using UML, combined with a translation of the model into a designated formal language
(COALA). Their approach, which enables specification of the interaction among roles
(organizations), management of shared resources, and exception handling, is focused on
dependability and error recovery at run time.
Infrastructures, such as XRL/flower [1], are designed to support the exchange of information
required by inter-organizational business processes. Means for defining the process are
provided. However, the support of flexibility and autonomy of the participating organizations
is not explicitly addressed, and can be assured only within a specific process. A business
contract language (XLBC) was introduced in [9] to formally link the component definition
language (CDL) specification of workflow systems based on business objects. The authors
briefly discuss the object visibility specified through contracts, but do not go into details.
Infrastructural issues also include the work on process specification standards (BPMI [10];
ebXML BPSS [11], BPMN [12]; W3C [13]; OASIS [14]). E-business standards, traditionally
focused on simple message exchange between organizations, have been expanding to
3
consider structured sequences of messages and the process implications behind such
sequences. Considering privacy and autonomy issues, the Workflow Management Coalition
(WFMC) proposed an interface (WF-XML) that allows variable degrees of visibility between
organizations [15].
A different direction for approaching the inter-organizational process is by addressing the
relationships between organizations. [5][4] deal with legal contracts between organizations,
and show how a detailed workflow can be derived from a contract. They also provide rules
for matching the contract-based workflow with the existing organizational business
processes. The contract-based workflow relates to the entire process, thus it allows no
flexibility to a single organization for changing the process or deviating from it in specific
cases. In [6] the focus is on the privacy of organizational processes, which is maintained at
run time, limiting the visibility of the internal process. However, the entire workflow has to
be defined at build time, when a contract between the parties is established. Being
contractually obligated to the workflow model, the flexibility of the parties is limited. In [2],
the contract specifies the internal process of the “service provider” party and the interface
between the organizations, and allows a limited visibility of the provider process. Here
autonomy and flexibility are reduced only for the “provider” party, and not for the other side.
The PRODNET project [16] is aimed at facilitating autonomy and heterogeneity of
organizations participating in a virtual organization. However, their solution is based on a
central mandating and coordinating party, to whom all parties must report. This requirement
forms a limitation on the privacy and autonomy of the participants.
A model that includes a means for process verification, both between and within the
organizations, is proposed by [17]. Steps in defining the inter-organizational process are
proposed, facilitating some privacy and autonomy of partners through workflow views and
inheritance.
Autonomy of the partners is also facilitated by the ebXML BPSS model [11]. However, its
evaluation on the basis of Bunge’s ontology [18] indicates a lack of ontological completeness
as well as clarity, which may lead to modeling and interpretation difficulties.
Clearly, when more constraints are imposed by the inter-organizational process, less
flexibility can exist in the internal processes of an organization [19][20].
Summarizing the above review of related literature, we observe that the issue of interorganizational process modeling and support has been extensively addressed. Yet, while the
proposed solutions strive to enable the operation of an inter-organizational process, no
explicit consideration of specific business requirements is made to relate specific solutions to
specific business scenarios.
4
3. Deriving Inter-organizational Business process requirements
For any formal conceptual model to be complete and valid, the ontological assumptions of the
model need to be made explicit. In this paper we have set our major objective to establish a
model that would maximize the interacting parties' autonomy and privacy while not losing the
run time governance of the inter-organizational process.
Our model is designed to satisfy the following set of requirements, which emphasize the
privacy and autonomy of the participating organizations, as well as the operational feasibility
of the process.
(1) No central governance of the over-all process. There is no entity that designs,
implements, executes, and monitors the end-to-end process. This requirement
follows the assumption that central governance reduces the autonomy of the parties
and may require visibility to details that are not necessarily visible in a purely
distributed process. Hence, organizations’ privacy and autonomy is expected to be
higher in purely distributed processes as compared to centrally governed ones.
(2) Partners' business privacy conservation. Each partner shares the minimum needed
information for enabling the over-all process design, implementation, and enactment.
(3) Partners' business autonomy conservation. Each partner has a full autonomy to
design, implement, execute and monitor its internal processes, provided they comply
with the partner's obligations toward the other partners.
(4) Process run time governance assurance. All collaborating partners need to have
governance of the overall process status at all time. Since visibility is limited, such
governance can be based on mutual commitments, which reduce the uncertainty and
foment the trust among the partners.
Note that these are among the most restrictive requirements that may be set for a valid interorganizational process definition. When privacy and autonomy are not at the top priority of
the organizations, these requirements may not be necessarily relevant and some of them may
need to be relaxed or even eliminated.
Once we have established a conceptual model that complies with these requirements, we
would be able to evaluate business process (BP) design and implementation models on the
basis of the conceptual model.
5
4.
The conceptual model
The proposed model builds upon the Generic Process Model (GPM) and extends it to
incorporate the relevant concepts for modeling inter-organizational business processes. GPM
does not explicitly address inter-organizational processes. We will first briefly present GPM
and to extend it to a conceptual model that addresses inter-organizational processes.
4.1 The Generic Process Model
This section introduces the Generic process Model (GPM), which is the basis of our interorganizational process conceptual model. GPM is based on Bunge’s ontology [2321][22], as
adapted for information systems modeling (e.g.,[23][24]), for conceptual modeling, and for
modeling business process concepts.
According to the ontological framework, the world is made of things that possess properties.
Properties are perceived by humans in terms of attributes, which can be represented as
functions on time. The state of a thing is the set of values of all its attribute functions (also
termed state variables). When properties of things change, these changes are manifested as
state changes or events. State changes can happen either due to internal transformations in
things (self action of a thing) or due to interactions among things. Properties that establish
relations between things are mutual properties, while properties that relate only to one thing
are intrinsic to that thing. The rules governing possible states and state changes are termed
state laws and transformation laws, respectively. States can be classified as being stable or
unstable, where an unstable state is a state that must change by law, and a stable state is a
state that can only change as a result of an event external to the thing or the domain.
A domain is a part of the world, namely, a set of things and their interactions. It is represented
by a set of state variables, whose values represent the state of the domain at a moment in
time. A sub-domain is a part of the domain, represented by a subset of the domain state
variables.
A process is a sequence of unstable states, transforming by law until a stable state is reached.
A process is defined over a domain, which sets the boundaries of what is in a stable or an
unstable state. Events that occur outside the domain are external events and they can activate
the domain when it is in a stable state.
A process model in GPM is a three-tuple <L, I, G>, where L is the law, specified as mapping
between subsets of states; I is a subset of unstable states, which are the initial states of the
process after a triggering external event has occurred; G is a subset of stable states, which are
the goal of the process. Subsets of states are specified by conditions over the state variables of
the domain. Hence, a process starts when a certain condition on the state of the domain holds,
6
and ends when its goal is reached, i.e., when another condition specified on the state of the
domain holds.
It is possible to define the projection of a process over a sub-domain, where the set of state
variables addressed by the law is a subset of domain state variables. Then all transformations
outside the sub-domain are considered external events, and the sub-domain may be in a stable
state while the process is active in other parts of the domain.
The process goal as addressed by GPM is the state achieved by the process. However, the
goal concept is sometimes used also to describe business objectives. GPM distinguishes
process goals from soft-goals, which are defined as an order relation on goal states [25]. In
other words, soft-goals relate to the desirability of possible states in the goal set (all meeting
the condition that terminates the process) according to defined business objectives. For
example, assume the goal of a sales process is a set of states where an order has been
fulfilled, but achieving it in two days is considered "better" than in two months.
Finally, GPM entails criteria for assessing the validity of a process, namely, its ability to
achieve its goal [26]. It enables the analysis of a process to identify causes for invalidity, and
suggests appropriate redesign actions to eliminate these causes.
4.2 The Inter-organizational process model
The notion of domain sets the scope of control over the process in a GPM process model.
Consider an inter-organizational process modeled from the point of view of one of the
partners (that is, defined over the domain of that organization). The process reaches a state
where some request was made for another partner organization (e.g., supplier) to operate.
Since actions taken by other partner organizations are outside the scope of the domain, the
process domain remains in a stable state, waiting for the results of the other partner’s action.
These results are conceived as an external event, and are not within the control of the
requesting organization. At the occurrence of the expected external event, the state of the
domain transforms from stable to unstable and the process is reactivated. This kind of
situation is termed a discontinuity point [26], since the process (as defined within the
organization) depends on an external event in order to proceed and achieve its goal1.
When looking at the overall process, the process domain is extended beyond the
organizational boundaries of each of the participants.
Definition 1: The inter-organizational process domain is a domain including all the
participating organizations.
1
Note that synchronous actions in both organizations are possible according to the model. Even so, at
the synchronization point the process might be waiting for an external event and will not proceed
without it.
7
For the sake of brevity, we herein refer to the inter-organizational process domain simply as
the process domain. The participating organizations are all sub-domains of the process
domain, and shall hence on be denoted as the partner sub-domains. The process domain is not
centrally mandated, but it can be captured as an aggregation of all its partner sub-domains,
which are autonomous and private.
Definition 2: A sub-domain is said to be private if its states, goals, and law cannot be
controlled or viewed from outside the sub-domain.
The partner sub-domains interact with each other. In ontological terms, this interaction takes
place through properties that are mutual to at least two partners. When the value of such
property (reflected by a state variable value) is changed by one partner, this event affects the
state of the other partner too and triggers a transformation in it.
Definition 3: The sub-domain that includes all the state variables representing mutual
properties of the partners shall be termed the shared sub-domain.
Note that if the collaboration spans more than two parties then a shared sub-domain may exist
with respect to any sub-set of parties which includes more than two members. For simplicity,
we herein refer to a single shared sub-domain. Since the process domain is composed of
private sub-domains, the process cannot be viewed or defined as a whole, but it is known to
exist. Nevertheless, the internal processes of the partners, which are well defined and known
within each partner sub-domain, are projections of the inter-organizational process over the
partner sub-domain.
Considering the agreements that bind the partners, they concern the process parts that are not
private, namely the shared sub-domain. It appears as if the agreements define the projection
of the inter-organizational process over the shared sub-domain. However, since the shared
sub-domain includes only mutual properties, its state cannot transform by itself. Rather, every
transformation in the shared sub-domain is a result of an event which is external to that subdomain, be it in a partner sub-domain or external to the entire process domain (e.g., time).
This argument leads to the following lemma.
Lemma: All the states of the shared sub-domain are stable.
A state can only be regarded stable or unstable with respect to a (sub)domain. Since all the
transformations in the shared sub-domain are a result of external events, all its states are
stable. Hence, no meaningful projection of the law exists over the shared sub-domain. Rather,
all its states can be considered as discontinuity points, where the (sub)domain is “waiting” for
an external event for its state to be transformed. For the inter-organizational process to
progress towards its goal, these events should be generated by the partner organizations.
8
Consider a set of states SI in the shared sub-domain, defined by a condition over some of the
state variables. A state in this set is stable, and it waits for a partner P to transform it into a
state in the next set of states, SF.
Definition 4: An obligation is a three-tuple <SI, SF, P>, where, given a state in SI, partner P
will transform the shared sub-domain to a state in SF.
As an example, consider an inter-organizational process in which once an order has been
made by a customer, the supplier must commit to a delivery schedule. In this case SI = {s|
Order_status=inserted}, SF = {s| Order_status = delivery schedule committed}, and the
partner P who should transform a state sSI to sSF is the supplier.
In other words, an obligation of a partner to a state (or a set of states) forms a commitment
that the law defined in its private sub-domain assures the achievement of that state. In the
above example, the law in the supplier’s private sub-domain is designed so as to plan,
provide, and commit to a delivery schedule when an order is received. The details of how this
is done are not known to other participants in the process. The outcome of an obligation is
that although an observer is not familiar with the projection of the process over a private subdomain, he knows it is designed so that the required state will be achieved. The set of
obligations can be viewed as equivalent to a law mapping between sets of states in the shared
sub-domain. Yet, the transformations are to be brought about by the partner organizations.
The implications of the obligations on the process design in each of the partner organizations
are in the form of given sets of states that the process must reach. These may be the goal of
the (local) process or some mandatory states within the process that constrain its course.
The validity of the process can be assured by: (a) ensuring that the law of every private
process meets the defined obligations (to be performed by each partner). (b) Verifying that
each of the defined shared states is on a "path" to the goal, based on the mappings established
by the obligations.
Another element in the process model is related to Quality of Service (QoS) parameters or
soft-goals in GPM terms. Constraints on performance measures related to the generation of
the events in the shared sub-domain can be agreed upon. For example, response to a request
(event) should be made within a given time limit (performance measure). Then this constraint
becomes a part of the state definition in the obligation.
To summarize this discussion, the construction of a process should address the states in the
shared sub-domain to which the partners will be obligated, and the constraints on QoS
parameters that are implied in these states. It may be possible that a partner organization
already has existing (local) business processes that should be matched to the defined
obligations. Due to the obligation definition, this matching becomes rather simple, verifying
that the required states are reached by the existing process.
9
The obligation mechanism allows maximal flexibility and autonomy to the partner
organizations. The partners' organizations are free to change their internal processes or to
deviate from them as long as they fulfill their obligations. The obligations are defined with
respect to the mutual properties of the organizations, which are clearly distinguished from
intrinsic properties. Hence, the requirements posed by the obligations do not concern issues
beyond those necessary for the interaction. Since only the shared sub-domain is visible to all
partners (both at design time and at run time), no unnecessary information is revealed and the
privacy of the organizations is maintained.
The concepts of the model and their relationships are summarized in Figure 1. The interorganizational process operates over a process domain, composed of the shared domain and
many partner domains. The shared domain includes mutual state variables of the partner
domains. Private processes, which are part of the inter-organizational process, operate over
the partner domains, and have obligations, which relate to the mutual state variables. The
obligations include QoS constraints and shared states, which hold values of shared state
variables. Note that these are concepts that reside as an upper level on top of GPM and
Bunge's concepts.
Figure 1. The overall process conceptual model
5. Evaluating Potential Inter-organizational Process Solutions
10
As already discussed, the conceptual model, whose set of requirements is clearly defined in
business terms, can serve for evaluating potential solutions in situations where these
requirements hold.
lists the evaluation criteria, which are derived from the conceptual model’s Table 1
requirements. In addition, the criteria relate to the possibility of assessing the validity of the
process. For each criterion,
Table 1 presents evaluation indicators related to structural elements that should exist in a
model in order to meet the criterion. The evaluation indicators are expressed using the
concepts of the conceptual model, and can be evaluated on the basis of a mapping established
between the conceptual model’s concepts and those of the solution under evaluation. The
evaluation procedure includes a step of establishing a concept mapping between the two
models, and an evaluation step, as described below.
5.1 Evaluation procedure
We denote our conceptual model as CM, while the evaluated model shall be denoted M.
Step 1. Concept mapping
(1) Identify the concepts of model M, based on a conceptual map of model M.
(2) Map each M concept to CM concepts. Several cases may occur:
a. The mapping may be exactly one-to-one,
b. In some cases an M concept may correspond to a set of CM concepts,
c. In other cases a given M concept may be partially mapped to a CM concept.
(3) Map CM concepts to model M concepts (“reverse mapping”), to assure the mapping
completeness.
(4) Once steps (2) and (3) completed, we have a table with three columns: CM concept,
M concept, and the degree of equivalence (complete, partial, no equivalence). Several
cases may occur:
a. A CM concept does not have a corresponding M concept,
b. An M concept does not have a corresponding CM concept
c. It may also be possible that several M concepts are fully or partially mapped
to a single CM concept.
Step 2. Evaluation
Based on the concept mapping established in step 1, assess the level of each criterion
evaluation indicator (
Table 1). Note that the evaluation is qualitative and its result is on a discrete scale
(Compliance, Partial compliance, Non Compliance).
Table 1. Evaluation criteria
Criterion
Criterion evaluation indicators (in
relation to the concept mapping)
(1) Non Central governance
No party should have full visibility or some control
of the domains at any moment while designing,
implementing, executing or monitoring the overall
process
Non existence of transformations outside
of private domains. (non existence of
shared sub-domain transformations)
Separation between shared sub-domain
state variables and private state variables
(2) BP run time governance assurance
Ability of partners to Identify the overall process Shared sub-domain state definition + association
state at any moment in time.
between obligations and sets of shared subdomains states
Partners' access to mutual state variables value.
Partner’s knowledge of expected run time Definition of obligations for each shared subbehavior.
domain state.
Identification of soft-goals (QoS parameters)
Definition of performance constraints for each
shared state
Mapping of the shared state performance
constraint to internal performance constraints
Association of events and transformations in the Inclusion of QoS state variables in obligation
model with QoS constraint incompliance.
definition
(3) Domain Privacy conservation
Distinction of necessary from optional private Distinction between internal and mutual
process visibility needs (Intrinsic and mutual state variables.
properties mapping).
Privacy of transformations execution
Privacy of process laws
No shared sub-domain transformationsonly private transformations
No shared process law
Shared domain state transition only through Shared domain state transition only
obligations fulfillment.
through obligations fulfillment.
(4) Domain Autonomy conservation (private process design & run time)
Minimal constraints on private process design
Minimal constraints on private process execution
Design constraints imposed only on
mutual properties through obligation
definition.
Run-time constraints imposed only on
mutual properties through obligation
definition.
(5) Validity of the overall process
Private Processes validity establishment
Shared domain process validity establishment
Private process model includes mutual
properties in addition to intrinsic ones.
Goal state identification (shared and
unshared ones)
Inclusion in the obligation definition of
the relevant external event definition
Existence of a Validity criteria for the
private process
For each state of the shared sub-domain,
there must be at least one obligation
associated with it.
5.2 Applying the procedure to existing solutions
We proceed to the evaluation of three potential inter-organizational process design and
implementation solutions: (1) the Public to Private (P2P) approach for inter-organizational
12
workflow [7], (2) the Contract Workflow Model (CWM) [3][4] [5] [27] and (3) the
RosettaNet approach [28][29].
These three approaches were selected as examples of models whose aim and focus are
different. In addition, the documentation of these approaches is detailed enough to enable
their analysis. A brief introduction to these models is presented below, followed by their
evaluation.
The Public to Private (P2P) model
The P2P approach [17] uses models expressed as workflow (WF) nets, which are a specific
form of Petri-nets.
The following steps are defined for setting the inter-organizational workflow:
Step (1): Following the contract specification, the partners form an end to end workflow,
named "the public workflow".
Step (2): The public workflow is partitioned onto domains: each interacting entity (e.g.
customer, supplier, partner, etc.) is associated with a domain. Public parts, while related to
each domain, form the definition of the inter-organizational workflow net (IOWF net). An
IOWF-net consists of a set of WF-nets, a set of channels, a set of methods, and a set of
channel flow relations. Methods represent the public view of domain tasks, and are associated
to channels through the channel-flow relations.
Step (3): Each domain creates its private workflow, which, for preserving the overall
workflow, must be a subclass of its public part.
The model focuses mainly on the control-flow view of the process, whilst other aspects of the
process are not dealt with (Data flows, time constraints). Workflow nets are based upon Petrinets that are constrained to a single-token per place. A WF net must have one initial place and
one final place, and can be verified for soundness. A sound WF net has to be connected, safe,
deadlock free, and free of dead transitions. Moreover, sound WF nets always terminate
properly (i.e., reach an end state which contains one token in the final place and no tokens in
other places of the net).
Aalst and Basten [130] defined the projection inheritance criterion, which establishes
equivalence of WF-nets, preserving soundness under a specific list of change operations. The
criterion ensures the equivalence of WF nets without accessing WF instance data. They also
provided a diagnosis tool called Woflan to automatically check inheritance equivalence rules
for two given schemas. The projection inheritance is intended to render schema change
impact as local as possible. Through projection inheritance soundness of the process can be
maintained, while preserving the privacy of the internal processes implemented by each
13
organization. However, it would be difficult to deal with information beyond the basic control
flow of the process (e.g., data flow). Excluding data tokens from the model (that is,
addressing control flow only), the problem is largely simplified. Moreover, there is no
inheritance relation that allows state order change, parallelization of otherwise sequential
transitions, etc, thus limitations are formed on the potential internal processes.
The model does not deal with time or performance constraints. Time constraints affect sets of
process paths and might cause difficulties in retaining inheritance equivalence.
The mapping of P2P concepts to CM concepts (including the relevant basic concepts taken
from GPM and Bunge's ontology) is presented in Error! Reference source not found.. The
equivalence in the table can be full (+), partial (P), or none (-).
Table 2. Mapping P2P concepts to CM concepts
CM concept
P2P concept
Process domain
Overall workflow
Shared domain
IOWF/public workflow/public domain
Private domain
Private domain/workflow
State
The set of marked places
Transformation
transition/task
--------------------------- Method
Event
Internal event A change in some place markings (transition).
External event A place marking -result of a method’s task firing.
Stable state
Sink place
Unstable state
Some place markings (other than the sink)
Shared sub-domain state The set of all enabled channels (IOWF net state).
mutual state variable
Channel/place
Process Goal
Sink place
Law
Arcs
Obligations
Channel-flow relation/arcs/transition input or output.
Soft goal constraint
------------------------Process validity criteria Workflow net soundness + projection inheritance criteria
------------ stands for no equivalent concept
Equivalence
of concepts
+
P
+
P
+
P
P
P
P
P
P
P
P
P
P
Detailed explanation of the mapping is given in Appendix 1. In summary, P2P model
distinguishes private from shared domains. However, this distinction is not based on
identification of mutual properties. Hence, some intrinsic properties of the organizations may
be exposed in the public domain. For example, the goal of the overall process, which may be
in one of the private domains, is public according to the P2P model. In addition, P2P specifies
transitions (methods) in the public domain, whereas in CM the shared (public) domain holds
states only, and all transformations are performed (privately) by the partners. Finally, P2P
does not address soft-goals or performance constraints.
14
The Contract Workflow Model (CWM) model
Within a multi-tier Contract Ontology (MTCO), [5] established a 3 tier ontology for
modeling business contracts. The goal was to integrate the contractual terms and conditions
into a regular business process workflow, in order to improve the alignment of the business
workflow with the expected behavior pattern of the contractual obligation. MTCO integrates
several ontologies in order to offer a model that is open and flexible enough to represent
many contract types:
-
Upper level core contract ontology
-
Specific domain level contract ontology
-
Template level contract ontology
The Upper level ontology is the one that, according to the authors, defines all the required
and necessary components of a business contract in order to be legally valid. The Specific
Domain level ontology relates to specific contract types and the Template level ontology
groups pre-defined contract models, using standard and/or established contract model forms
such as the ICC.
For the sake of evaluation we are interested in the basic concepts upon which the model is
built, which are modeled within the Upper Level Core Contract Ontology.
The MTCO main concepts are: Contract, Role, Consideration, Obligation, Performance,
Timeframe, Non-performance, Rights and Prohibitions.
A contract is an abstract concept representing the contract document. A Role is the
responsibility an actor undertakes to perform under the period and scope of the particular
contract. A Consideration describes the objective or purpose for which the agreement is being
made. An Obligation is a promise made by the contracting parties and the duties and
responsibilities that accompany them. Different levels and kinds of obligations are
distinguished in the model. Performance is a concept used for defining the expected behavior
or actual execution of the contract. It may be a business event or activity like the delivery of
ordered goods. Every performance is related to some obligation. A group of performances
may be required to fulfill the same primary obligation. Non-performance relates to situations
where performance is not achieved as promised. Time-frame is a specified time period after
which the contract is either terminated or renewed or a new business contract may be
renegotiated. Rights are powers and options awarded by one party to the other empowering
the receiver of the rights to certain entitlements or guarantees subject to certain conditions
and situations. Finally, Prohibitions specify conditions that must not be met. An occurrence
of prohibited acts would result in a contract violation.
In Table 3 we establish a mapping of the CWM model to CM (again, including relevant GPM
and Bunge's concepts).
15
Table 3: Mapping CWM concepts to CM
CM concepts
CWM concepts
Process domain
Shared sub-domain
Private sub-domain
State
Transformation
Contract + actors + roles.
--------------------------------------Obligation states + performance state.
Performance/
performance
event,
Nonperformance/Non-performance event
Event
Business events/obligation state change
Internal event
-------------------External event
-------------------Stable state
-------------------Unstable state
-------------------Shared sub-domain State
Obligation states+ performance states
Mutual state variable
obligation states + performance states
Process Goal
Consideration, Timeframe
Transformation Law
Obligation
State
transformation
diagrams,
prohibitions.
Obligation
Obligation (primary, reciprocal, conditional,
secondary).
Obligation
Permissions/Rights
Process validity criteria
Valid contract criteria
Soft-goal
------------------------Annotations legend:(+)= equivalent; (P)= partially equivalent; (-) = non equivalent.
Equivalence
of concepts
P
P
P
P
P
P
P
P
P
P
P
-
Detailed explanation of the mapping is given in Appendix 1. In summary, CWM addresses
the entire process domain without establishing private and public domains. Hence, no
mapping is found regarding the different domains, the external/internal events, and
stable/unstable states. CWM does not address soft-goals and validity criteria either. On the
other hand, it distinguishes different kinds of obligations as well as permissions and rights, all
mapped to a single CM concept. We note that these distinctions are useful in the context of
contract establishment and monitoring, but can all be generalized to a single concept.
RosettaNet
RosettaNet [28] is consortium of more than 500 companies within the electronic component
and information technology industry, which have joined forces to address the need for more
accurate information throughout the global supply chain. This goal is achieved by the
standardization of RosettaNet Partner Interface Processes (PIPs) to define business processes
between trading partners. Each PIP defines how two specific processes, running in two
different partners’ organizations, will be standardized and interfaced across the entire supply
chain. A PIP includes all business logic, message flow, and message contents to enable
alignment of the two processes.
RosettaNet relates to an eBusiness Process, which comprises a set of PIPs. Each PIP is a
template of a specific process, including documented specifications of its services,
16
transactions, messages (including dictionary properties), class and sequence diagrams in
UML, validation tools, and an implementation guide.
A PIP depicts the activities, decisions and partner role interactions that fulfill a business
transaction between two partners in the supply chain. Each partner participating in the partner
interface process must fulfill the obligations specified in a PIP. If any partner fails to perform
a service as specified in the PIP implementation guide then the business transaction is null
and void.
PIP Specifications include three major sections. These three specifications represent three
different levels of abstractions. The Business Operational View (BOV) describes the business
goal that the Partner Interface Process is supposed to achieve. The Functional Service View
(FSV) describes the transaction dialog. The Implementation Framework View (IFV) includes
message guidelines and protocols for communications between software components. In this
paper we focus on the BOV aspects of the PIP, partly complemented by FSV.
RosettaNet PIP blueprints contain the following sections: (a) Business process definition; (b)
PIP purpose; (c) PIP business process flow diagram (figure); (d) PIP start state and end state
(specified as pre-and post-conditions); (e) A table specifying partner role descriptions; (f) A
table specifying business activity descriptions, including its responsible role and pre- and
post-conditions; (g) A table specifying business activity performance controls, which
specifies controls such as time limits for specific events (e.g., acknowledgement) and
authorizations; (h) A table specifying PIP business documents and its data entities; (i)
Business data entity security requirements.
Table 4: Mapping RosettaNet concepts to CM
CM concept
Rosetta Net solution
Process domain
Shared domain
Private domain
e-Business Process
PIP
Private
process (including PIP
integration)
PIP state
Business activity descriptions (table)
State
Transformation
Event
Internal event
External event
Equivalence
of concepts
P
+
implementation P
Part of the Business activity Pre and post conditions
Part of the Pre and Post-conditions; Messages defined
within the Functional service view
Stable state
PIP state, PIP start state, PIP end state
Unstable state
------Shared sub-domain state PIP state
mutual state variable
Business documents
Process Goal
PIP end state
Law
PIP business process flow diagram
Obligations
Business activity descriptions (table) + Business activity
performance controls
Soft goal constraint
Included in the Business activity performance controls)
P
P
P
+
+
+
+
P
P
+
P
17
CM concept
Rosetta Net solution
Equivalence
of concepts
Process validity criteria
PIP definition conditions
P
A detailed explanation of the mapping is provided in Appendix 1.
Criteria Evaluation
Based upon the previous mapping, we proceed in the following to the evaluation of the
investigated models, presented in Table 5.
Table 5. Models evaluation
Criterion/criterion
evaluation
Rosetta Net
P2P evaluation
CWM evaluation
P
(P2P Methods are
shared domain
transformations, done
by one of the partners)
P
(Channels represent
mutual state variables,
but there is no
structured distinction
of mutual from
intrinsic variables)
(All transformations are
visible to all domains)
P
(through the method
concept the IOWF is
related to internal
Petri-nets; yet no QoS
variables
+
(the view of a partner
includes its private
workflow and the
public one)
P
(Obligation states, like
all states, are shared. No
QoS variables)
P
( methods mapping,
partial because of
missing QoS
variables)
(performance
constraints are not
identifiable in P2P)
P
(Obligations and
performance states
represent partially
shared domain states,
missing QoS variables)
(performance constraints
are not identifiable in
CWM)
(performance
constraints are not
identifiable in P2P
(performance constraints
are not identifiable in
CWM)
Non Central governance
Non existence of
transformations outside
of private domains.
Separation between
shared sub-domain
state variables and
private state variables
+
(PIP activities are
done by one of the
partners, although all
of them are visible)
+
(RosettaNet deals only
with documents to be
shared)
(No distinction of
mutual from intrinsic
variables)
BP run time governance assurance
Shared sub-domain
state definition and
association between
obligations and sets of
shared sub-domains
states
Partners' Access to
mutual state variable
values.
Definition of
obligations for each
shared sub-domain
state.
Definition of
performance
constraints for each
shared state
Mapping of the shared
state performance
constraint to internal
performance
+
(PIP state, business
activity, and business
activity performance
controls)
+
(only shared
documents (mutual
variables) are modeled
and all partners have
access to them)
+
(Business activity
performance controls)
P
(as part of the PIP
business activity
performance controls;
limited to specific
ones defined)
(RosettaNet focuses
on the shared domain;
the private domain
+
(access to all variables,
not only mutual)
18
constraints (on private
interaction states)
Inclusion of QoS state
variables in obligation
definition
details are out of
scope)
+
(the business activity
performance
associated to the PIP )
model)
(performance
constraints are not
identifiable in P2P)
(performance constraints
are not identifiable in
CWM)
P
(Channels represent
mutual state variables,
but P2P offers no
method to distinguish
mutual from intrinsic
properties)
P
(Method are shared
transformations
visible to external
domains, but there are
private transitions as
well)
(Process law exist in
the IOWF)
(In CWM all process
variables are shared)
Domain Privacy conservation
Distinction between
internal and mutual
state variables.
+
(only shared
documents which are
mutual variables are
modeled in
RosettaNet)
No shared sub-domain
transformations
P
(PIP activities are
done by one of the
partners in his internal
domain, although they
are publicly visible)
No shared process law
(PIP blueprint, shared
between partners,
includes the process
law)
+
(PIP state is governed
by the set of business
activity descriptions
and business activity
performance controls)
Shared domain state
transition only through
obligations fulfillment.
P
(The shared domain
has a process law by
itself. However state
changes are related to
channel-flow
relations, partially
mapped to
obligations)
(All performance/
performance events,
Non- performance
events are shared in
CWM)
(All Obligation State
transformation diagrams,
prohibitions are visible
to all partners)
P
(No shared domain
identification, but the
obligations and
performance states are
the mechanisms of
process state transition)
Domain Autonomy conservation (private process design & run time)
Design constraints
imposed only on
mutual properties
through obligation
definition.
Run-time constraints
imposed only on
mutual properties
through obligation
definition.
+
(Only the shared
documents are
modeled; each partner
implements its internal
processes based upon
the desired PIP's for
attaining its
transaction goals
+
(Rosettanet addresses
and constrains only
exchanged documents
& data)
P
(Projection
inheritance constraints
on internal processes)
(No distinction of
mutual from intrinsic
properties, process
design addresses all
properties)
P
(Methods are visible
and constrained in run
time, internal
transitions are not)
( no distinction between
mutual and intrinsic
properties exist )
P
(Channels are mapped
to internal places)
P
( no distinction between
mutual and intrinsic
properties exists)
P
(P2P has one (shared)
sink place)
P
(CWM's considerations
and contract timeframe
Validity of the overall process
Private process model
includes mutual
properties in addition to
intrinsic ones.
Goal state
identification (shared
and unshared ones)
(only mutual
properties are
modeled; private ones
are out of scope)
P
(only shared goal
states are modeled
19
Inclusion of the
relevant external event
in the obligation
definition
Existence of a Validity
criteria for the private
process
through the PIP end
state; the goal of the
overall process is not
necessarily modeled)
+
(Pre- and postconditions of business
activities)
(only for the interorganizational process
is validated in
RosettaNet)
are all shared).
P
(P2P channels and
channel-flow relations
provide the relation
between methods of
different domains)
+
(although there is no
distinction of external
and internal events,
obligation state
transition diagrams
specify events for each
transition)
(CWM provides no
mechanism to assure the
overall process validity)
P
(WF net Soundness +
projection criteria.
However, they
address process
structure rather than
goal reachability)
For each state of the
+
+
+
shared sub-domain,
(PIP validation
(Soundness criteria +
(Obligations states
there must be at least
criteria)
projection criteria
diagrams )
one obligation
ensure that each
associated with it.
channel is associated
with methods through
channel flow
relations)
Annotations legend: (+) = compliant; (P) = partial compliant; (-) = non-compliant.
Evaluation Summary
The P2P solution establishes an extensive implementation model through the concept of
projection inheritance, and the adoption of Petri-nets at the basis of its workflow net. This
provides a solid run time governance of the process state. However, the model does not
support performance constraints (time and quality constraints over process paths), nor does it
deal with data flow modeling, which may lead to a risk of incomplete transformation and law
definition. Its focus is on the construction of sound private workflows that maintain the
soundness of the public IOWF. To this end, the P2P approach models the shared domain
using IOWF-net, mapped through projection inheritance into the private workflows. The
existence of shared transformations and laws and the lack of an explicit distinction of mutual
properties from intrinsic domain properties may imply the external visibility of intrinsic
private domain properties; hence domain privacy may be compromised. The privacy of the
parties can be improved if it is explicitly checked that no intrinsic properties are exposed. As
well, P2P includes the process goal in the public workflow, although it may be within some
private domain. When the exposure of the goal state is not necessary, it is recommended to
avoid it, thus gain an improved privacy.
P2P process validity verification relates to its soundness, which contributes to the goal
reachability in terms of the process logical flow, but not, e.g., the completeness of its
20
definition. As well, validity of data flows and transformations are out of the scope of the
model. The soundness of the private processes can be established wherever the projection
inheritance criterion is applicable. Hence, it provides some flexibility to the partners in
designing and modifying their internal processes as long as projection inheritance is kept.
However, projection inheritance is applicable under specific conditions, and is not applicable
whenever the necessary modification in the private domain implies changing state order,
parallelization of otherwise sequential tasks, etc.
Performance (soft goal) constraints mapping may result in design modifications of internal
process domains (state laws, transformation laws, adding state variables). As well, process
path selection may be notoriously changed by soft-goal related conditions. P2P provides no
mechanism for such modeling.
The CWM solution establishes a contract workflow model based upon an extensive ontology
of contracts. Herein we consider only the generic layer of the MTCO ontology.
CWM defines the end-to-end process in a completely visible manner. Its focus is supporting
the transition from a business legal contract to an operational workflow model. During both
process design and process implementation all domains are fully visible. Hence, the domains'
autonomy and privacy are compromised. Although this provides a high level governance of
the process state at run time, it disables the capability of the partners to modify their internal
processes or to deviate from their definition, thus decreases their flexibility. To gain some
autonomy and flexibility, it may be recommended to model the internal activities of the
organizations at a low level of granularity and keep their details hidden.
CWM offers an exhaustive model for obligations and distinguishes different types of these. It
manages and monitors the life-cycle of obligations. It also addresses goals (referred to as
considerations). However, it does not enable soft-goals and performance constraints mapping
and handling. Soft-goal constraints mapping may result in design modifications of internal
process domains (state laws, transformation laws, adding state variables). As well, process
path selection may be notoriously changed by soft-goals related conditions. CWM provides
no mechanism for such modeling.
Finally, CWM postulates that the contract document which is agreed upon between partners
allows the specification of a valid overall process. However, process validity criteria are not
established.
Note that, as mentioned, our analysis relates to the upper-level ontology of CWM, while
disregarding the lower-level ones, which provide additional concepts, whose value is in the
context of contracts between organizations. However, the lower-level ontologies rely on the
upper-level one and extend it, thus they preserve its assumptions.
21
The Rosettanet approach is focused on facilitating the interaction within an interorganizational business process. As such, it seems to provide a high level of compliance
regarding the autonomy and privacy requirements. PIP's provide a solid framework for
defining the building blocks of possible transactions between partners, with a well defined set
of validity criteria for the PIP, including obligations and performance constraints definition at
the PIP level.
However, RosettaNet PIP's are only the building blocks for an overall process, which is not
modeled in RosettaNet, leaving the internal process design to other methodologies or
approaches, thus avoiding a view of an overall process whose validity needs to be
established. As compared to, e.g., P2P, RosettaNet preserves privacy by relating only to
information that needs to be shared. However, while P2P supports the construction of
compatible and sound private processes, this aspect is not addressed at all in RosettaNet.
Moreover, each PIP in RosettaNet is designed for a specific use. If processes that are not
predefined are to be implemented, they first need to be modeled, thus the RosettaNet would
need to be extended for that. RosettaNet is designed for a specific market segment, and not a
generic one (EC and IT markets specific).
Although RosettaNet provides specifications that encompass many aspects of an automated
business relationship, it does not address problems of aligning legacy systems and internal
business processes towards the specified application integration scenarios.
RosettaNet can beneficiate from the conceptual model established in this paper to link its PIP
building blocks as elements within the overall business process. This would provide also for
overall BP validity criteria, essential for linking the PIP's goals to the overall process goals.
6. Discussion
We have established a minimal but consistent set of requirements which are related to the
required balance between the control over the process and the autonomy and privacy of the
partners organizations involved in business transactions. The completeness of such model can
be assessed with respect to: (a) the set of requirements it is aimed to fulfill. Our model was
designed based on a defined set of requirements and derived from these requirements.
Considering possible requirements which are not in this set, the model may need to be
extended. (b) The expressive power of the model in representing the phenomena under
consideration. Our model is based on Bunge’s ontology, which has been widely used as a
basis for evaluating the expressive power of models. This basis provides for completeness in
terms of the model’s expressive power.
From these requirements we derive a formal, ontology based Inter-organizational BP
conceptual model, based upon a formal generic process model, the GPM.
22
Establishing a CM prior to selecting potential implementation solutions provides a formal and
valid framework for analyzing potential solutions, while remaining at a high level of
abstraction and allowing traceability between the solution implementation and the business
requirements.
Key concepts in the model are the domains, whose demarcation is clear. Defining the shared
sub-domain as a sub-domain whose states are all stable clarifies the responsibility of the
organizations to transforming the state of this sub-domain and makes their obligations
concrete. The concept of obligations as it is defined in the model minimizes the constraints
posed on the internal operation of the participating organizations. The concept of state
variables is highly generic, and may bear a large variety of forms. This can be considered
both as a strength and as a weakness. It is a strength because it enables the model to address
diverse issues, such as status attributes, data flows, and performance constraints. It is a
weakness when implementation is considered, because these issues require different
implementation mechanisms, which are not addressed by the model. Hence, such
mechanisms should be supported when an implementation solution is designed.
Based upon the CM, we presented an evaluation procedure that relates to our underlying set
of requirements, and applied it to three potential BP implementation solutions in light of the
established set of BP requirements: the P2P approach [17], the CWM approach [4], and
RosettaNet [28]. The findings provide a clear assessment of the strength and weaknesses of
these approaches with respect to our requirements, and support the selection of an appropriate
solution.
The evaluation itself is comparable to ontological evaluation of modeling languages [24].
Green and Rosemann [18] discuss weaknesses of such evaluations, including lack of
completeness, lack of objectivity, lack of guidance, and others. They propose a reference
methodology for conducting ontological analysis, based on meta-models. The evaluation
procedure proposed in this paper follows this approach. The first step of concept mapping
relates to meta-model concepts; cross-mapping is intended to ensure completeness, and the
evaluation criteria indicators establish a direct relation between the concept mapping and the
evaluation, in order to provide a strong guidance when performing the evaluation and to
avoid a lack of objectivity.
The evaluation procedure can be applied to any other inter-organizational process solution
providing a clear mapping of possible adaptation for satisfying the above list of requirements.
However, our model is based on a specific set of requirements. It may need to be extended or
modified to satisfy different sets of requirements. In fact, we recognize that in many cases not
all our requirements are required. Such is the case, for example, of associations of
organizations which have a central governance committee, where the non-central governance
23
assumption is not relevant. Another example is the case of a supply chain established between
partners, where powerful partners may impose visibility of details on other partners, less
powerful. Even in this case the work need not be redone from scratch, as the model is at at a
high level of abstractions and traceability of the requirements to conceptual model
components is straight forward.
Finally, we highlight the importance of a sound requirement based conceptual model as an
underlying basis for BP implementation solutions.
7. Conclusion
The importance of inter-organizational processes has been widely recognized, leading to a
variety of approaches and proposed solutions to their design and implementation. While most
of the approaches focus on a specific aspect of these processes and on their implementation
details, this paper focuses on a high-level conceptual model, aimed at achieving an
understanding of the interaction among organizations in situations where particular
requirements are made.
Proposing this model, the paper makes two main contributions. First, the model is sound and
theory-based, and provides a sharp understanding of how organizations can interact in
ontological terms. It satisfies a set of restrictive requirements regarding the governance of the
overall process and the conservation of privacy and autonomy of the participating
organizations. Furthermore, it can be used for designing an inter-organizational process, as
shown by 1.32]. Second, we propose the CM as a platform for evaluating potential solutions
for inter-organizational process establishment. This proposition relies on the generic nature of
the model, on its sound theoretical basis, and on its explicit relation to specific business
requirements. By using the established conceptual model, we have illustrated the ability to
map different implementation models and compare their compliance with our preset model
requirements. We have also demonstrated how possible improvements can be made to the
examined approaches based on our model.
Future research may address other sets of requirements and identify the difference required in
the underlying conceptual model when such different assumptions are made. We believe that
the current model provides a basis that can, with minor modifications, be valid for other sets
of requirements too. Another research direction is to develop an implementation solution
based on the model, which will address the entire scope of issues represented by state
variables and allow control as well as privacy and autonomy.
24
References
1. Aalst, W. M. P and Kumar, A. (2003) “XML-Based Schema Definition for Support of
Inter-organizational Workflow”, Information Systems Research 14(1), p. 23-46.
2. Grefen P., Abere K., Hoffner Y. And Ludwig H. (2000), “CrossFlow: CrossOrganizational Workflow Management in Dynamic Virtual Enterprises“, International
Journal of Computer Systems Science & Engineering, 15 (5), p. 277-290.
3. Kabilan V. and Johannesson P. (2003), “Semantic Representation of Contract Knowledge
using Multi Tier Ontology“, Proceedings of Semantic Web and Databases Workshop,
(SWDB 2003).
4. Kabilan V. (2005), “Contract Workflow Model Patterns Using BPMN“, EMMSAD’05,
Proceedings of CAiSE’05 workshops Vol. 1, Porto, Portugal, p. 557-568.
5. Kabilan V., Johannesson P. and Rugaimukammu, D. (2003), “Business Contract
Obligation Monitoring through Use of Multi-tier contract ontology“, Proceedings of
Workshop on Regulatory Ontologies (Worm Core 2003), Italy, (LNCS 2889), SpringerVerlag, Berlin
6. Kafeza E., Chiu D. K.W. and Kafeza I. (2001), “View-Based Contracts in an E-Service
Cross-Organizational Workflow Environment“, Proceedings of TES 2001 (LNCS 2193),
Springer-Verlag, Berlin, p. 74-88.
7. Cassati F. and A. Discenza (2001) “Modeling and Managing Interactions among
Business processes”, Journal of Systems Integration (10), pp. 145-168.
8. Guelfi N., G. le Cousin and B. Ries (2004), “Engineering of Dependable Complex
Business Processes Using UML and Coordinated Atomic Actions“, Proceedings of OTM
workshops (LNCS 3292), Berlin: Springer-Verlag, pp. 468-482.
9. Weigand, H. and Van den Heuvel, W.J, (2002), “Cross-organizational workflow
integration using contracts“, Decision Support Systems 33(3), p. 247-265.
10. Business Process Management Initiative (2006), http://www.bpmi.org.
11. ebXML BPSS (Electronic Business using eXtensible Markup Language) (2006), ebXML
BPSS specification, website:http://www.ebXML.org/.
12. OMG (Object Management group) (2006), Business Process Modeling Notation
(BPMN), http://www.bpmn.org/
13. W3C (World Wide Web Consortium) (2006), http://www.w3.org.
14. OASIS (Organization for the Advancement of Structured Information Standards) (2006),
http://www.oasis-open.org.
15. WFMC (Workflow Management Coalition) (2006), “Workflow Management Coalition
Interface: Process Definition Interchange Process Model“. http://www.wfmc.org.
25
16. Camarinha-Matos, L.M and Afsarmanesh, H. (Eds) (1999), “Infrastructures for virtual
enterprises –Networking industrial enterprises“, Kluwer Academic Publishers.
17. Aalst, W. M. P and Weske, M. (2001) “The P2P Approach to Inter-organizational
Workflows“, Proceedings of CAiSE’01 (LNCS 2068), Springer Berlin p. 140-156.
18. Green, P. F., Rosemann, M. and Indulska, M. (2005), “Ontological Evaluation of
Enterprise Systems Interoperability Using ebXML“, IEEE Transactions on Knowledge
and Data Engineering 17(5), p. 713-725.
19. Soffer, P. (2005), “On the Notion of Flexibility in Business Processes“, Proceedings of
the CAiSE’05 Workshops, p. 35 – 42.
20. Soffer P. and Ghattas J. (2006), “Business Process Flexibility in Virtual Organizations”,
Workshop on Business Process Modeling, Design and Support (BPMDS’06),
Proceedings of CAiSE’06 Workshops, p. 188-197
21. Bunge, M. (ed.) (1977), “Treatise on Basic Philosophy: Volume 3: Ontology 1: The
furniture of the world“. Reidel, Boston.
22. Bunge. M. (ed) (1979), “Treatise on Basic Philosophy: Vol. 4, Ontology II: A World of
Systems, Reidel, Boston.
23. Wand, Y. and. Weber, R. (1990), “An Ontological Model of an Information System“,
IEEE Transactions on Software Engineering, Vol. 16, No. 11, pp. 1282-1292.
24. Wand Y, and Weber R. (1993), “On the ontological expressiveness of information
systems analysis and design grammars“. Journal of Information Systems 3 pp. 217–237
25. Soffer, P., and Wand, Y. (2005), “On the Notion of Soft Goals in Business Process
Modeling“, Business Process Management Journal 11(6), p. 663-679.
26. Soffer P. and Wand Y. (2004), “Goal-driven Analysis of Process Model Validity“,
Advanced Information Systems Engineering (CAiSE’04) (LNCS 3084), p. 521-535
27. Zdravkovic J. and Kabilan V. (2005), “Enabling Business Process Interoperability Using
Contract Workflow Models“, OTM 2005: CoopIS, DOA, and ODBASE: OTM Con.
International Conferences, Cyprus (LNCS 3760) Springer-Verlag, Berlin, pp. 77-93.
28. Rosettanet Organization & Standards, website: http://www.Rosettanet.org/, 2007.
29. Damodaran. S (2004) “B2B integration over the Internet with XML: RosettaNet
successes and challenges”, Proceedings of the 13th international World Wide Web
conference, pp. 188-195
30. Aalst, W. M. P and Basten, T (2002), “Inheritance of Workflows: An approach to tackling
problems related to change“, Theoretical Computer Science 270(1-2), pp. 125-203.
31. Green, P. and Rosemann, M. (2005) "Ontological analysis of business systems analysis
techniques: experiences and proposals for an enhanced methodology" in P. Green and M.
Rosemann (eds.) Business Systems Analysis with Ontologies, IDEA, Hershey, pp. 1-27.
26
32. Ghattas J. and Soffer P., (2007) “Facilitating Flexibility in Inter-Organizational Processes:
A Conceptual Model”, International Journal of Business Process Integration and
Management (forthcoming)
APPENDIX 1: Models detailed mapping
Detailed mapping of P2P
CM : P2P concept
Explanation
Process domain (CM);
Overall workflow (P2P)
The overall workflow in P2P includes the public and private workflows, as
the process domain in CM unites all the partner domains (including the
shared sub-domain).
Shared domain (CM); A P2P Inter-organizational net (IOWF net) represents the public part of the
IOWF/ public workflow/ workflow. While the CM shared domain includes no process (only stable
public domain (P2P)
states), the IOWF net describes a complete process model, where methods ate
transformations generated by partners, defined in the shared domain; hence
the mapping is partial.
Private domain (CM); P2P offers a complete process model for the private domain based upon the
Private workflow (P2P)
WF-net concept. CM private domains set the scope the private processes.
Transformation (CM);
P2P has transitions/tasks in the private workflows, and method, which are
transition/task (P2P)
transformations that are visible-to all domains. CM transformations are all
private. CM postulates that the minimal requirement for a valid inter(no equivalent in CM);
organizational process definition is to define the shared states (mutual
Method (P2P)
properties, their associated semantics and possible values transitions) and
obligations (partners' commitment to implement the needed transformation of
shared states within their domains). Hence there is no need for transformation
visibility outside the private domains. The transformation public visibility
inevitably exposes intrinsic domain properties to the public.
Internal event (CM); CM establishes the concepts of internal/external events and stable/unstable
Place markings change states with respect to a particular domain. In P2P transitions in the private
(P2P)
workflows cause internal events to these domains, while methods fired by
External event (CM); other partners cause external events
Place
marking
after
method firing (P2P)
Stable state (CM); Sink The stability of a state in a private domain in P2P cannot be seen. Hence,
place (P2P)
only the sink place in P2P is identified as stable, while the others are
Unstable state (CM); considered unstable
Place marking (P2P)
Shared state (CM); The A channel is mapped into places within the private workflow. A token may
set of all enabled arrive to this place whenever a transition (representing a method) is fired.
channels (P2P)
Hence an enabled channel's place may be compared to the activation of a
Mutual state variable shared state. P2P channels represent mutual properties' values. Hence they
(CM);
Channel/place are mapped to mutual state variables. However, not all mutual state variables
relate to channels (e.g., QoS), thus the mapping is partial
(P2P)
Process Goal (CM); Sink In CM there may be multiple process goal states for each domain (process,
Place (P2P)
private and shared). While private domains have a set of defines goal states,
the overall process domain goals may be located in part of the domains and
be invisible to other partner domains. P2P IOWF net sink places represent
shared goal states, while WF-nets may represent private goal states in
addition to the mapping of shared goals into the private domain. Hence there
may be cases where CM unshared goal states are shared within the P2P
model.
Law (CM); Arcs (P2P)
CM law is private by definition. Arcs in P2P may represent public laws,
which have no equivalent in CM.
Obligations
(CM); A channel flow relation is a unidirectional association from a specific method
Channel-flow;
to a specific channel. A method generates a token that is passed to another
27
relation/arcs/input
or
output of a transition
(P2P)
Soft goal (CM); (none
in P2P)
Process validity criteria
(CM); WF net soundness
criteria+
projection
inheritance criteria (P2P)
domain through a channel. A method of domain A is mapped to a method of
domain B through channels and channel-flow relations. Hence channel flow
relations are state mappings between domains. This is somehow equivalent to
CM obligations concept.
P2P establishes no Soft goal (Performance) constraints in general. CM
performance constraints are associated with obligations; these obligations are
mapped into the different domains, as state laws that ultimately are
constraints/conditions set upon state variables.
IOWF nets are ultimately mapped into WF-nets, for which soundness criteria
exist (no deadlock, live-locks, free of dead transitions). The projection
inheritance assures for some cases that soundness of the process is
maintained through the construction of the private workflow-net. Unlike CM
process validity, soundness relates to structural properties of the process
rather than to its goal.
Detailed mapping of CWM
CM : CWM
concepts
Process
domain
(CM); Contract +
actors
+
roles
(CWM)
Shared sub-domain
(CM);
(none
in
CWM)
Private sub-domain;
(CM);
(none
in
CWM)
State
(CM);
Obligation
states;
performance
state
(CWM)
Transformation
(CM); Performance/
performance event,
Non-performance/
Non-performance
event (CWM)
Explanation
CWM provides a model for the end-to-end process, through the contract
definition, actors and roles mapping. Although it may be argued that actors
represent domains, their full process visibility is not consistent with CM domain
definition. All the actors' processes are completely visible and there are no
demarcations of domains. Domain goals, states, laws are not distinguished from
overall process domain goals, states and laws; hence CWM establishes neither
private domains nor shared domains.
As all the actors' processes are public, all the properties are shared by definition.
Hence, CWM does not identify mutual properties, although obligation states and
performance states may represent them implicitly.
CWM defines for each obligation a state transformation diagram, where possible
obligation states are: inactive, active, pending, fulfilled or terminated/ cancelled.
Each obligation is associated with a set of performance and non-performance
events, which have their own states. Hence the process state is described through
the obligation state and its performance/non-performance events' states.
CWM performance events and non-performance events are transformations that
are visible to all interacting actors. CM transformations visibility is limited to a
single specific private process domain. While CM established a single concept,
CWM offers two concepts: one for expressing transformations that handle
desirable process flow and the other for handling undesirable situations. Such
distinction highlights exception handling, important in the context of the contract
between the parties. However, on the conceptual level they are of the same kind.
Event
(CM);
Business
events/
obligation
state
change (CWM)
Internal / External
event;
Stable
/ As all the domains are shared, all states are shared and there are no private states;
Unstable state (CM)
hence there is neither distinction between stable/unstable states nor
Shared State (CM) external/internal events, except for the end-to-end process domain, where external
Obligation
states+ events may be originated by third parties.
performance states
(CWM)
Shared state variable
(CM);
obligation
states + performance
states (CWM)
28
CM : CWM
concepts
Explanation
Process Goal (CM); CM enables defining different goals for different domains (process, private and
Consideration,
shared). If the process goal is in a private domain it is not visible to the others.
Timeframe (CWM)
CWM's considerations and contract timeframe are all shared; there are neither
private goals, nor process goals visible to one side only.
Law
(CM);
CWM distinguishes between lawful and unlawful transformations using two
Obligation
State
different concepts: lawful transformations are expressed within the obligation state
transformation
transformation diagrams, while unlawful transformations are represented though
diagrams,
the prohibitions concept.
prohibitions (CWM).
Obligation
(CM); (1) CM obligations form part of the shared state definitions and represent a
Obligation (primary,
partner's commitment to transform shared domain states. CWM obligations and
reciprocal,
roles define the commitment between actors.
conditional,
(2) CWM obligations establish publicly visible tasks (performance/nonsecondary) (CWM)
performance events), associated with actors through roles. CM defines only
mutual properties and their required transformations and leaves the task
definition to the private domains.
(3) CWM obligations types include primary, secondary, reciprocal, and
conditional. CWM obligations may be nested (primary obligations may include
secondary obligations), while CM obligations are not. CM obligations may be
mapped to CWM conditional (triggered in specific conditions) obligations; CM
obligations represent both primary and reciprocal obligations as inherent in the
definition of CM obligation, i.e., commitment of the domains to implement a set
of transformation of shared state variables for a given shared state.
Obligation
(CM); CWM distinguishes obligatory obligations ("obligations") from optional ones
Permissions/Rights
("rights"). CM obligations are synchronous (triggered by shared events), as
(CWM)
opposed to rights which are asynchronous. While rights may be enacted by any
actor, it is not clear what mechanism helps other actors to identify their triggering.
This may cause ambiguity in the state of the overall process as perceived by other
actors, and consequently a risk of loosing control, or misinterpretation of
obligations. However, with a more accurate definition these concepts can be
partially mapped to obligations.
Process
validity CM process validity criteria apply to both the inter-organizational process and the
criteria (CM) Valid private processes. CM obligations assure the overall process validity, while private
contract
criteria process validity is assured by each organization, based on goal reachability. CWM
(CWM)
claims that a valid contract is established between two contracting parties/actors,
but it provides no mechanism to assure the overall process validity.
Soft-goal
(CM); CWM establishes no equivalent for CM Soft goal (performance) constraints. CM
(none in CWM)
performance constraints are associated with obligations mapped into the different
domains as constraints set upon state variables.
Detailed mapping of RosettaNet
CM : RosettaNet
concepts
Process domain (CM); eBusiness process
(RosettaNet)
Shared sub-domain (CM);
PIP blueprint (RosettaNet)
Private sub-domain; (CM);
Private process (RosettaNet)
State (CM); PIP start state,
PIP end State (RosettaNet)
Explanation
RosettaNet relates to an overall process termed the e-Business process for
B2B transactions. However, it defines only the inter-organizations aspects
of the transactions the partner should implement between them, which
would be a subset of all RosettaNet PIP's.
Each Partner needs to model its own private processes, but RosettaNet does
not provide any model to be used internally. The details of the
implementation are completely private and out of scope of RosettaNet.
Rosettanet does not address the overall process state. RosettaNet PIP state
represents the shared state. Hence the CM state has no complete equivalent
in RosettaNet.
29
CM : RosettaNet
concepts
Transformation (CM);
Business activity
descriptions
Event (CM); Business
activity Pre and post
conditions, Messages within
the Implementation view
(RosettaNet)
Internal / External event
(CM); Pre/post conditions
(RosettaNet)
Stable / Unstable state
(CM); Business activity
(RosettaNet)
Shared State (CM) ; PIP
state (start, end)
(RosettaNet)
Shared state variable (CM);
Business data document
(RosettaNet)
Process Goal (CM); No
equivalent
(RosettaNet)
Explanation
RosettaNet defines the transformations required of each partner within the
business activity descriptions, which provides also a definition of the pre
and post conditions of the transformations. RosettaNet does not provide the
overall process model- hence only B2B transactions are modeled – which
provide a partial equivalent to CM transformation concept.
RosettaNet Business activity Pre and post conditions are the triggers for the
PIP state change; However as RosettaNet models only the inter-org.
aspects of the private process these concepts are only partially equivalent
to CM event concept; RosettaNet Pre/Post conditions that trigger another
activity in the same domain are internal events to that domain.
RosettaNet Pre/Post conditions that trigger another activity in the same
domain are internal events to that domain. All the rest of pre-post
conditions would be equivalent to external events.
RosettaNet models only internal events related to the inter-org. process; in
PIP's where several related transformations need to be occurring in a
sequence there may be unstable states. These states would be invisible to
the external partners- however their effect upon shared documents (that are
mutual properties) would be visible to other partners.
RosettaNet provides a complete model of the PIP state, which is based
upon the shared business document transformations.
PIP business documents diagrams (table) included in the PIP blueprint are
shared state variables.
CM enables defining different goals for different domains (process, private
and shared). If the process goal is in a private domain it is not visible to the
others. RosettaNet 's PIP end state represents the goal of executing the
PIP. However the goal of the overall process is not defined.
Law (CM); PIP business
process flow diagram
(RosettaNet).
RosettaNet PIP business process flow diagram represents the PIP subprocess law. However the overall process law is not modeled in
RosettaNet.
Obligation (CM);
PIP Business activity +
Business activity
performance control
(RosettaNet)
CM obligations form part of the shared state definitions and represent a
partner's commitment to transform shared domain states. RosettaNet PIP
defines the commitment between partners. RosettaNet obligations establish
publicly visible tasks (business activity diagrams), associated with actors
through roles, though these tasks are applied only to shared documents
(that are the equivalent of CM mutual properties)
CM process validity criteria apply to both the inter-organizational process
and the private processes. CM obligations assure the overall process
validity, while private process validity is assured by each organization,
based on goal reachability. RosettaNet defines PIP validity criteria,
however these do not ensure goal reachability.
RosettaNet establishes PIP soft-goals within the Business activity
performance control included in the PIP blueprint. CM performance
constraints are associated with obligations mapped into the different
domains as constraints set upon state variables. The equivalency between
the two is only partial as the overall process soft-goals are not modeled. In
addition, only specific pre-defined soft-goals can be addressed, while
others cannot be added.
Process validity criteria
(CM) Valid contract criteria
(RosettaNet)
Soft-goal (CM); Business
activity performance control
(RosettaNet)
30