BPMFramework v12

The BPM Framework V11 24/10/2008
BPM Framework
Version 12
Jochen M. Alt 1.1

Deutsche Bank AG
Jochen M. Alt 1
This framework
What is BPM, SOA, workflow?

Modelling Guide
Architecture blueprint
Toolset & Deliverables
Patterns
Information on tools, notations, etc.
Domain Architects Solution Architects
This framework will give you an overview and detailed information about BPM and Workflow within PCB
Deutsche Bank. Following parts are considered:
Scope and differentiation between BPM, workflow and SOA

Modelling Guide – descriptions of what and how to model in BPM
Architecture blueprint for systems having a significant workflow part
Toolset & Deliverables – descriptions which tools are available, what they a for and their deliverables
Specific patterns to be used within workflows
Additional Information on tools, notations, etc.
The intended audience is domain architects and solution architects. After reading, you should have an
understanding where the workflow parts of your system are, how to design it, and which tools to use.
Jochen M. Alt 2
BPM Framework
What
WhatisisBPM,
BPM,what
whatisis
workflow
workflowand
andwhat’s
what’sthethe
difference?
difference?Is
Iseach
eachproject
project
with
withbusiness
businessprocesses
processesaa 1 BPM / Workflow
workflow
workflowproject?
project?How
How
does
does BPM
BPMcorrelate
correlatewith
with
2 Principles / Modelling Guide

SOA?
SOA?What
Whatdo
doIIget
getififII
follow
followthese
theseguidelines?
guidelines?
Workflow Principles
3 Modelling Guide
5 An Example
6 Additionals
The following defines BPM and it’s differences to a workflow. We will see that not every BPM project is a
workflow project and how to identify the processes which are well suited to be implemented with a workflow
system.
Besides that, the correlation between BPM and SOA is explained, that is where is the cut between a process
and a service.
Finally, the benefits are listed when following this framework.
Jochen M. Alt 3
Is Business Process Management needed?
Conventional business concepts written with plain text have these shortcomings:
mistakeable definition of processes
undefined change management of processes
inappropriate notation for discussion and optimization of processes
difficult maintenance of process definitions
In a nutshell, BPM is business analysis PLUS a

management process covering the lifecycle of processes.
Objective is to define, maintain and optimize processes in a transparent manner
Conventional business concepts written with plain text have these shortcomings:
• mistakeable definition of processes
• undefined change management of processes
• inappropriate notation for discussion and optimization of processes
• difficult maintenance of process definitions
These shortcomings are to be solved by BPM.
Business Process Management is a holistic approach and covers the whole lifecycle of modelling, re-
engineering, monitoring, execution and optimization of business processes.
A business process is a specific ordering of work activities across time and space and clearly defined inputs and
outputs: a structure for action.
A process model created by the use of BPM gives a precise process model appropriate for IT-concept and
defines how to manage a process definition during its lifetime.
In a nutshell, BPM is business analysis PLUS a management process covering the lifecycle of processes.
Jochen M. Alt 4
What is BPM?
Process Process Process Process

Modelling Execution Monitoring Optimisation
Process
Re-Engineering
Process Modelling Process Execution Process Monitoring Process Optimisation

Delivers precise and Executes an existing Use of process’ Optimizing process efficiency
standardized description implementation of a business executions analysis and quality by analyzing
of business processes process in a workflow engine capabilities to monitor detected bottlenecks
Delivers criteria to Implements process and analyze processes,
measure efficiency and reporting on business level their bottlenecks and
quality of process shortcomings
Process Re-Enineering
Process Modelling based
on an existing process,
known limitations and
shortcomings and new
requirements
BPM‘s lifecycle has the following blocks:
Process Modelling
During process modelling, a precise and standardized description of business processes as well as criteria to
measure efficiency and quality is delivered.
Process Execution
Process execution is about running a business process in a workflow engine already implemented. During
execution, events that are relevant for business monitoring take place.
Process Monitoring
During process monitoring, the business events are monitored and analyzed to allow the following process
optimization
Process Optimization
The result of the process monitoring should be used to optimize the process itself, that is to change the process
in a way that criterias defined during process modelling improve.
Process Re-engineering
If an existing process has to be re-engineered due to a necessary optimization or to meet additional
requirements, lifecyccle doesn‘t start from scratch but from an existing process. The formal procedure of process
modelling remains the same, but the contents is different and considers the existing process.
Jochen M. Alt 5
What is a Workflow?
Process Workflow
Design
Modelling Modelling
Criterias for projects suitable for workflow:

Document-based or form-based
processing
Standardized processes with a large
number of users (vs.
planning/disposition systems)
Processes which tells the users
what to do (not vice versa)
E.g. standardized approval processes with
multiple involved parties
Not every BPM project is a workflow project, because workflow is just one technical possibility to implement a
business process. Whether your business process is appropriate to be implemented on base of a workflow
platform can be detected by these criterias:
A process is well suited for being implemented with a workflow tool if

• the business process works on base of a document or a form which is enriched step by step.
• business process is standardized with a large number of users (vs. planning/disposition systems)
• business processes tells the user what to do in a kind of a task oriented working style (not the other way
round!)
A common example for a workflow is a standardized approval processes with multiple involved parties
In a nutshell, workflow is the second step after BPM having already identified workflow activities. Based on a
business processes on an abstract level, a workflow model is developed by making design decisions and
adding properties used to execute the process in a process engine
Jochen M. Alt 6
Model layer definitions

Tools
Business
Process
Level
Process
Adonis
Subprocess
Workflow
TIBCO iProcess
Workflow
Level
Workflow /
Action item
Business
Service
Accessed via
TIBCO ESB
Level
Hosted by/
service
Access
functions
Backend
Level
Backends
Business Processes:
Business processes are the enterprises main processes on a high level without details. The main process model
is for overview and navigation purposes and defines the enterprise process landscape consisting of
management, core, and support processes.
Subprocess Workflow:
The layer of sub processes contains the business content model. This model contains description of all activites
which have to be done to run a process on a usecase level (e.g. entering a form). The model does not contain
technical information.
Subprocess Workflow
The workflow layer is parallel to the sub process level above. The difference is, that these workflow layer will be
defined in a technical manner from implementation perspective – it is nearly developing the application. The drill
down to action items are the basic single steps to accomplish in the workflow.
Business Service
Translation of the business driven process description into customizable IT services, depending on the current
project. The business services have a functional specification. The according composition/orchestration of
services is based on the available access functions.
Access functions
Abstract definition of basic services, which are called and used by the business services. The access functions
are like an communication shell to get the access to the plain function on backend side. This is EAI pure
functionality.
Jochen M. Alt 7
From a Business Process to a Workflow
done
W hat’s
during Process Workflow
w hat Design
design, Modelling Modelling
to be
info has
d ed w ith
ad
ols?
w hich to
(Adonis) (TIBCO Business Studio)
A workflow is not identical with a business process although the business process is a good starting point.
During the design phase, it’s up to IT to model the workflow in a technically feasible way.
Furthermore, the following details have to be added to allow the execution of a workflow model in a workflow
engine:
The process cut has to be design.

Typically a workflow model has much more activities than a business process.
Data types have to be designed
Business defines data in a coarse grained level, while IT needs to know each single attributes and their
precise types
Dataflow has to be designed
In a business process dataflow is not mentioned explicitely, in a workflow it is best practice to have lean
interfaces by a clear dataflow between activities and not to publish all information available.
Manual and automated steps are to be defined with all constraints
While a business process describes what is to be done, it is often not yet clear whether this can be done
automatically. Especially in case of partly automated steps IT has to design which system activities are
subject to a constraint.
Access to 3rd-party applications and according business services have to be integrated
It has to define the communication style and integration technique.
Jochen M. Alt 8
Deliverables of BPM, Workflow, SOA
(Adonis) (Tibco)
Process Workflow
Modelling Modelling
Service Service <?xml version="1.0" encoding="UTF-8"?>

<xs:schema>
<xs:element name="SORequiredSignatureRequest"
Identification Design type="SORequiredSignatureRequestType"/>
<xs:complexType name="SORequiredSignatureRequestType">
<xs:sequence>
<xs:element name="Buyer" type="xs:string"/>
<xs:element name="Seller" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="SORequiredSignatureResponse„
…
(Service Registry, RAM) (WSDL)
Each design and development activity has its own deliverable based on different technology. The building blocks
of BPM (process modelling and workflow modelling) and SOA (service identification and service design) are
listed as follows:
Business Process Modelling

Business process modelling is done with Adonis by business people, a high level tool allowing to define
processes on a high level.
Workflow Modelling
Workflow modelling is done by technicians with Tibco BPM suite. Tibco Business Studio allows to enrich a
workflow model with all details necessary to execute it in TIBCO iProcess (workflow engine).
Service Identification
All services available for re-use are stored and maintained in the service registry implemented with Rational
Asset Manager. It’s the tools used to lookup existing functionality as well as to publish newly created services.
Service Design
Service design results in definition of a wsdl (webservice definition language). Fortunately, this file must not be
written by hand but is mostly generated by service implementation tools (e.g. Tibco Business Works). Besides
the technical specification of a service the service template contains non-functional requirements too.
Jochen M. Alt 9
1 BPM / Workflow
Which diagram types do
2 Modelling Guide / BPM Principles

we use for modelling
business processes,
how do they correlate to
layers of processes and
Workflow Principles
what are the principles
of modelling? 3 Modelling Guide
4 An Example
5 Additionals
In the following section we go into details and describe process modelling and the diagram types
provided by Adonis. Especially the questions which diagrams are useable for which purpose is
discussed.
Jochen M. Alt 10
Model Types
Process Landscape
(Adonis diagram type: Company
re
T hese a Map)
pes
m odel ty
in
available
we
Adonis
end to Company
CompanyMap
recomm Map
u se
Business Processes Roles and

(Adonis diagram type: Business Work
Responsibilities
Business WorkEnviron-
Environ-
Business Process Model) Process
ProcessModel
Model ment
mentModel
Model (Adonis diagram
type: Working
Environment Model)
Application
Application
Architecture
Architecture
M.
M.
System Landscape
(Adonis diagram type: Application Architecture
Model)
Process Landscape
(Adonis diagram type: Company Map)
Describes the high level processes necessary to run the business line. This is more of a business description
than a process description.
Business Processes
(Adonis diagram type: Business Process Model)
Model the detailed business processes sufficient to start IT concept. The Adonis diagram type allows to model
activities and transitions on a usecase level.
Roles and Responsibilities

(Adonis diagram type: Working Environment Model)
Model the organization and people involved in processes. Roles defined here are used in user activities of
business processes.
System Landscape
(Adonis diagram type: Application Architecture Model)
This diagram models all applications involved in business processes. An application is modelled by a simple box
with use- and invocation-relationships to other applications. Additionally, business processes having activities
are listed on a per-application base.
Jochen M. Alt 11
Business driven identification of Landscape

Company
CompanyMap
Map
d
I procee
How do
ing BP M?
us
Business
Business Work
WorkEnviron-
Environ-
Process
ProcessModel
Model ment
mentModel
Model
Application
Application
Architecture
Architecture
M.
M.
Example landscape (Adonis)
Defining the process landscape results in a very high-level description of all processes necessary to run a
business line.
The following steps may help to identify business processes and differentiate them to either the landscape or the
process level:
• Analyze functional areas
• Structure the processes into the categories
• Management processes (finance and controlling, strategy, business management, …)
• Core processes (operation, business, value-added chain,…)
• Support processes (HR, Accounting, QA, Infrastructure, Communications… )
Jochen M. Alt 12
Business driven identification of Processes

Company
CompanyMap
Map
Business
Business Work
WorkEnviron-
Environ-
Process
ProcessModel
Model ment
mentModel
Model
Application
Application
Architecture
Architecture
M.
M.
Example process (Adonis)
Starting from the process landscape, refine your business processes by defining activities and decisions
resulting in a description sufficient for IT.
• Survey the operational sequences and according information and model them in structured processes and
definitions
• Describe the triggers
• Actors (Persons, responsibilities)
• Processes triggered and involved
• Events sent and received
Jochen M. Alt 13
Organization
Company
CompanyMap
Map
Example organization (Adonis) Business

Business Work
WorkEnviron-
Environ-
Process
ProcessModel
Model ment
mentModel
Model
Application
Application
Architecture
Architecture
M.
M.
The definition of an organizational chart helps to structure and assign the common roles and responsibilities.
• Prepare the organizational chart
• Abstract overview of organization & hierarchy (common reuse)
• Organization related to the current project
• Roles should be generic
• For each process identify the actor
• Who is owner resp. responsible for the process?
• Which abstract role is covering that?
• At process-level roles can be assigned to processes/activities
• It is not recommended to assign detailed names (except perhaps by modelling the as-is
situation)
• Situational level of assignment (processes, subprocesses, activities)
Jochen M. Alt 14
Application Architecture
Company
CompanyMap
Map
Business
Business Work
WorkEnviron-
Environ-
Process
ProcessModel
Model ment
mentModel
Model
Example application
architecture (Adonis) Application
Application
Architecture
Architecture
M.
M.
The application architecture helps in structuring the project and identifying all applications which have to be
involved. It is also useful to structure a project along these applications.
To define the application architecture, proceed as follows:

Prepare the business process
• Define which activities are to be automatic
• Define which activities needs information from systems outside the business process does
not own
For each automatic process activity
• Identify application responsible for executing
• Identify application providing information needed
For all applications collected
• Identify dependencies and usage-relationship
Jochen M. Alt 15
Diagrams and Relationships
vital for Work for

ppens to
What ha s if
busines X
on
applicati hat
?W
crashes
if Dieter
happens ve?
is o n lea
needs Company
Company
Map
Map needs
Business
Business Work
Work
Process
Process Environ-
Environ-
Model
Model ment
mentModel
Model
necessary for Application

Application
Architecture
Architecture is used by
M.
M.
Is implemented in
uses
Having modelled all diagram types like this, major benefit is a complete description of business. Especially the
dependencies between diagram types are useful to answer to the following questions:
• What happens if a person is on leave?
Lookup the roles this person has, lookup all activities these roles are involved in. All these activities and
owning business processes are on hold in case of a missing backup.
• What happens if an application goes down?
Lookup all processes which have activities running on the crashed application.
• How can a service level agreement or an application level agreement be computed from a given
business level agreement?
By multiplying the availabilities of all applications involved.
The depicted relationships are to be read in the following manner:

Application A is necessary for business process B.
Jochen M. Alt 16
Principles – Overview
s have
Principle
d e ve loped
been st
fr om be
s
practise
Method Usage Usage of common methodology standard BPMS with standard notation
Discipline of Discipline of Modelling means to model what is needed only and not to oversize the model
Modelling structure. The reuse opportunities have to be considered by approaching top down, check the
landscape and then go into detail for the business models
Level of Discrete level of decomposition has to be ensured, so that the right models cover the right
Decomposition level of process modelling
Business Driven Business driven, in BPM mainly all processes are triggered and modelled by business itself.
IT may coach, but business is responsible for the content.
Well-defined Processes and models are well-defined and their structure and definition follow an
Processes appropriate and adequate methodology
Extensibility Processes and subprocesses (probably on higher levels) have to be abstract and generic
enough to be reused in different context
Originator The organization model should reflect the necessary roles and responsibilities for the
Responsibility associated business context – the originator should be assigned as process owner
Unified Description A unified and aligned description, to support an understanding of both IT and Business in a
sufficient and complete manner
Discipline of Modeling: Model only what you expect IT to ask you.

Level of Decomposition: Each level of decomposition has its corresponding model type. To maximize re-use
and support a common understanding each model type should be used at the right level.
Business Driven: Business Processes are related to the Business need and not to IT’s. They reflect the real life
and how the business work is going to be, especially in the meaning of requirements. Business is responsible for
the content, IT may support.
Well-defined Processes: The decomposition of processes has to follow some rules to get models which are
readable by business as well as IT. Processes should be disjunctive, free of redundancies, and of a comparable
complexity. decomposition mainly means top down, but to cover existing functions/application it has to be mixed
up with a bottom up approach.
Extensibility: The extensibility of business processes is a necessity. Therefore the structuring, decomposition
and description of processes has to be of high quality. Extensible means to look for existing processes first and
not till then create new processes disjunctive and free of redundancies.
Originator Responsibility: Business processes have to be assigned to an organizational model with according
roles and responsibilities. It is important to recognize the organizational to evaluate the reuse possibilities. Also
each process must have an process owner being responsible for content.
Unified Description: Descriptions have to follow some common standards to achieve an appropriate
documentation of the modelled processes. The descriptions have to be
• Comprehensible for IT and Business to get a common understanding
• Functional and professional covering the whole business scope
• Primarily and completely model the standard process, describe exceptions separately
Popular Mistakes: Processes are too small, and so there are too many
• Exceptions are modelled too often and early
• Inadequate use of process and subprocess structuring
• Business process describes the dialog-structure and not the operational sequence
Jochen M. Alt 17
Round Trip Engineering
ip
Round tr
BPM
between ow
fl
and w ork d
un
or no ro
trip?
BPM
different tools different people
Workflow
different job
Round Trip Engineering

• The intention of round trip engineering is to model business process and the workflow integrated. Each
change in the BPM is reflected in the workflow automatically.
• objective is that business can develop the application by modelling the processes
But…
• The workflow is part of the application development
• Workflow looks different than business process for technical reasons
• Each change on the business side has carefully to be implemented on workflow level
• An automatic round trip forces a workflow to be structured like business processes. IT-Design is not able
rearrange activities due to technical reasons.
Thus
• There is mandatory need for a manual break between BPM and Workflow to ensure a proper application
development. Workflow cannot be generated properly from a business process model but is a human
design task instead, supported by a specific toolset per each party
Hence, we do not recommend to use round trip engineering for BPM/workflow
Jochen M. Alt 18
Top Down vs. Bottom Up
Top-down Bottom-up
+ process model perfectly reflects business + Good utilization of existing services

- re-use of existing services unlikely due to - hard to adapt business process around existing
gaps of functionality services
Basically, you can approach your model by using top-down as well as bottom-up strategy. The difference is:
Top Down
Applying a Top-Down approach means to start from a high-level view and divide into detailed processes until all
necessary activities are explored and described.
Bottom-up
Applying bottom-up means to start from existing functions, processes and services and to build the system by
adding necessary functionality and the glue in between.
Discussion
From the perspective of a perfectly implemented business process working top-down is the approach of choice,
because no processes are adapted due to combining existing functionality. On the other hand, existing
functionality is unlikely to be re-used, because as soon as process steps down to design level, there’s nearly no
chance that existing services accidentally implement the functionality needed.
Jochen M. Alt 19
Process Modelling: Top Down vs. Bottom Up
Process Overview
Landscape
Start new by designing the process
Level
landscape…
… continue by defining processes…
Process
Process
Level
Modelling
But how?
… continue by defining workflow
Workflow
based on services…
Level
Iterate between Top-Down and
Bottom-Up
Service
Level
… look up existing services and
improve them
Instead of using a pure top-down or bottom-up approach, it is recommended to work in two phases:
Work top-down on landscape level and process level

This phase identifies all activities high-level, major task of this phase is is to understand and to model business
appropriate.
Continue using a jojo-approach

Before diving into the specification of a single activity, it is essential to know of existing services to cut the
activities in a way that existing services can be re-used. Recommended approach is to iterate between workflow
level and service level during design to gain maximum re-use.
Jochen M. Alt 20
1 BPM / Workflow
BPM Principles
2 Modelling Guide
Is there a blueprint for a
workflow system? Which
3 Workflow Architecture & Patterns

components does it
comprise? How can I
enhance this blueprint if not
all requirements are met?
Are there best practices?
4 An Example
5 Add-ons
The following chapter describes the mapping from a business process to a workflow system, so it’s intended for
solution architects. First question to answer is which parts of a business process should be implemented by use
of a workflow system. It also introduces a reference architecture of building blocks which can be enhanced be
special components in case of need. Possible enhancements are demonstrated by use of patterns. Additionally,
best practices are the description of choice to show best practices.
Jochen M. Alt 21
From a Business Process to a Workflow-System

Design and
Implementation
Process
Process starts here
Landscape
Landscape
Business
Business Work
Work
Understand Business Define Platform and
Process
Process Environ-ment
Environ-ment and Requirements Tools
Model
Model Model
Model
Application
Application
Architecture
Architecture
M.
M.
I build a
How d o
w orkflow a
on from
applicati ess
Busin
ation ?
Specific
Define white-Box- Review Govern Implementation

Specification
Follow the following rules to successfully build a workflow system:
Understand Business and Requirements

Analyse business process, application landscape and organization, identify workflows and components
Define Platform and Tools

Build IT-Architecture, define reference architecture, define patterns to use and chose best practices to look at by
definition of special technical challenges you expect.
Define white-Box-Specification
Define input/output data per component and workflow, define service definitions, define components, define data
flow, and define a coarse-grained description of all algorithms.
Review
Give everything you have to a person you respect
Govern Implementation
Understand fundamental technology of each part of the system, ensure every day that code built follows the
architecture, and – last but not least - be confident and calm down, we support you!
Jochen M. Alt 22
Who does what and when?

Organisation
Organisation
Process
Process
Landscape
Landscape
Business
Business
Process
Process
Business
Applications
Applications SOA
SOAModel
Model
Domain Architect
Review
Review
Service
ServiceCut
Cut
SOA Domain Architect
Review
Review
Process
ProcessCut
Cut
BPM Domain Architect
ITIT Workflow
WorkflowCut
Cut
Architecture
Architecture
Solution Architect
Implementation
Implementation
Developer/Supplier
Business has to model the process landscape, the organisational chart and the business processes with
Adonis. After that, the domain architect should define the applications which are involved in the business
processes. This definition happens along the domain blueprint describing the to-be landscape of services and
applications. New applications need a service cut if not yet defined in the domain blueprint. All this is done with
Adonis diagram types.
Due to the importance of application and service cut, this should be reviewed by SOA/BPM architects.
Eventually, process definitions as well as application and service cut is the base for the solution architect to
start IT design
Jochen M. Alt 23
Architecture blueprint - The building blocks
Thin Client Presentation
or
Application
Rich client
Server
Workflow
Engine
Business
Services
Workflow system
blueprint with ESB
building blocks MESH
Service Service Service

Provider Provider Consumer
Basic workflow blueprint consists of an application server hosting all conventional business logic, a workflow
engine executing the workflow itself, and a presentation layer (thin client or rich client).
An ESB (Enterprise Service Bus) does all the transformation and communication needed to connect the
application server and workflow engine to external systems.
In the following, this blueprint is introduced in a detailed manner. It can be modified and enhanced by optional
patterns respectively components fulfilling additional requirements.
Jochen M. Alt 24
Basic Blueprint
MESH
Tomcat
Client
Thin Client (Browser)

(TIBCO general interface))
http
Action Processor
(iProcess API)
Workflow-Engine
(TIBCO iProcess)
Start Lorem ipsum End

Start Lorem ipsum End Ora
ESB
(TIBCO Business Works)
Converter Converter Converter
calling
Provider A Provider B Consumer
IT Business Logic aggregation
The picture shows the reference architecture‘s building block refined with products and communication
connections.
Use this blueprint, if

Process consists of pure workflow, that is the users follows a static process.
• All business logic needed is available in systems accessed via published services
• Client is based on a workitem / worklist model and needs not to be enhanced (that is the default user
interface of TIBCO is sufficient)
• reference data needed is stored in external system
Components needed
• Workflow-Engine (TIBCO iProcess)
• hosts all workflows
• ESB (TIBCO Business Works)
• Hosts provided services
• hosts small transformation tasks used in services
• Oracle Database
• internally used for iProcess
• Webserver/Servlet-Engine (Tomcat)
• hosts TIBCO iProcess API (ActionProcessor)
• Hosts TIBCO client-JSPs (general interface)
In case small components with plain logic are needed, Business Works or Tomcat can be used for hosting.
Jochen M. Alt 25
BUSINESS PROCESS MODELING NOTATION
Most frequently used symbols:
Start
Start Start aktivity
Lorem
Loremipsum
ipsum Activity (system- or useractivity)
yes
no
Exclusive Gateway
Parallel Gateway
thread A
thread B
Each workflow
has a starting
point and an
Lorem
Loremipsum
ipsum
end poiint
Start Lorem That‘s a

Start Lorem
Loremipsum
ipsum Loremipsum
ipsum End
End
gateway to fork
That‘s an a workflow
activity
Workflow definitions based on BPMN assume a model working on tokens. A token starts on the start activity,
and flows through all activities. A token can duplicate itself with a fork- gateway (and also be joined afterwards).
As soon as all tokens reach the end activity, the workflow finishes.
Activities
There are different types of activities. User activities perform a step within user-interaction by use of dialogs,
system activities invoke a webservice or call a script, receiving activities waiting for a message from a sending
activity, and many kinds of activities enhanced by events, timers.
Activities can be activated by at least one input transition, their output is at least one transitions also.
Gateways:
Gateways major purpose is to model a decision resulting in two transitions, e.g. a simple yes/no question.
Furthermore, gateways can be used to join a workflow as well as to split a workflow useful for handling parallel
workflows (e.g. escalation tasks).
• Exclusive gateway
When splitting, it routes the sequence flow to exactly one of the outgoing branches based on conditions.
When merging, it awaits one incoming branch to complete before triggering the outgoing flow.
• Parallel gateway
When used to split the sequence flow, all outgoing branches are activated simultaneously. When merging
parallel branches, it waits for all incoming branches to complete before triggering the outgoing flow.
Of course, there are much more symbols defined in BPMN (especially regarding events) please look it up under
http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_1_Poster_EN.pdf
Jochen M. Alt 26
Workflow Antipattern
A workflow is appropriate for
static processes assigning activities to a user or a service (e.g. approval processes, new employee
onboarding application)
A workflow is not appropriate for

user controlled applications not following static processes (e.g. HR scheduling systems)
Seems not to be a
workflow, but a Lorem
Loremipsum
ipsum
user-controlled Lorem
Loremipsum
ipsum This seems
part:each activity to be a
Lorem
Loremipsum
ipsum
can be invoked workflow!
repeatedly
Start
Start Lorem
Loremipsum
ipsum End
End
Depending on a Lorem
Loremipsum
ipsum
user-decision, next
activity is selected
Repeat until user
Lorem
Loremipsum
ipsum decides to stop
This anti-pattern describes the characteristics of a business process not appropriate for implementation in a
workflow system.
(Don’t) use, if
A workflow is not appropriate for user controlled applications not following static processes (e.g. HR scheduling
systems). That is, the user decides what is to be done next in a manner of an application like Office. The
corresponding workflow contains loops (because the user can call menus and dialogues repeatedly the way he
like). An additional indication is the completeness of the workflow graph, because application does not force a
special order activities are to be executed.
First (difficult) step during application design is to identify workflows in a process. Workflow engines should be
used for workflow steps and for nothing else.
Popular mistake:
Using workflow systems for non-workflow-parts, leading to mostly complete graphs with loops.
If an activity contains an application-like step (e.g. assign time schedule) integrate this following the non-
workflow integration pattern or service-side Business logic pattern to solve this
Jochen M. Alt 27
Patterns
Project Reviews
to
Do I have ct
je
read pro on
ntati
docume apply
wa n t to
if I
ctices?
best pra
CoE Discussion
Pattern
Now it‘s going into details,

the following patterns are
intended for IT-architects
Typically, getting concepts developed in existing projects is difficult and time consuming. To enable re-use of
proven concepts and pieces of software, CoE (Center of Excelence) is about to be founded to collect, polish and
publish concepts worth for re-use.
Basic idea is that project reviews are used to collect patterns, which can be discussed and improved in the
community of the CoE. Afterwards, a condensed documentation of patterns like is to be provided by members
CoE.
Besides that, we encourage domain architects and solution architects to share their experiences with SOA/BPM
domain architects for the same reason.
For more information on CoE, please ask Abhijit Gupta.
Jochen M. Alt 28
1 BPM / Workflow
BPM Principles
2 Modelling Guide
Workflow Principles
3 Modelling Guide
All that sounds very academic.
I won’t believe the benefits
promised as long as I haven’t
4 An Example
seen a real-world example.
5 Additionals
To demonstrate all tools introduced as well as the procedure how to design a running system, a small example
from Global Banking is shown implementing a real-world use case. The example starts with design of a business
process, continues with the design of the workflow and shows the final implementation.
Jochen M. Alt 29
Business background
Project TSU:
Result of discussion with business
Enter
EnterPurchase
PurchaseOrder
Order Approve
ApprovePurchase
PurchaseOrder
Order
Start
Start
Generate
Generate
Import
ImportPurchase
PurchaseOrder
Order Purchase
PurchaseOrder
Order
Match
Match Report
Report End
End Invoice
Invoice
Generate
Generate
Import
ImportSales
Sales Order
Order Sales
SalesOrder
Order Wait until both
Start
Start
orders are
there, that is
until a order
Enter
EnterSales
SalesOrder
Order Approve
ApproveSales
SalesOrder
Order arrives with
the same
ordernumber
An order can be
imported, generated,
or entered in a form
Business process
Two companies want to do business together. One is selling something (any goods), the other buys it. The bank
in between ensures, that as long as no goods are delivered the seller doesn‘t get his money, as long as the
money is not yet available, the goods are not to be delivered.
Requirements
The system is supposed to import orders in an automatic or manual way. A purchase order and a seller order
arrive independently into the system, following an identical process. After an approval step, an order waits until
the corresponding order of the opposite type is there. Once both orders are available, a matching procedure
starts (matching is done by use of an ordernumber), reporting is invoked and the final invoice of the bank is
generated.
The discussion with business resulted in the depicted diagram.
Jochen M. Alt 30
Modelling the Process Landscape
Model path in Adonis: Adonis/Ballpark/Jochen Alt/TSU/TSU - Process Landscape - Company Model
The process landscape describes the high level processes in global banking and where the system we want to
build is located.
Jochen M. Alt 31
Modelling the Roles and Responsibilities
Adonis/Ballpark/Jochen Alt/TSU/TSU - Purchase Order Colaboration – Organigram
The organisation diagram shows that the trade department is located in Global Banking. Two persons are
involved (Jochen and Christoph), with specific roles:
• Order Worker: this role assigns the task of entering an order

• Order Manager: having the order manager role allows to approve an order.
• Administrator: allows to track and to fix lost or broken processes
Jochen M. Alt 32
Modelling the Business Process
path in Adonis: Adonis/Ballpark/Jochen Alt/TSU/TSU - Purchase Order Process
This diagram shows the Adonis business process model in detail.
SO – sales order
PO – purchase order
During analysis the following activities were added in comparison to the first sketch:
• An order can be entered manually (A Save PO incomplete), and can be imported (Accept PO from TSU).
• An imported order does not have to be approved. In case of a manually entered order, the uniqueness of
the order number has to be ensured
• Some orders do not need an corresponding order (SO required)
• In case a corresponding order is required, some customer relationships allow to generate the
corresponding order automatically (Auto-Generate SO)
Jochen M. Alt 33
Modelling the System Landscape
path in Adonis: Adonis/Ballpark/Jochen Alt/TSU/TSU Application Architecture
This shows the applications involved. The newly built system is named TSU, it is invoked by eBill. The
application FSCM (financial service chain matching) is an external system providing additional matching
functionality
Jochen M. Alt 34
Combining all the information
Company
Company
Map
Map
Business
Business Work
Work
Process
Process Environ-
Environ-
Model
Model ment
mentModel
Model
Application
Application
Architecture
Architecture
M.M.
implements
needs
works on
Implemented in
works with
Adonis allows references from one diagram type having a complete business model. This pictures shows how
each diagram type is related to each other. This model helps to answer the questions as follows by looking at
these references:
• Who works on Purchase Order Process (lookup roles involved, lookup people having those roles)
• Which business processes fail when TSU system fails? (lookup all processes implemented in TSU)
• Which activities and processes fail when someone does not work? (lookup his roles, lookup all activities
this role is involved in)
Jochen M. Alt 35
Business Analysis finished!
ess
ss proc
Busine n is hed,
g is fi
modelin ig n!
IT-Des
pass to
Jochen M. Alt 36
Defining the Architecture
Thin
ThinClient
Client Presentation
Presentation
Workflow
Workflow
Engine
Engine
ESB
ESB
Workflow
Workflowsystem
systemblueprint
blueprint
with FSCM
withbuilding
buildingblocks
blocks FSCM
Browser
Browser Webserver
Webserver(Tomcat)
(Tomcat) Processengine
Processengine(TIBCO
(TIBCOiProcess)
iProcess)
(Generic
(GenericInterface)
Interface)
Form A
Form A
Form A
Aksjhd qiueza kjdh
Generic
Interface TIBCO
Action Start
Start Activity
ActivityAA … End
End
…
Processor
Enterprise
EnterpriseService
ServiceBus
Bus
(TIBCO
(TIBCOBusiness
BusinessWorks)
Works)
Webservice A …
The process is pure workflow – that is, only a few services needs to be implemented. These services do not
need an enhancement of the basic architecture blueprint. It is used unmodified.
There‘s no need for an application server. All services can be implemented within Tibco Business Works
A thin client based on the Tibco standard client is sufficient
Jochen M. Alt 37
Designing the Workflow
Sales
SalesOrder
Order No
Start
Start Enter
EnterPurchase
PurchaseOrder
Order Approve
ApprovePurchase
PurchaseOrder
Order Wait
Waitfor
forSales
SalesOrder
Order
already
alreadythere?
there?
Yes
ag e
Send
SendPurchase
PurchaseOrder
Order
ess
to
toSales
SalesOrder
Orderprocess
process
m
nd
Se
Apply the Merge Processes Pattern! End
End
continued…
(Matching)
Send
SendSales
SalesOrder
Order
to
toPurchase
PurchaseOrder
Orderprocess
process
Yes
Purchase
PurchaseOrder
Order No
Start
Start Enter
EnterSales
SalesOrder
Order Approve
ApproveSurchase
SurchaseOrder
Order Wait
Waitfor
forPurchase
PurchaseOrder
Order
already
alreadythere?
there?
When creating the workflow we need to design how both processes are communication with each other,
especially the activity joining both independent processes doing the matching procedure needs to be clarified.
That is, a purchase order‘s process and a sales order‘s process are to be merged as soon as both are available
in the system. How should this be done?
Solution:
Two symmetric workflows are modelled.
The first order entering the system takes over responsibility to continue the joined process in the end. The order
arriving later sends itself to the waiting process and quits right afterwards. That is, joining two processes is done
by sending a message from the second process to the first one.
Jochen M. Alt 38
Purchase Order Workflow in TIBCO

Enter a PO Approve the order
manually with Is this order (only in case it has Look for
a form entered not been entered corresponding
manually or manually) Sales Order
imported? (WS)
Automatically generate If SO exists, send a

a Sales order (for message to the
imported POs only) corresponding process
Perform the
Reporting (WS)
Perform the
matching(WS)
This has been modelled using TIBCO Business Studio, all properties necessary
to run in TIBCO iProcess are attached to activities (not depicted here)
This is the workflow of a purchase order modelled using Tibco Business Studio. That is the real implementation,
all activities contains the information needed to be executed by TIBCO iProcess engine.
Jochen M. Alt 39
Implementation
Thin
ThinClient
Client Presentation
Presentation
Workflow
Workflow
Engine
Engine
ESB
ESB
Workflow
Workflowsystem
systemblueprint
blueprint
with
withbuilding
buildingblocks
blocks FSCM
FSCM Keen on seeing this
workflow in action?
Send an email to
Jochen-A.Alt@db.com!
Using architecture blueprint and workflow design, implementation starts:

• implement webservices needed in TIBCO Business Works
• implement workflow by adding data fields, properties needed, defining parameter to workflow activities,…
• implement dialogs by defining forms, assign events and values
Jochen M. Alt 40
1 BPM / Workflow
BPM Principles
2 Modelling Guide
Workflow Principles
3 Modelling Guide
4 An Example
Where can I get support for the
5 Add-ons
tools mentioned? Who is the right
person to contact? Are there any
further links?
That’s it. The rest is just addition information.
Jochen M. Alt 41
Contacts, Tools and Links
BPM domain architects:

Christoph Blesing, Jochen Alt
SOA domain architect

Uwe Meyer
CoE (Center of Excellence)

Abhijit Gupta
Mesh
Rouven Heck / Tom Gilbert
Tibco (http://www.tibco.com)
Jochen Alt
Adonis (http://www.box.at)
Christoph Heins
Service repository
Pieter Hauffe
BPM domain architects:

Christoph Blesing (focus on PWM, HR) (http://gd.db.com/perl/servlet/GdEntry?dbdirid=94104&visualtype=html/en)
Jochen Alt (focus on GB) (http://gd.db.com/perl/servlet/GdEntry?dbdirid=2308255&visualtype=html/en)
BPM in the Intranet: http://worksphere.pcb.cio.gto.intranet.db.com/cooc/3191.html
SOA domain architect
Uwe Meyer (http://gd.db.com/perl/servlet/GdEntry?dbdirid=2115395&visualtype=html/en)
SOA in the Intranet http://worksphere.pcb.cio.gto.intranet.db.com/cooc/3191.html
CoE
Abhijit Gupta
Mesh
Rouven Heck / Tom Gilbert
Mesh in the intranet http://soa.ies.gto.intranet.db.com/MESH
Tibco (http://www.tibco.com)
Jochen Alt (http://gd.db.com/perl/servlet/GdEntry?dbdirid=2308255&visualtype=html/en)
Adonis (http://www.box.at)
Adonis can be ordered via https://asd.tools.intranet.db.com/ASD/en/
Christoph Heins (http://gd.db.com/perl/servlet/GdEntry?dbdirid=2286021&visualtype=html/en)
Service repository
Pieter Hauffe (http://gd.db.com/perl/servlet/GdEntry?dbdirid=2249675&visualtype=html/en)
Repository in the intranet: http://repository.soa.gto.intranet.db.com/
Links
BPM Awareness course:
https://dblearnrepository.hronline.intranet.db.com/dblearn/elearning/gto/architectureSOAii/bpm_training/launch_dblearn.html
BPMN Notation: http://bpt.hpi.uni-potsdam.de/pub/Public/BPMNCorner/BPMN1_1_Poster_EN.pdf
Jochen M. Alt 42
Contact
Jochen M. Alt
Deutsche Bank AG, GTO PCB IT/O

Domain Architect BPM/Workflow
Tel +49 (0) 69/910-65292

Mobile +49 (0)172/ 3708542
E-Mail: jochen-a.alt@db.com
Alfred–Herrhausen-Allee 16-24
65760 Eschborn, TZE, 18th floor
Jochen M. Alt 43

BPMFramework v12

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BPMFramework v12

Hochgeladen von

Copyright:

Verfügbare Formate

The BPM Framework V11 24/10/2008

Jochen M. Alt 1.1

What is BPM, SOA, workflow?

Information on tools, notations, etc.

Domain Architects Solution Architects

Scope and differentiation between BPM, workflow and SOA

2 Principles / Modelling Guide

Finally, the benefits are listed when following this framework.

Is Business Process Management needed?

In a nutshell, BPM is business analysis PLUS a

These shortcomings are to be solved by BPM.

Process Process Process Process

Process Modelling Process Execution Process Monitoring Process Optimisation

BPM‘s lifecycle has the following blocks:

Criterias for projects suitable for workflow:

A process is well suited for being implemented with a workflow tool if

Model layer definitions

From a Business Process to a Workflow

(Adonis) (TIBCO Business Studio)

The process cut has to be design.

Deliverables of BPM, Workflow, SOA

Service Service <?xml version="1.0" encoding="UTF-8"?>

(Service Registry, RAM) (WSDL)

Business Process Modelling

2 Modelling Guide / BPM Principles

Business Processes Roles and

Roles and Responsibilities

Business driven identification of Landscape

Example landscape (Adonis)

Business driven identification of Processes

Example organization (Adonis) Business

To define the application architecture, proceed as follows:

Diagrams and Relationships

vital for Work for

necessary for Application

The depicted relationships are to be read in the following manner:

Discipline of Modeling: Model only what you expect IT to ask you.

Round Trip Engineering

different tools different people

Round Trip Engineering

Hence, we do not recommend to use round trip engineering for BPM/workflow

Top Down vs. Bottom Up

+ process model perfectly reflects business + Good utilization of existing services

Process Modelling: Top Down vs. Bottom Up

… continue by defining processes…

Work top-down on landscape level and process level

Continue using a jojo-approach

3 Workflow Architecture & Patterns

From a Business Process to a Workflow-System

Define white-Box- Review Govern Implementation

Follow the following rules to successfully build a workflow system:

Understand Business and Requirements

Define Platform and Tools

Who does what and when?

Architecture blueprint - The building blocks

Thin Client Presentation

Service Service Service

Thin Client (Browser)

Start Lorem ipsum End

Converter Converter Converter

Use this blueprint, if

BUSINESS PROCESS MODELING NOTATION