Portable BPM?

One of the developers that I recently worked with asked me if the "stuff" that he was developing using Lombardi Teamworks could be exported to any other BPM development or deployment environments...  The answer is pretty simple: Nope.

The wider question is whether or not this will ever be possible... What would have to happen for a BPM solution to be truly portable?

BPMN 2.0 is working towards "Enabling the exchange of business process models and their diagram layouts among process modeling tools to preserve semantic integrity". Is that portable BPM?  Maybe... but maybe not. 

There are several elements that would have to come together to make BPM solutions portable.  The first (and probably the easiest) step towards "portable BPM" is to adopt a standardized representation for the Process Flow.  BPEL somewhat accomplishes this... You can create a BPEL process definition with a number of tools, and import that definition into several of the existing BPM development suites (Teamworks included).

The main shortcoming with BPEL used to be its lack of explicit support for Human Centric Services (as far as BPM is concerned) .  BPEL4People seeks to address this shortcoming... and there are a couple of implementations available (from Intalio and Active Endpoints).  

Adding people to BPEL shouldn't be that hard (conceptually).  To a good Process Engine a Human Powered Service looks pretty much like any other Asynchronous Web Service.  Send Data to a Service, Retrieve Data from the Service.  If my Process Engine can orchestrate asynchronous Services then Human Powered Services should be a snap.

Note to those who are actually using BPEL4People... I haven't had time to play with it yet.  Please share any insights that you have on how well it meets its goals.

One nasty little detail that often crops up when dealing with people (in a business process) concerns  determining which people should be able to perform the Service.  I've worked on quite a few managed business processes where the logic for getting tasks to the right participants was far from trivial.  It would be nice if every task could be assigned to the members of a group or to people who have been assigned a specific role... but sometimes you have to figure out "who should get what" based on very dynamic criteria.  Portable BPM will have to address this - perhaps by incorporating external Routing Services (return a list of users).

So... If we can define the Process Flow in a portable format, and we come up with a portable format for specifying routing logic, then we are still left with those darn Activities.  How can you make Activities portable? 

BPEL is Activity agnostic... BPEL choreographs Services.  Implementing those Services is somebody else's problem.  BPM suites, on the other hand, pretty much have to implement Activities or nobody will use them.

Some BPM suites leverage XForms to implement Activities... That's a good approach, but I just don't think that you'll ever convince everyone to use XForms.  Some folks demand Filthy Rich Interfaces for their Activities that are beyond what XForms can support.  For those of you who are using XForms, please tell me if I've underestimated XForms' abilities.

I think the answer here (to reach the Portable BPM goal) would be to package Activities as separately deployable entities.  If you could export a single Activity as a deployable entity, then you could theoretically use that Activity in another BPM suite... You probably couldn't change the Activity, but you "could" use it.

So... If we have portable Process Definitions, and if we sort-of-have portable Activities... have we reached our goal of Portable BPM? Well... maybe.

There's a awful lot of stuff in a BPM solution that's beyound the process flow and the participant activities.  Increased Process Visibility is a big driver for most BPM projects (UPS Envy).  Process owners (managers, etc) want "Dashboard" access to a variety of reports - both real time and historical.  Generating those reports requires accessing a lot of business data, some of which is available to the process engine...and some of which belongs to a system of record.  It's not immediately clear to me how this aspect of a BPM solution could be made portable.

I don't think I will hold my breath waiting for truly portable BPM.

Fortunately for developers... the lion's share of the skills that you'll need to be successful with any BPM suite are portable.  Process patterns are process patterns.  Service interfaces are services interfaces.  A good Task-Oriented User Interface is a good Task-Oriented User Interface.  It's just all of those nasty little implementation details that you'll have to worry about ;-)