Business Process and Activity Interfaces

Business Processes are made up of Business Activities. In a BPM solution the transitions between each Activity are automated, but the Activities themselves may either be automated or they may be performed by Humans (That's why I use the term Managed Business Process instead of Automated Business Process).

Most of the focus in the community of BPM practitioners of late has been on the Business Process Definitions (BPDs) that the Process Managers use to control the transitions between Business Activities. BPDs provide the information that the Process Manager needs to assign the right Activities to the right Participants at the right time. Google BPMN, BPEL or XPDL and you'll find plenty to read.

BPDs are crucial... but they only define the Process Flow. Activities are identified in BPDs, but only the interfaces to the Activities are actually defined (The interface to the Activity defines the information that is passed from the Process to start the Activity and the information that is returned to the Process from the Activity when it completes).

All of the BPM suites that I am aware of generate executable process definitions (in one form or another). Some BPM suites generate "portable" definitions using standards like BPEL and XPDL, but many (including the Lomabardi Teamworks suite that I use) produce proprietary definitions that will only run on their own Process Managers. One of the big drivers between the efforts to make BPMN 2 "executable" is to drive the industry towards "portable" BPDs that can run Process Managers from any vendor. Great idea... but it's going to take some time to see if it gains traction.

Many BPM suites also incorporate tools to implement Business Activities. A Business Activity is really just an application that is tailored to perform a specific task. The Process Manager kicks off the application with some initial information, the application runs (usually gathering information from a Human) and when it completes it passes information back to the Process Manager.

I've had discussions with BPM practitioners who feel that implementing Business Activities should fall outside the realm of a BPM suite. Perhaps I've been spoiled by Teamworks, but I can't imagine creating my BPD in one tool and implementing my Activities in another tool. It's just incredibly nice to be able to drill down from an Activity on a Process Diagram to the underlying implementation of that Activity.

Despite my bias toward integrated Activities, I freely admit that you must be able to implement an Activity outside the limitation of your BMP suite of choice. Some Activities do require a very sophisticated user interface - and in many cases a pre-existing application can be fairly easily adapted to perform an Activity. I've had to resort to "external" Activities on several occasions (for key Activities).

If the implementation of an Activity is beyond a simple Form that the Participant needs to fill out, then you'll have to build some sort of task focused application for the Participant to use to complete the Activity.

BPM suites such as Teamworks allow you to build rather sophisticated task focused applications - but sometimes it makes more sense to go outside the suite and build the application using JSP, ASP, .Net, Ruby - whatever tools make the most sense to get the job done.

The "problem" is the lack of standard interfaces for connecting these "external" task oriented applications with your Process Manager/Process Engine. Most of the good BPM Process Managers provide the necessary interfaces, but they are almost always proprietary interfaces.

In the early days of BPEL, Activities were "just" standard web services. An Activity (web service) that was invoked from one BPEL engine could be invoked by any other.

BPEL (by itself) could only implement processes that could be completely automated. Most Business Processes include Human Activities - so pure BPEL implementations were few and far between.

Unfortuntely we've yet to come up with a standard (or even a de-facto standard) for implementing Human Activities. Some BPM suites (like Intalio) make use of standards (like XForms) to implement the user interfaces for their Activities, but the back-end interfaces between the Process Manager and the Activities are still unique to each vendor. There's no standard for registering an "Activity Application" with a Process Manager There's no standard way for an "Activity Application" to authenticate its user with the Process Manager. There's no standard way for an "Activity Application" to query a Process Manager for Activities that belong to its user.

Until we have these standards, there's really no such thing as a "Portable Activity". I could build a framework that helped me build task oriented applications, but I'd need adapters for any BPM suite that I wanted to interface with.

Hopefully this will change soon. As more BPM suites begin to support "standard" BPDs it will become obvious that we need Portable Activities too.