bpm essentials with open source

8/6/2019 BPM Essentials With Open Source

1/45

Copyright 2006 GLiNTECH. All Rights Reserved Privacy Policy

Business Process Management

Essentials

Illustrated using Open Source Technologies

Tanguy [email protected]


2/45

White Paper Page 2 Business Process Management Essentials

Contributions

Dimitri Spyridopoulos GLiNTECH Sydney, Australia

John Spyridopoulos GLiNTECH Sydney, Australia

Jim Alateras Independent Consultant Melbourne, Australia

Jacques-Alexandre Gerber Intalio Redwood City, CA, USA

Arnaud Blandin Intalio Redwood City, CA, USA

Ismael Ghalimi Intalio Redwood City, CA, USA

Paolo Pelizzoli TIBCO New York, USA

Jean-Jacques Dubray Independent consultant Chicago, USA

Ben Barghava BEA San Francisco, CA, USA

Philippe Bournhonesque IBM Paris, France


3/45


Table of Contents

CONTRIBUTIONS ..............................................................................................................................................2

TABLE OF CONTENTS .....................................................................................................................................3

INTRODUCTION ................................................................................................................................................5

BACKGROUND ON BUSINESS PROCESS MANAGEMENT .............. ............ ............. .............. ............. ... 6

DEFINITION .........................................................................................................................................................6OBJECTIVE:ALIGNING BUSINESS AND ITMETHODOLOGIES WITH THE BUSINESS PROCESS LIFE CYCLE ............ 7

Business Process Life Cycle ............ .............. .............. ............. ............ .............. ............. .............. ......... 7 BPMs Objectives ............ ............ .............. ............. .............. ............ .............. ............. ............ .............. . 8

THE REALITY OF BUSINESS PROCESS MANAGEMENT SYSTEMS TODAY ..............................................................8

BUSINESS PROCESS MANAGEMENT STANDARDS ............ .............. ............ ............. .............. ............. . 10

THE STANDARD BODIES ....................................................................................................................................10THE BIG PICTURE ..............................................................................................................................................12THE NEED FOR A STANDARD NOTATION ...........................................................................................................12BPMN, THE BUSINESS PROCESS MODELING NOTATION ................................................................................... 13

Introduction to BPMN ............. .............. ............. ............. ............. .............. ............. ............ .............. ... 13

Limitations of BPMN ............................................................................................................................15 XPDL OR XMI AS A PROCESS INTERCHANGE FORMAT .....................................................................................16BPEL, THE BUSINESS PROCESS EXECUTION LANGUAGE................................................................................... 16USER INTERACTION WITH A PROCESS................................................................................................................18

BPEL4People May Add Workflow Capabilities to BPEL............. .............. ............. ............ .............. ... 18STATE OF THE ART.............................................................................................................................................18

THE BUSINESS PROCESS MANAGEMENT SYSTEM....... ............ .............. ............. .............. ............ ...... 20

ANATOMY OF A BPMS...................................................................................................................................... 20

Process Design .............. ............. ............ .............. ............. .............. ............ ............. .............. .............. 20 Process Simulation ............ ............. .............. ............. ............ .............. ............. .............. ............ .......... 21

Process Packaging and Deployment ............ ............. ............ .............. ............. .............. ............ .......... 21

Process Execution....... ............. .............. ............. ............. ............. .............. ............. ............ .............. ... 22

Process Monitoring ............. ............ .............. ............. .............. ............ .............. ............. .............. ....... 23OPEN SOURCE BPMS........................................................................................................................................23

JBoss jBPM...... .............. ............. ............ .............. ............. .............. ............ ............. .............. .............. 23 ActiveEndpoints ActiveBPEL.............. .............. ............. ............ .............. ............. .............. ............ ...... 24 Intalio / Apache ODE. ............. .............. ............. ............. ............. .............. ............. ............ .............. ... 25

RELATIONSHIP WITH SERVICE-ORIENTED ARCHITECTURE......... .............. ............. .............. ....... 27

FROM ADAPTERS TO SERVICES..........................................................................................................................27SOASTANDARDS..............................................................................................................................................28

Web Services.... .............. ............. ............ .............. ............. .............. ............ ............. .............. ............. . 28 JBI Java Business Integration ............ ............. ............. ............. .............. ............. ............ .............. ... 28 SCA Service Component Architecture ............. ............. ............. .............. ............. ............ .............. ... 28

BPM AND SOA:PARADIGM SHIFT ....................................................................................................................29

GETTING STARTED WITH BUSINESS PROCESS MANAGEMENT............... ............. ............ ............. 31

THINK BIG,START SMALL.................................................................................................................................31SET UP A BPMTEAM.........................................................................................................................................31

Identify Process Designers ............. .............. ............. ............ .............. ............. ............ .............. .......... 31

Create a BPM Competency Centre.. .............. .............. ............. ............ .............. ............. .............. ....... 32CHOOSE A TECHNOLOGY STACK ....................................................................................................................... 32SELECT YOUR MODELING APPROACH ...............................................................................................................33

Bottom-up Approach.......... ............. .............. ............. ............ .............. ............. .............. ............ .......... 33

Top-down Approach ............ ............ .............. .............. ............. ............ .............. ............. .............. ....... 34

Meet in the middle ............. ............. .............. ............. ............ .............. ............. ............ .............. .......... 34

ILLUSTRATION: CREATING A TIMESHEET APPROVAL PROCESS.... ............. .............. ............ ...... 35


4/45


5/45


Introduction

Business Process Management (BPM) is not a new concept Business Process

Reengineering, a management approach that attempts to improve the efficiency of the

underlying business processes within a business, was a hot topic in the 1990s1.

However, with the emergence of new standards and tools to accelerate time-to-market

for new business ideas, BPM made a comeback around 2001. The principle of BPM is to

provide business and technical users with a common framework to model, implement,

deploy, execute, measure and improve business processes. Since 2001, a number of

start-ups have attempted to address this problem2. BPMs visibility peaked in 2003-

20043, but since then its popularity waned for various reasons; the value of the

technology was oversold, products failed to deliver what was promised, and many

vendors were using the BPM acronym to sell unrelated products4. BPM was in most cases

either marketing vaporware or a re-branding of EAI and workflow technologies. A market

consolidation followed, and the smaller players were absorbed or removed by IBM,

Microsoft, Oracle, and SAP. Open Source vendors emerged as well, namely JBoss,

ActiveEndpoints and Intalio. Five years later the tools are now more stable, there is a

clearer view of standards, and we believe the market is ready to absorb this technology.

Figure 1 - BPM in the "Hype curve"

The objective of this document is to provide an overview of BPM technologies, illustrated

using Open Source. It is targeted at a technical audience, and covers the concepts and

methodologies of BPM, the link with existing technologies (Web Services, SOA) and the

implications of introducing a BPM system.

After introducing the objectives of BPM, a description of the standards will be explored,

followed by an illustration of the concepts by creating a simplistic timesheet approval

process using an open source BPMS. Finally, a methodology to approach BPM will be

outlined, and the paper will conclude with BPMs value proposition.

1http://www.prosci.com/reengineering.htm 2 Collaxa acquired by Oracle, Fuego acquired by BEA, etc.3 BPMN released by BPMI.org, BPEL endorsed by OASIS, etc.4 BPM 2.0, by Ismael Ghalimi, http://www.prosci.com/reengineering.htm


6/45


Background on Business Process Management

Definition

Many definitions exist for Business Process Management (BPM), which creates confusion

in the marketplace. According to Ismael Ghalimi, BPM visionary and founder of Intalio,

Today, the BPM moniker is used to describe anything from legacy workflow products,

business rule engines, flowchart diagramming tools, Java code generators, or even

business process reengineering consultancy services5. In this document, definitions will

be based on documents provided by the Business Process Management Initiative6.

A Business Process is a set of coordinated tasks, achieved by humans or systems,

whose objective is to achieve a particular business goal. A business process can be

modeled, and measured. Order management, resource management, internal

procurement, and employee leave management are examples of business processes that

companies may utilise. An Executable Business Process is a business process whose

tasks can be orchestrated with a software platform, using a combination of automated

systems tasks (e.g. looking up customer information in a relational database, sending an

order to a partner through a B2B gateway) and user tasks (e.g. users approving a

timesheet, users starting a process from a form, users managing a process, etc.).

Making a process executable does not mean automating it: most business processes

usually consist of tasks executed by systems, and tasks achieved by individuals.

Business Process Management Systems are software suites that provide business

analysts and IT with a systematic ability to model, implement, deploy, execute, monitor

and improve executable business processes. Currently, almost every software vendorclaims to provide a Business Process Management suite, when in reality they provide one

or a combination of the following:

Enterprise Application Integration (EAI) software

Human workflow software

Web Services orchestration platforms

Portals

Business Activity Monitoring dashboards

Business Process Modeling tools

An ideal business process management system provides all of the above, and more, in

an integrated platform. This is a challenge, especially for vendors with a legacy of

applications. It took IBM approximately three years to release WebSphere Process

Server, which is an implementation of their BPM and SOA strategy. Before this product,

IBM provided multiple platforms, each one addressing a specific area (human workflow,

5 BPM 2.0, http://itredux.com/blog/bpm-20/ 6www.bpmi.org, merged with the OMG, Object Management Group, www.omg.org


7/45


8/45


and the deployment time grows exponentially based on the number of people and

systems involved.

BPMs Objectives

BPMs first objective is to enable business users to drive the implementation of

processes, and to provide them with visibility upon their execution. To quote Phil Gilbert,CEO of Lombardi7, Business process management is about CHANGE and VISIBILITY. []

It's not about execution per se. It's not about modeling per se. It is about making your

business better by changing it as fast as it needs changing, based on the measured

results of previous changes.

This is achieved in the following ways:

Provide a common framework for a process designer to be able to

communicate with 2 worlds: business and IT.

Accelerate delivery with visual programming: visual programming has and

will always have limitations, however it answers the 80/20 rule, and provides a

systematic approach to solving common problems: invoking a service, asking a

user to approve a form, following a process end to end, etc.

Keep the specifications and the code in sync: the main value proposition of

BPM is to enable continuous process improvement. Even if it takes the same time

to implement a specific process using code or a BPM diagram, the difference is

striking when this process needs to be changed. The main reason is that the

implementation of a process and its specification lie in the same diagram. It is

therefore possible to update a process with a linear cost.

Provide business users with dashboards: dashboards enable business users

to measure their processes and identify the necessary changes, as well as to

analyse the impact of a previous change.

Furthermore, BPM should enforce reusability and governance. Howard Smith, CTO of

CSC, recently described the future of BPM as Building new processes, composite

applications, end to end integrations, sophisticated processes like Procure-to-Pay, that

takes complex process and complex reuse (as process) of existing systems, like ERP,

Procurement apps etc. A BPMS can expose all those processes, via inspection and

projection, and they can be re-purposed to create new processes. Its reuse on steroids,

something the object movement did not achieve other than for fine-grained OO-

programming models.8

The Reality of Business Process Management SystemsToday

7http://blog.lombardicto.com/8http://www.itredux.com


9/45


Today, it is possible to reduce time-to-market and ease continuous process improvement

using a combination of business process management and Service-Oriented Architecture

(SOA) platforms.

Business Process Management Systems (BPMS), coupled with SOA platforms, are

perhaps the next generation integration and workflow platforms, providing a new

method of collaborative development for business and IT. They support long running

processes and transactions, and do not require the same maintenance as the monolithic

EAI and human workflow platforms.

The paradigm shift is derived from including business users in the design and validation

phases, which enables a combination of bottom-up (leveraging IT services) and top-

down (driving IT development from the business) approaches.

However, BPM is still dedicated to early adopters, and enforces the usage of Web

Services as the main integration paradigm. Most BPMS are not adapted to high volume

transactional environments; they focus on the low volume, long running business

transactions.

Finally, BPM platforms are rarely integrated to Business Activity Monitoring tools.

Therefore, BPM lacks substance for the actual management of processes, e.g. the

possibility to monitor KPI on existing processes within an organisation.


10/45

White Paper Page 10 Business Process ManagementEssentials

Business Process Management Standards

Business process management is a domain where the standardisation activity is

flourishing. BPM standards were created by the same individuals who launched the SOA

phenomenon. Therefore, they are linked to Web Services in many ways, which may

create some confusion when targeting the business audience. This concern will be

addressed later in the document. The standards will be examined below.

The Standard Bodies

The W3C (World Wide Web Consortium) is historically the standards body in charge

of the ratification of standards for technologies created within the Internet era. For

example, this organisation maintains HTTP, CSS, XML, and SOAP (the most popular

standard for Web Services). However, the W3C is not involved in the BPM standards.

Firstly, it could not keep up with the pressure of big software vendors constantly pushing

new specifications on the market; and secondly, it applies a standard Intellectual

Property Rights policy for all technical committees, which did not suit the big vendors

creating the innovations.

In order to accelerate the technologies adoption and to solve any issue around

intellectual property, software vendors created their own organisation: WS-I, the Web

Services Interoperability group. WS-I did not provide standards, but rather a set of

profiles and recommendations to promote the development of interoperable Web

Services across the numerous software platforms in that space.

Although WS-I helped rationalise the Web Services phenomenon, it is not appropriate to

let vendors ratify their own standards. In particular, IBM, BEA and Microsoft created a

big cloud around the WS-* Specifications (specifications addressing specific concerns:

security with WS-Security, transactions with WS-Transaction, etc.). Vendors were

competing on standards to make sure that they were the first ones to provide the tools

that support them. Standards based solutions became a selling strategy, whereby the

bigger vendors won; specifications usually became de-facto standards when IBM and

Microsoft shared their efforts.

In parallel, a consortium of industry experts created the Business Process

Management Initiative (BPMI.org). The BPMI produced two specifications: BPML, the

Business Process Modeling Language, a process execution language that was later

dropped and replaced by BPEL, the Business Process Execution Language (created

by IBM and Microsoft); and BPMN, the Business Process Modeling Notation, a

graphical notation enabling business analysts and IT developers to collaborate in the

modeling and design of executable business processes.


11/45


Figure 3 - BPM Specifications Focus (source: BPMI.org)

It was necessary to find standards organisations to maintain the more mature

specifications, to ensure that they could be stabilised outside of the vendors quarter-based strategy. That is where OASIS, the Organization for the Advancement of

Structured Information Standards, and the OMG, Object Management Group,

came into action. OASIS has a faster adoption cycle than the W3C, and is more flexible

in defining different levels of intellectual property rights for technical committees. OASIS

accepted a number of Web Services specifications, including BPEL, which is now the de-

facto standard for business process execution. As for the modeling part, BPMN competed

with UML (maintained by the OMG) on several aspects. The OMG worked on a UML

notation dedicated to business process management that was supposed to be released

with UML 2.0. Finally, the OMG and BPMI.org merged their efforts; BPMN is now the de-

facto standard notation for the modeling of executable business processes.

A final question to be addressed includes how to store a BPMN diagram(s) in a format

that can be exchanged between modeling tools. This is where the WfMC Workflow

Management Coalition comes into play. The WfMC defined a specification called

XPDL, the XML Process Definition Language, which addresses this concern.

W3C WS-I

(Vendors)

OMG

(BPMI.org)

OASIS WfMC

XML X

Web ServicesBasic specifications

X X(not owner)

Web Services

Advanced specifications

X

(not owner)

X

BPMNProcess notation

X

XPDLProcess interchange

X

BPELProcess execution

X


12/45


It is important to examine what these specifications provide, for process design,

interchange and execution. SOA standards and its relationship with BPM will be

addressed later in the document.

The Big Picture

BPMN is the standard notation shared by tools to represent a process visually

XPDL should become BPMNs wire format for process model interchange between

process modelers

BPEL is the XML runtime representation of a process

There is no standard for the integration of user interaction with a process

Figure 4 - BPMN/XPDL-XMI/BPEL

The Need for a Standard NotationUntil recently, every business process modeling tool provided its own graphical notation,

with different perspectives for business and technical users. In addition, most companies

created their own custom graphical notation, based on their internal methodology. Below

are some examples:


13/45


Figure 5 IDS-Scheer Aris Figure 6 - Custom Methodology

Figure 7 - Custom Methodology

To bridge the gap between business and IT, it is necessary to provide a model for both

profiles to collaborate in the definition of executable business processes. First, it enables

the exchange of process models between tools: ideally, we should be able to model a

process in Visio, import it in a technical process modeling tool to map it to technical

systems, and to consult this process back in Visio along the way. Secondly, it is then

possible to define a mapping between the standard notation and an execution language.

If this notation is complete, we should be able to add all the technical information

necessary to make the process executable, and to deploy it as is on a process server.

BPMN, the Business Process Modeling Notation

Introduction to BPMN

BPMN is a partial answer to these concerns. The specification provides a standard

modeling notation for executable business processes, and a mapping to BPEL, the

execution language. BPMN uses the following concepts:

A process is composed of activities, also called tasks

Activities can be in sequence, in parallel, or connected through gateways (AND,

OR, etc.)

A process has several participants, each modeled in a swimlane. For example,

in a timesheet approval process, you can have the following participants:

o A timesheet system: system participant

o A billing application: system participant


14/45


o A manager, that approves / rejects timesheets: human participant

o Another process, managed by the HR department

Participants collaborate via the exchange of messages

Here is an example of a BPMN diagram:

Figure 8 - Sample BPMN Process Diagram

In addition to a notation, BPMN defines attributes for each artifact proposed by the

specification. For example, the Task artifact supports the following attributes:

TaskType: Service, Receive, Send, User, Script, etc. In other words, is this task

sending a message, receiving a message, assigning a task to a user?

In case the TaskType is Service:

o InMessage: name of the received message

o OutMessage: name of the message to send

o Implementation: Web Service, other.

Etc.

These attributes are filled by technical people based on a process diagram described by a

business analyst. They are used to generate the BPEL skeleton for the process to

implement. BPMN supports all artifacts that are needed for procedural programming,

including some event based concepts.

System participant

Process participant

Human participant

TaskTransition

Message

GatewayEvent


15/45


Scope of the BPMN specification

Create high levelBPMN process

model

Augment BPMN

diagram withtechnical activities

Augment BPMN

diagram withtechnical attributes

BPMN diagramBPEL

Business Analyst

IT

IT

BPM designer

Improve

Deploy BPEL BPM designerBPM server

Run BPEL BPM server

Figure 9 - Scope of BPMN

In order for the notation to be complete, the creators of BPMN specified a way to model

activities that occur in case of an exception in the process a fault handler is assigned to

a group of activities to try to recover from the error, as well as compensating activities9.

Limitations of BPMN

The BPMN specification provides a model for business analysts and IT to collaborate;

however it suffers from two main limitations:

First, it does not provide a complete technical model. Specifically, it is not possible

to describe the data manipulated by the process, the data transformations, the KPI to

monitor for each activity, etc. We are likely to see the OMG complementing BPMN with

UML diagrams to address this concern. For the moment, this is left to the discretion of

BPMS designers.

9There is a complex theory behind BPM transactions that is out of the scope of this paper. To sum up, a group of activities are

either part of a short running transaction, or a long running one. The short running transactions are the traditional ones (XA), forexample inserting 2 elements in a database. In case the process fails, the rollback is automatic. The long running transactionsare for activities that can last longer (hours, days, months), for example assigning a task to a user, for which it is not possible toexecute a rollback. The process designer needs to specify which activity to execute in case the process failed and could notresume for example removing the task from the users task list.


16/45


Secondly, BPMN only specifies a notation; it does not provide a wire (interchange)

format. Therefore, it is not possible to export a BPMN diagram from a tool and import it

into another one in a standardised manner. This is a serious limitation, as the scope of

BPM is so big that no tool will be able to provide all required functions; several tools

need to collaborate on the same process model. Some tools are specialised in process

modeling for business analysts, others in process simulation, others in technical process

modeling (adding technical information to call a Web Service, etc.). This will only be

possible if BPMN provides a standard interchange format. This could potentially be a job

for XMI (XML meta-data interchange) or XPDL (XML Process Definition Language).

XPDL or XMI as a Process Interchange Format

Figure 10 - Process Interchange Format

This is where XPDL could be applied. XPDL is a process design format based on XML, and

contains extensions in order to be able to represent all aspects of BPMN10. Basically, a

process can be designed in a modeling tool using the BPMN notation, then be exported in

the XPDL format (XML document), and opened with another tool, for example a process

simulation tool, with exactly the same layout.

Another candidate specification, which is more likely to succeed as it is maintained by

the OMG, is XMI, the XML Metadata Interchange specification.

At the time of writing, this work was still exploratory; however, there are a few tools on

the market that support the combination BPMN-XPDL/XMI. The OMG needs to focus on a

standard mapping BPMNXPDL, or BPMNXMI, as they did for the execution language.

BPEL, the Business Process Execution Language

Once the process is modeled, it is deployed and executed on an engine. BPEL is the

XML format that describes a business process for a runtime environment. ABPEL document, along with documents describing the services that are invoked in this

process, is supposed to be self-sufficient for an engine to execute a process.

BPEL is a simple concept; unless you try to write a BPEL document by hand. A BPEL

process is a combination of:

Receive: receive a message from a partner


17/45


Reply: reply to a partner based on a previous receive activity

Invoke: invoke an external service provided by a partner

Send: send a message to a partner

Assign: execute a data transformation

Those activities can be orchestrated through process constructs: while, for-each.

Activities can occur in sequence, or in parallel and events can suspend a process

execution branch to take another path. BPEL provides an exception handling mechanism,

and a way to specify transaction boundaries and compensating activities. BPEL is not

meant to be human readable, it is an execution format.

As BPEL addresses both short and long running processes, it supports message

correlation. For example, if you have 50 processes running that are waiting for a

document on a JMS queue, and a message arrives on this queue, you need to route this

document to the appropriate process instance. This is usually done by looking at the

message payload, retrieving an ID or a combination of attributes, and mapping it with

the process data. Correlation is a missing piece in many traditional EAI tools, which do

not normally support long running processes the process context needs to be persisted

and retrieved manually when the next message arrives.

BPEL Document

Service

Process

interface

Service

partner

Service

partner

Application

partner

Service

partner

Figure 11 - BPEL Process

An important note is that BPEL only orchestrates services described using WSDL, the

Web Service Definition Language, and is accessed as a service described using the same

language. This means that a BPEL process is a Web Service that orchestrates other Web

Services. However, several initiatives extend WSDL to support the definition of other

types of services11: a java POJO, a database stored procedure, a JBI component, etc. For

the moment, the only bindings supported by WSDL are SOAP over HTTP and SOAP

over JMS (SOAP being the message format for a Web Service message). Should other

bindings be defined for other technologies, BPEL could be used to orchestrate any

10The BPMN-XPDL-BPEL value chain - http://kswenson.wordpress.com/2006/05/26/bpmn-xpdl-and-bpel/ 11

WSIF Web Services Invocation Framework - http://ws.apache.org/wsif/


18/45


service - databases, legacy applications, and java classes. At present, these services

need to be wrapped in a Web Service.

The advantage of BPEL is that you should not care about BPEL. A business

process that you model using BPMN has multiple participants, and might require multiple

BPEL processes to be generated. The tools should take care of that for you.

However, BPEL has an important limitation; it does not support constructs to enable

users to interact with a process (user starting a process from a form, process assigning a

workflow task, user managing a process). The only artifacts that a BPEL process

orchestrates are services. This limitation is addressed below.

User Interaction with a Process

BPEL4People May Add Workflow Capabilities to BPEL

There is no standard for the integration of user tasks in a BPEL process. Most vendors

hook the user interface and the workflow components through Web Services, each in

their own way, which means you are stuck with a vendor if you start using their user

interaction components.

IBM and SAP proposed an approach in a co-released whitepaper in July 2005 WS-BPEL

Extension for People BPEL4People. They identified the following use cases for user

interactions with a BPEL process:

A process assigns a task to a user: approval, confirmation, etc. In that case, it

must be possible to delegate, reassign, and expire a task. Administrators should

be able to modify task permissions, nominate a user for the execution of a task,etc.

A user starts a process through a form

Users manage long running processes: add missing data, etc.

A task performed by a user can be switched to a service, and vice versa

(an application is down, but a person can provide the relevant information)

In addition, these strategies need to be integrated with policy systems.

Finally, there is a lot of work to be done before there is an agreed upon standard for this

area. Perhaps OASIS will take action and provide recommendations.

State of the art

After an evaluation of the available tools in the marketplace, GLiNTECH reached the

following conclusions:


19/45


BPMN was adopted by most business process modeling tools: IDS-Scheer, MEGA,

Popkin, Rational, Microsoft (Visio) provide a BPMN diagram. It is still too early to

state if XPDL, XMI, or another solution will be provided by the OMG as BPMNs

wire format.

BPEL was adopted by almost all process execution platforms: commercial vendors

included IBM with WebSphere Process Server, Microsoft with Biztalk, Oracle with

Collaxa, SAP with Netweaver XI, etc.; and in the open source space Intalio, JBoss

jBPM, and ActiveEndpoints ActiveBPEL.

However, most tools require a conversion from BPEL to an internal format before

deployment. Therefore, the migration of BPEL code from one vendor to another is

not yet possible. In addition, there are several versions of BPEL: BPEL4WS

provided by Microsoft and IBM, called BPEL 1.1; WS-BPEL provided by OASIS,

called BPEL 2.0.

There is no standard approach for user interaction with a business process.

In summary, standards are still in a very early stage of formation. However, the

situation has improved considerably in the past three years, when companies and

standards organisations were in the middle of political battles to push their own standard

for every level of the stack. A significant number of specifications were left dead: BPML

from BPMI.org, XLang from Microsoft, WSFL from IBM, WSCI from Intalio to name a few.


20/45


The Business Process Management System

Anatomy of a BPMS

This section is a conceptual overview (blueprint) of a complete business process

management system. It is highly unlikely that in the near future all features will be

provided by a single vendor, but the draft standards should guarantee that the tools can

be integrated to cover the full BPM life cycle.

The open source BPMS GLiNTECH selected provides a subset of these features. The

details of evaluating each tool is beyond the scope of this paper, however, this

framework will be used to compare at a high level the various BPM tools.

Process Design

BPMN process layout: the need for BPMN has already been highlighted. Most

high level business process modeling tools, such as Visio, IDS-Scheer Aris, MEGA

or Popkin chose to provide a BPMN diagram. This notation should be the basis for

a BPMS.

Service discovery: most BPM designers are able to introspect service definitions

(WSDL files), render the operations available, and enable their use in a process

model via drag and drop. They also introspect the services operations, input and

output schemas for data manipulation. Ideally, the user should be able to retrieve

service definitions from a directory (UDDI) or an inspection (WSIL) document.

Forms design: a user can interact with a process in several ways. The two most

common cases are: a user instantiates a process using a user interface form, and

a process assigns a task to a user with a particular role approval. The form

specification is part of the business process definition.

Process reusability: a BPEL process orchestrates Web Services. It can then be

exposed as a service, and invoked from an application, or another process. The

BPM solution should generate a WSDL interface for the process. Ideally, it should

also connect to a service directory to publish and advertise the new service

provided.

Business rules definition: a business process has decision points. Some

decisions can be made using user approval forms, such as a customer who needs

to manually approve a timesheet for billable purposes (checking hours, sick days

and leave). Others can be defined and deployed as part of the business process:

for example if an incoming trade confirmation is received that matches a trade,

and a trade cancellation is received at the same time, an alert needs to be raised.

(tradeconfirm.tradeID = trade.tradeID) && (tradecancel.tradeID = trade.tradeID)

is a rule that should be expressed by a business user and translated by a

technical user.


21/45


Data mapping: a business process manipulates data data from services, data

provided by back-end systems and data provided by users through forms. The

business process modeling tool should enable data manipulation.

KPI design: a process is measured based on KPI. Some are instance specific

(each credit check process should not take more than 1 day), and some are

based on a business process class (on average credit checks should not exceed 4

hours). A BPM designer should enable the definition of a process KPIs, as it is part

of the process specification.

Process versioning: there are several versioning levels for a business process.

A process relies on assets, such as application interfaces, user forms, other

processes, message schemas, KPIs, and business rules. These assets versions

need to be synchronised.

Process Simulation

A BPM designer should enable business analysts and IT to run simulations of the

processes, in other words to execute the processes without connecting to the actual

back-end applications, or expecting user inputs. The simulation data should either be

provided by the user that executes the tests, or come from historical data. For example

if you ran a credit approval process for a few months and wanted to change it, you might

want to simulate it based on the data accumulated and see what outcomes occurred.

Two types of simulation can be distinguished:

Technical simulation: execute a process without connecting to the back-end

applications, or isolating a few applications to test. For example, if you introduce

a new application in your process, you might want to validate connectivity andbehavior for this application only, simulating the rest of the process. These tests

focus on technical criteria connectivity, response time, data transformations,

exceptions and transactions.

Business user simulation: execute a set of processes against simulation data

and analyse impact of a change. For example, if a new human workflow approval

step is introduced in a process, what is the impact in terms of response time to

the targeted customer? Business analysts might also want to check completeness

of all process paths, using any combination of possibilities.

Process Packaging and Deployment

Deployment is usually the bottleneck of new tools. Most tools on the market allow

deployment to one server, but do not support realistic deployment scenarios:

Support for process packaging: the deployment bundle should contain the

process, as well as its assets, such as forms and BAM screens.


22/45


Support for different user roles: in most companies, packaging and

deployment is done by users from different organisations.

Support for multi-city environments

Support for project environments and migrations: development, unit test,

integrated test, user acceptance and production.

The challenge is not to move along the code itself, but the entire configuration that

comes with it (the endpoint for services are different for each city and environment).

Business process deployment is more challenging than integration deployments, in the

sense that a process can run for a long period of time. If a new version needs to be

deployed, what is the impact on processes in execution?

Process Execution

We are listing here the basic features that a BPMS engine (combination of a BPEL engine

and a user interaction engine) should propose:

BPEL support: the process server should accept BPEL as a process definition.

The BPEL document may be compiled in an engine native format afterwards.

Scalability: it is not as important to have a highly transactional server as it is to

have one that can scale by adding more resources (e.g. memory and CPUs), and

more servers via load balancing. Some servers provide a combination of load

balancing and fault tolerant services to have multiple engines run in parallel in a

cluster.

Fault tolerance: fault tolerance is required on the server level. It can be

achieved using:

o Cold failover: a secondary server starts when the primary server goes

down

o Warm failover; a secondary server is started but not processing, and is

activated when the primary server goes down

o Hot failover: a secondary server is started, processing in parallel, but not

sending any message, it activates when the primary server goes down.

Exception management: at the process level, the engine must support fault

tolerance on service invocation, and execute user defined fault handlers.

Transaction handling: the engine should contain or work with an external

transaction processing monitor, that supports both short running and long

running (compensation-based) transactions.


23/45


System connectivity: at a minimum, a BPM engine should support Web

Services connectivity through SOAP/HTTP. It is possible to use an external

adapter framework to connect to the systems (expose their functions as Web

Services); however there is a significant impact in terms of performance,

transaction support and security. For this reason, a combination of BPMS with an

SOA product (for example an ESB - Enterprise Service Bus) and a messaging

system is used.

Integration with a user interaction engine: the engine should be natively

integrated with a user interaction engine, enabling the user to start processes or

to capture interaction through forms, monitor process execution, and modify

process data / interact with the process execution.

Audit trail:the engine should support a configurable audit trail to debug process

execution, and aggregate technical KPIs.

Process Monitoring

Process console: the console should enable users with different roles to access

information about running processes, and query process data. The console is a

tool dedicated to process administrators.

Process query API (Application Process Interface): the process engine

should provide an API to query process data for historical and real time analysis.

Business Activity Monitoring Dashboard (BAM): the BPMS should provide, or

be integrated with a dashboard, which enables measurement of process

performance, and enables business users to identify bottlenecks.

Open Source BPMSIf you search Open Source Workflow in Google, you will find numerous open source

frameworks that provide either human workflow capabilities, or integration features but

most of them are incomplete. GLiNTECH ran a selection and identified three leading

tools: jBPM from JBoss, ActiveBPEL from ActiveEndpoints, and Intalio/Apache ODE.

All three provide a designer based on Eclipse, a BPEL server, and a console. JBoss is

the only tool offering a complete open source framework. ActiveEndpoints and Intalio

provide an open source version of their tool, and an enterprise edition that supports

more complex features and deployment capabilities. The donation of their open source

code base to a strong community would guarantee the longevity of the tools and the

projects that rely on them. Intalio took this approach and partnered with Apache (for the

moment only with the server).

JBoss jBPM

jBPM was created a number of years ago by JBoss as a designer and an engine

supporting a proprietary runtime language (jPDL), which required heavy coding.


24/45


Recently, JBoss added BPEL support but only for the server, the designer only generates

jPDL.

Figure 12 - jBPM Designer

If JBoss is the desired tool, use the designer, JPDL and Java coding. The BPEL engine is

at a very early stage and is not integrated with a design environment. jBPM was not

selected for this document as the focus is on products that rely on standards. However,

it is worth mentioning as JBoss maintains a powerful presence in the open source space,

and could potentially contribute significantly to the field.

ActiveEndpoints ActiveBPEL

ActiveEndpoints provides an open source BPEL server, and a free BPEL Designer (not

open source). The designer is not BPMN compliant, and provides more of a BPEL coding

assistant. A deep understanding of BPEL is required to use this tool. It is limited to Web

Services orchestration, and does not provide integration with user actions.


25/45


Figure 13 - ActiveBPEL Designer

Some positive features of the designer are the stability and the ability to execute a

simple process simulation. The designer and server support fault handling and

compensating transactions. It should not take more than a day to be able to create,

deploy and monitor your first BPEL process with a few Web Services calls and error

handling.

This product is for technical audiences only; a business analyst would not find his way to

model a business process. If all that is required is a Web Services orchestration platform,

this is most likely the simplest choice.

Intalio / Apache ODE.

ODE is an incubation project in Apache that was created after the donation of the code

base from Sybase. Recently, Intalio, a commercial BPMS vendor, proposed to donate

PXE, its BPEL engine to Apache. In parallel, Intalio maintains a community edition of the

designer and the server, as well as an enterprise edition with more complex features

(the community edition works with Geronimo and MySQL only).

The Intalio platform is the most ambitious open source project for BPM at the moment:

BPMN Designer, upcoming integration with UML, with a visual data mapper

BPEL Server: Intalio acquired FiveSight, and therefore their BPEL PXE engine

Human workflow engine, written in BPEL

User interface framework based on XForms/AJAX (the presentation layer relies on

the open source Orbeon framework) for the creation of user screens: initiate a

process, user task assignment


26/45


XForms Designer is also integrated in Eclipse, which generates the code and

configuration to integrate with the workflow engine

Figure 14 - Intalio Designer

With introductory BPMN training it should be easy for a business analyst to draw a

process using the designer. From a technical aspect, the learning curve is quite steep

and training is highly recommended. The execution is also in its infancy and debugging a

process is not an easy task.

However, this is definitely the most promising open source product available at the

moment. At GLiNTECH we are following them very closely and will continue testing

updates to the platform internally.


27/45


Relationship with Service-Oriented Architecture

BPM standards and platforms fail to address one concern - how to expose services from

an existing application in order to be able to include it as a system participant in a

process. This is where SOA concepts and platforms need to be addressed. The

philosophical aspects of SOA will be avoided so as to focus on what the existing tools

were designed for - creating and operating services.

From Adapters to Services

Legacy EAI tools were using adapters to connect to external systems. Each vendor

provided its own adapter framework, concepts and runtime, which made them difficult to

reuse. Moreover, an adapter is a low level technical concept.

Services provide an abstraction layer on top of adapters, and address a broader problem

- how to expose functionality of a software piece, whether it is an adapter, a process or a

database stored procedure.

The following definition will be used for a service: a service is a component, with an

interface, an implementation, external references (a service might depend on external

services), and a set of configuration properties.

Figure 15 Service, as described in the SCA Specification12

SOA platforms enable the management of services throughout their life cycle, and are

not limited to Web Services. SOA standards address the problem through three different

angles:

Accessing a service: Web Services specifications

Providing a service runtime environment: JBI Java Business Integration

Describing systems composed of services: SCA Service Component Architecture

12SCA, JBI and morehttp://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html


28/45


SOA Standards

Web Services

A Web Service basically provides operations described in an interface specification

(WSDL Web Service Definition Language), that are invoked using the exchange of XML

messages (SOAP Simple Object Access Protocol). Web Services specifications do not

define how a Web Service is implemented, but all the aspects necessary to communicate

with it, including security (WS-Security) and reliability of the communication (WS-

ReliableMessaging).

The main advantages of Web Services are:

Their adoption: more or less all software vendors adopted them and it is possible

to invoke and provide services from any platform (e.g. .Net, Java)

The conceptual simplicity of the frameworks

However, it does not mean that Web Services answer all integration questions. Their

inherent simplicity actually masks larger problems, such as how to model the interaction

between services, how to manage version upgrades and how to operate a service.

JBI Java Business Integration

The striking element, when looking at the profusion of Web Services and BPEL runtime

environments, is that they are all using different approaches to host and manage

services throughout their lifecycle. In the Java world, they all attempt to run on top of an

application server (some on top of the JVM, providing their own runtime), but each with

different design choices, and different packaging models. Therefore, a service developed

with Apache Axis cannot be deployed to another Web Service platform.

JBI is a Java specification (JSR 208) that defines an environment, a packaging model,

and the communication between components. In other words, JBI is a specification that

extends application servers to enable them to host components (services, processes),

which can be accessed in a standard way.

Intalios BPEL engine, for example, can be deployed as a JBI component in an application

server.

SCA Service Component Architecture

The Service Component Architecture specification (SCA) was proposed by IBM, Oracle,

and SAP. It is probably the first real answer to the constraints of SOA: how to operate

systems composed of multiple services that interact with each other, and run on

different platforms? What is the impact of a change on the overall infrastructure?


29/45


Figure 16 - SCA Module13

SCA enables the modeling of applications built using the composition of components.

SCA provides a model that enables IT to design each individual service, as well as the

relationship with other services (called references). The binding policies with external

services specify all the aspects of the communication between individual services -

communication protocol and security levels.

Using a SCA platform, it is then possible to generate the skeleton for each component,

and the developer task is to implement the logic, without having to consider how this

component is going to be invoked, or the mechanisms used to invoke external services.

The binding policies should be defined either at deployment time (these services are

deployed in the same application server local java call, this service is developed in

.Net and calls a service developed in Java SOAP call, etc.), or changed at runtime.

SCA is a very young specification, as it does not address the versioning of modules and

services. However, products such as IBM WebSphere Process Server already implement

it. Due to this support, SCA should become the de-facto standard for the construction of

Service-Oriented Architecture.

BPM and SOA: Paradigm Shift

How do we link that back to BPM? The short answer is, BPM advocates a top-down

approach, the development is driven by the business, and SOA is a bottom-up approach.

We saw significant activity in the blogosphere on BPM versus SOA14. These two

approaches are in fact complementary: BPM enables business to define the processes

they need to implement, and the technology team to identify the services that are

required. The technology team then uses the SOA methodologies to implement these

services.

13 SCA, JBI and morehttp://azur.typepad.com/bpel/2005/12/sca_jbi_and_mor.html 14 Bruce Silver The Phony war Between BPM and SOA http://www.brsilver.com/wordpress/


30/45


Top-down

Bottom-up

Figure 17 - BPM and SOA

Ideally, the two concepts should be bridged into the same platform. In the meantime,

developers can use Web Services platforms to wrap existing application adapters and

expose them to BPMS.

BPM System

SOA platform

Web Services

Figure 18 - BPM and SOA

Some products, like IBMs WebSphere Process Server, actually integrate the two visions

into one single platform.


31/45


32/45


Process Designer

The man in the middle

Business Analyst

Systems Architect

Figure 19 - Process Designer

Create a BPM Competency Centre

In order to enforce governance of best practices and methodology on a BPM project, it is

common practice to set up a related competency centre. This group can act as the

central point of reference for BPM projects, and can provide standard processes to

engage new projects; best practices, tools and templates; subject matter expertise;installation, support, deployment and monitoring services. The organisation of the

competency centre depends on your companys business model. The following are the

most commonly used models:

Centralised: a single group implements and maintains enterprise wide

processes. The centre of excellence is the single point of contact for all BPM

projects. Companies usually start this way for the initial scope.

Decentralised: the company hosts several centres of excellence, usually one per

business unit, with minimum inter-communication.

Federated: the centre of excellence hosts a group of experts that are allocated

on projects but report back to their group. This is the most common

organisational model, which provides enterprise-wide scalability.

Choose a Technology Stack

The open source BPM tools rely on a Web Service stack. They require Web

Services to be exposed by applications. They can also expose processes as Web

Services. But they are NOT addressing the creation of Web Services that expose

an applications functionality. For this reason, you need a platform that enables you

to define, implement, deploy, and maintain Web Services from your legacy applications.

This is not completely true for commercial platforms. For example, IBM WebSphere

Process Server is able to invoke any type of service, whether it is a Web Service, a

database stored procedure, a Java POJO, etc.

Regardless, here are the elements that should be considered when selecting a BPM tool:


33/45


Monitoring

Figure 20 - Software stack

User interface: common framework for users to interact with processes and

services

BPM: as described in this document

Service platform: platform enabling the modeling, development, deployment,

referencing, and operations of services that are used in processes

Messaging platform: platform used for message transport between process

participants

Monitoring: transversal integrated monitoring platform for the control of the

entire infrastructure

For example, the Intalio stack is:

Monitor

ing

None

(technica

lconsole)

Figure 21 - Software Stack - Intalio

Select your Modeling Approach

The line between services and processes is very blurry. A process reuses services, and

exposes services to the outside world.

Bottom-up Approach

The bottom-up approach has been favoured by technology teams for a while, and was

reflected in the SOA space. The main idea is that IT is driving the creation of reusable

services on top of existing applications. These services can then be assembled in higher

level services and business processes. This approach suffers from practical limitations:


34/45


Return on investment / time to market: budget owners only see their ROI when

the services are operational, and ready to be assembled to answer to new

business needs. If the services development is not driven by the business based

on real use cases, the bottom-up approach can actually slow down time-to-

market.

Money-wise, service development is mostly driven by projects that have the

budgets. The cost of a reusable service goes beyond a specific integration.

The tools are not really there to allow an efficient bottom-up approach. In fact,

developing a service is only a beginning. Bigger concerns arise when multiple

applications are using the same service, and the service needs to be upgraded.

Top-down Approach

The top-down approach is more practical. The basic principles of this approach are that

business users describe the processes to implement, and identify the high level services

that need to be implemented by IT. Services are then implemented by IT based on the

specifications provided by the business, and based on project budgets.

This approach is more cost effective for tactical projects. However, it does not enforce

governance of best practices in the implementation of services. The risk is to get a 1 to 1

mapping between processes and services, and to have multiple implementations of the

same service scattered in the environment.

Meet in the middle

The reality is that in most cases, the previous approaches do not scale enterprise-wise.

The approach that we have seen working to bridge the gap between business and IT is a

mix between the two:

Business users define business processes and identify services to implement.

These services use business specific generic objects, or UDM (Universal Data

Model).

The BPM centre of excellence keeps a registry of available services. A first cut of

the required services is implemented by IT and referenced. The centre of

excellence has a budget to maintain the services life cycle outside of the scope of

a specific project.

The process designer maps the business specific objects to the services provided

by IT. The transformation maps are kept by the center of excellence and can be

reused.

A set of methodologies can be used to keep the business and technical layers in sync

and limit the impact of a change from one layer to the other. This includes, but is not

limited to, the use of abstract processes, the use of process interfaces and

implementations.


35/45


Illustration: Creating a Timesheet Approval

Process

The Intalio BPMS will be used to illustrate the creation of a business process: a

simplistic timesheet approval process.

MethodologyA team that implements this process would comprise:

A Business Analyst

A Technical Process Designer

A Programmer

The approach taken is top-down: the business analysts models the to-be process, the

process designer maps it to the systems and workflow tasks, the programmer

implements the required services on top of the applications to integrate.

We will follow the business process life cycle exposed at the beginning of the document:

Model and Simulate Business

A business analyst describes the process the following way:

When a consultant enters a timesheet in the timesheet application, we need to send it

for approval to his manager, and then to the client. If the timesheet is rejected, the

manager and the consultant should be informed.

Now converted to a formal process definition:


36/45


Figure 22 - Simplistic Timesheet Process, Business View Intalio Designer

The business analyst also provides a specification of the timesheet approval form using

the same designer:

Figure 23 - Approval Form Design Intalio Designer

Model and Simulate Technical

Enriching the Process Model

Now here is what a technical person adds on top of the business analysts description:

A consultant submits the timesheet using the timesheet application created in

.Net.


37/45


The application kicks off the approval process, providing the timesheet, via a Web

Service call.

The approval process retrieves the users manager using a Web Service that sits

on top of Active Directory

The approval process assigns a task to the manager by calling the Web Service

generated by the forms designer (that talks to the workflow component)

The response from the workflow engine comes back asynchronously

The approval process assigns a task to the client

The approval process updates the timesheet application status along the way by

calling a Web Service

That requires some modifications on the base diagram provided by the business analyst.

For example, the first activity, manager approval; needs to be turned it into a sub-

process:

Figure 24 - Manager Approval Sub-Process Technical View

There are a number of methods that allow technical users to complete a business

process base diagram, without confusing business users. The two views need to be

aligned. The compact view of this sub-process guarantees that the business analyst still

sees his base process the contract between business and IT:

Figure 25 - Manager Approval without Details Business View

The technical user represents the interaction with external systems, for example the .Net

timesheet application, using a swimlane. Basically, each process participant (system,

person, process) is a separate swimlane. Participants collaborate via the exchange of

messages (dotted line in the following diagram):


38/45


Figure 26 - System Participant Swimlane

This can be translated as, When a timesheet is entered in the timesheet application, a

message starts the timesheet approval process.

The technical user then drags and drops an existing XML schema on the message to

specify its structure. Several tools on the market allow technical users to create and

display XML-Schemas, we are using XML Spy Home Edition, integrated with Eclipse. And

as the Intalio Designer is also Eclipse based, the two tools are available on the same

platform:

Figure 27 - Timesheet Schema with XML Spy Eclipse Plug-In

Integrating a system Process and Data View

There is now a high level diagram that describes our process. The first activity to

implement is Lookup manager from Active Directory.


39/45


Looking up the manager information from Active Directory is done through a Web

Service call. The Web Service is available, and provides an interface, described in a

WSDL Web Service Definition Language document. The Intalio Designer introspects

the WSDL definition of this Web Service and provides a list of all available operations. It

is then a matter of calling a specific operation by dragging and dropping it in the process

model. Active Directory is another system participant in the process; it is therefore a

new swimlane:

Figure 28 - Invoking a Web Service

The next step is to provide to the Active Directory Web Service the data it is expecting

(in this case, a consultant name). This data is available in the timesheet provided from

the source application (the .Net timesheet application). Intalio Designer provides a visual

data mapper that generates BPEL assignment code.


40/45


Figure 29 Intalio Designer Data Mapper

Translation, We are passing a concatenation of the resourceId and username from the

input timesheet message, as the input of the getManagerDetails operation.

Integrating a User Form

Integrating the user form follows the same concepts: the designer generates several

Web Services that can be called to assign a task to a user, and receive the approval

response. There is the ability to map the response of the Web Service to the workflows

expected approver field. That gives:

Figure 30 Intalio Designer User Approval Step


41/45


Note that in that case, the response from the person comes asynchronously. It can in

fact take several days before the timesheet is approved. In the meantime, the process

may execute other actions.

Note that the user approval step and the system integration step are defined as

part of the same diagram. At runtime, they will be executed as part of the same long

running transaction. Legacy EAI and workflow systems require separate tools for the

human workflow steps and the system integration steps. In most cases, the system

integration engine used a different meta-model from the one used in the human

workflow, and integrating the two was challenging!

Deployment

Process compilation generates a Web Service, which can be invoked by the timesheet

application to start the process when a new timesheet is entered, and a BPEL document

is created. It bundles all of this with the user interface screens and deploys it to the

server.

The process Web Service interface, WSDL document, is available from the server. It is

used by the .Net application to generate a client, to be invoked when a user saves a new

timesheet.

Figure 31 - Intalio Designer - Deployment

Note that only one deployment option is available deploying to a single server. This

limitation might be addressed later on in the enterprise edition of Intalio. One advantage

of Eclipse is that it provides an extension mechanism. It is therefore possible to extend

Intalio Designer to add support for more complex deployments.

Execution

Starting the Process

The process is started from the .Net application, using a Web Service call. The console

enables technical users to follow processes during execution, and to inspect process

data.


42/45


Figure 32 - Intalio console, process definition view

User Approval Step

When the user logs into the system, inspects his available tasks, and selects a task, the

UI displays the information provided by the process using the form created previously.

Figure 33 - Intalio task list, based on XForms

Intalio implemented its workflow engine using BPEL. On the front end, they used

Orbeon, an open source XForms engine, with AJAX capabilities. They implemented a

basic task list (top half of screen) while we implementing an XForm representation for

approval (bottom half of screen).


43/45


Measurement and Improvement

In addition to this basic process, visibility needs to be provided to the business

stakeholders, to follow Key Performance Indicators: how long does an approval take?

Who has not entered timesheets at the end of the week? How many hours are worked

per day on average for each particular project? This cannot be accomplished easily with

open source BPM systems; a business activity monitoring and reporting suite, or customdevelopment would be required.

However, should the process need to be changed, this change can be driven

independently by the business (e.g. when adding an approval step) or I.T. (e.g. needing

to integrate another application).


44/45


Conclusion

BPM standards are on the way. The most important standard for a Business Process

Management System (BPMS) to support is BPMN the Business Process Modeling

Notation. There is still a gap in the standards: the integration of user interactions with a

business process.

BPMS are emerging. The open source ones are improving but caution is recommended

when implementing critical high volume business processes. Some custom development

is required to integrate BPM systems with Business Activity Monitoring dashboards, in

order to provide visibility to the business users, to measure processes based on Key

Performance Indicators.

In conclusion, BPM is still for early adopters (standards based BPM systems ready for live

pilots and the first production projects), and it is expected that the tools will be ready for

large scale production deployments in late 2006.

Emerging POC Pilot Production Large scale

BPM today


45/45

About GLiNTECH

Founded in 2000, GLiNTECH is a professional services IT consultancy, specialising in

technical applications development, technical consulting and architecture services.

GLiNTECHs team of knowledgeable and skilled consultants ensure that our clients

receive truly objective and informed advice on the right technology, every time.

bpm essentials with open source

Documents