Decoupling ECM features revisited

Many vendors have successfuly decoupled search from ECM. Many people have been asking for decoupling of other features as well. I’ve written on CMS Watch on what I think about this.

James McGovern had made some observations about a related post that I had written some time back. Here’s my take on some of those:

Should CMS should control BPM or BPM should control ECM? Doesn’t this require that both ECM and BPM products support industry standards to allow them to be embedded? If so, whom do you feel is best positioned to kick off the creation of such standards?

I think it will vary. I wouldn’t call it as one controlling the other but one of them will certainly be primary and the other one be secondary. If its a content heavy application and BPM refers to document driven processes then I would think CMS will be primary. However, if its a transactional application like an employee intranet where there are processes for say, employee reimbursement, employee travel and so on, I think BPM will be primary. For any of such decoupling to work, standards will play an important role. So if a CMS has to allow a decoupled version management or decoupled BPM then along with the CMS, the version management systems or the BPM also have to adhere to standards. I would think that large vendors who have presence in multiple areas would be best positioned to create standards. Obviously they would need a buyin form smaller niche players, industry and users.

Anything wrong with Subversion or ClearCase?

Not at all. When I mentioned CVS and VSS, I was only giving examples. This is not a complete list and others are okay too 🙂

Is this integration dynamic where all historical content is pulled from the version control system in real-time or simply check-in, check-out?

Hmm..okay there are two areas of version management in a CMS. One is the content (website, documents, images etc) and the other is the code that is used for development or customization of CMS. So for example, it could be XML files that define content types or templates that define how the site will look like. I was referring to versioning of code when I wrote about integration with external version management software. For content, I am perfectly happy to be versioned within the CMS. It is debatable though if code should also be considered as content and managed by CMS (CMS managing itself) but that is a topic for another post.

What’s wrong with the way portal products integrate with CMS products? If the portal has its own security model separate and distinct from CMS, how should they work together?

It really depends on how tightly the Portal and CMS are integrated. Actually I have been working on a longer article about CMS and Portal integration. I will share a link with you once that is done.

4 thoughts on “Decoupling ECM features revisited”

  1. One difference I’ve noticed is that BPM products usually provide a visual modeler for process design while it is not so common with CMS products – do you think there is a need for CMS products to provide advanced modeling tools for workflows, process design etc?

  2. Kashyap,
    Thanks for stopping by.
    You are right but then CMS vendors would say that modelling is not their key functionaility.

    However, i believe many vendors have started including more visual tools. Interwoven’s TeamSite has one and so do Documentum and FileNet.


  3. Howard Shao, the other co-founder of Documentum, and I recently had a disagreement about this. We had an on-going discussion during the 90s as to whether we should just concentrate on content management and partner on workflow or do both. The sales force was pulling us in both directions.

    With Alfresco, we had the choice and chose to embed jBPM, but keep the interface open to other engines. Standards like BPEL make it possible to do this more easily. Content management is neither above nor below workflow – they are orthogonal dimensions that intersect frequently. When workflow strays beyond content management to intersect with CRM, ERP or communication, then it is clear that you need a different set of expertise.

    We are taking the same approach with search. Rather than just make the search engine pluggable, we are really making search pluggable. Using the interface we can federate, not just other Alfresco repositories, but anything that supports opensearch, including internet search.

    Services around search, content control, content capture, presentation, etc. should be componentized and built around low-friction, low-impedance interfaces allow component providers to follow their core competencies. As more vendors start to adopt REST interfaces and mash-ups start to become a more common occurence in the enterprise, this evolution we become more natural and inevitable.

  4. The notion that Apoorv alluded to and John expanded on with regards to the correlation of BPM and ECM rings very true – these product sets do need to be componentized and support loose coupling based on open standards so as to allow customers to easily assemble a solution infrastructure that combines these different product sets to solve business problems.

    In reality, automating and managing business processes is mostly a enterprise integration problem involving people, systems & services, and goes beyond just BPM and ECM systems to also include ERP systems, Mainframes, custom apps, external data feeds, email systems etc.

Comments are closed.

If you would like to get short takes directly in your mailbox, please do consider subscribing to my newsletter. I won’t spam you and your information will be safe. I usually send it like once a week (or once in 15 days).

%d bloggers like this: