how to simplify the evolution of business process lifecycles

How to simplify the evolution of business process lifecycles

Dr Alexander Samarin

BPMDS’08MONTPELLIER, FRANCE

www.samarin.biz

The goal – easy evolution of business process lifecycles

• Experience shows that business wants separate requests for change to be implemented quickly

• These changes are typically small (from the point of view of the business) and unpredictable (from the point of view of IT)

• To carry out these changes easily and in a managed way, BPM systems must be properly architected and implemented

2008-06-172 How to simplify the evolution of business process lifecycles

www.samarin.biz

BPM and BPM systems

• Definition of BPM (as a discipline):– BPM allows you to model, execute, control, automate,

measure and optimise the flow of business activities that span your enterprise’s systems, people, customers and partners within and beyond your corporate boundaries

• Obviously, all enterprises have their own BPM system, but often a BPM system:– is a “problem” of its history,– suffers from problems of complexity, inefficiency

• Not surprisingly, many enterprises want to improve their BPM systems


www.samarin.biz

BPM view of the business (1)

• The business is driven by business events• For each business event there is an associated

business process to be executed• A business process coordinates the execution of

business activities• The execution is carried out in accordance with

business rules


www.samarin.biz

BPM view of the business (2)

• Each business activity operates with some business objects

• A group of staff members (business roles) is responsible for the execution of each human activity

• The execution of business processes produces audit trails, which are used for the calculation of key performance indicators


www.samarin.biz

Architecting an enterprise BPM system (with systems thinking)

• A BPM system is a dynamic set of artefacts • Artefacts are interconnected and interdependent• We have to anticipate potential changes:

– policies, priorities, compliance, technology, etc.

• Implementation of such changes necessitates the evolution of some artefacts and the relationships between them

• It must be easy to modify all artefacts and relationships without causing any negative effects


www.samarin.biz

Principal artefacts: services and processes

• The business world understood a long time ago that services and processes are the backbones of most businesses

• The IT world recently “re-discovered” and accepted the notion of services, and so emerged SOA

• But IT is still not very comfortable with processes (often, an application is a mixture of data-entry and workflow-driven approaches)


www.samarin.biz

Relationships between services and processes

• All processes are services• Some operation(s) of a service can be implemented

as a process• A process may include services in its implementation


www.samarin.biz

All BPM artefacts

– added-value chain– events– processes– rules– activities– roles– objects (data structures)– objects (documents)– audit trails– performance indicators– services


www.samarin.biz

Main architecting principles

• All artefacts must be evolved to become digital, external and virtual

• All artefacts must be versionable throughout their lifecycle

• All relationships between these artefacts are modelled explicitly

• All models are made to be executable


www.samarin.biz

Improvement of artefacts

• Digitalised – available in electronic form

• Externalised – available as separate entities with proper definition, naming, versioning, storage, security, traceability, etc. – e.g. transportation of objects between services

• Virtualised – available independently of traditional IT resources (servers, databases, media, browsers) as services


www.samarin.biz

Relationships between artefacts

• Reveal all hidden relationships and structure them Examples:– static (in design phase)– dynamic (in execution phase)– composition (from atomic artefacts to a composite

artefact)– instantiation (from a template to instances)– compatibility (between different versions)

• If possible, model relationships as formal, explicit, traceable, testable, secure, SLA aware and executable


www.samarin.biz

Explicit and executable models

• Process model is an aggregation of – events, activities, roles, objects, rules, audits, etc.

• Versioning is vital• In an implementation, a model acts as a skeleton or

foundation to which we attach services (what you design is what you execute)


www.samarin.biz

Synergy between BPM and SOA

• SOA is an architectural approach for constructing complex software-intensive systems from a set of universally interconnected and interdependent building blocks, called services (stand-alone units of functionality)

• 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


www.samarin.biz

Role of architecture

• Consider a complex and dynamic system with many artefacts, relationships, stakeholders

• Understand the concerns of each group of stakeholders• Provide the step-by-step improvement of a system (like

the Deming wheel)– Plan, Do (or implement), Check (or validate),

Act (or refactor)

• Consider together different technologies, such as BPM, SOA, ECM, EA and IT governance

• Build an agile system in an agile way


www.samarin.biz

An architectural framework for improving BPM systems

• Considerable reduction of Total Cost of Ownership (TCO)

v.1 v.2 v.3 v.4 Life-cycle

TCO

First BPM/SOA project

Further BPM/SOA projects

Maintenanceapprox. 80 %

Initialdevelopmentapprox. 20 %

Typical IT projects


www.samarin.biz

Modelling of executable business processes

• Diagramming style in BPMN

• A dozen practical patterns

• Structuring for better “executability”

• Modelling procedure

• Tool for prototyping – Intalio BPM suite


www.samarin.biz

Diagramming style in BPMN


www.samarin.biz

The modelling procedure

• Its purpose is:– to analyse a building block (what it is supposed to do)

– to synthesise its implementation (how it does this) as explicit coordination of other building blocks (processes or activities)

• It is iterative: we can apply it until we only have left indivisible building blocks (i.e. activities)

• Artefacts are constructed recursively, like Russian dolls


www.samarin.biz

Four phases


www.samarin.biz

Blackboxing phase

• The purpose – to analyse a building block as a whole

– to discover its functional characteristics and some related artefacts

• The method– the business story behind this building block should be

carefully analysed to recognise its artefacts

• Recommendations– don’t go into excessive detail for each artefact; this can

be done later


www.samarin.biz

Structuring phase (1)

• Steps


www.samarin.biz


• Steps and artefacts


www.samarin.biz

Re-construction phase

• The diagram


www.samarin.biz

Instrumentation phase

• The diagram


www.samarin.biz

Conclusions

• The formal expression of relationships enables their automated validation

• The aggregation or assembly of services becomes the main implementation activity

• Small cycles “model–implement–test–refactor” considerably simplify both modelling and implementation

• There is a good match between BPM (provision of the context for services) and SOA


www.samarin.biz

Thank you!

Contact information:+41 76 573 40 [email protected]


www.samarin.biz

Principles of the modelling procedure

• it treats human and automated activities equally

• it is primarily for capturing the flow of control within a building block, but not for optimisation

• it is a tool for both business and IT (maybe with coaching by a process analyst)

• it provides validation by simulation• it provides validation by quick prototyping –

real services can be invoked• it is visual programming


www.samarin.biz

• An enterprise solutions 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, Swiss federal government

– Co-author of the book “The LaTeX Companion”– Have created systems which work without me– Practical adviser for design and implementation

of enterprise solutions

About me (1)


www.samarin.biz

• Current specialisation is improving business process management systems– effectiveness (“Do the right things”)– efficiency (“Do the things right”)

• Knowledge how to use together the following technologies: – BPM, SOA, EA, ECM and IT governance

About me (2)


www.samarin.biz

Pattern DBLDecoupled Business Logic


www.samarin.biz

Anti-Pattern PRFProcess Realisation Faked


www.samarin.biz


• The purpose – to analyse a building block from within to

determine its internal structure and its major artefacts

• The method– determine the main functional (or logical) steps– classify artefacts for these steps– add check-points between steps

• Recommendations– don’t have more than 7 steps– avoid loop-back over check-points


www.samarin.biz

Re-construction phase (1)

• The purpose – to synthesize an initial version of the formal

coordination: some kind of process skeleton

• The method– add intra-step logic– start formalising the business objects involved– collect test scenarios

• Recommendations– consider implementation of human activities as

interactive forms


www.samarin.biz

Instrumentation phase (1)

• The purpose – to enrich the process skeleton by adding more

automated activities

• The method– add pools– apply different practical patterns– use a business rule engine if available– collect test scenarios

• Recommendations– work iteratively (step-by-step)


www.samarin.biz

An architectural framework for improving BPM systems

• A comprehensive set of recommendations, models, patterns and examples of how to transform existing disparate IT systems into a coherent, agile and flexible BPM/SOA solution

• Documented in soon-to-be-published book www.improving-BPM-systems.com

• Further slides are examples of what this framework brings to different stakeholders


how to simplify the evolution of business process lifecycles

Technology

business activity

business world

bpm artefacts

bpm systems definition

bpm view

atomic artefacts

improvement of artefacts

principal artefacts