It seems the smartest guys in the room, BPM-wise, have suddenly discovered content management.  Or, more accurately, have begun to imagine what an intersection between the two might possibly look like… as if that were almost possible.  Ismael tosses out three candidates: 1. Manage the lifecycle of content objects in CM, and just store the links to them in the process instance.  (Memo to FileNet.  Hmmm, might work, maybe try this…)  2. Use the CM repository as source control system for BPM developers (Memo to engineering… Oh, never mind.)  3. Embed a subset of BPM inside CM to do document approval workflows (is there a CM product anywhere that doesn’t do this natively?)

webMethods’ always-entertaining Kiran Garimella, ebizQ’s latest BPM blogger, adds:

If BPM takes on management of process knowledge, as I think it should, what?s left for ECM? Will ECM morph into the middleware for management of transactional documents? After all, it seems pretty evident by now that we will never be a paperless society. Besides, a lot of enterprise content will be on PostIt notes (to the utter delight of 3M)…

What these guys forget is that life on earth did not begin yesterday, and business is not driven by XML messages alone.  Any bank, brokerage, insurance company, utility, or healthcare provider today has a lot more IT investment tied up in ECM repositories than in BPM.  And the lifetime of those content objects is far longer than that of the workflows that put them there.  Ismael’s hypothesis #1 is of course a huge business already for FileNet (now IBM), EMC, Global 360, and others… and has been for well over a decade.  Loans, claims, underwriting…  Does any BPMS manage those processes for a G2000 customer without using ECM to manage the lifecycle of attachments? 

Not to single out Ismael and Kiran, who really are the smartest BPM guys in the room.  They’re just examples of the general fact that BPMS vendors (who did not come from the CM space) still don’t get CM: what it is, what its benefits are, and what its intersection with BPM should be.  Retention management alone would be a huge step forward for BPM.

I went through this with all those vendors when I did my 2006 BPMS Reports.  Several of the use cases in the evaluation had clear requirements for CM integration, but most vendors had nothing to offer.  To them, integrating a CM repository was no different than integrating any other “legacy app.”  Note: They tried the same gambit with business rules a couple years ago until Gartner crushed them for it on the MQ.  Now they all include business rules in the BPMS, either out of the box, or prebuilt integration with ILOG, FairIsaac, or Corticon.

This is a huge missed opportunity for BPMS vendors, who have basically ceded the content-centric process space to the CM vendors.  I have nothing against the new inexpensive bloggy open-source CM offerings, but let’s face it, it’s the CM installed base of FileNet, EMC/Documentum, IBM, G360 that’s – to borrow Willie Sutton’s phrase – “where the money is” in BPM.  Introspecting the Java APIs is not enough.  Native viewers, content events, team collaboration…  This list of integration features goes on.  All these vendors support SAP adapters, when a simple Java adapter might “do.”  I think they would get as big a bang out of a few ECM adapters.  (Memo to Sinur and Hill: Maybe put this in the next MQ criteria?)