Web CMS's Dissected

[pmonks2]

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:

	CPS	PMS
Architecture	Separate management and delivery systems	Single 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	Strong	Weak to none
Content Delivery Capabilities	Weak to none - often API based	Strong
Canned Content Models	Few to none	Extensive, though mostly presentation-centric: sites navigation / site map pages layouts regions components / modules / portlets templates skins / themes
Support for Custom Content Models	Rich, often based on XML or relational technologies	Typically weak, often limited to simple map / dictionary data structures
Examples	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.