The BPM-ECM Intersection

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?