More Related Content
Similar to BPM for developers (20)
More from Alexander SAMARIN (20)
BPM for developers
- 2. About me
• An enterprise architect
– From a programmer to a systems architect
– Experience in scientific, international, governmental and industry
environments: CERN, ISO, IOC, BUPA, Groupe Mutuel, State of
Geneva, EDQM, Bund ISB, AfDB
– Have created systems which work without me
– Practical adviser for design and implementation of enterprise
architectures and solutions
• My main “tool” is a blend of:
– BPM, SOA, EA, ECM, governance and strategy
• Blog http://improving-bpm-systems.blogspot.com/
• PhD in computer graphics and 2 published books
© A. Samarin 2013 BPM for developers, v1 2
- 4. Business Process Management (BPM) is
a tool for improving business
performance
A natural evolution of
BPR, Lean, ISO 9001, 6 A multitude of tools
Sigma “handle” processes
The theory The tools
BPM as a discipline BPM as software:
The aim is to have a single
(use processes to business
description of BPM suite (BPMS)
manage an
processes:
enterprise)
- model in design
- input for project
planning and execution An enterprise portfolio
- executable program for of the business
coordination of work processes as well as
- documentation for all the practices and tools
staff members for governing the
- basis for management design, execution and
decisions evolution of this
The practice portfolio
Any process-centric enterprise has some BPM, but
how can we industrialise this BPM?
© A. Samarin 2013 BPM for developers, v1 4
- 5. BPM as a management discipline (1)
• BPM as a management discipline about how to use
processes to manage the enterprise
– to model, automate, execute, control, measure and optimise
the flow of business activities that span the enterprise’s
systems, employees, customers and partners within and beyond
the enterprise boundaries
• Model means to make known, to describe or to
communicate a plan of how to carry out future actions to
obtain a desired outcome
– To plan
– To simulate
© A. Samarin 2013 BPM for developers, v1 5
- 6. BPM as a management discipline (2)
• Automate means to instrument the proposed plan of
work by some existing or new tools
– To instrument
• Optimise means to introduce formally justified changes
– To reflect
– To refactor
– To improve
• Those 6 BPM functions are applied iteratively and
continuously
© A. Samarin 2013 BPM for developers, v1 6
- 7. Feedback improvement loop
• An enterprise is a complex, dynamic and adaptive
system; one can improve it by:
– measuring
– observing
– deciding
– implementing
2
3
4 1
© A. Samarin 2013 BPM for developers, v1 7
- 14. Be ready for common
(mis-)understanding
© A. Samarin 2013 BPM for developers, v1 14
- 15. Process anatomy (1)
• The business is driven by events
• For each event there is a process to be executed
• Process coordinates execution of activities
• The execution is carried out in accordance with business
rules
© A. Samarin 2013 BPM for developers, v1 15
- 16. Process anatomy (2)
• Each business activity operates with some business
objects
• A group of staff member (business role) is responsible
for the execution of each activity
• The execution of business processes produces audit
trails
• Audit trails (which are very detailed) are also used for the
calculation of Key Performance Indicators (KPIs)
© A. Samarin 2013 BPM for developers, v1 16
- 17. Process templates and instances
• Process template – a formal description of the process
Templates Instances
and their
• Process instance – versions
enactment of a process
template
• Different variations of
relationship between
template and instance
© A. Samarin 2013 BPM for developers, v1 17
- 18. Different enterprise artefacts
• Business artefacts
– Events
Human
– Processes “workflow”
Data structures
– Activities Roles
– Roles Documents
Events
– Rules Rules
Processes
– Data & documents Services
Audit trails
– Audit trails
KPIs
– Performance indicators
– Services
• Organisational and technical artefacts …
© A. Samarin 2013 BPM for developers, v1 18
- 19. Business processes are complex
relationships between artefacts
• Who (roles) is doing What (business objects), When
(coordination of activities), Why (business rules), How
(business activities) and with Which Results
(performance indicators)
• Make these relationships explicit and executable
What you model is
what you execute
© A. Samarin 2013 BPM for developers, v1 19
- 20. Services and processes (1)
• Services are considered to be explicitly-defined and
operationally-independent units of functionality
– Formal description
– Operational independence
– Invisible implementation
© A. Samarin 2013 BPM for developers, v1 20
- 21. Services and processes (2)
• Processes are considered to be an explicitly-defined
coordination of services to create a particular outcome
– Formal description
– Coordination
© A. Samarin 2013 BPM for developers, v1 21
- 22. Synergy between BPM and SOA (1) –
structuring relationships
• BPM, by revealing the artefacts and the relationships
between them, provides the necessary context (e.g.
granularity) for the definition of services
• SOA provides
recommendations
for the implementation,
execution and governance
of services
© A. Samarin 2013 BPM for developers, v1 22
- 23. Synergy between BPM and SOA (2) –
structuring relationships
• Each enterprise is a complex, dynamic, unique and
“fractal” relationship between services and processes
– All processes are services
– Some operations of a service can be implemented as a process
– A process includes services
in its implementation
service process
© A. Samarin 2013 BPM for developers, v1 23
- 24. Coordination between activities
• Interdependencies between activities must be managed
• Coordination can be:
– implicit vs explicit
– human vs automated
– centralised vs decentralised
– imperative vs declarative
– strong vs weak
• May change over the time (e.g. a crisis situation)
© A. Samarin 2013 BPM for developers, v1 24
- 25. Different scales of coordination
• Controls on the same page
• Flow of pages
• Integration of services
• Human workflow
• Business-to-business
© A. Samarin 2013 BPM for developers, v1 25
- 26. The explicit coordination brings several
advantages
• It allows planning and simulation of the behaviour of a
service to evaluate its performance. If that service uses
other services, then the demand-side needs for those
services can also be evaluated.
• It can be made to be executable, thus guiding how work
is done.
• It allows control that the actual behaviour of the service
matches its intended behaviour, thus pro-actively
detecting potential problematic situations.
• It allows the measurement within a service of the
dynamics of different characteristics, e.g.
valuing, costing, risk, etc.
© A. Samarin 2013 BPM for developers, v1 26
- 27. Explicit coordination techniques
• template-based (or token-based)
• event-based (or business-events-based)
• data-based (or business-objects-based)
• rule-based (or business-rules-based)
• role-based (or business-roles-based)
• intelligence-based (or business-intelligence-based)
• goal-based (also known as purpose-based)
• performance-based
• community-based
• etc.
© A. Samarin 2013 BPM for developers, v1 27
- 28. Coordination logic in BPMN (1)
• Template-based
– static connection of “flow objects” or sequence relationship
(predecessor and successor)
– similar to a river (upstream and downstream)
– process template is an abstract description of a process
© A. Samarin 2013 BPM for developers, v1 28
- 29. Coordination logic in BPMN (2)
Click for animation
• Token-based
– token marks elements which active at a particular time
– dynamic connection of “flow objects” or synchronisation (wait for)
/ chronologic relationship
– similar to a “flock” of ducks (split and join)
– several tokens may co-exist
© A. Samarin 2013 BPM for developers, v1 29
- 30. Coordination logic in BPMN (3)
Click for animation
• Event-based
– non-structured synchronisation between tokens
– exchange of messages (signals, errors, etc.)
– exception handling
Wait for (catch) a message event
Generate (throw) a message event
© A. Samarin 2013 BPM for developers, v1 30
- 31. Coordination logic in BPMN (4)
Click for animation
• Instance-based
– process instance is an enactment of a process template
– each instance may have different behaviour of tokens
– process instances may be coordinated via event-based
coordination logic
© A. Samarin 2013 BPM for developers, v1 31
- 32. Look at automation within processes
• Mixing human and automated activities
• Each human activity may be surrounded by two
automated activities (pre-processing and post-processing)
© A. Samarin 2013 BPM for developers, v1 32
- 33. Speed of developing automation is the
primary factor of agility
• Explicit versioning of everything (another topic for
developers)
• Keep automation outside the process template (as they
have different speed of changes)
• Use an interpretive language for automation scripting (no
need to recompile)
• Use recovery loops (preserve
instance, carry out quick corrections in
“this” instance)
• Smart error handling (bypass some
levels of support)
© A. Samarin 2013 BPM for developers, v1 33
- 34. More tricks
• Combine static and dynamic programming languages
• Use the strong typing, introspection, no exotic features
• Use external (to process engine) universal program
(robot) to execute automation scripts (scalability)
• Assign automated activities to robots (potential use of
specialised robots)
• Multiple robots (load balancing)
• Process engine queues jobs for robots
• Proactive monitoring of resource availability (better to
wait a little than recover from an error)
• Idempotency
© A. Samarin 2013 BPM for developers, v1 34
- 35. Java and Jython codes examples
© A. Samarin 2013 BPM for developers, v1 35
- 37. Multi-layer implementation model (2)
• The business data layer comprises many pieces of information –
names, dates, files, etc.
• The business objects layer comprises the many objects specific to a
particular business, e.g. a business partner, a product, etc.
• The business routines (or regulations) layer comprises the
actions which must be carried out on the business objects to perform
the business activities.
• The business execution layer carries out the business processes.
• The business monitoring layer analyses the execution of the
business process.
• The business intelligence layer implements enterprise-wide
planning, performance evaluation and control actions applied to the
business processes.
© A. Samarin 2013 BPM for developers, v1 37
- 39. Multi-layer implementation model (4)
SAP BW/BI, etc.
NetWeaver
PI, SolMan, etc.
NetWeaver
BPM, etc.
NetWeaver
BRM, Java, ECC6,
etc.
XSD, Java, .Net
SQL
Server, Oracle,
etc.
© A. Samarin 2013 BPM for developers, v1 39
- 42. Categories of services (1)
• Business-specific
– unique business-managed processes and non-reusable IT-
managed services
• Business-generic
– reusable business-managed processes and reusable IT-managed
services
• Technology-generic
– advanced utilities available as IT-managed services (these services
act like an insulation layer)
• Technology-specific
– typical basic utilities available as IT-managed services
© A. Samarin 2013 BPM for developers, v1 42
- 44. Some SOA topics and BPM
• Service design -> access to BPM artefacts
• Service implementation –> wrapping BPM artefacts
• Transitioning beyond Basic Services -> processes
• Execution and deployment -> messaging over ESB
• Governance -> architecting flexible BPM systems
© A. Samarin 2013 BPM for developers, v1 44
- 45. Incremental introduction of executable
processes
As is Application A Application B Application C
1st iteration Application A Application B Application C
2nd iteration Application A Application B Application C
3rd iteration Application A Application B Application C
To be Application A Application B Application C
© A. Samarin 2013 BPM for developers, v1 45
- 46. Integration with BI and enterprise risk
management
Risk-related events, reports, alerts, indicators, etc.
Risk-related rules, logic and knowledge
Enterprise Enterprise document
data warehouse management and collaboration
© A. Samarin 2013 BPM for developers, v1 46
- 48. Variant 1 – classic (one template is used
for many instances)
© A. Samarin 2013 BPM for developers, v1 48
- 49. Variant 2 – tailoring (a template is
adjusted for each instance)
© A. Samarin 2013 BPM for developers, v1 49
- 50. Variant 3 – reactive (no initial template
and next activity is selected based on
the current situation)
© A. Samarin 2013 BPM for developers, v1 50
- 51. Variant 4 – proactive planning (similar
to variant 3, but a few next activities
[fragment] are executed together)
© A. Samarin 2013 BPM for developers, v1 51
- 52. Variant 5 – scenario-based (similar to
variant 4, but a few scenarios are
considered)
Process fragments are used; those may be patterns
© A. Samarin 2013 BPM for developers, v1 52
Editor's Notes
- approach-other-c