Peter Monks

(with apologies to the Propeller Heads and Shirley Bassey)

Laurence Hart recently posted some reminisces regarding his formative years in content management, and it got me feeling a little nostalgic about my own introduction to and history with content management.  Allow me to bore you with a rather self indulgent look back at the last decade or so…

Sun, Surf and Sandstone

For me it all started in late 1996, when I decided to update the 1991 rockclimbing guide to Sydney.  Lacking in publishing experience and having heard from more experienced souls that publishing was more than half the work in preparing such a guide, I decided to update the information, put it online and then consider a hard copy edition at a later date (the classic divide-and-conquer get-bored-and-do-something-else approach).

At the time I was working for one of the (then) Big-5 management consulting firms, and had specialised in BEA (now Oracle) Tuxedo, so the web and its technologies was pretty much foreign territory for me.  I figured this little guidebook project would be a good use case for learning about this newfangled interwebitube thingamajig.

Not having heard of content management (in part because it was a niche indication in those days!) I rolled my own “CMS” in MS Access, and used that to publish out the new guidebook as a static HTML site.  This wasn’t just a one-trick pony CMS either – the editor of a rockclimbing guide to the Glasshouse Mountains also picked it up a year or two later, and has been using it to manage his guidebook since then.  It’s with mixed feelings that I admit that this is one of the longer lived CMS implementations I’ve worked on!

The key takeaway for me from this period was that keeping presentation and content separate is indeed a highly valuable guiding principle, but that it’s also difficult to do without creating a visually repetitive site (which isn’t necessarily a bad thing, but tends to rub marketing and creative folks the wrong way).

The 300lbs Gorilla

Having caught the web bug (and if the truth be known, being completely fed up with developing business applications in C & C++), in 2000 I took a leap of faith and joined Vignette, arguably at about the time the company was at the pinnacle of its success.  To the casual observer it could appear that Vignette was on a steady decline from that point on, but for me personally it was a pretty wild ride – a lot of very smart people with a dizzying array of ideas – many of them brilliant, even more of them completely outlandish and/or impractical in the extreme.

And of course all of it focused on how best to manage and deliver web content, rather than being seen as a slightly perverse hobby that detracted from the “real work” of OLTP, N-tier client-server, data warehouses and the like!

In some ways the dotcom bust and subsequent “dark ages” actually helped Vignette, by bringing a previously missing intensity of focus to operational matters and (mostly) putting paid to the hubris accrued during the heady closing days of the 20th century.

If I can summarise that period in one statement, it would be that relational databases make *terrible* CMSes.  So many of Vignette’s technical flaws (specifically in the StoryServer and VCM product lines) stem directly or indirectly from the architectural decision to implement custom content models directly as relational data models.

Creative Interlude

After a stint in product management, I left Vignette in early 2006 and joined Avenue A | Razorfish – a Web Design Agency.  While only brief, this assignment gave me a new appreciation for the fine art of web design and the highly skilled, creative individuals who choose this profession.

It also reinforced the fact that many Web CMSes are still wrestling with basic plumbing issues (versioning, deployment, performance etc.) and have yet to really wrestle with some of the higher level issues of usability and productivity all while supporting creative freedom.

On a more mundane note, this experience also gave me a marked distaste for docroot management systems – that model was antiquated last millennium and makes no sense in this day and age!

Open Source Comes Calling

While I’d always had an interest in open source (in fact the Sydney climbing guidebook has been published under an open source documentation license – the GNU FDL – since its first edition in 1997), I’d never worked for an open source company before, and when the chance presented itself in late 2006, I jumped at the chance to join Alfresco, where I continue to work.

While it’s a little premature for me to be drawing any conclusions from my experiences at Alfresco, there are some patterns that I can clearly identify.  For starters there’s no doubt that open source is a disruptive business model – having a company that spends a majority of revenue on R&D (rather than on sales commissions) is a huge win for everyone (except career sales executives! ).  There’s also something to be said for openly visible source code – the “given enough eyeballs, all bugs are shallow” principle and all that.

In terms of content management, Alfresco comes closest (that I’ve seen) to realising the promise of a blended DM and WCM system (although as with any system there’s always room for improvement).

Julian Wraith recently started a discussion entitled “The future of content management” that has kicked off quite a few interesting responses.

Of those, the one that really grabbed my attention was Justin Cormack’s great response entitled “CMS technology choices“. By strange coincidence it closely echoes (but far more eloquently and in a lot more detail!) a conversation Kevin Cochrane and I had in twitter at about the same time, and while I almost entirely agree with everything Justin has written, the twitter conversation does highlight my one fundamental disagreement with the post.  Here’s the transcript of my side of that conversation:

Managing web content is about more than simply supporting the technical constructs the web uses (REST, stateless etc.).

eg. the graph of relationships between the content items making up a site can be an important source of information for authors.

But the web itself has no direct support for graph data structures (beyond humble “pointers”: <a href> tags and the like).

And perhaps as a consequence many (most?) Web CMSes don’t have support for that either.

IMNSHO the future is: schemaless (ala CouchDB, MongoDB, at al), graph based (ala Neo4J), distributed version control (ala Git).

(in hindsight I should also have mentioned “queryable (ala RDBMS, MongoDB, etc.)”)

To better describe my divergence from Justin’s vision of the future, I believe that management of, and visibility into the “content graph” (the set of links / relationships / associations / dependencies / call-them-what-you-will) is one of the more important features a CMS can provide, particularly for web content management where the link structure (including, but not limited to, the site’s navigation model) is so integral to the consumer’s final experience of the content.

So what “content graph” features, specifically, should a hypothetical CMS provide?

In my opinion a CMS needs to support at least the following operations on the content graph:

• Track all links between assets that are under management, in such a way that the content graph can be:
  • bi-directionally traversed ie. the CMS can quickly and efficiently answer questions such as “which assets does asset X refer to?”, “which assets refer to asset X?”
  • used within queries ie. the CMS can quickly and efficiently answer questions such as “show me all content items that are within 3 degrees of separation from asset X, are of type ‘press release’, and were published in the last month by ‘Peter Monks’”
• Flag any content modifications that “break” the content graph eg. deletion of an asset that is the target of one or more references
  • From a usability perspective our hypothetical CMS would provide the ability for the user requesting the breaking change to automatically “fix” the breakages eg. by correcting the soon-to-be invalid (dangling) links in the source item(s)
• Support arbitrary metadata on references, preferably using the same metadata modeling language that is used for “real” content assets
• Support basic validity checking of external links – links that point to assets that are not under management (eg. URIs that point to other web sites)

Other than linking, I think Justin’s post pretty much nails it.  I’m a big fan of schemaless repositories, having worked extensively with several “schemaed” CMSes that made seemingly simple steps (such as adding or removing a single property from a content type that happened to have instances in existence) a lengthy exercise in frustration.

I’m also a big fan of “structural” versioning (ala SVN, Git, Mercurial etc.), as it’s the only way to properly support rollback in the presence of deletions.  Trying to explain to an irate user that they just deleted not only an asset but also its entire revision history is not something I particularly relish!

Rich query and search facilities are a given – it’s one thing to put content into a CMS, but if you can’t query and search that content, it’s little better than a filesystem.

Replication (as in CouchDB, Git, etc.) is also an inevitable requirement for CMSes – I regularly see requirements for a CMS that can provide efficient access to documents across locations that are widely geographically distributed (including cases where connectivity to some of those locations is low bandwidth and/or intermittent).  Replication (with automatic conflict detection and sophisticated features to assist with the inevitably manual process of conflict resolution) is the only mechanism I’m aware of that can handle these cases.

And in closing, a big thank you to Julian Wraith for initiating this discussion – it’s extremely refreshing to discover other folks who are as passionate and (if I may say) as opinionated about CMS technology as I am!

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:

 
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.