My CMS does delivery too!

Content goes through three four distinct stages in its lifecycle – Creation, Management and finally Delivery Delivery and finally Archival. There are many products out there that claim to do delivery as well as content management and it becomes important to understand how they deliver content . Some products are good at management, others are good at delivery and some can do both.

I’ve been thinking of this topic for a while and will probably write a detailed whitepaper (that hopefully someone will publish :)). Here are some of my thoughts:

In my opinion, architectures for content delivery can be broadly classified into two types:

• Loosely coupled delivery
• Tightly coupled delivery

In a loosely coupled architecture, the CMS and delivery applications are generally separate applications, with different repositories. Content managed by the CMS is published to another repository from where it is picked up by the delivery application. The delivery application is generally not aware of CMS.

In a tightly coupled architecture, the delivery is either done by the CMS itself or there is much tighter integration.

Loosely coupled delivery

This is preferred by organizations who want to use best of breed applications for different aspects of managing the content lifecycle. In this, there is a very thin layer of integration between the two environments. The environments are either decoupled or at best very loosely coupled. If the environments are completely decoupled, the content management system’s responsibility ends after it publishes content. This can be to a file system (as static htmls or XMLs) or to a database. The presentation layer is then written in the delivery application that picks this published content and presents it to users.

Interwoven TeamSite is a good example of this approach. Content is created and managed by TeamSite and converted to html (or XML files). This content is then deployed using OpenDeploy to an application server’s file system and the associated metadata is published to a database using Database or home grown scripts. A J2EE presentation layer written on an application server (ATG, BEA or similar) queries this database and includes appropriate files to display to the users. There are different possibilities of achieving this, depending on the choice of delivery environment but the idea is similar.

Pros

1. There is division of labour. Each system does what it is best at and hence best of breed products can be used.
2. Existing investments are protected. So if an organization has invested in an application server, they can reuse the same infrastructure.
3. In general, requirements of a CMS and Delivery, in terms of infrastructure resources, performance and availability are very different. Hence this model becomes quite useful.
4. Different best of breed applications can be used for doing multi channel delivery.

Cons

1. The two environments are generally disparate. This usually means a different file system for the two, different repositories for content and users and so on. So features like in-context editing where users can make changes from within the context of end user application will not be there.
2. Presentation layer is handled by a different application. So content authors, generally cannot preview content as it would appear on the website.
3. If changes are done on delivery environment, it is generally not possible to bring them back into the CMS. This could be important in cased where user submitted content needs to go through a workflow.
4. Content expiry needs to be handled very carefully because content that expires on the website needs to be reflected in the CMS also.
5. Different skills sets for development and maintenance, different vendors to manage etc

Tightly coupled delivery

In this, usually, the same application does an end to end management of content lifecycle. There could be separate instance for management and delivery but essentially the applications are same. Even if there are different products being used for content management and delivery, the integration is much tighter.

Fatwire and Vignette are good examples of this approach. In Fatwire, for instance, content is created and managed within Content Server. The content is published (either dynamically or statically) to another environment that also runs Fatwire Content Server. Templates are then written within Fatwire to deliver personalized content.

Pros

1. It is easier to manage because the same product is used for end to end. So, in terms of resources, support and integration issues, it is less painful.
2. The delivery and management systems are better synchronized. So changes in one can be easily propagated to the other.
3. Replication, backup and recovery are generally easier.
4. It is easier for the content folks to visualize and edit content in the context of end use website.

Cons

1. Some of the features in best of breed applications might not be present in this approach.
2. The product itself might not be good at doing all things and hence some compromises might be required.
3. Licensing cost could be prohibitive if the product needs to be there on both management and delivery environments.