bpm for developers

BPM for developers:improve agility of implementations

A. Samarin

BPM for developers, v1 2

• 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

About me

http://improving-bpm-systems.blogspot.com/


• BPM

• Process

• Coordination

• Automation

• Implementation model

© A. Samarin 2013

Agenda

BPM for developers, v1© A. Samarin 2013 4

Business Process Management (BPM) is a tool for improving business

performance

The theoryBPM as a discipline (use processes to manage an enterprise)

The toolsBPM as software:BPM suite (BPMS)

The practiceAny process-centric enterprise has some BPM, but how can we industrialise this BPM?

A natural evolution of BPR, Lean, ISO 9001, 6 Sigma

The aim is to have a single description of business processes:- model in design- input for project planning and execution- executable program for coordination of work- documentation for all staff members- basis for management decisions

An enterprise portfolio of the business processes as well as the practices and tools for governing the design, execution and evolution of this portfolio

A multitude of tools “handle” processes


• 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 as a management discipline (1)


• 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 as a management discipline (2)


• An enterprise is a complex, dynamic and adaptive system; one can improve it by:

– measuring

– observing

– deciding

– implementing

Feedback improvement loop

1

2

3

4

© A. Samarin 2013


Process improvement disciplines

© A. Samarin 2013


Process-oriented view of an enterprise (before BPM)

© A. Samarin 2013


Process-oriented view of an enterprise (with BPM)

© A. Samarin 2013


Process-oriented view of an enterprise (with BPM)

BPM for developers, v1 12© A. Samarin 2013

BPM suite components


BPM suite components (extended list)


Be ready for common (mis-)understanding


• 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

Process anatomy (1)


• 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

Process anatomy (2)


• Process template – a formal description of the process

• Process instance – enactment of a process template

• Different variations of relationship between template and instance

© A. Samarin 2013

Process templates and instances

Templates and their versions

Instances

BPM for developers, v1

• Business artefacts

– Events

– Processes

– Activities

– Roles

– Rules

– Data & documents

– Audit trails

– Performance indicators

– Services

• Organisational and technical artefacts …

© A. Samarin 2013 18

Different enterprise artefacts

KPIs

Processes Services

Events

Roles Data structures

Documents

Rules

Human “workflow”

Audit trails


• 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

Business processes are complex relationships between artefacts


• Services are considered to be explicitly-defined and operationally-independent units of functionality

– Formal description

– Operational independence

– Invisible implementation

© A. Samarin 2013

Services and processes (1)


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

– Formal description

– Coordination

© A. Samarin 2013

Services and processes (2)


• BPM, by revealing the artefacts and the relationships between them, provides the necessary context (e.g. granularity) for the definition of services

• SOA provides recommendationsfor the implementation, execution and governance of services


Synergy between BPM and SOA (1) – 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 servicesin its implementation


Synergy between BPM and SOA (2) – structuring relationships

service process


• 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

Coordination between activities


• Controls on the same page

• Flow of pages

• Integration of services

• Human workflow

• Business-to-business

© A. Samarin 2013

Different scales of coordination


• 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

The explicit coordination brings several advantages


• 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

Explicit coordination techniques


• 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


Coordination logic in BPMN (1)


• 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


Coordination logic in BPMN (2)Click for animationClick for animation


• Event-based

– non-structured synchronisation between tokens

– exchange of messages (signals, errors, etc.)

– exception handling


Coordination logic in BPMN (3)Click for animation

Wait for (catch) a message event

Generate (throw) a message event


• 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


Coordination logic in BPMN (4)Click for animation


• Mixing human and automated activities

• Each human activity may be surrounded by two automated activities (pre-processing and post-processing)

© A. Samarin 2013

Look at automation within processes


• 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

Speed of developing automation is the primary factor of agility


• 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

More tricks


Java and Jython codes examples

36© A. Samarin 2013 BPM for developers, v1

Multi-layer implementation model (1)

37

• 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




B C

A

A - SharePoint

B – in-house development

C – SAP ECC6



SAP BW/BI, etc.

NetWeaver PI, SolMan, etc.

NetWeaver BPM, etc.NetWeaver BRM, Java, ECC6, etc.

XSD, Java, .Net

SQL Server, Oracle, etc.

40

virtualisation infrastructure

PI infrastructure

Business

intelligence

Business

monitoring

Business

execution

Business

routinesBusiness

objectsBusiness

data

Repository

Repository

Repository

Portal or workplace




• 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 (1)

© A. Samarin 2013


• 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

Some SOA topics and BPM

© A. Samarin 2013

45

As is

1st iteration

2nd iteration

3rd iteration

To be

Application A Application CApplication B






Incremental introduction of executable processes

46

Enterprisedata warehouse

Risk-related rules, logic and knowledge

Risk-related events, reports, alerts, indicators, etc.

Enterprise document management and collaboration


Integration with BI and enterprise risk management


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