The Value-Add Side of CMS

I’ve been involved with dozens of content management systems – both designing and building them, and working with some of the big, enterprise systems. During this time, I hit upon a seemingly obvious point that it took me a while to grasp: content management and content publishing are two different things.

There are two sides to publishing Web content: First you create the content, store it, edit it, send it through workflow, get it approved, then stage it somewhere until it’s published. Second, you display the content on a Web page. The first is infinitely more complex than the second.

In one of the first content management systems I was involved in developing, our API was backwards. All the code was focused on publishing the content – displaying it on a Web page. There was no code for managing the content prior to publication – we did this all with raw SQL calls from the Web server. It was kind of an afterthought, I’m sad to say. In hindsight, we were looking the wrong way. Our programming talents should have been focused on the management and administration of content, not the publishing.

When I was evaluating Interwoven Teamsite for an enterprise implementation, I asked Interwoven for some display templates. They sent me a few JSP files, and I was a little confused. Reading through the code, I saw that they got a recordset from a database, looped through it, and displayed the records using simple scriptlets. Well, I could do that. Where was the magic? Where was the voodoo that we were supposed to pay $168,000 for?

I quickly learned that all the magic was on the administration and management side – getting the content to the point where those JSP files could do what they did. To get content approved and “sent to publication,” as it were, you have to :

1. Create the content item from library of templates
2. Edit it, no-doubt with WYSIWYG support
3. Identify related files (images or printable PDFs or whatnot)
4. Proof it in-context (as it will appear on the public site)
5. Send it to workflow
6. Let other people in the approval chain proof it in-context
7. Gather approvals
8. Revise and re-route as necessary

It’s long and complex process to get a content item from inception to approval.

You know what you have to do to “publish” it once it’s approved? Nothing more than standard Web development stuff that we’ve been doing for years with ASP, PHP, ColdFusion, whatever. Compared to the act of creating and managing the content, publishing the result is quite anti-climactic.

If I had to choose between developing the admin side of a CMS or developing the publication side, I’d pick the latter in a heartbeat. Displaying a database table on a Web page is not hard. So long as someone else has gotten a content item through the entire creation, editorial, and approval stages and provides me with a database record and supporting files, there’s not much else to it.

So, when you’re looking at spending six-figures on a CMS, understand that the value-add is on the “management” side, not the “publication” side. The entire point of a CMS is to get content to “publishable” state. After that point, it’s pretty much downhill and you don’t need a massive system to display the end result.