Web CMS's Dissected

Showing results for 
Search instead for 
Did you mean: 

Web CMS's Dissected

Member II
0 12 2,883
It's no secret that Content Management Systems (CMS) are a pretty heterogeneous bunch of technologies, covering everything from paper document imaging systems through to portal servers through to desktop productivity apps - applying some Tufte to the CMS space demonstrates this heterogeneity pretty clearly. What's less apparent is that even within the relatively narrow confines of Web CMS (WCMS) technologies, industry definitions are almost as fuzzy.

Interestingly, this confusion is not apparent when looking at WCMS technologies directly.  Over the last decade or so the WCMS market has matured into basically two quite well defined and quite distinct types of application, yet I rarely find this distinction reflected in discussions around WCMS technology.

I refer to these two categories of WCMS as:

  1. Content Production Systems (CPS)

  2. Presentation Management Systems (PMS)

Here are some typical distinguishing characteristics for these two types of system:

ArchitectureSeparate management and delivery systemsSingle monolithic system for both management and delivery
Content Production Capabilities

  • individual content production workspaces ('sandboxes')

  • versioning / audit history

  • workflow / QA

  • in-context preview prior to launch

  • site rollback

  • deployment / publication

StrongWeak to none
Content Delivery CapabilitiesWeak to none - often API basedStrong
Canned Content ModelsFew to noneExtensive, though mostly presentation-centric:

  • sites

  • navigation / site map

  • pages

  • layouts

  • regions

  • components / modules / portlets

  • templates

  • skins / themes

Support for Custom Content ModelsRich, often based on XML or relational technologiesTypically weak, often limited to simple map / dictionary data structures

  • Interwoven TeamSite

  • Vignette VCM

  • Documentum Web Publisher

  • Drupal

  • Joomla

  • The Nukes (PHPNuke / DotNetNuke)

  • Portal Servers

  • Wikis


As can be gleaned from the table, for the most part these types of systems address orthogonal use cases (the content creation / production process vs the content delivery process) which explains why it's so confusing to directly compare a CPS with a PMS (something I've seen numerous times).

Now there's no reason that a single system couldn't do both, and in fact some WCMS vendors have product offerings that attempt to do this.  The problem is that to date most of these attempts have involved cobbling together what were previously independent applications, resulting in seemingly arbitrary distinctions between content that's fully managed via the CPS vs content that isn't.

As an example, one of the products sold by one of the vendors listed above marries a CPS with a portal server, but none of the portal server's configuration data (pages, layouts, regions, portlets, etc.) is stored in the CPS, so there's no ability to manage (workflow, review, version, etc.) changes to that data.  To the typical editorial team, this distinction is arbitrary and baffling, and can contribute to adoption problems.

So where does Alfresco WCM fit in all of this?

By now it should be clear that current versions of Alfresco WCM are solidly in the CPS camp - the core functionality is specifically focused on the content production use case, with presentation management left up to the delivery tier (which implementers of Alfresco WCM can implement using whatever technologies they're comfortable with).

That said, Alfresco has recognised the value of a combined CPS + PMS solution for some time, but up until recently the focus was on implementing the CPS first, since:

  1. it's arguably easier to add PMS constructs on top of a CPS than it is to retrofit a PMS with CPS style functionality

  2. there are situations where a PMS is already in place (eg. a custom web application), and the requirement is to introduce a WCMS that can integrate with that PMS rather than replacing it - in this case a pure play CPS is an appropriate solution

Earlier this year work began on the PMS side of things, and that's started to bear fruit in the recent 3.0 release; specifically with the introduction of the Surf platform.  The next step (currently targeting a later release in the 3.x product line) is to introduce a visual site building tool (tentatively called Web Studio) that allows less technical users to visually manipulate the Surf content model (ie. build 'sites', 'pages' etc. using a visual editing tool).

The beauty of this approach is that the Surf data model is stored in the (existing) repository, so all of the content production capabilities of the repository (sandboxed content creation / modification, workflow / QA, in-context preview, full revision history of the content set, rollback / roll forward, deployment / publishing, etc.) apply to all changes to a Surf site, regardless of whether it's a user writing a new press release, a subject matter expert optimising the navigational hierarchy for their section of the site, a web admin re-skinning the entire site or a web developer creating new page templates to add to the library.

Compare this to the product described above, where some changes are made in the WCMS (and can be content managed) and some are made in the portal (and are not managed at all) and I'm sure you'll see why we're so excited about both the Surf platform and the upcoming Web Studio tool.
Active Member
[...] Web CMS’s Dissected - where does Alfresco WCM fit in compared to other products? - Essential reading from Peter Monks for anyone who is new to Alfresco WCM, or starting to investigate the product.  https://www.alfresco.com/blogs/pmonks/2008/11/05/web-cmss-dissected/ [...]
Active Member
This is a good breakdown, but I kind of groaned when I saw your acronyms. In our conversations with clients we try to use 'coupled' for PMS and 'de-coupled' for CPS to identify the main difference in the two architectures (the coupling or decoupling of the presentation tier from the repository). I think coupled/decoupled has also been used by others like Tony Byrne over at CMSWatch. Maybe we could do with two less acronyms in the CMS world? Smiley Happy
Member II

(with thanks to this ultimate acronym list)  ;-)
Member II
To further add to the acronym soup, an excellent post on NPR's 'COPE' strategy for content management defines the same concepts, but uses the phrase Content Management System (CMS) for CPS, and the phrase Web Publishing Tool (WPT) for PMS.

Perhaps we need a naming standard for the various types of 'Content Management System'?  ;-)
Active Member
[...] is the delivery framework. These are called Web Publishing Tools (WPT) in NPR’s COPE and Presentation Management Systems (PMS) by Peter Monks. Things like Struts, Spring Web, ASP.NET MVC, Ruby on Rails and many many more are [...]
Active Member
[...] is a specific example of a general pattern I’ve observed for a while now. Jon continues:  The problem we have at the moment is that both [...]
Active Member
[...] that be a “lurmudgeon”?) over on the Alfresco team blog, I realised that I was covering more than just Alfresco specific topics and decided it was high time to split my general interest in [...]
Active Member
[...] be misidentified as a single commoditised use case – an issue that has been beaten to death in the past, but still has no remedy in [...]
Active Member
[...] seemingly narrow confines of WCM, we’re discussing (at least!) two different problem domains (Content Production Systems and Presentation Management Systems) that have markedly different requirements (and are arguably unrelated), and I’ll discuss the [...]
Active Member
[...] up I’ll be reviewing the repository-level requirements for Presentation Management CMSes, and we’ll repeat this comparison process to see how NoSQL technologies stack up against that [...]
Active Member
[...] Content Production System (CPS) has a number of requirements that are relevant to NoSQL solutions. These [...]
Active Member
[...] Web CMS’s Dissected [...]