Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Analysis and optimization of business processes. Course of lectures
.pdf
from among a set of services (supplier services) the one that is
suited best for the task at hand.
4.3. 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, that is, 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. The first variant is discussed in this section.
An example of changes in the implementation of business
process activities is represented in Figure 4.8. 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 activities.
This situation is depicted in Figure 4.7 by dotted lines between
the business process activities and the information systems that
realize them. 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.
71
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
implementations 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.
72
Figure 4.8. Business process uses ERP systems functionality to realize process
activities, while the business process remains unchanged
4.4. 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.
Figure 4.9. Business process management systems architecture model
73
Figure 4.9 shows a high-level business process management
systems architecture model consisting of components and
relationships. 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
processmodel 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.
74
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, that is, the agents do not share memory,
but are distributed. These messages are sent along the arcs shown
in Figure 4.10.
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 events that occur within a process engine during the
enactment of a process instance are shown in Figure 4.10. The first
event that occurs represents the occurrence of the start event in the
process model. Let n1 be this event.
The process engine detects that there is a process model
deployed 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.
75
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.
Figure 4.10. Process model and events of process instance
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.
76
Figure 4.11. Event diagram of business process execution environment
An event diagram of a process instance involving the agents of
a business process execution environment is shown in Figure 4.11.
To ease presentation, initialization events and events associated with
gateway instances are omitted in that figure.
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.
77
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.
The conclusions on the topic
1. Describes business process flexibility
2. Describes architecture of process execution environments
Questions
1. Tell us about business process flexibility
2. What do you know about architecture of process execution
environments?
78
Part II. BPMN Method and Style
TOPIC 5. ABOUT BPMN
Plan of the lecture
5.1. BPMN Tools
5.2. BPMN stands for Business Process Model and Notation
5.3. The Paradox of BPMN
5.1. BPMN Tools
The simplest BPMN diagrams can be drawn by hand, but BPMN
assumes use of a software tool. The good news is that there are
many such tools to choose from, and the meaning of the diagram
does not change from one tool to the next. But even though BPMN
is a standard, the tools are not all equally good. Some are little more
than drawing tools. They can produce diagrams containing the
standard shapes and connectors, but they do not “understand” their
meaning. They cannot, for example, validate the model, or save it in
XML interchangeable with another BPMN tool. Some tools support
all of the BPMN shapes and symbols, while others – particularly
those offered as part of a BPM Suite – include just those that the
Suite’s process engine can execute. Tools mostly adhere to the
symbols, markers, and semantics specified by the standard, but
some take liberties here and there. Some tools allow you to draw
pools and message flows, while others do not. Some naturally
support the hierarchical modeling style, in which subprocesses are
expanded on separate hyperlinked diagrams, while others are
geared toward “flat” process models with inline subprocess
expansion. Also, BPMN tools vary widely in the non-BPMN
information they describe, such as problems and goals, KPIs,
organizational roles, and systems. Prior to version 2.0, the BPMN
spec did not even attempt to describe requirements for
“conformance”. As a consequence, many tools claim to support
BPMN but really do not. The BPMN 2.0 spec does spell out
requirements for Process Modeling Conformance. The Descriptive
79
and Analytic subclasses, equivalent to our Level 1 and Level 2
palettes (in fact, borrowed from my BPMN training!), specify the
elements in non-executable models that must be supported to claim
conformance. The BPMN-I Profile, described in Part IV of the book,
provides serialization rules for non-executable models that allow
tool vendors to interchange those models automatically. At this
writing, no BPMN tool vendor yet claims full conformance with the
BPMN-I Profile, but some are close. All this is a long way of saying
that even though BPMN is a standard, BPMN tools are not all the
same, and your choice of tool may significantly impact your ability
to create “good BPMN” consistently. The diagrams used in this book
were created using Process Modeler for Visio, an addin to Microsoft
Visio from itp commerce ltd, of Bern, Switzerland. [5] This is the tool
I primarily use in my BPMN training and certification. A key reason is
it has the style rule validation built in. Also, it supports the full BPMN
2.0 element set with proper XML serialization and model export and
import, and simplifies hierarchical modeling as recommended by the
Method. A major strength of BPMN is that users enjoy a wide choice
of tools. Nevertheless, some readers will surely find that the BPMN
tool they are currently using does not support some of the shapes,
symbols, and patterns described in this book. One possible reason is
that the tool is based on BPMN 1.x, while the book is based on
BPMN 2.0. Tool vendors are often loath to advertise which version of
the standard they support, so here is an easy way to tell. If your tool
includes a shape that looks like this then it is based on BPMN 1.0.
That was obsolete in 2008, so if you are serious about process
modeling, I would recommend upgrading your tool. If your tool can
draw a shape that looks like this or a shape with a black
envelope, like this but not shapes like these
then it is probably based on BPMN 1.2. This is all right for Level 1
modeling, but it doesn’t support important shapes such as noninterrupting event and data store. More important, it doesn’t
support the formal BPMN metamodel and XML interchange format.
80
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]