Multi-Manager Workflow Solutions

If you've worked with Filenet, Alfresco, or any number of Content Management suites, then you've most likely encountered their embedded workflow capabilities. It's very common to enforce some sort of process around adding, changing, and deleting content from your corporate system of record - so embedding workflow capabilities in these products just plain makes sense.

If you've worked on a BPM project that involves a wider scope than your corporate management system, then you've probably had to answer the dreaded question:

Which product should I use to implement this process?

My first encounter with this conundrum was with an Identity Management product rather than with a Content Management product, but the factors to consider were pretty much the same.

The process that we needed to implement involved employee credentials that were managed by Sun's Identity Management product. The Identity Management product's embedded workflow features weren't enough to handle the whole process,  so we were left with the option of implementing everything in Lombardi's Teamworks or of implementing the "master process" in Teamworks and key sub-processes in the Identity Manager.

Our original approach was to go with a pure Teamworks solution to keep all the process logic in a single system, but during implementation we changed our minds.  Using Identity Manager's embedded features for a few key sub-processes shortened our development cycle, so we went with it.

In an ideal world - at least from my perspective - Process (workflow) Managers would be decoupled from specialized products.  The specialized products would all expose Services (both Human-Powered and Automated), and the external Process Manager would choreograph and orchestrate those Services.

Unfortunately, my perspective is far from ideal if you are the vendor of a specialized product.  Leaving the process and workflow elements of your solutions to an external product just doesn't work.  Your product needs to provide as near an "Out Of The Box" solution as is possible, or people won't buy it.  You could (of course) partner with a Process Manager vendor, but that requires inter-vendor collaboration... and the end result probably won't be as tailored to your specific domain as you'd like.

Consequently, product vendors will embed workflow capabilities into their products, and we'll be left to answer the dreaded question:

Which product should I use to implement this process?

Clearly, it's not unreasonable to assume that you may have to deal with multiple "Process Managers" to implement a single process...  Teamworks may handle most of the process, Sun Identity Manager may handle "identity" aspects, and Filenet may handle "Document" aspects.  What's needed is a standard API for each Process Manager to use when interacting with another Process Manager...  Here's a partial list:

• Start a Process Instance
• Signal that a Process Instance has completed

I could easily come up with many more APIs... but these two are the biggies.  If I can start a process, and get notified when a process completes, then I can incorporate any process that's managed by and external Process Manager into a process that I am managing myself.

So far, so good - but I'm not quite done yet with my wish list...  I'm fine with Process Manager "A" handling the overall process, and with Process Manager "B" handling some key sub-processes... but only if Process Manager "B" keeps Process Manager "A" updated on what's going on.

For example - Let's assume that "A" kicked off a sub-process with a dozen activities that's handled by "B", and for some reason it's taking more time to complete than expected.  What's going on?  Which of "B's" tasks have been completed?  Which of B's tasks are left to complete?  Enquiring minds want to know :-)
 
If users have to switch between process managers to get a clear picture of "who is doing what" (or to claim tasks) then they're not going to be happy.  Multiply process managers are fine "under the hood" - but keep the hood closed and let the users concentrate on driving.