There are often cases when a website or portal needs to display content generated internally in the CMS along with content generated externally. Examples include showing news feeds from 3rd party content providers or displaying content from other applications like a CRM. So the question often asked is – Should this external content first get into the CMS and then delivered by the site OR should the site directly pull content from these sources and display it?
There’s no single answer and the solution obviously depends on each situation. Routing all content thru a CMS has some advantages:
- You can use the CMS features – Workflows, version management, archival etc for managing external data as well.
- Once all data is in CMS, you only need to publish from CMS to delivery environment. This means that there is no need to write sophisticated publishing mechanisms for all the applications. This is also better from the view of security and management as CMS is the only application that connects with your live environment.
- The delivery environment needs to query only one data source.
However, not all content can and should be routed thru CMS. If you are not going to use CMS features there’s not too much too be gained. You will only duplicate data and build bottlenecks. You also have to take care of content changes at the source i.e., if the external vendor updates a story, you need to update your copy too. This would not be a problem if you were directly querying the source.
Here are some points to consider while deciding wheather or not to route your content to a CMS:
- The first factor is the content mix of your site. If you have a site where external and internal content are of same type, it makes sense to bring the external content in the CMS first. For example, you have content folks who create news. At the same time, you also get news from external sources like Reuters. In such a scenario, you can use the same CMS structure – Data types, data storage, workflows, metadata etc for managing both since they are essentially same type of content but just from a different source.
- If the external content is dynamically and frequently generated, it’s better to directly query it. For example, if your web site displays product information (which comes from the CMS) along with product inventory status (that comes from an ERP), it’s probably a good idea to directly query the ERP.
- What if you have multiple CMSs? This is where standards like JSR 170 are useful. If your organization has multiple CMSs, you should push your vendors to make their systems JSR 170 compliant. At the very least, each CMS should be able to publish to a common XML/database format.
- Does your CMS do delivery also? If yes, it’s probably easier to route your content to the CMS.
As mentioned before, there is no straight answer. It depends on your architecture as well as process choices and most often, the choice would really be a mix and match – you will end up routing content from some applications to your CMS and querying others directly.
2 thoughts on “What data should a CMS manage?”
In your opinion – does your CMS systems also drive this choice? For instance if the CMS had a Portal Server based delivery – it probably makes it easier to integrate content directly at the delivery end, so should that be the choice regardless of above. And If not – its not hard to go for “auto-publishing” at a scheduled interval or at events for third party content, so possibly content end might be easier to integrate to?
Pranshu, thanks for the comment. Yes, you are right – the choice of CMS itself can impact your decision. This is what I was referring to in my last point “Does your CMS do delivery also?” but your example is good.
Comments are closed.