Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec H -- By Mathias Weske

Deferred Choice

Deferred choice is a state-based pattern. State-based patterns capture the implicit
behaviour of processes that is based not on the current case but rather on
the environment or other parts of the process. Some of the following patterns
require the existence of an external process that represents the environment.
This process is used as a source for external events.
A deferred choice is a point in a process model where one of several
branches is chosen. In contrast to the exclusive or split, the choice is not
made explicitly—for example, based on data values or a user decision—but
several alternatives are offered to the environment.
The environment activates one of the alternatives, and the other branches
are then withdrawn. Because the choice is delayed until one of the alternative
branches has actually been started, the moment of choice is deferred to a point
in time that is as late as possible.
Regarding the states of activity instances, each of the alternative branches
is represented by one activity instance in the init state. The state transition
from init to enabled is triggered by the environment, for instance, by sending
a message. After the state transition has occurred, the activity instances that
were not chosen enter the skipped state.
In that example, after a terminates, activity instances b, c, and d are created. Assuming that b is selected by receiving a message, b enters the enabled state, while c and d are
no longer required. Therefore, these activity instances are skipped.

Sequential Execution without A Priori Design Time Knowledge

The sequential execution without a prior design time knowledge pattern is
described as follows: a set of activity instances is executed sequentially in an
order that is decided at run time. No two activity instances of this set are
active at the same point in time.
Originally this pattern was called interleaved parallel routing; however,
this was somewhat misleading: The activity instances do not interleave, and
they are not executed in parallel. They are executed sequentially in an order
that is defined while the process instance runs. Therefore, in this book the
term sequential execution without a prior design time knowledge refers to this
pattern.
Activity models B,C,
and D are part of this pattern, so any sequential execution of activity instances
b, c and d are valid. This pattern is very useful in situations in which several
activities need to be executed sequentially and in any order. Since for any n
elements there are n! permutations, each of which corresponds to a sequential
execution ordering of n activity instances, modelling these explicitly is not
feasible.
The pattern can even be extended so that the execution ordering is not defined
before the first activity instance of the pattern has started. The sequence
can be defined also during the execution of the activity instances. A concrete
example is as follows: three persons need to work on a file, and each person
works on a separate part, so that the order in which the work is conducted is
not relevant. In this setting, after completing the first activity instance, one
person selects the next person to do his or her work.
The sequential execution in this case is induced by the single resource—
the file—that cannot be shared by the persons. Therefore, current allocation
of work to persons can be taken into account when deciding at run time on
the actual sequence in which the activities are executed.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec G -- By Mathias Weske

Multiple Instances With A Priori Design Time Knowledge

In the multiple instances with a priori design time knowledge pattern, the
number of activity instances of an activity model is known at design time.
These activity instances are synchronized, so that once all activity instances
have completed, the follow-up activity is enabled.
The follow-up activity c can only be enabled after the last activity instance
of B has completed, in this case b1. This property is shared by all multiple
instances patterns that are “synchronized.”
The specific property of the pattern at hand is that the number n = 2 of
activity instances of B is defined at design time, i.e., as part of the process
model. Depending on the process language used, there can be an attribute of
the activity model B that states, for instance, NrOfInstances = 2;.

Multiple Instances With A Priori Run Time Knowledge

In the multiple instances with a priori run time knowledge pattern, the number
of instances of a given activity model depends on the characteristics of the
case or the availability of resources. Therefore, it is only known at some stage
during run time of the process instance, but before the instances of the multiple
instances activity are created. This pattern also assumes synchronization
of the activity instances before the next activities can be enabled.
Rather than specifying the number of activity instances directly, we define
an expression. This expression is evaluated during run time to compute the number of activity instances for a specific process instance. This computation
occurs before the activity instances of the multiple instances activity are
created.
A process language might provide a functional representation of the number
of instances to create, so that, for instance,
NrOfInstances = GetNoOfLineitems(order);
might be a valid term. Here, the number of activity instances is computed by
a function that takes the current order and returns the number of line items
in it. An individual activity instance is then performed for each line item.

Multiple Instances Without A Priori Run Time Knowledge

In the multiple instances without a priori run time knowledge pattern, the
number of instances of a given activity is not known during design time; nor
is it known at any stage during run time before the instances of that activity
are enabled.
The difference with the previous pattern is that even while some of the
instances are being executed or have already completed, new activity instances
can still be created. During the
execution of these activity instances, new activity instances are created.When
all instances of B have terminated—in the example, b5 is the last activity
instance to complete—the next activity instance in the process can be enabled.
In order to realize this pattern in a process language and in a process
engine, there need to be additional assumptions in place. The main question in this context is, until what point in time is it possible to create new activity
instances of B?
One choice would be to indicate that while bs are running, new instances
of the multiple instances activity can be created. While this is a valid choice,
realization of this might not be practical, because it would assume that the
activity instances would include the creation of new instances, thereby intertwining
process management tasks (start new process instance) and doing the
actual work.
An alternative solution is to install a management activity related to the
multiple instances activity. This management activity explicitly defines the
end of the multiple instances activity. It is also responsible for creating new
instances of the multiple instances activity. It can even create new instances
after all instances have terminated. This is a valid approach, since in dynamic
settings, there might be an explicit decision about whether additional activity
instances are required to achieve the business goal related to the multiple
instances activity.
In the first alternative—if the follow-up activity is automatically enabled
after the current instances of the multiple instances activity have completed—
there are no options to create new instances of the multiple activity task once
all instances have completed.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec F -- By Mathias Weske

Implicit Termination

The implicit termination pattern is defined as follows: a given process instance
should be terminated when there is nothing else to be done. This means, there
is no activity instance in the process instance in the init, ready, or running
state and—as a result—no activity instance can be become enabled.
While implicit termination is defined as one of the control flow patterns,
its role differs with respect to the other patterns. It does not relate activity
instances with each other, such as, for instance, the sequence pattern or the
split and join patterns discussed. It represents a termination condition of an
overall process.
In several process languages, termination is explicit, because there is exactly
one state in the process that marks its termination. If there are many
states in which the process can terminate, then termination is implicit.

Multiple Instances Without Synchronization

More important than implicit termination are the patterns involving multiple
activity instances. These activity instances are based on a single activity model
in the context of a business process.
There are many situations that can be expressed properly by multiple
instances patterns. For instance, assume an order process in which an incoming
order contains a number of order lines. For each of these order lines, a check
activity needs to be executed. This means that only at run time can the
business process management system decide how many activities actually need
to be instantiated in order to perform the required checking activities.
The multiple instances without synchronization pattern is defined as follows.
In the context of a single process instance, multiple activity instances
of one activity model can be created. No synchronization of these activity
instances takes place.
In the process model shown, activity model B uses
the pattern. After the termination of activity instance a, a number of activity
instances are initiated and enabled for activity model B. In the event diagram,
activity instances b1, b2, and b3 are shown. These instances are enabled and
can be started.
The term “without synchronization” in the context of this example means
that the follow-up activity instance c can be enabled immediately after the
instances for B have been enabled. Since there are no assumptions on the
execution times of activity instances, c can terminate while activity instances
of the multiple instances activity are still running. In the event diagram shown,
b1 and b2 are still running when c has already completed.
This behaviour of the pattern has some consequences. First of all the control
flow between activity models B and C does not—strictly speaking—have
the semantics of a sequence pattern, since an instance of C can be enabled
while instances of B are still active. As a result, the sequence pattern is somehow
violated by the multiple instances without synchronization pattern.
This pattern causes problems not only with the sequence flow, but also
with the termination of the overall process. Since the activity instances are
not synchronized, it cannot be guaranteed that these activity instances have
terminated when the end of the process is reached. This means that certain
execution guarantees related to soundness properties (which will be discussed
in Chapter 6) cannot be satisfied.
Multiple instances patterns can be distinguished for the point in time
when the actual number of instances is determined. The multiple instances
without synchronization pattern does not make any assumptions on whether
the number of instances is defined at design time or at run time. This is
subject of the control flow patterns discussed next.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec E -- By Mathias Weske

N-out-of-M Join

The N-out-of-M join is a generalization of the discriminator. It is a point in
a process model where M parallel paths converge into one. The subsequent
activity is initiated after N  M paths have completed and the respective
termination events have occurred. Completion of all remaining paths is ignored.
As with the discriminator, once all incoming branches have fired, the
join resets itself so that it can be performed again. The N-out-of-M join is
illustrated in Figure 4.16.
A concrete example of the N-out-of-M join is a request for quotation
process, in which quotations are invited from five companies, although the
process can continue after receiving three quotations. Without a dedicated Nout-
of-M join, this business rule would be complex to model, because at design time it is not known which of the companies will respond to the request in
time.
There are variations on this control flow pattern with respect to the time
when the number N of sufficient threads is determined: it can be determined
at design time or at run time. The run time specification of N needs to be
done in an activity instance that is executed before the join.
There might be additional variations in the design time specification of the
N-out-of-M join if it is part of a loop. Design time specification of N could
therefore be taken within the loop, so that different iterations of the loop use
different values N for the number of sufficient threads to complete.
The N-out-of-M join degenerates to an and join if N = M. For N = 1,
however, it does not realize an exclusive or join, because the assumption of
the exclusive or join is not met (only one thread will be activated).
Nor does it realize a multi-merge, because in the multi-merge the completion
of the second and following threads would enable additional instances of
follow-up activities, while the 1-out-of-M join ignores them. The 1-out-of-M
join, however, realizes the discriminator pattern.

Arbitrary Cycles

An arbitrary cycle is a point in a process model where one or more activities
can be executed repeatedly. An arbitrary cycle is graphically depicted in Figure 4.17. In this example,
a sequence consisting of activity models A, B, and C is iterated. The iteration
is represented by an exclusive or split that decides whether to iterate the cycle
or whether to leave it and continue with activity instance d, associated with
activity model D. In case the loop is iterated, the exclusive or join triggers
another instance associated with activity model A.
As this example shows, arbitrary cycles are expressed with other control
flow patterns, for instance, exclusive or split and exclusive or join. Since these
control flow patterns have been specified already, no additional definitions are
required in order to define the arbitrary cycles pattern.
The problem in this example is that the cycle enters
one of two concurrent branches of an and split whose branches are joined by
a multi-merge.
The process starts by activitiy instance a, followed by the concurrent execution
of b1 and c1. When c1 completes, the first firing of the multi-merge
spawns off d2. We assume that the loop is not taken, so that e2 is started.
While d2 is still active, b1 terminates, so that the multi-merge creates
another instance of activity model D, namely d3. If the loop is iterated, the
second instance of activity model B is created, i.e., b3 (it holds the same
thread identifier than the previous activity instance).
When b3 terminates, d4 is started, and the loop can be entered again by
spawning off b4. To reset itself, the multi-merge waits for c3. Since the loop
was entered only in one of the concurrent branches, however, c3 does not exist!
Therefore, the multi-merge will not enable new instances of activity model D
when additional instances of activity model B complete.
In this example, after b4 terminates, the process instance will enter a
deadlock, because the multi-merge does not enable a new instance d5. An
event diagram of this execution is depicted in Figure 4.19.
This example shows that the combination of the multi-merge pattern with
loops might cause problematic process behaviour that process designers need
to be aware of to avoid erroneous processes.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec D -- By Mathias Weske

Discriminator
The discriminator is a point in a process model that waits for one of the
incoming branches to complete before activating the subsequent activity. From
that moment on it waits for all remaining branches to complete and “ignores”
them. Once all incoming branches have been triggered, it resets itself so that
it can be triggered again. This allows a discriminator to be used in the context
of a loop.
If gathering the ignored branches were not part of the functional behaviour
of the discriminator pattern, there would be no way to distinguish a second
iteration of a loop from a late branch of its first iteration.
A process model with activity models B, C, and D, and a gateway G such
that E  {(B,G), (C,G), (G,D)} and type(G) = Discriminator.To discuss the execution semantics of the discriminator, assume
that activity instance b terminates while c is still active. If this is the case, d
is triggered, and the discriminator continues to wait for the termination of c.
When c terminates, the discriminator is again ready for the next thread.
The process starts with activity instance a before an and split occurs that
spawns activity instances b1 and c1. Assuming b1 terminates first, the discriminator
fires and enables d1. When d1 terminates, assuming a new iteration of
the loop is required, new activity instances based on B and C are created. These activity instances are b2 and c2. What is remarkable in this example is
that there are two instances of activity model C active concurrently, assuming
c1 has not yet terminated.
Even if c2 terminates before c1, the semantics of the discriminator makes
sure that it can only fire and enable d2 after the first iteration has completed,
i.e., only after the remaining activity instance c1 has terminated. If this is
the case, the discriminator can fire a second time, to enable d2. Formally, for each enable event of d there are termination events of b and
c, and (at least) one of these termination events occurs prior to the enabling
event of d, i.e., 8ed 9tb, tc 2 Ep, such that tb < bd _ tc < bd.
In addition, the discriminator can become active only after the termination
events of all incoming edges that belong to the thread that has spawned the
current activities have occurred. In the example, d2 can only be enabled after
the termination operation of c1 has occurred.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec C -- By Mathias Weske

Multiple Merge

A multiple merge or multi-merge is a point in a process model where two or
more concurrent threads join without synchronization. The activity following
the merge is started for every activation of every incoming branch.
The multi-merge is functionally equivalent with the exclusive or join; the
only difference is that the latter assumes that only one of its incoming branches
gets activated. This assumption is not in place for the multi-merge pattern.
A process model with activity models B, C, and D, and a gateway G
such that E  {(B,G), (C,G), (G,D)} and type(G) = MultiMerge.
For each terminating activity instance b and c, one activity
instance associated with activity model D is started. This means that for each
termination event ti 2 Ep, where i 2 {b, c}, there is an enable event ed that
occurs after the respective termination event, i.e., ti < ed, i 2 {b, c}.
The multiple merge pattern spawns off new threads of control. These
threads need to be identified so that future joins can be realized properly.
These aspects are illustrated in an example shown in Figure 4.11, where a
process model with an and split followed by a multi-merge is shown. As a
result, any of the threads induced by the and split will survive the multiple
merge and spawn a new instance for activity model D and of the activity
models following D in the process model.
Each of the threads of control spawned off by the multi-merge is subject
to the and split/and join shown in the process model. The and join requires
information on the identity of the threads that come in; otherwise, situations
could arise in which activity instances that belong to different threads of
control are synchronized. These issues can be illustrated by the event diagram This diagram can be considered an abstract form of an
event diagram in which the lifetime of each activity instance is shown as a line
with borders marking the enabling and terminating of the activity instance.
The process starts with activity instance a, followed by the concurrent
execution of b and c. Assuming b terminates before c does, the multi-merge
spawns off a new thread of control, called thread The first
activity instance of this thread is d1.
While d1 is still running, c terminates, and the multi-merge spawns off
thread 2, starting with d2. When d1 completes, the and split occurs, and
concurrent threads are created, realized by activity instances e1 and f1.
After d2 terminates, e2 and f2 are created. Assuming that f1 and e2 terminate,
the and join faces a situation in which there are termination events of
activity instances on its incoming edges. Knowing that these belong to different
threads of control (f1 belongs to thread 1, while e2 belongs to thread 2),
the and join can “decide” that these threads cannot be synchronized, although
they belong to the same process instances.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec B -- By Mathias Weske

And Split

An and split or parallel split is a point in a process model where a single
thread of control splits into multiple threads of control which are executed concurrently. Consider a process model with activity models A, B, and C and
a gateway G such that E  {(A,G), (G,B), (G,C)} and type(G) = AndSplit.
Since thereby the process model P = (N,E, type) is well defined, we refrain
from providing the formal definition of P with the subsets of N. An and split determines that for each termination of an activity instance
a there are enable events of activity instances b and c, and these events occur
after the termination event of a. Therefore, for each ta 2 Ep there exist eb, ec 2
Ep such that ta < eb ^ ta < ec.

And Join

An and join is a point in a process model where multiple concurrent threads
converge into one single thread of control. It is an assumption of this pattern
that each incoming branch is executed exactly once.
Consider a process model with activity models B, C, and D, and a gateway
G such that E  {(B,G), (C,G), (G,D)} and type(G) = AndJoin. For each enable event of an activity instance d, there are termination events of activity
instances b and c, such that the termination events occur before the enable
event. Therefore, for each ed 2 Ep 9tb, tc 2 Ep such that tb < ed ^ tc < ed.

Xor Split

An xor split or exclusive or split is a point in a process model where one of
several branches is chosen. A process model with activity models A, B, and
C and a gateway G such that E  {(A,G), (G,B), (G,C)} and type(G) =
XorSplit The execution semantics of an exclusive or split determines that for each
termination of an activity instance a associated with activity model A there is
either an enable event of activity instance b or an enable event of an activity
instance c, but not both: for each ta 2 Ep: eb 2 Ep , ec /2 Ep, such that either
ta < eb or ta < ec.

Xor Join

An xor join or exclusive or join is a point in a process model where two
or more alternative threads come together without synchronization. It is an
assumption of this pattern that exactly one of the alternative branches is
executed.
Consider a process model with activity models B, C, and D, and a gateway
G such that E  {(B,G), (C,G), (G,D)} and type(G) = XorJoin.
For each termination event of an activity instance b or c there is one and
only one enable event of an activity instance d. Therefore, for each ti 2 Ep,
such that i 2 {b, c} there is an event ed 2 Ep such that ti < ed.
While it is an assumption of this pattern that the branches are alternative
and none of them are ever executed in parallel, the branches can be part of
a loop. But even in this case, for each iteration of a loop, the branches are
alternative and have exclusive or semantics.

Or Split

An or split is a point in a process model where a number of branches are
chosen. Selection of any nonempty subset of branches is a proper behaviour of
an or split. Figure 4.8 shows a process model with activity models A, B, and
C and a gateway G such that E  {(A,G), (G,B), (G,C)} and type(G) =
OrSplit.
An or split restricts the events of related activity instances as follows: for
each termination event of a there is a subset of enable events of b and c. In
general, for each termination event of a there can be enable events for any
subset of activity instances on the outgoing branches of the split.
In the example, the respective enable events are eb, ec 2 Ep, and any subset
of this event set reflects an acceptable behaviour of the or split, as long as
ta < eb and ta < ec are satisfied (if both branches are selected). In the general case where the or split has n
outgoing edges, 2n −1 options are possible: all nonempty subsets that can be
created out of n activities.

Or Join

An or join is a point in a process model where multiple threads of control
converge into one single thread. It is an assumption of this pattern that a
branch that has already been activated cannot be activated again while the
merge is still waiting for other branches to complete.
A process model with activity models B, C, and D, and a gateway G such
that E  {(B,G), (C,G), (G,D)} and type(G) = OrJoin . Once all active branching paths are completed and the respective end events of the final activities in these paths have occurred, the synchronization takes place.
Either only
the upper thread is taken and only activity instance b is enabled, or only the
lower thread is taken and c is enabled, or both threads are performed and b
and c both are enabled. In general, any nonempty subset of the threads are
valid options, so that 2n − 1 options are allowed for n incoming edges of the
or join.
The or join is a problematic control flow pattern. The problem is that
the join cannot locally decide how long to wait for its activation. Even from
the simple process model fragment shown in Figure 4.9, this problem can be
explained: once one incoming branch is triggered, for instance, by termination
of b, how should the or join react? There are two options:
• Wait: The or join waits before the activity instance d is triggered, because
the other incoming path—which completes in activity instance c—can still
be executed.
• Trigger : The or join triggers d immediately after the termination of b.
The problem is that we cannot decide which of these alternatives the correct
one is. After the first incoming branch has terminated, how long should the
or join wait for the other branch to complete?
If no additional knowledge is available, there is no way of deciding whether
c will eventually terminate for the particular process instance. Since there is no upper bound on the waiting time, realizing the waiting alternative leads
to a deadlock situation if the second thread is never activated.
If the or join triggers d after one incoming branch is activated, a situation
might occur in which c terminates after d has already started! This behaviour
contradicts the semantics of the or join, since in this case it has to wait until
both branches complete.

Business Process Management (Part-2 Business Process Modelling[Chapter IV Process Orchestrations ] ) Sec A -- By Mathias Weske

Control Flow Patterns

Control flow patterns provide a yardstick for expressing process orchestrations.
Control flow patterns are independent of concrete process languages, so that
each pattern can be expressed in different process languages. Control flow
patterns can also be used to compare the expressiveness of process languages.
Basic control flow patterns include sequence, and split, and and join, as
well as exclusive or split and exclusive or join. These control flow patterns
are supported by virtually any process metamodel. Control flow patterns are
defined at the process model level. Their execution semantics, however, applies
to process instances.
In this section, the semantics of control flow patterns will be investigated
on the basis of the events and event orderings they imply on process instances.
Due to its simplicity, the sequence pattern is well suited to explaining the
general approach.
Consider a process model P = (N,E, type) according to Definition 3.3
with activity models A and B and a sequence flow A ! B. This process
model defines an ordering on the activity instances associated with A and
B in the context of a single process instance: for each process instance, the
activity instance associated with B can only start after the activity instance
associated with A has terminated.
As a result, the process model restricts the ordering of events that occur
during process instances. In the example, the termination event of the activity
instance associated with activity model A must occur before the begin event
of the activity instance associated with activity model B.
Each control flow construct is represented in the process model by a gateway.
As with activity instances, there are instances for gateways, e.g., an
instance of a sequence flow ordering the execution of two activity instances.
Each gateway instance has a begin event and a termination event. For a uniform
treatment of control flow structures, sequences are also considered as
gateways, as discussed above.
Activity models are denoted by capital letters, A,B,C, . . ., while the associated
activity instances are denoted by a, b, c, . . .. In case multiple activity
instances are associated with an activity model in the context of a given
process model, subscripts are used, for instance, a1, a2, . . .. Gateways are typically
denoted by G, and g is an instance of a gateway. Let P be a process
model and p a process instance based on this model with an event set Ep.

Sequence

The sequence pattern defines that an activity instance b in a process instance p
is enabled after the completion of activity instance a in p, with process model P = (N,E, type) containing activity models A, B, and a gateway model
G such that A,B 2 NA, G 2 NG, E  {(A,G), (G,B)}, and type(G) =
Sequence.
The application of the sequence pattern in A ! B induces an event ordering
between the termination event of a (and the activity instance of activity
model A) and b, such that b can only be enabled after a has terminated. This
approach relates the control flow patterns directly to the state transitions of
activity instances.
In particular, the state transition from init to enabled of an activity instance
b can only be done after the state transition from running of a to
terminated of a has occurred. In process instance p, for a termination event ta 2 Ep of an activity instance a, there is an enable event bb 2 Ep of an activity instance b, such that ta < eb.
The discussion captures well the case of a single activity instance per
activity model. However, if the activity models are part of a loop, then there
might be multiple activity instances based on activity models A and B.
Therefore, the execution semantics of the sequence control flow pattern
needs to be refined so that eventually for each termination event of some
activity instance a1, a2, . . . there is an enable event of an activity instance
b1, b2, . . ..
A fragment of a process model where A and B are part of a loop is shown
in Figure 4.3; to realize this loop, an exclusive split gateway, an exclusive or
join gateway, and a set of sequence flows are added.
A process instance based on this process model is shown in the lower part
of that figure. The loop is iterated three times, resulting in activity instances
a1, b1, . . . , a3, b3. Rather than showing all events of these activity instances,
just the enable and termination events are displayed. As can be seen in the
event diagram, in each iteration of the loop, the activity instance ai terminates
before bi can start, for i 2 {1, 2, 3}.
However, the ordering “first a then b” can be violated if a and b belong to
different iterations of the loop. For instance, the termination event of b1 occurs
before the start event of a2. In order to capture loops properly, it is necessary
to define that for each termination event of a there is an enable event of b such
that ta < bb. This condition is satisfied by the process instance: for ta1 < eb1,
ta2 < eb2, and ta3 < eb3.
These event orderings relate termination events to enable events and not
direcly to begin events. Since begin events can only occur after the respective
enable events have occurred, it is guaranteed that the termination event of ai
occurs before the begin event of bi.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec Q -- By Mathias Weske

Architecture of Process Execution Environments

So far, this chapter has discussed the modelling of different aspects of a business
process. This section looks into the representation of a business process
management system capable of controlling the enactment of business processes
based on business process models.
The architecture
model contains the Business Process Environment, a Business Process Modelling
subsystem, a Business Process Model Repository, a Process Engine, and
a set of Service Providers. The roles of these constituents of the architecture
model are characterized as follows.
• Business Process Modelling: The business process modelling subsystem
is used for creating business process models, containing information on
activities, their operations, and the structure of the business process. This
architecture subsystem can be realized by business process modelling tools.
• Business Process Environment: The business process environment triggers
the instantiation and enactment of process instances based on process
models.
• Business Process Model Repository: The business process model repository
holds business process models that are created by the business process
modelling component.
• Process Engine: The process engine is responsible for instantiating and
controlling the execution of business processes. It is the core component
of a business process management system. This component is triggered by
the business process environment. It uses process models to instantiate and
control the enactment of process instances. To execute a particular activity
instance, it calls entities that act as providers of the required functionality.
In a service-oriented architecture, service providers are called to execute
individual services that realize business process activities.
• Service Providers: Service providers host application services that realize
business process activities. In the architecture model, service providers
represent an abstract entity that subsumes not only Web service providers
but also knowledge workers that realize particular activities in business
processes. The organizational and technical information that the process
engine needs in order to determine and access the service provider is also
stored in the business process model repository.
These components of the architectural model control the enactment of process
instances. To capture the distributed nature of business process executions,
the components and the service providers are represented by agents that communicate
by sending and receiving messages, i.e., the agents do not share
memory, but are distributed.
Gateways are nodes in a process model that are used to guide the process
flow. Therefore, for each gateway node the process engine needs to perform
some action. This work that the process engine conducts is represented by
a gateway instance, just as the work defined by an activity model is represented
by an activity instance. A property of gateway instances is that the
process engine executes them, whereas activity instances are executed by service
providers, requiring nonlocal communication.
The first event that occurs represents
the occurrence of the initial event in the process model. Let e1 be this
event.
The process engine detects that there is a process model defined for this
event. Therefore, a process instance is instantiated. For each activity model in
the process model, an activity instance is instantiated; for each gateway node,
a gateway instance is created, represented by events i2 through i6. When the
instances are initiated, the AnalyzeOrder activity instance can be started,
resulting in event b2. After the termination of this activity instance in event
t2, the gateway instance is started, represented by event b3.
After the gateway instance terminates in event t3, the process engine can
decide which path to take. In the process instance shown, the advanced check
activity instance is disregarded and the simple check path is taken. Therefore,
the AdvCheck activity instance is skipped, represented by event s5. The SimpleCheck
activity instance is started (event b4) and later terminates in event
t4. Finally, the execution of the gateway instance and the occurrence of the
final event n7 terminate the process instance.
The event diagrams introduced are extended to capture agents involved
in the enactment of process instances. Each agent is represented by a horizontal
line, on which the events that occur in this agent are drawn. Time
proceeds from left to right. In addition to the events directly associated with
the execution of activity instances, the begin and end of a computation and
the sending and receipt of a message are also represented by events. Message events of agents represented by directed arcs connecting the send event with
the corresponding receive event.
The business process environment, the process engine, and two service
providers are the agents represented in the event diagram. Since the operation
of the business process modelling component is not the focus of attention,
these components of the architecture model are not represented as agents in
the event diagram.
When the initial event of the process model occurs in the business process
environment, the process engine instantiates a process instance, including its
activity instances. Then, the process engine determines the first activity instance
to be executed. A service provider is determined for executing this
activity, in the example, Service Provider 1.
The service provider receives this message and starts an AnalyzeOrder
activity instance, marked by event b2. Once that activity instance is completed
(t2), the service provider returns a message to the process engine. This message
typically contains the return value of that invocation. Using this information
and possibly other information, the process engine can evaluate the condition
associated with the gateway node. Based on the decision made by the process
engine on behalf of the gateway, the AdvCheck activity instance is skipped
(skip event s5) and the SimpleCheck activity is started.
In order to realize this process instance, the process engine sends an invocation
message to the service provider responsible for executing the simple
check service. Service Provider 2 receives this message and starts the SimpleCheck
activity, marked by event b4.
Once this activity instance completes in event t4, the service provider
returns a message to the process engine, which then executes the join gateway
node (events omitted). The process instance completes with the final event and by sending the respective message to the business process environment,
informing it about the termination of the process instance.
As will be detailed in the next chapter for more complex workflow patterns,
control flow patterns restrict the ordering of execution events for activities
involved in a business process. For instance, an AnalyzeOrder activity can
only be started after the initial event has occurred, and a SimpleCheck activity
can only be started after the exclusive or gateway has completed, and so on.
The execution semantics of a process instance based on a process model is
described by restrictions on the events and their ordering during the execution
of process instances.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec P -- By Mathias Weske

Selection of Business Partners in Process ChoreographiesThe modelling of organizational aspects in business process management
can be extended to business partners, which is important in the context of
business-to-business processes.
Consider a business process choreography with multiple business partners,
each of which plays a specific role in the choreography. If there is a role Shipper
specified according to the requirements for shipping goods, it can be bound to
specific enterprises that can perform the work. Additional flexibility is gained
because the organizations participating in a choreography are not hardwired,
but represented at the model level.
There are different options for selecting a particular shipper. The selection
can be done before a particular process instance starts. This alternative is
useful if sufficient information on the goods to be shipped is available before
the process starts.
In scenarios where only during run time of the process instance are the
goods and the sender and receiver determined, the dynamic selection of a
shipper is useful. Based on the information on the shipment and on its additional
properties—such as dangerous goods—an appropriate shipper can be
selected at run time.
Before the process choreography can be realized, the broker requires information
on the suppliers available. This information is gathered by the broker in a
separate process choreography, whose message flow is not shown in the figure.
The process choreography starts with the creating of an order by the customer.
Then, the customer sends a Request Supplier Info message to the broker.
The broker receives this message and uses local information to find the
supplier most suitable for fulfilling the order. In the Send Supplier Info message,
the broker informs the customer about this supplier.
The customer receives this message and uses the information received to
send an order to the selected supplier, Supplier-A in this case. When the
supplier has processed the order, the supplier sends the goods to the customer,
and the process completes.
In the example shown, the selection is performed using a third party, the
broker. While this is a valid option in scenarios where a broker has rich information
on a set of business partners, the selection can also be done locally,
i.e., without the involvement of a third party.
In this case, the actual selection can be performed as a manual activity,
using information on suppliers available and capable of fulfilling the order.
Role resolution in this case is not performed by the business process management
system, but by a knowledge worker. This task also matches the
service-oriented approach, where a service requestor (the knowledge worker)
uses the broker to select from among a set of services (supplier services) the
one that is suited best for the task at hand.

Standardized Software Interfaces

Standardized interfaces to existing software systems are another means of
flexibility in business process management. A variety of techniques to specify
software interfaces are known from software engineering and software architectures.
It is a key concept to decouple the use of a software component from its
implementation, i.e., to hide implementation details from usage information,
following the information hiding principle.
In the context of business process management, standardized software interfaces
are of crucial importance in system workflows, and also in human
interaction workflows, since the overall process structure can be decoupled
from the implementation of particular activities realized by software components.
A flexible association of process activities with software systems allows us
to change the implementation of specific process activities without changing
the overall business process. There are two variations: the software system
realizing a particular activity can be defined at design time of the process or at
run time of the process instances.
We assume that an ERP system is deployed to provide the functionality
of the order management system and of the inventory management system in
an integrated, robust, and scalable manner.
By standardized software interfaces, the business process activities can use
the functionality of the new system without changing the business process.
This enhances the flexibility of the business process implementation, because
the realization of particular process activities can be changed without modifying
the business process.
This discussion describes an ideal setting, in which activity realizations
can easily be exchanged. However, specific properties of legacy systems make
the definition of clean, standardized interfaces cumbersome, because legacy
systems offer their functionality typically by proprietary and often not well
documented interfaces.
In addition, the granularity with which legacy systems provide functionality
often does not match the granularity required by the business process. In
particular, legacy systems often realize complex subprocesses rather than individual
activities in a business process. Sometimes, the processes realized by
legacy systems and the modelled business processes are not immediately comparable.
These issues have to be taken into account when software interfaces
to existing information systems are developed.
One option to solving this problem is developing software interfaces that
make available the functionality provided by legacy systems with a granularity
that allows reuse of functionality at a finer level of granularity. The granularity
should match the granularity required at the business process level.
Depending on the legacy system, its complexity, software architecture,
and documentation, as well as the availability of knowledgeable personnel,
the required effort can be very high. If the need for finer-grained granularity
and efficient reuse of functionality is sufficiently high, then partial or complete
reimplementation can be an option.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec O -- By Mathias Weske

Organizational Modelling

The modelling of organizational aspects also provides flexibility in business
process management. In this section, role resolution in an intra-company setting
is discussed, in which different approaches are investigated to associate
knowledge workers with business process activities .
In the case of human interaction workflows, the enactment environment of
the business process has to take into account the organizational structure of
the company that runs the business process. Flexibility in organizational modelling
is achieved by assigning roles to process activities, and not to specific
individuals.
By associating roles with activity models at design time and mapping roles
to personnel that is skilled, competent, and available to perform the activity
at run time, flexibility is improved, because changes in the personnel structure
of the organization do not affect the business processes.
For instance, absent knowledge workers are not with associated with specific
activity instances, as are persons who are currently available. Thereby, the dynamic aspect in the organization—knowledge workers might be temporarily
absent or there might be changes in the work force—can be represented
at the model level. Consequently, changes in the personnel are hidden from
the process, as long as the roles defined in the model can actually be filled by
persons in the organization.
Consider a business process with a set of activities that need to be executed
sequentially.These activities involve entering a credit request
(Enter Credit Request), gathering information on the financial situation of
the client (Analzye client), proposing a decision on the credit request, and
reviewing and submitting the decision.
A subset of these activities is assigned the same role. In the example,
a clerk is responsible for the first three activities, whereas the clerk’s boss
finally decides and submits the decision. This situation can be represented in
a business process model by associating the role Clerk and the role Boss with
their respective activities.
For each process instance by role resolution, the system offers these activities
to knowledge workers who can fulfil the respective role. Figure 3.35 shows
a situation in which three different knowledge workers with the role Clerk are
associated with the activity instances of that role.
While this role resolution is correct from a formal point of view, this situation
is undesirable in most cases because each clerk needs to understand the
context of the case, which leads to longer process durations and potentially
incorrect decisions.
In the example, the handover of work from Peter to Charles and from
Charles to Anne leads to delays in process executions and should therefore
be avoided. In addition, Charles needs to get familiar with the case entered
by Peter, and Anne needs to get familiar with the case that Charles analyzed
beforehand.
This figure also shows that at the business process instance level, knowledge
workers are associated with activity instances, while at the business
process model level, roles are associated with activity models.
To provide adequate support through role resolution, the business process
model needs to contain the information that whoever conducted the first clerk activity also has to conduct the other two clerk activities. In this case, all
clerk activities are associated with Charles, who then can perform them much
quicker than the three persons in the previous setting.
This advanced role resolution works well if the same knowledge worker
is available during the whole business process instance—or at least during
the steps that the person conducts. But there are cases where a person has
started on a process instance by conducting the first activity, but then becomes
unavailable.
In this case, a decision needs to be made: either the process is delayed
until the person returns to work or the case is transferred to another clerk.
This clerk needs to understand the overall context of the case before he can
start processing the activity. This decision is influenced by multiple factors,
such as the type of business process, the expected delay, and the effect of the
delay, and therefore cannot be performed automatically in general.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec N -- By Mathias Weske

Business Process Flexibility

The quest for flexibility can be regarded as the main driving force behind
business process management, both at an organizational level, where strategic
business processes are investigated, and at an operational level, where
human interaction workflows and system workflows are important concepts
for realizing business processes.
According to Wikipedia, flexibility refers to the “ability to easily bend an
object or the ability to adapt to different circumstances.”
In todays dynamic market environments, “different circumstances” are
induced by changes in the market environment of the company. Business processes
are objects that need to adapt easily to changes. Since products that
companies provide to the market are generated by business processes, flexible
business processes are an important asset for coping with market changes in
an effective manner.
Different aspects have to be taken into account when considering flexibility.
First of all, flexibility is provided by explicit representation of business
processes, because adaptations of explicit, graphically specified business processes
is much easier than adaptation of written organizational procedures or
business policies buried in software code.
Enactment platforms, such as workflow management systems, provide
powerful mechanisms for enacting business processes in diverse technical and
organizational environments. One area specific to human interaction workflows
is the assignment of knowledge workers to process activities.
In typical workflow environments, such as system workflows and human
interaction workflows, information systems are required for enacting workflow
activities. The interfaces to these systems might be hardcoded in the adapters
of the workflow management system. In dynamic software landscapes, where
functionality is provided through standardized interfaces, the ability to change
the binding of particular software to workflow activities is another source of
flexibility.

Explicit Process Representations
Business process management systems are created to narrow the gap between business goals and their realization by means of information technology. The
main way to provide this flexibility is based on explicit representations of
business processes at different levels. While organizational business processes
have a coarse-grained structure and are typically specified textually by forms,
operational business processes consist of process activities, and execution constraints
that relate them.
Explicit process representations provide flexibility, since changes to the
current process can be discussed and agreed upon by the different stakeholders
involved in the design of the business process. In this context, flexibility is achieved by changes at the business process model level that are immediately
translated to actual business process instances.
This process features a sequence of activities, where the first activity
to store the order is preceded by a start event. After the order is stored,
the inventory is checked. This version of the business process rules that the
shipment is prepared only after the invoice is sent and the funds are received.
Finally, the goods are shipped and the process terminates.
Due to the somewhat cautious policy realized by the business process—
prepare shipment only after receiving the funds—business process instances
based on this process model might suffer from long processing times, resulting
in insufficient customer satisfaction.
In order to solve this problem, the process owner starts a review of this
business process by inviting process participants and process consultants to
a joint workshop. The business process model is used as a communication
platform for these stakeholders at this workshop.
Discussing the problem of the process instances, the stakeholders find out
that concurrency can be exploited within the process. If activities can be
executed concurrently, their order of execution is irrelevant. For instance, the
preparation of the invoice can be started before the shipment is handled. The
new and improved version of the business process is shown in Figure 3.33.
Although in this example the deficits of the business process are obvious,
the improvement of the process by introducing concurrency shows quite well
how an explicit process model can foster response to change.
The translation of the business process model to the actual operational
environment can be realized in different ways. If the business process is realized
by a human interaction workflow, then the modified business process
model needs to be deployed in the workflow management system. Deployment
typically includes enrichment of the business process model with information
to make the process executable.
In particular, there needs to be a translation from the graphical model to
an executable format that is specified in a particular workflow language or—
in case the system workflow is realized in a service-oriented environment in a service composition language. In any of these realizations, the explicit
representation of business process models provides the flexibility to change
the process and to finally enact the modified process.
New process instances would then follow the new, improved business
process model. If, on the other hand, business processes are enacted without
any system support, then the business process model is translated manually
to a consistent set of procedures and policies that the knowledge workers need
to follow.
The flexibility resulting from the explicit modelling of business processes
is fundamental to business process management applications.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec M -- By Mathias Weske

Modelling Operation

While business process management organizes the work that a company performs
by focusing on organizational and functional aspects, the realization
of business process activities also needs to be taken into account. Activities
can be distinguished depending on the level of software system support. The
terms system workflows and human interaction workflows were introduced to
characterize the different kinds of business process enactment.
A classification of activities in business processes was introduced in Figure
3.1, consisting of system activities, user interaction activities, and manual
activities. To recapitulate, system activities are performed by software systems
without user interaction, user interaction activities require the involvement of
human users and manual activities do not involve the use of information systems.
During the enactment of human interaction workflows, knowledge workers
perform activity instances. When a knowledge worker starts working on a specific activity, the respective application program is started, and the input
data as specified in the process model is transferred to that application program.
When the knowledge worker completes that activity, the output data
generated is collected in the output parameters. These parameter values can
then be stored in the application program. They can also be transferred by
the business process management system to the next activity, as specified in
the business process model.
Business process modelling aims at mapping high-level and domain-specific
features of the application process; the technical details—the main components
of the operational perspective—are taken into account in the configuration
phase of the business process management lifecycle. The heterogeneous
nature of information technology landscapes led to various kinds of interface
definitions, most of which did not prove to be compatible. With the advent of
service-oriented computing, the operational aspects of business processes are
represented by services, providing the required uniformity.
This section discusses how activities realized by software functionality can
be modelled. Conceptually, the same levels of abstraction apply to modelling
the operational perspective as to modelling the other perspectives: at the
metamodel level, interface definition languages reside. They describe specific
interface definitions at the model level. At the instance level executing software
code is categorized.
This approach fits the modelling of activity instances (and, therefore, also
to process instances) well, because activity instances can be realized by executing
software code. It also fits the organizational perspective in which persons
reside at the instance level. Persons are—at least in human interaction
workflows—responsible for performing activity instances.
In order to automatically invoke this software functionality, business
process management systems require concepts and technology to access these
systems. The operational perspective of business process modelling provides
the information that equips a business process management system with information
required to invoke the functionality of external application systems.
The operational perspective includes the invocation environment of application
programs, the definition of the input and output parameters of the
application program, and their mapping to input and output parameters of
business process activities. Therefore, functional requirements need to be detailed
in order for us to evaluate whether a certain software system provides
the required functionality in the context of a business process.
This perspective is not limited to functional requirements. Non-functional
requirements also need to be represented, for instance, security properties
and quality of service properties of the invoked applications or services, such
as execution time and uptime constraints. In service-oriented architectures,
these properties are typically specified in service-level agreements between
collaborating business partners. These service-level agreements are part of a
legal contract that the parties sign.
Interface definition languages are used to specify the usage of procedures
and functions, implemented by software system. They are also essential to
connect software systems that have been developed independently from each
other. Therefore, they are essential for middleware systems. Middleware based
on service-oriented architectures play an increasingly important part as realization
platforms for enacting business processes. The reminder of this section
discusses aspects of service-oriented architectures that are relevant for business
process management.
The creation of service wrappers that encapsulate business-relevant functionality
of existing information systems is called service-enabling. While there
are environments in which one service is realized by one information system,
the typical case is where business functionality is realized by the interplay of
multiple existing application systems, making service-enabling a costly and
complex matter.
Service-enabling closes the gap between business process activities and
the technical infrastructure for realizing them.
AnalyzeOrder is realized by a
service called Analyze Order Service which combines the functionality of three
underlying software systems that run on a technical infrastructure. While
the definition and realization of the Analyze Order Service is a complex and
challenging task, this book assumes that dedicated business functionality is
available and can be used to realize activities in business processes.
Service-oriented computing also facilitates the dynamic binding of services
to particular business process activities. This situation is represented in the
conceptual model of these layers by a many-to-many relationship between
activity and service. This means that a given activity can be realized by multiple
services. Advanced concepts in service engineering facilitate the dynamic
binding of a business process activity to a service at run time, providing the potential to increase fault tolerance by selecting from a set of possible services
a service that is currently operational.
A more detailed picture is provided in Figure 3.31, where enterprise application
integration middleware is explicitly shown. Two legacy systems provide
their functionality via enterprise application integration middleware. For each
of these systems, an adapter is realized that hides the heterogeneity of the
legacy systems from higher levels. But there can also be existing software
systems that do not require the enterprise application integration middleware
layer.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec L -- By Mathias Weske

Deferred Allocation

In deferred allocation, the decision about who performs an activity instance
is only made at run time of the business process. To this end, there is no
distinction between deferred allocation and role-based allocation. However,
in deferred allocation, rather than using the role information defined during
design time, the allocation is performed as an explicit step in the business
process, and not influenced by role information

Authorization

Authorization allocates persons to activity instances based on their positions.
So, a list of positions is enumerated that specifies the persons who can perform
the activity instance. This could also be achieved by adding a new role
that captures the authorization. A specific type of authorization that uses
capabilities of the knowledge worker to perform allocation is also possible.

Separation of Duties

The separation of duties allocation scheme relates different allocations within
one business process. For instance, a document needs to be signed and countersigned
by two employees with a common role. In role-based allocation, these
activities could be performed by the same employee. Separation of duties allows
relating allocations in a way that this is ruled out, so that each document
is signed by two different employees.

Case Handling

In the case handling allocation scheme, certain activities in a business process
require an understanding of the overall case. In these environments, it is useful
that the same knowledge worker deals with all activities of one business
process instance. This avoids errors and reduces processing time, because the
knowledge worker already knows the case, and so can solve the issues at hand
more efficiently than a colleague to whom the case is not known “retain familiar” allocation scheme is very similar to case handling; however,
not all activity instances of a case are allocated to one specific knowledge
worker, but rather only a subset of them.

History-Based Allocation

The idea of history-based allocation is that a person is allocated to an activity
instance based on what this person worked on previously, i.e., on the history
of the activity instance that he or she completed. This includes other business
process instances. The goal is to allocate work to persons according to their
personal experiences and expertise that is not represented in the role information.
While this is not part of a role specification, this information needs
to be represented in the business process management system so that it can
decide on the allocation based on the history and personal experiences. This
allocation scheme is useful for realizing a “one face to the customer” strategy,
in which for each customer there is a dedicated individual responsible for all
aspects of communication with it.

Organizational Allocation

If organizational allocation is used, not roles but the positions within the
overall organization are used to allocate activity instances. For instance, to
authorize expenditure, the manager of the organizational unit that requested
the expenditure needs to approve. Depending on the particular language used
to express organizational allocation, complex allocation rules can be realized,
all of which take advantage of the organizational structure of the company.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec K -- By Mathias Weske

Direct Allocation

In direct allocation, an individual person, rather than a position in an organization,
is allocated to all activity instances of a particular activity model. This
resource allocation is useful in cases where there is exactly one person who is
suitable for performing these activities, such as the chairperson of a company,
who has to finally decide on investments exceeding a certain threshold.
Direct allocation can always be simulated by role-based allocation, discussed
next, simply by providing a role with one member, in our example
the company owner. However, if this property of the organization will remain
stable over a long period of time, introducing a separate role (owner) is not
required, so direct allocation can be used. The limitations of direct allocation
will be discussed in the context of role-based allocation.

Role-Based Allocation

Role-based allocation is the standard way of allocating work to the members of
organizations. It is based on the understanding that all members of a certain
role are somehow functionally equivalent, so that any member of the role can
perform a given unit of work.
To each activity model in a business process model, a is role assigned,
indicating that all members of the role are capable of performing the respective
activity instances. The mapping of role information to specific knowledge
workers is called role resolution. Current information on the availability of the
knowledge worker is used during role resolution.
There are two ways of realizing role-based allocation. In the first way, when
an activity instance enters the ready state, the work item is communicated
to the members of the group. Once one member of the group selects a work
item, the work items associated with the other group members are deleted. In
the second way, only one person is selected to perform the activity instance,
so only one work item is created.
Role-based allocation provides a set of interesting advantages with respect
to direct allocation, all of which are related to enhancing the flexibility of
business processes. Firstly, the business process model does not need to be
changed when there are changes in the personnel, i.e., employees retire and
new employees are hired. When using direct allocation, any change in the personnel related to the directly allocated persons would result in a change in
the business process model.
Secondly, by role resolution at run time of the business process, only available
persons are selected to perform activities. This approach avoids situations
in which persons are selected to perform activity instances that are currently
not available, for instance, due to meetings or absence. In direct role resolution,
when the person is not available, there is no way of continuing the
business process.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec J -- By Mathias Weske

Modelling Organization

An important task of a business process management system is the coordination
of work among the personnel of an enterprise. To fulfil this, the system
has to be provided with information on the organizational structures in which
the business process will execute.
As in process modelling and data modelling, the metamodel level
provides the means to express models, in this case organizational models.
Concepts at this level are positions, roles, teams, and relationships between
positions like supervisor. In organization modelling, there are a few formal
rules on how to express organizational structures, as well as notations to express
them.
The general principle behind organization modelling is the resource, an entity
that can perform work for the enterprise. The general concept of resource
subsumes humans and other resources, such as trucks, warehouses, and other
equipment a company requires to fulfil its goals.
Persons are part of an organization, typically a business organization. The
persons in these organizations work to fulfil the business goals of the enterprise.
Each person typically occupies some position, and the duties and
privileges of that person come with the position, not with the person. This allows filling positions according to an overall organizational plan. In addition,
the company can cope better with changes in personnel. Organizational units
are permanent groupings of persons based on their positions. Organizational
teams or project teams are specific organizational units without a permanent
nature.
In order for us to not overload that figure, it contains positions only at the top
levels, the chief executive level and the department level. Departments are
organizational units with a set of member positions.
The link between the organizational structure of an enterprise and the
business processes is accomplished by work items. Work items represent activity
instances to be performed, and work items are associated with knowledge
workers to facilitate their selection by knowledge workers. In particular, when the business process management system determines that a certain activity
instance enters the ready state, a work item is offered to a set of knowledge
workers.
Each work item is associated with exactly one activity instance. The selection
of the process participants is subject to resource allocation mechanisms,
which will be discussed below. When a knowledge worker completes the activity
instance, the business process management system is informed, so that
the process instance can be continued accordingly.
In order to discuss the resource allocation principles, a state transition
diagram of work items is considered, and a relationship of activity instances
to the respective state transitions is provided.
The assignment of process participants to activities in a business process
can be classified by resource patterns. A rich set of resource patterns have
recently been introduced; in this book, the most relevant resource patterns
are discussed.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec I -- By Mathias Weske

Workflow Data Patterns

To organize data-related issues in business process management, workflow
data patterns have been introduced. Workflow data patterns formulate characteristics
on how to handle data in business processes. They are organized
according to the dimensions data visibility, data interaction, data transfer,
and data-based routing.
Data visibility is very similar to the concept of scope in programming
languages because it characterizes the area in which a certain data object is
available for access. The most important workflow data patterns regarding
data visibility are as follows.
• Task data: The data object is local to a particular activity; it is not visible
to other activities of the same process or other processes.
• Block data: The data object is visible to all activities of a given subprocess.
• Workflow data: The data object is visible to all activities of a given business
process, but access is restricted by the business process management
system, as defined in the business process model.
• Environment data: The data object is part of the business process execution
environment; it can be accessed by process activities during process
enactment.
Data interaction patterns describe how data objects can be passed between
activities and processes. Data objects can be communicated between activities
of the same business process, between activities and subprocesses of the same
business process, and also between activities of different business processes.
Data can also be communicated between the business process and the business
process management system.
Data transfer is the next dimension to consider. Data transfer can be
performed by passing values of data objects and by passing references to data
objects. These data transfer patterns are very similar to call-by-value and callby-
reference, concepts used in programming languages to invoke procedures
and functions.
In data-based routing, data can have different implications on process
enactment. In the simplest case, the presence of a data object can enable
a process activity. Data objects can also be used to evaluate conditions in
business process models, for instance, to decide on the particular branch to
take in a split node.
Workflow data patterns are an appropriate means to organize aspects of
business processes related to the handling of data.

Business Process Management (Part-2 Business Process Modelling[Chapter III Business Process Modelling Foundation ] ) Sec H -- By Mathias Weske

Modelling Process Data

Business processes operate on data. Explicitly representing data, data types, and data dependencies between activities of a business process puts a business
process management system in a position to control the transfer of relevant

data as generated and processed during processes enactment.

Modelling Data

Data modelling is at the core of database design. The Entity Relationship
approach is used to classify and organize data in a given application domain.
The Entity Relationship modelling approach belongs to the metamodel level. it provides the required concepts to express
data models. Data modelling will be illustrated by a sample application
domain, namely by order management.
In a modelling effort, the most important entities are identified and classified.
Entities are identifiable things or concepts in the real world that are
important to the modelling goal. In the sample scenario, orders, customers,
and products are among the entities of the real world that need to be represented
in the data model.
Entities are classified as entity types if they have the same or similar
properties. Therefore, orders are classified by an entity type called Orders.
Since each order has an order number, a date, a quantity, and an amount, all
order entities can be represented by this entity type. Properties of entities are
represented by attributes of the respective entity types.
The entities classified in an entity type need to have similar, but not identical
structure, because attributes can be optional. If the application domain
allows, for instance, for an order to have or not to have a discount, then the
amount attribute is optional. This means that two orders are classified in
entity type order even if one has a discount attribute while another does not.
Entity types in the Entity Relationship metamodel need to be represented
in a notation by a particular symbol. While there are variants of Entity Relationship
notations, entity types are often represented by rectangles, marked
with the name of the entity type. Other entity types in the sample application domain
are customers and products. The attributes are represented as ellipsoids
attached to entity types.
Entities are associated with each other by relationships. For instance, a
customer “Miller” requests an order with the order number 42. These types of
links between entities are called relationships. Just as there are many customer entities and many order entities, there are many customer-order relationships.
To represent these relationships, a relationship type requests classifies them
all. In Entity Relationship diagrams, relationship types are typically represented
by diamond symbols, connected to the respective entity types by edges.
The complex nature of data in a given application domain can be well
represented by Entity Relationship Diagrams. These diagrams can be used to
create relational database tables, using transformation rules. Once the respective
database tables have been created in a relational database, application
data can be stored persistently. The data can be retrieved efficiently using
declarative query languages, for instance Structured Query Language.
While this discussion focuses on data modelling in the context of database
applications, the same data modelling method can be used to represent data
structures in business process management. Based on these data structures,
data dependencies between activities in business processes can be captured
precisely.
Data modelling is also the basis for the integration of heterogeneous data.
In the enterprise application integration scenarios discussed above, one of the
main issues was the integration of data from heterogeneous data sources. Once
data models are available for these data sources, the data integration problem
can be addressed. There are advanced data integration techniques that also
take into account data at the instance level, but explicit data models in general
are essential to addressing data integration.
Data integration can then be realized by a mapping between the data
types. For instance, there might be applications on top of database systems A
and B, such that these systems have tables CustomerA and CustomerB, respectively,
that differ. For instance, while CName is the attribute of the CustomerA
table, referring to the name of the customer, CustN might be the respective
attribute in the CustomerB table. In order to integrate both tables, the attributes
need to be mapped. In this case, CustomerA.CName is mapped to
CustomerB.CustN.
In data integration projects, complex integration problems are likely to
emerge. There might be attributes that cannot be mapped, but there might
also be attributes that need to be mapped to different tables, often by our
using transformation rules. The hardest set of problems, however, stem from
semantic heterogeneity. There are assumptions on the data that are not explicit
in the data model or in the actual data stored in the database. These
semantic differences can only be taken into account when investigating the
meaning of the attributes in detail, often during interviews with the persons
involved in the data modelling and database design of the systems to integrate.
Semantic specification of data can be used to solve these data integration
problems. However, complete semantic specification of data requires considerable
resources, and the completeness of the semantic specification cannot be
proven automatically. Therefore, further research is required to evaluate the
possibilities of semantics-based data integration.
In graph-based approaches to business process modelling, data dependencies
are represented by data flow between activities. Each process activity is
assigned a set of input and a set of output parameters. Upon its start, an
activity reads its input parameters, and upon its termination it writes data it
generated to its output parameters. These parameters can be used by followup
activities in the business process.
The transfer of data between activities is known as data flow. By providing
graphical constructs to represent data flow between activities, the data
perspective can be visualized and used to validate and optimize business processes.