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
object or the ability to adapt to different circumstances.�
In todays dynamic market environments, �different circumstances�
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
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.
Sunday, October 4, 2009
Organizational Modelling in business process:
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.
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.
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.
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.
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.
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.
Explicit Process Representations in modelling foundation:
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 isThis 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.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.
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 isThis 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.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.
Standardized Software Interfaces in modelling business process:
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.
In the original implementation, an inventory
management system is used to realize the Check Inventory activity, and an
order management system is used to realize the Store Order and the Prepare
Invoice activity.
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.
discussed in Chapter 2.
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 optio
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.
In the original implementation, an inventory
management system is used to realize the Check Inventory activity, and an
order management system is used to realize the Store Order and the Prepare
Invoice activity.
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.
discussed in Chapter 2.
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 optio
Selection of Business Partners in Process Choreographies:
The 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.
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.
Event-driven Process Chains:
Event-driven process chains are an important notation to model the domain
aspects of business processes. The main focus of this rather informal notation
is on representing domain concepts and processes rather than their formal
aspects or their technical realization. Event-driven process chains are part
of a holistic modelling approach, called the ARIS framework; ARIS stands
for Architecture of Integrated Information Systems, and it was developed by
August-Wilhelm Scheer.
This approach is often denoted as the ARIS house with three pillars and
a roof, as shown in Figure 4.32. The pillars reflect data, control and function,
while the roof reflects the overall organization. In each area, three levels of
abstraction are identified: a concept level, an architecture level, and an implementation
level, characterized by the terms Requirements Definition, Design
Specification, and Implementation Description, respectively.
The concept level is the highest level of abstraction in which data, control
and function are modelled. This level looks at nontechnical requirements of
business processes and their execution environment. Business goals and functions
are typical artefacts in the function view at this level.
The main views are as follows.
� Functional View: The functional view represents the goals and subgoals of
the enterprise and their relationships. In general, one subgoal might contribute
to a number of goals at the higher level. For instance, the subgoal
�reduce business process execution time� contributes to the goals �increase
customer satisfaction� and �reduce overall cost.�
At a lower level of abstraction, each subgoal is associated with a set of
functions that contribute to goals and subgoals. Functions are then hierarchically
decomposed until the desired granularity of functions is achieved,
similarly to functional decomposition in value chains.
� Organizational View: The organizational view describes the organizational
structure of an enterprise at a type level and at an instance level. There
are detailed specifications of organizational entities, including their relationships
and positions, roles, skills, and individuals associated with them.
Administration information such as the address of an organizational entity
can be represented. The organizational view also includes organizational
aspects of information technology of the enterprise, including its main
operational information systems, its storage facilities, and its network infrastructure.
� Data View: The data view characterizes business relevant data objects that
are manipulated by functions during business process execution. Entity
Relationship diagrams are used for data modelling.
� Business Value View or Output View: The business value view describes
the outcome of business processes, i.e., the products and services the enterprise
generates. These can be physical goods like automobiles or electronic
devices, as well as intangible goods, such as a processed order or a flight
booking.
aspects of business processes. The main focus of this rather informal notation
is on representing domain concepts and processes rather than their formal
aspects or their technical realization. Event-driven process chains are part
of a holistic modelling approach, called the ARIS framework; ARIS stands
for Architecture of Integrated Information Systems, and it was developed by
August-Wilhelm Scheer.
This approach is often denoted as the ARIS house with three pillars and
a roof, as shown in Figure 4.32. The pillars reflect data, control and function,
while the roof reflects the overall organization. In each area, three levels of
abstraction are identified: a concept level, an architecture level, and an implementation
level, characterized by the terms Requirements Definition, Design
Specification, and Implementation Description, respectively.
The concept level is the highest level of abstraction in which data, control
and function are modelled. This level looks at nontechnical requirements of
business processes and their execution environment. Business goals and functions
are typical artefacts in the function view at this level.
The main views are as follows.
� Functional View: The functional view represents the goals and subgoals of
the enterprise and their relationships. In general, one subgoal might contribute
to a number of goals at the higher level. For instance, the subgoal
�reduce business process execution time� contributes to the goals �increase
customer satisfaction� and �reduce overall cost.�
At a lower level of abstraction, each subgoal is associated with a set of
functions that contribute to goals and subgoals. Functions are then hierarchically
decomposed until the desired granularity of functions is achieved,
similarly to functional decomposition in value chains.
� Organizational View: The organizational view describes the organizational
structure of an enterprise at a type level and at an instance level. There
are detailed specifications of organizational entities, including their relationships
and positions, roles, skills, and individuals associated with them.
Administration information such as the address of an organizational entity
can be represented. The organizational view also includes organizational
aspects of information technology of the enterprise, including its main
operational information systems, its storage facilities, and its network infrastructure.
� Data View: The data view characterizes business relevant data objects that
are manipulated by functions during business process execution. Entity
Relationship diagrams are used for data modelling.
� Business Value View or Output View: The business value view describes
the outcome of business processes, i.e., the products and services the enterprise
generates. These can be physical goods like automobiles or electronic
devices, as well as intangible goods, such as a processed order or a flight
booking.
Architecture of Process Execution Environments:
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.
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.
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.
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.
Subscribe to:
Posts (Atom)