This document discusses the evolution of workflow technology from the 1980s to present day. It covers 7 generations of workflow technology, from early document routing systems to the current focus on modeling and execution convergence. The architectures of workflow management systems are also examined, including key components like process modeling tools, workflow engines, and the invocation of application functions.

1. EvoluJon
of
Workflow
Technology:
Usages,
Architectures,
Languages
University
of
Stu/gart
Universitätsstr.
38
70569
Stu/gart
Germany
Phone
+49-­‐711-­‐685
88470
Fax
+49-­‐711-­‐685
88472
Prof.
Dr.
Frank
Leymann
InsJtute
of
Architecture
of
ApplicaJon
Systems
Leymann@iaas.uni-­‐stu/gart.de

2. ©
Frank
Leymann
2
A
Caveat!
n “Workflow”,
“Business
Process”
or
simply
“Process”
are
used
synonymous
n Although
someJmes
people
make
a
subtle
difference:
n a
business
process
is
what
happens
in
the
real
world,
n a
workflow
is
the
corresponding
representaJon
in
an
IT
environment
n Same
is
true
for
“Workflow
Model”,
“Business
Process
Model”,
“Process
Model”
n SomeJmes,
it’s
ok
to
speak
about
“workflow”
if
“workflow
model”
is
meant
n …and
“(business)
process”
vs
“(business)
process
model”
n It
most
ocen
clear
from
the
context
what
is
meant

3. 2010
2005
2000
1995
1990
©
Frank
Leymann
Business
Processes
as
a
Service
Modeling/ExecuJon
Convergence
Mega
Programming
3
Brief
History
of
Workflow
Technology
(no
scien>fic
rigor
intended)
WF
AutomaJon
People
Facing
Web
Service
ComposiJon
WF
use
in
EAI
Document
RouJng/Case
Processing
1985
BPR
ProducJon
WF
TransacJonal
WF
WF-­‐based
Apps
WF
StandardizaJon
Begins
Graphical
Modeling
WF
in
eScience
Office
AutomaJon,
Forms
Processing,…

4. 4
Agenda
Out
of
the
Galaxy
EvoluJon
Architectures
Languages
BPM
Lifecylce
Summary

5. 5
Agenda
Out
of
the
Galaxy
EvoluJon
Architectures
Languages
BPM
Lifecylce
Summary

6. ©
Frank
Leymann
6
Why
Care
About
Workflow
Technology?
n Companies
use
computers
to
support
their
business
n The
way
to
do
business
is
prescribed
via
a
business
process
n ApplicaJons
support
business
processes
and
have
to
ensure
compliance
with
business
processes
e
Applica>on
=
Business
Process
+
Business
Func>ons
n Changes
in
how
to
perform
business
must
be
reflected
as
soon
as
possible
in
applicaJons

7. ©
Frank
Leymann
7
But
the
Really
Important
Thing
is…
From
most
companies’
perspecJve:
Product
=
Process
Thus:
n #
of
products
produced,
sold,…
=
#
of
processes
executed
n Cost
of
producing,
selling,…
=
Cost
of
process
execuJon
n Time
of
producing,
selling,…
=
Time
of
process
execuJon
n …and
so
on
⇒
Importance
of
Business
Process
Engineering
(BPR)
⇒
Importance
of
enforcing
to
follow
the
process
model
⇒
Importance
of
monitoring,
analyzing,
mining
processes

8. ©
Frank
Leymann
8
Fundamental
Metamodel
Collect
Credit
InformaJon
Assess
Risk
Request
Approval
Accept
Credit
Reject
Credit
risk
=
‘low’
Layman’s
View
J
salary
<
1000
decision
=
‘no’

9. ©
Frank
Leymann
9
Three
Dimensions
of
Workflows
What?
Good Customer?
Who?
Customer
Address
With?
Get
Order
Check
Customer
Accept
Order
Reject
Order
Always! Bad Customer?
Credit Card
Information
Worklists
Workitem

10. ©
Frank
Leymann
10
Workflow
Execu>on
Workitem
Worklist
WFMS

11. ©
Frank
Leymann
11
Structure
of
Workflow-­‐Based
Applica>on
Business Process Models
Service +
… .EXE CICS MQ EJB Web
Business Functions

12. WFMS
Application Server
©
Frank
Leymann
12
Key
SWE
Aspect
of
Workflow-­‐Based
Applica>ons
Application
Data
Independence
Flow
Independence
DBMS DBMS

13. 13
Agenda
Out
of
the
Galaxy
EvoluJon
Architectures
Languages
BPM
Lifecylce
Summary

14. ©
Frank
Leymann
14
1st
Genera>on
The Document Routing Age
n Electronic
document
and
folder
rouJng
(late
80s)
n Document
=
image,
folder,...
n RouJng
through
enterprise's
organizaJonal
structure
n User
associated
electronic
basket
is
key
n PotenJal
flow
of
documents
prescribed
in
advance
n In
"paper
factories"
(administraJon,
insurance,
banking,...)
work
mainly
equates
to
processing
documents,
thus
the
term
workflow
has
been
used
for
rouJng
documents
between
people

15. ©
Frank
Leymann
15
2nd
Genera>on
The People-Facing Age
n FuncJons
performed
by
users
in
1st
generaJon
WFMS
are
mainly
retrieval,
browsing,
ediJng,
archiving,...
n But
“cases”
represented
by
documents
were
recognized
to
be
only
part
of
larger
business
processes
n Not
only
execuJon
of
document
management
funcJons
required
but
also
usage
of
other
funcJons
provided
by
applicaJon
systems
supporJng
the
operaJon
of
an
enterprise
n WFMS
extensions
needed
to
invoke
any
kind
of
executable

16. ©
Frank
Leymann
16
2nd
Genera>on
(cont.)
n Launching
executables
requires
parameter
passing
n Thus,
data
flow
features
complemented
available
control
flows
n In
turn,
control
flows
can
now
be
expressed
in
terms
of
these
new
parameters
("business
rules")
n Data
flow
is
used
for
integraJng
applicaJons
with
long
temporal
delays
between
their
iniJaJons
n Parameters
managed
by
data
flow
must
be
persistent

17. ©
Frank
Leymann
17
3rd
Genera>on
The Dawn Of BPR
n Being
able
to
support
large
spectrum
of
business
processes
in
compuJng
environments
made
WFMS
of
strong
interest
for
Business
Process
Reengineering
(BPR)
projects
-­‐
early
90s
n Goal
of
BPR
is
to
speedup
business
processes
and
reduce
their
costs.
ResulJng
requirements:
n Parallelism
within
workflows
(à
speedup)
n Deadline
processing
(à
speedup)
n Monitor
actual
workflow
status
(à
speedup)
n AudiJng
of
significant
events,
i.e.
processing
history
(à
cost
reducJon,
compliance)
n Maintain
execuJon
history
for
analysis
(à
cost
reducJon,
compliance)
n Process
acJviJes
without
human
intervenJon
(à
speedup
+
cost
reducJon)

18. ©
Frank
Leymann
18
4th
Genera>on
The Production Age
n Workflow-­‐based
applicaJons
become
state-­‐of-­‐the-­‐art
(mid
90s)
n Strict
separaJon
of
business
process
logic
and
business
funcJons
n Business
processes
implemented
via
workflow
system
n Business
funcJons
implemented
"tradiJonally"
(TP-­‐monitor,
applicaJon
server,...)
n Enterprises
become
dependent
on
WFMS
n Similar
to
TP-­‐Monitors
and
DBMS
before
n The
term
produc>on
workflow
has
been
coined
to
indicate
that
WFMS
is
driving
operaJonal
aspects
of
an
enterprise
(i.e.
the
“producJon
line”
of
an
enterprise)
n Consequences:
n WFMS
had
to
provide
quality
of
services
known
before
from
"producJon
systems"
like
DBMS
and
TPM
n High/conJnuous
availability
n Scalability
n Robustness

19. ©
Frank
Leymann
19
5th
Genera>on
The Automation Age
n ApplicaJon
integraJon
becomes
very
important
(end
of
90s)
n OrganizaJonal
integraJon
becomes
more
and
more
important
n Interoperability
of
WFMS
(building
blocks),
as
well
as
Web
access
required
n Workflows
understood
as
business
oriented
"logical
units
of
work"
n Advanced
transacJon
management
funcJons
required
n Forward
recovery
of
workflows
as
well
as
workflow-­‐based
applicaJons
n Backward
recovery
(spheres
of
atomicity
and
compensaJon)

20. ©
Frank
Leymann
20
6th
Genera>on
The Service Age
n Web
Services
appeared
about
2002
n Workflows
needed
to
make
use
of
Web
Services
n Interact
with
an
ESB
n Exploit
human
beings
as
Web
services
n Workflows
have
been
considered
early
on
as
technology
to
aggregate
services
into
new
services
n “Recursive
aggregaJon
model
for
Web
services”
n “OrchestraJon”
n BPEL
has
been
created
to
support
all
of
this

21. ©
Frank
Leymann
21
7th
Genera>on
The Model-Execution Age
n Modeling
of
business
processes
gained
a
lot
of
a/enJon
about
2005
n Domain
experts
became
the
immediate
source
of
models
n BPMN
became
predominant
modeling
language
n Transforming
models
created
by
domain
experts
into
something
executable
must
not
loose
semanJcs
of
the
original
process
n ExecuJng
BPMN
evolved
as
a
requirement
n …and
BPMN
2.0
had
been
developed
to
support
this

22. 22
Agenda
Out
of
the
Galaxy
EvoluJon
Architectures
Languages
BPM
Lifecylce
Summary

23. ©
Frank
Leymann
23
Major
Building
Blocks
of
a
WFMS
Buildtime
Modeling Tool (BPR, Workflows)
Workflow Management System
Runtime
Workflow
Database
Process Model
Applications,
Tools

24. Data Modeling Tool Relational Algebra
©
Frank
Leymann
24
...And
Their
Correspondence
In
DBMS
Buildtime
Modeling Tool (BPR, Workflows)
Workflow Management System
Runtime
Workflow
Database
Process Model
Applications,
Tools
(Metamodel)
SQL DDL
Catalog
User Data
(tables, indexes,…)
DBMS
SQL DML
StP, UDF,…

25. ©
Frank
Leymann
25
The
WfMC
Reference
Model
Business
Modeling
Workflow
Enactment
Engine
AdministraJon,
AudiJng
Workflow
Enactment
Engine
Worklist
Processor
Worklist
ApplicaJon
ApplicaJon
InvocaJon
ApplicaJon

26. ©
Frank
Leymann
26
Modern
Terminology
Process
Modeling
Tool
Process
(ExecuJon)
Engine
Management
Tool
Process
Engine
2
Workitem
Management
Worklist
ApplicaJon
ApplicaJon
InvocaJon
ApplicaJon
FuncJon

27. Input Container Output Container
©
Frank
Leymann
27
Invoking
Ac>vity
Implementa>ons
Worklist
...
Workitem
...
Activity
Pgm
2
3 5
4
1

28. ©
Frank
Leymann
28
Internal
Component
Flow
Navigator
MQM
PES
Invocation State
& Metadata
Pgm
<OS Address
Space>
n WFMS
Navigator
determines
program
to
be
executed
n "ExecuJon
Messages"
send
to
launching
component
called
Program
ExecuJon
Server
(PES)
n "CompleJon
Message"
send
back
to
Navigator
when
invoked
program
returns

29. ©
Frank
Leymann
29
Program
Execu>on
Server
Service
Locator
PES
Info
Extract Data
n WFMS
won't
be
able
to
support
all
mechanisms
to
launch
executables
n Thus,
users
should
be
able
to
build
their
own
PESes,
e.g.
WFMS…
n …provides
interfaces
between
PES
building
blocks
n ….defines
required
messages
exchanged
between
navigator
and
PES
(User-­‐provided
PES
(UPES))
n Specific
metadata
are
needed
by
PES,
e.g.
security
informaJon,
mapping
prescripJons
etc.
Mapping
Program
Invocation
Invocation State
& Metadata
Program
Data
Format Pgm
Operational
Data
PES
J
Yes,
this
is
core
ESB
funcJonality!!!

30. ©
Frank
Leymann
30
Architectural
Impact
Process
Modeling
Tool
Management
Orchestrator
Tool
Orchestrator
2
Workitem
Management
Worklist
ApplicaJon
Service
Bus
Service

31. Architectural
Impact:
High-­‐Level
View
n Work
request
no
longer
only
created
by
WFMS
n Thus,
Workitem
Manager
is
split
from
WFMS
and
becomes
a
separate
component
in
SOA
environment
(“Task
Manager”)
Navigator
©
Frank
Leymann
31
WFMS
Workitem
Manager
WFMS
Task
Manager
(aka
Task
Processor
aka
Human
Task
Infrastructure)
Navigator
TradiJonal
Architecture
Modern
Architecture

32. ©
Frank
Leymann
32
Architectural
Impact
Process
Modeling
Tool
Process
Engine
Management
Tool
Process
Engine
2
Task
Manager
Service
Bus
Task
List
Client
Service

33. 33
Agenda
Out
of
the
Galaxy
EvoluJon
Architectures
Languages
BPM
Lifecylce
Summary

34. Process Management Stack Data Management Stack
Conceptual Process Model
©
Frank
Leymann
34
How
People
are
Used
to
Model
(BPMN)
Transform
Logical Process Model
(BPEL)
Deploy
Process Engine
Conceptual Data Model
(e.g. Entity-Relationship)
Transform
Logical Data Model
(e.g. SQL)
Deploy
DBMS

35. ©
Frank
Leymann
35
Architectural
Impact
Process
Modeling
Tool
Conceptual
Process
Model
Logical
Process
Model
Process
Engine
Management
Tool
ExecuJon
Engine
2
Task
Manager
Service
Bus
Task
List
Client
Service

36. ©
Frank
Leymann
36
Workflow
Language
Genealogy
WSFL
FDML XPDL
FDL
BPEL
XLANG
BPMN 1.x
(OMG)
BPML WSCI BPSS
WS-CDL
(IBM)
(IBM)
(IBM)
(Microsoft)
(WfMC) (bpmi.org) (SUN, SAP,
Oracle)
(OASIS
ebXML)
(W3C)
(IBM, Microsoft, BEA
à OASIS)
BPELJ
GSFL … YAWL
(Research Groups)
BPEL4People BPEL-SPE ?…?
GPEL
Pi-Calculus++
(Microsoft)
BPEL4Chor
✜-Calculus
PM-Graphs
BPMN 2.0 Petri-Nets
(OMG)

37. ©
Frank
Leymann
37
Other
Languages
n Data
Flow
oriented
approaches
n Especially
used
in
scienJfic
workflow
community
n Only
data
dependencies
between
acJviJes
are
modeled
n As
soon
as
all
input
data
of
an
acJvity
is
available,
start
the
acJvity
n Examples:
DAGMan,
Kepler,
Taverna,
Triana
n Research
prototypes
n DeclaraJve
approaches
n Define
constraints
of
valid
execuJon
“sequences”
instead
of
specifying
all
poten/al
execuJon
“sequences”
n Based
on
some
temporal
logic
(e.g.
LTL)
n Example:
DECLARE
n Research
prototype
n Rule-­‐based
approaches
n Mainly
based
on
ECA
rules
n Example:
Lotus
Notes
workflow
ObservaJon:
Products
focus
on
control
flow
languages

38. The
“mother”
of
all
workflow
languages
IT Infractructure ("With")
©
Frank
Leymann
38
Flow
Defini>on
Language
(FDL):
Example
PROCESS 'Loan Process'
PROGRAM_ACTIVITY 'Collect Credit Information'
PROGRAM 'Credit Information Program'
DONE_BY 'Loan Officer'
END 'Collect Credit Information'
PROGRAM_ACTIVITY 'Assess Risk'
PROGRAM 'Risk Program'
DONE_BY 'Financial Officer'
END 'Assess Risk'
CONTROL
FROM 'Collect Credit Information'
TO 'Assess Risk'
END 'Loan Process'
PROGRAM 'Credit Information Program'
WINNT
EXE
PATH_AND_FILENAME 'CIP.EXE'
END 'Credit Information Program'
PROGRAM 'Risk Program'
AIX
EXE
PATH_AND_FILENAME 'RP.EXE'
END 'Risk Program'
ROLE 'Loan Officer'
RELATED_PERSON 'Leymann'
END 'Loan Officer'
ROLE 'Financial Officer'
RELATED_PERSON 'Roller'
END 'Financial Officer'
PERSON 'Leymann'
FIRST_NAME 'Frank'
LAST_NAME 'Leymann'
END 'Leymann
PERSON 'Roller'
FIRST_NAME 'Dieter'
LAST_NAME 'Roller'
END 'Roller'
Process Logic ("What")
Process Logistics ("Who")

39. ©
Frank
Leymann
39
BPEL:
Business
Processes
Between
Web
Services
X
Y
Z
pt3
o1
o2
pt1
o1
o3
o4
pt2
o2
o4

40. ©
Frank
Leymann
40
BPEL:
Business
Processes
As
Web
Services
X
Y
Z
pt
o1
o2
pt* o7
o9
o8

41. ©
Frank
Leymann
41
BPEL:
Aggrega>ng
Web
Services
X
Y
Z pt
o1
o2
pt3
o1
o2
pt1
o1
o3
o4
pt2
o2
o4
P
Q
pt*
o8
o9
Precisely:
BPEL provides
a recursive
aggregation
model for Web
services

42. ©
Frank
Leymann
42
Separa>ng
Processes
And
Port
Types
Process
A
C
B
D
E
Application
Deployment
Descriptors
Activity:
Partner
Role
Port Type
Operation
...
Port Types

43. Process
©
Frank
Leymann
43
Run>me:
Use
of
Deployment
Informa>on
A
C
B
D
E
Service
Bus
Application
Deployment
Descriptors
Activity:
Port Type
Operation
Qos
... Policy
EPR
Ports

44. Deployment Service
©
Frank
Leymann
44
Programming
Model
Application
Flow/Process/…
Components/Services/…
Workflow
System
Application
Server
Programming
in the
Large
Programming
in the
Small
Bus
Deployment Descriptor
pT pLink Locator

45. ©
Frank
Leymann
45
BPEL:
Example
(The
Obvious
One
J)
TravelService
orderTrip
receiveItinarary
getHotel getFlight
chargeCC
HotelService
bookRoom
AirlineService
bookFlight
CCService
payBill
Hotel
Airline
CCCompany
TravelAgent
overnight?

46. ©
Frank
Leymann
46
The
Process
Header
And
Partners
<process name=“TripBookingProcess"
targetNamespace="http://fl.com/Travel/Booking"
xmlns="http://schemas.xmlsoap.org/ws/2003/05/business-process"
xmlns:tag="http://travel.org/wsdl/travelAgent">
<partnerLinks>
<partnerLink name="Customer"
partnerLinkType="tag:Traveler"
myRole="TravelAgent"/>
<partnerLink name="Hotel"
partnerLinkType="tag:Hotel"
partnerRole="HotelChain"/>
<partnerLink name="Airline"
partnerLinkType="tag:Airline"
partnerRole="AirlineCompany"/>
<partnerLink name="Billing"
partnerLinkType="tag:CreditCard"
partnerRole="CreditCardCompany"/>
</partnerLinks>

47. ©
Frank
Leymann
47
The
Variables
<variables>
<variable name="Order"
messageType=“tag:trip"/>
<variable name="Hotel"
messageType="tag:hotelBooking"/>
<variable name="Flight"
messageType="tag:flightBooking"/>
<variable name="payment"
messageType="tag:payments"/>
</variables>

48. ©
Frank
Leymann
48
The
Ac>vi>es
(1/5)
<flow>
<links>
<link name="Itinerary-to-Hotel"/>
<link name="Itinerary-to-Flight"/>
<link name="Hotel-to-Charge"/>
<link name="Flight-to-Charge"/>
</links>
<receive name=“receiveItinerary”
partnerLink="Customer"
portType="tag:TravelService"
operation="orderTrip"
variable="Order">
<source linkName="Itinerary-to-Hotel“
overnight?
transitionCondition=“overnight=‘true’"/>
<source linkName="Itinerary-to-Flight"/>
</receive>
....
receiveItinarary
getHotel
getFlight
chargeCC

49. ©
Frank
Leymann
49
The
Ac>vi>es
(2/5)
....
<assign>
<copy>
<from variable="Order"
part="itinerary"
query="/rooms"/>
<to variable="Hotel"/>
</copy>
</assign>
<assign>
<copy>
<from variable="Order"
part="itinerary"
query="/flights"/>
<to variable="Flight"/>
</copy>
</assign>
....

50. ©
Frank
Leymann
50
The
Ac>vi>es
(3/5)
...
<invoke name=“getHotel”
partnerLink="Hotel"
portType="tag:HotelService"
operation="bookRoom"
inputVariable="Hotel">
<target linkName="Itinerary-to-Hotel"/>
<source linkName="Hotel-to-Charge"/>
</invoke>
<invoke name=“getFlight”
partnerLink="Airline"
portType="tag:AirlineService"
operation="bookFlight"
inputVariable="Flight">
<target linkName="Itinerary-to-Flight"/>
<source linkName="Flight-to-Charge"/>
</invoke>
...
receiveItinarary
overnight?
getHotel
getFlight
chargeCC

51. ©
Frank
Leymann
51
The
Ac>vi>es
(4/5)
....
<assign>
<copy>
<from variable="Order"
part="customerInfo"/>
<to variable="Payment"
part="customerInfo"/>
</copy>
<copy>
<from variable="Hotel"/>
<to variable="Payment"
part="orders"
query="/rooms"/>
</copy>
<copy>
<from variable="Flight"/>
<to variable="Payment"
part="orders"
query="/flights"/>
</copy>
</assign>
....

52. ©
Frank
Leymann
52
The
Ac>vi>es
(5/5)
...
<invoke name=“chargeCC”
partnerLink="Billing"
portType="tag:CreditCardService"
operation="payBill"
inputVariable="Payment“
joinCondition=
overnight?
"vprop:getLinkStatus(‘Hotel-to-Charge')
or
vprop:getLinkStatus(‘Flight-to-Charge')">
<target linkName="Hotel-to-Charge"/>
<target linkName="Flight-to-Charge"/>
</invoke>
</flow>
</process>
receiveItinarary
getHotel
getFlight
chargeCC

53. ©
Frank
Leymann
53
BPMN:
A
Graphical
Language

54. ©
Frank
Leymann
54
Basic
Order
Process

55. ©
Frank
Leymann
55
Order
Process
with
Excep>on
Paths

56. ©
Frank
Leymann
56
Order
Process
with
Swimlanes

57. ©
Frank
Leymann
57
Subprocesses

58. ©
Frank
Leymann
58
Parallel
Split
and
Join

59. ©
Frank
Leymann
59
Excep>on
Handling

60. ©
Frank
Leymann
60
Choreographies

61. 61
Agenda
Out
of
the
Galaxy
EvoluJon
Architectures
Languages
BPM
Lifecylce
Summary

62. KPIs
Analysis
©
Frank
Leymann
62
BPM
Lifecycle
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

63. BPM
Lifecycle:
Modeling
KPIs
Analysis
©
Frank
Leymann
63
BPMN
n Today,
typically
based
on
BPMN
(2.0)
n Done
by
domain
experts
n StaJc
analysis
used
to
“quickly”
check
obvious
modeling
errors
n AnalyJcal
simulaJon
used
to
check
saJsfacJon
of
KPIs
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

64. BPM
Lifecycle:
IT
Refinement
KPIs
Analysis
©
Frank
Leymann
64
BPEL
n Today,
ocen
generaJon
of
BPEL
from
BPMN
n Web
services
have
to
be
determined
that
perform
the
tasks
of
the
processes
n Done
by
IT
experts
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

65. BPM
Lifecycle:
IT
Refinement
2.0
KPIs
Analysis
©
Frank
Leymann
65
BPMN
2.0
n If
a
BPMN
2.0
engine
is
used,
no
transformaJon
is
needed
n As
before,
Web
services
have
to
be
determined
that
perform
the
tasks
of
the
processes
n Done
by
IT
experts
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

66. BPM
Lifecycle:
Deployment
KPIs
Analysis
©
Frank
Leymann
66
BPEL
BPMN
2.0
n The
Web
services
of
the
refined
process
model
must
be
bound
to
endpoints
n Well,
task
can
have
different
implementaJons
(like
scripts,
EJBs,
REST
APIs,…)
n They
must
be
bound
too
n Done
by
IT
experts
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

67. BPM
Lifecycle:
Execu>on
KPIs
Analysis
©
Frank
Leymann
67
BPEL
BPMN
2.0
n Either
a
BPEL
engine
executes
the
transformed
BPMN
model,
or
n …a
BPMN
2.0
engine
executes
the
BPMN
2.0
model
n In
any
case
the
bound
task
implementaJons
are
invoked
during
navigaJng
the
process
models
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

68. KPIs
Analysis
©
Frank
Leymann
68
BPM
Lifecycle:
Monitoring
n During
execuJon
the
actual
status
of
each
running
process
is
available
n Individual
processes
can
be
inspected
and
depicted
n CollecJons
of
processes
can
be
defined,
and
their
aggregated
status
can
be
depicted
n The
status
of
(aggregaJons
of)
processes
can
be
enriched
with
other
informaJon
to
enable
deeper
inside
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

69. KPIs
Analysis
©
Frank
Leymann
69
BPM
Lifecycle:
Analysis
n The
history
of
already
completed
processes
is
maintained
n This
allows
post
mortem
analysis
of
(collecJons
of)
processes
n Used
to
improve
models
of
processes
n …to
be/er
saJsfy
KPIs
n Can
be
combined
with
data
analysis
to
derive
be/er
models
n Mining
algorithms
can
be
used
n …to
improve
control
flow
n …to
improve
use
of
staff
n …
Modeling
IT
Refinement
Deployment
ExecuJon
Monitoring

70. 70
Agenda
Out
of
the
Galaxy
EvoluJon
Architectures
Languages
BPM
Lifecylce
Summary

71. ©
Frank
Leymann
71
Conclusion
n Process
knowledge
is
a
key
resource
of
a
company
n Workflow
technology
is
managing
this
knowledge
n The
technology
is
mature
and
proven
(≈25
years
of
evoluJon
in
pracJce)
n WFMS
architectures
are
compliant
with
a
service-­‐
oriented
environment
n Two
languages
have
been
established
in
pracJce
n BPMN
(2.0)
for
modeling
n BPEL
for
execuJon
n Processes
are
managed
in
a
lifecycle
that
typically
use
specialized
technologies
in
an
integrated
manner

72. 72
The
End