BPM for developers

BPM for developers:
improve agility of
implementations

A. Samarin

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

Agenda

• BPM
• Process
• Coordination
• Automation
• Implementation model


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?

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


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


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


Process improvement disciplines


Process-oriented view of an enterprise
(before BPM)


(with BPM)


BPM suite components


BPM suite components (extended list)


Be ready for common
(mis-)understanding


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


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)


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


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 …


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


Services and processes (1)

• Services are considered to be explicitly-defined and
operationally-independent units of functionality
– Formal description
– Operational independence
– Invisible implementation


Services and processes (2)

• Processes are considered to be an explicitly-defined
coordination of services to create a particular outcome
– Formal description
– Coordination


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


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


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)


Different scales of coordination

• Controls on the same page
• Flow of pages
• Integration of services
• Human workflow
• Business-to-business


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.


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.


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


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


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


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


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)


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)


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

Java and Jython codes examples


Multi-layer implementation model (1)



• 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 - SharePoint

B – in-house
development

C – SAP ECC6 B C
A



SAP BW/BI, etc.

NetWeaver
PI, SolMan, etc.
NetWeaver
BPM, etc.
NetWeaver
BRM, Java, ECC6,
etc.
XSD, Java, .Net

SQL
Server, Oracle,
etc.


Services are externalised artefacts


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


Categories of services (2)


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


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


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





Thanks


Variant 1 – classic (one template is used
for many instances)


Variant 2 – tailoring (a template is
adjusted for each instance)


Variant 3 – reactive (no initial template
and next activity is selected based on
the current situation)


Variant 4 – proactive planning (similar
to variant 3, but a few next activities
[fragment] are executed together)


Variant 5 – scenario-based (similar to
variant 4, but a few scenarios are
considered)

Process fragments are used; those may be patterns


BPM for developers

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (17)

Similar to BPM for developers

Similar to BPM for developers (20)

More from Alexander SAMARIN

More from Alexander SAMARIN (20)

Recently uploaded

Recently uploaded (20)

BPM for developers

Editor's Notes