discussion about pro's and con's of the different types of content delivery in the web content management market today

1. Differentiating between Web Content Management delivery mechanisms
Architectures for WCMS content delivery can be broadly classified into two types:
• Decoupled / Loosely coupled delivery
• Tightly coupled delivery
In a decoupled or loosely coupled architecture, the WCMS and delivery applications are generally separate
applications, with different repositories, but there can be an association between the two that creates a
dependency. For fully decoupled delivery mechanisms the WCMS is primarily used as an editing, authoring,
approval tool before content is published to a live environment which has no WCMS software installed (often
referred to as ‘static’ or ‘baked’ content delivery). For loosely coupled content delivery, content managed by
the WCMS is published to another repository from where it is picked up by the delivery application and
rendered to the visitor. The content delivery application is generally not aware of the WCMS, but is configured
to accept content from it.
In a tightly coupled architecture, both the creation of the content and the delivery of the same content is done
by the same WCMS application on the same server or there is much tighter dependency. In a scaled or
separated architecture, the content delivery application is in most cases a replication of the WCMS application
used to edit the content - simply installed again on another server to allow the architecture to scale.
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 can be 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 html, asp, aspx, php, XML etc) or to a database for a more dynamic personalised
approach to content delivery. 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 loosely coupled content delivery. 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.
Similarly, Open Texts Web Solution (pka RedDot) offers loosely coupled content delivery akin to the
Interwoven model – the main difference that it provides its own presentation layer application as well as being
able to use BEA or similar. In addition Open Text WCMS offers a totally de-coupled content delivery model for
websites not requiring e.g. personalisation or any form of management of the content post publication.
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 WCMS and Delivery application, in terms of infrastructure resources,
performance and availability are very different. Hence this model becomes quite useful as each
component can be optimised to its task.
4. Different best of breed applications can be used for doing multi channel delivery such as delivering
content to PDA devices.

2. 5. If a customer does not need e.g. personalisation and simply wants a tool to manage content but not
delivery, they do not need to purchase ‘redundant’ licenses from the WCMS vendor as they would with
tightly coupled solutions.
Cons
1. The two environments are generally disparate. This usually means a different file system or different
repositories for content management and content delivery.
2. Features like in-context editing where users can make changes from within the context of end user
application may not be there as they are only available in the live environment and not whilst editing.
3. If changes are done on delivery environment, it is generally not possible to bring them back into the
CMS. Changes have to be made to the application that is responsible for editing and published to the
content delivery mechanism.
4. Different skills sets for development and maintenance, potentially different vendors to manage each
component (though Open Text offers a total solution)
Tightly coupled delivery
In this, usually, the same application does an end to end management of content lifecycle – from content
creation to content delivery. 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 as they are essentially the same product.
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.
Cons
1. Dynamic delivery of content is never as fast as static decoupled delivery – even with sophisticated
caching – thus potentially degrading the visitor experience unless hardware is scaled to offset the
performance drag (see point 9 for license implications)
2. Some of the features in best of breed applications might not be present in this approach.
3. Many entry level WCMS solutions offer one software application for both editing processes and
content delivery processes – effectively installing a single point of failure (if the editing server goes
down so does the live environment).
4. If the same instance is used for content editing, publishing and delivery – the editing process may
impact on the visitor experience as the server slows and vice versa.
5. Many solutions that offer tightly coupled delivery provide for different WCMS software instances to
scale but share the same database – making the database a single point of failure.

3. 6. Even if the customer only wants an application to manage the creation of content, they have to
purchase and install the WCMS software at all points rather than only where needed.
7. Multi Channel delivery becomes also controlled by the WCMS resulting in a compromise for best
application to deliver e.g. Blackberry or other PDA output.
8. The product itself might not be good at doing all things and hence some compromises might be
required.
9. Licensing cost could be prohibitive if the product needs to be there on both management and delivery
environments – especially as many tightly coupled solutions not only license per software install but
per CPU and in some cases the amount of memory installed – even more so if the live environments
are hosted across multiple clustered servers for failover or performance considerations.
References:
This article is based on a submission made by Apoorv Durga in 2006. The original can be viewed at
http://it.toolbox.com/blogs/pcm/my-cms-does-delivery-too-10191 and Apoorv’s own blog can be viewed at
http://it.toolbox.com/people/apoorvdurga/. The article has been updated and reproduced with kind permission.
Copyright notice:
This document and the version available on the website and its associated content are copyright of
"contentmanager.eu.com" © "contentmanager.eu.com" 2008. All rights reserved.
Any redistribution or reproduction of part or all of the contents in any form is prohibited other than the
following:
• you may print or download to a local hard disk extracts for your personal and non-commercial
use only
• you may copy the content to individual third parties for their personal use, but only if you
acknowledge the website as the source of the material
You may not, except with our express written permission, distribute or commercially exploit the
content. Nor may you transmit it or store it in any other website or other form of electronic retrieval
system.