The BPM-ECM Intersection

By: Bruce Silver December 29, 2016 bpms

Despite the inclusion of content management functionality in Gartner's checklist of BPMS must-include components, most BPMS vendors cannot even spell ECM. The few that can -- EMC Documentum, FileNet, Global 360, Pega, IBM -- generally had an ECM business long before they got into BPM. I've been thinking about it more lately as I finish up my report on EMC's Documentum Process Suite for the 2006 BPMS Report. And I see bits of it popping up lately in a variety of contexts:

  • The Gilbane Group, normally the smartest guys in the room when it comes to ECM analysis, dipped their toe into the topic this week -- not much more than admonishment to BPMS vendors to make their tools easy to use or some such profundity... but at least they're beginning to talk about the intersection.
  • Pega's BPM VP Setrag Khoshafian, who wrote about the intersection in edoc, a magazine for ECM users, is promising some snazzy new ECM functionality in PegaRules Process Commander for October's PegaWorld.
  • Blogger Phil Ayres has latched on big-time to BPM's need for ad hoc team collaboration, but was until recently unaware that it's the ECM vendors with a BPMS -- EMC, FileNet, G360 -- that actually provide it today. Now he's all over it.
I've written about this topic a lot in reports and white papers, generally in the context of the how these products put ECM and BPM together and the business value, but I haven't blogged about it yet. I think that's because my view of it is starting to change.

If you recall my discussion a week or so back with ILOG's Alain Gendre re business rules -- another of Gartner's BPMS checklist items -- he explained why rules belonged at the SOA layer, not in the BPMS or any one application system. A similar logic obviously applies to ECM. It should be a business service in the SOA layer. But in rules, just as in ECM, what you have in reality are partnership agreements between BPMS vendor A and rules/ECM vendor B, involving some bit of proprietary integration to glue the pieces together. In a perfect SOA world you wouldn't need such agreements, but so far, in the real world, you still do.

The main reason is that ECM products that claim to be SOA mostly expose their services and events only to other pieces of that vendor's own ECM/BPM suite. Better than what they had before, but obviously not enough. If those ECM offerings were packaged better as true enterprise services, the BPM-ECM intersection would be a lot easier. Besides exposing content operations as services, it's important to publish content events in a standard way. A content event is a signal generated automatically in the ECM system whenever a document is added or updated in the repository, or its metadata is updated, or its lifecycle state promoted, etc. ECM vendors publish these events to their own BPMS, but not externally. But then again, if they provide their own BPMS, why would they want to?