WCM Vendors: It's Time to Abstract Your Repository

By Deane Barker on September 5, 2010

I couple weeks ago, I posted about how “content developer” is starting to be a more appropriate term for what we do, given that the Web is no longer the only content channel in town.

This built off a previous post from last year, where I pointed out that we tend to be too Web centric about content management – we tend to think “content object = Web page,” which is no longer the case (and might never have been, in some circles).

This has all got me thinking that there’s something WCM vendors need to start doing: it’s time to abstract the repositories and make them non-Web centric.  The logical next step, is to make a content management repository channel-neutral, and build your WCMS on top of that as just one product that uses it as a data storage tool.

At Gilbane San Francisco this year, I was in a pre-conference workshop with Tony Byrne when he mentioned that a lot of larger companies are running tweets through their CMS.  They enter the tweet in the CMS, run it through workflow, versioning, audit, etc. and the last step in this process pushes it out to Twitter.

This is an example of “content development” rather than “Web development” at work.  This tweet began life by being entered into their content management repository, and it will most likely end its life by being read by someone in a Twitter client.  It will live and die with no explicit intention of ever seeing the inside of a Web browser.

But if this tweet was being entered into an average CMS (which, let’s face it, is most likely a WCMS), it would be force-fit into some Web-centric form.  Episerver, for example, deals only in “pages."  Ektron has “metadata” which is still largely focused around HTML meta, and it requires things like template selection.  Drupal generally wants a “menu” selection.  Joomla has a whole host of things it wants entered as if everything is a Web page.

Where I think vendors need to get is to have a core repository product at the center of their product line.  Other products would drive from this core.  Their WCMS would use the repository to store “pages."  The email management system would use it to store “emails."  The “Micro-Content Uber-Caster 5000” would use it to store “updates” that it pushed into Twitter, Facebook, and whatever else.

(Perhaps take some time to read a previous post: “The Dawn of the Web Content Delivery System."  It discusses the same concept of taking a back-end data and homogenizing it for Web delivery.  It concentrates on the collation of multiple, disparate sources, but the intent is the same whether you have one source or many.)

Now, some might argue that we already have this – it’s called a “database."  I disagree.  I think a content management repository wraps around a database and offers more advanced services.  (See this post for a list.)  There are content management-specific functions – versioning, workflow, permissions, etc. – that need to built on top of the traditional database.

(This reminds me of a conversation I had with my friend Fred Salchli from Duo Consulting in Chicago.  Fred said, “In the end, a CMS is just a ‘relational database management system management system.'"  I thought that was brilliant.)

You build outwards.  A SQL-compliant database gets wrapped in a content management repository.  This then gets wrapped (and re-wrapped) in a value-add product – a WCMS, a micro-content syndicator, an email management system, a records management system, etc.

Now, I suspect Peter Monks is reading this right now and just shaking his head.  Peter does professional services for Alfresco, which is a traditional “enterprise content management” (ECM) system. I know Peter is saying, “But we do this now...."  (with a “g’day mate” tossed in there somewhere).

And he’s right.  I’ve always thought that “ECM” was code-word for “not on the Web."  ECM systems are designed to manage pure content and then cast it into...whatever.  Alfresco wraps their core product with a WCMS, and there are a bunch of other value-add, non-Web-centric apps for it as well – everything from book publishing to asset management.

This is great, and possible because Alfresco was born out of Documentum, and Documentum was founded in 1990 before anyone knew what the Web was.  But systems born while the Web was in full swing were born with an identity crisis.  What we saw with WCM pure play vendors is that the repository and the WCMS itself got welded together into the same thing.

Fast forward to today and Wired explains that the Web is dead.  This means that a lot of WCMS vendors are now facing the fact that their product only natively supports one channel.  When there was only one channel, this was fine.  But that’s not the case anymore.

So, I think the next evolution in Web content management is for vendors to start backing repositories out of their core product into their own thing.  It’s only going to take a few of them trying to use their WCMS to store lots of non-Web content to realize that this is the direction they need to move.

Just watch.  The revolution will begin with someone at Ektron or the Drupal core team or some other pure WCMS vendor saying, “Hey...let’s make a TCMS – a Twitter Content Management System!”

With this, the pure repository will be born again.

Comments (4)

James Robertson says:

While I agree that we need to start managing a wider range of content than just web pages, I fear that moving CMS towards becoming generic content platforms risks throwing the baby out with the bathwater.

The DMS-becomes-CMS products show the danger. They were great at “content”, but terrible at “web management”. While the content of web pages is one thing, a great CMS does a lot to streamline authoring, site management, etc, etc.

I’m not convinced that web CMS vendors have spent enough time yet even understanding the current customers (web teams) before moving onto the next business need. Look how weak metadata, workflow and site management are in terms of meeting real world practicalities.

So while I’m all for the steady march of progress, I’d like the existing marketplace to mature a little bit more first.

Cheers, James

Deane says:

The DMS-becomes-CMS products show the danger. They were great at “content”, but terrible at “web management”.

And therein lies the key difference. We’re not going from ECM to WCM. We’re starting with a core WCM product, and abstracting a piece of it. So we’re going from the opposite direction than the one you have issue with.

fschaap says:

There is no link for the Micro-Content Uber-Caster 5000 you mention. Apart from this site, there is no mention of it on the web. It sounds like a serious piece of kit and we were wondering where we’d get it. Appreciate your help.

Vidar Langberget says:

Great post! I totally agree with you.

We have developed just what you are describing. We launched our first asp based CMS back in 2000, but decided to rewrite the whole CMS from scratch in ASP.NET in 2005. We spent a LOT of time on the data model to make it as flexible as possible. Several research grants from the Norwegian government allowed us to spend more time in getting the core of the system solid enough to be future proof. Most of our predictions back then about the needs in the future mirror your thoughts.

Everything in our system is built from a base object. That base object includes support for the CMS features you mention, like revisions, multiple languages, publishing workflows, permissions, caching and other core services. As mentioned, everything in the system like modules, templates, sites, files, users, usergroups, newsletters etc inherit from this base class.

Customer specific content types also inherit from the base object, or any of the other built-in types. All of these content types are defined in our “Semantic definitions module”. This definition, or semantic ontology as we call it, is then translated into an object model where the different content types end up as proper c# classes with strongly typed properties. Our ORM then handles the retrieving and updating the content in the relational database. All data access is done through the ORM using a strongly type query language(similar to LINQ. A LINQ provider is scheduled for Q4 2010).

There is nothing web specific in this core functionality, and we have used it in Winforms applications and traditional web based database applications where the customer doesn’t even know it’s running on our CMS engine.

The biggest advantage of our system as we see it is our support for content relations. By defining the content types, and the relationships between them, customers not only get a website tailored to their needs, but it also helps them structure their data according to their own domain terms. This also gives that data meaning, which is inferred from the relationships to other content, and the metadata describing the content. We call this content for semantic content, and we believe it is an important step towards the holy grail of the semantic web.

Sorry for the long post, I got a bit excited to see that someone else has the roughly the same thoughts as we do on this topic.. :-)