Decoupling CMS features

CMS Watch has a post on decoupling of search and ECM. In my interactions with the clients, I’ve also noticed a similar trend. Clients who are considering implementing a CMS or Portal product have started putting more focus on a particular set of functionalities among their requirements. These requirements go under the category of “flexibility” and require that instead of using a specific feature of the product, it should be possible to decouple it from the product and use the same feature from another “best of breed” product. Some examples of such features:

  • Instead of CMS product’s workflow, It should be possible to use a third party BPM engine
  • The CMS should be able to integrate with CVS or VSS for version management
  • Instead of using the portal product’s built-in document management portlet, it should be able to integrate with an enterprise DMS
  • Decoupled delivery so that content can be delivered by any portal
  • And so on..

While some of this decoupling is good, like in the case of a decoupled search engine or integrating with a single signon solution, I’m not sure if it is such a good idea for core CMS or Portal features.

  1. If you are implementing a CMS product and using workflow, version management and other such features from other product(s), what’s the point of using a CMS product in the first place? The idea of using a product rather than a custom development is that you get many features out of the box. If you are using a product but not using the core features, you’d be better off choosing another product or doing custom development
  2. This usually means that the product needs to be changed so much that it no longer remains the same product. This leads to support issues and problems during upgrade
  3. The product brochure or the sales folks often claim the product is very flexible and can work with any other third party product. However, these integrations are easier said than done and huge amount of effort is required to achieve any reasonable integration. Hence during product selection, it is very important to make sure that this can be done by doing a proof of concept.

However, in general, I think that when one buys a product, one should avoid extending it too much. The philosophy should be to customize rather than extend. If you require too many extensions, the product is probably not a right fit for you.

Next week, I’ll be at AIIM and am hoping to meet many folks. I hope it’ll be a great learning experience.

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: