Architecture and Functionality in Content Management

The more I work with content management, the more I find that major architectural considerations are big indicators of how happy you’re going to be developing with any given CMS.

These are not specific, detailed functional questions (“does the system automatically generate RSS”). While those are important as well (see below the list for more on that), a system begins with its grand architecture, and I’ve found that this foundation really drives everything else.

So, at the risk of trying to sound all wise and sage, here is my battle-tested list of the most important architectural questions you need to ask of a CMS:

• How well does the CMS model content? Can you structure a specific content type by breaking it up into separate properties, which you can then access independently? Can properties repeat, so a property could effectively be an array of values?

• Does the CMS generate input interfaces for types automatically? How well can input be validated?

• How well does the CMS relate content, meaning how well does it let you associate pieces of content with each other? Can you do this implicitly by putting a piece of content in a certain place in the content tree? Can you do this explicitly by stating that a certain property on a piece of content is a reference to another object somewhere in the system?

• Related to the above, are nodes in the content tree actual content objects themselves, or are they other structures (“folders,” for instance)? Can you create a content object (of any type) and then assign “child” objects to it, which can also have child objects, etc.? Can you designate properties or settings to a node that apply to content below it?

• How easily can you get content out of the repository, by whatever criteria or method? How specific and granular are your searching capabilities, and does the content come back in a neutral format?

• When you retrieve content from the repository, how much information does it carry with it? Does it come back with clear and accessible information about its context? Can you “query” a piece of content to find out exactly where in the tree it’s from? Can you find out its path to the root of the tree? Can you find out if it’s in a certain branch of the tree?

• How accessible from code is the structure of the tree itself? Can you programmatically attach to the tree and navigate it? Can you isolate queries and other action by branches of the tree (“search from this node down”)?

• Is there an event model which can trigger arbitrary code execution when specific actions take place in the system? What are the defined events? What information is provided to the event handlers?

In writing this post, I’m struck by the difference between (1) an architectural concern, and (2) a functional concern.

Consider my example from above: “Does the CMS automatically generate RSS?” This is a functional question, defined as one which can be easily programmed around. If the CMS doesn’t generate RSS, but it has an architectural foundation sufficient to retrieve content in a neutral, “manipulable” format, then I can generate the RSS myself.

As a developer with the capability to write code, I find myself much more concerned with architectural matters. Functionality can be programmed, but I’m at the mercy of architecture. Put another way, give me the right tools and materials, and I can build anything. But give me nothing but a pile of sand and a toothbrush, and I’m pretty much screwed.

Someone who isn’t a developer, and who is buying a “boxed” CMS and just wants to plug it in, has to be much more concerned about functional issues. If they want RSS, they better be sure the CMS they’re buying supports it, because they have no way to program around that limitation if it doesn’t.

And that’s were functional stuff sells well, and why a lot of CMSs hype their specific, functional capabilities. As for me, I don’t care one way or another if your system automatically generates RSS. If it does, great, but if it doesn’t, I’ll write it myself.

Just don’t hype your RSS generator as the single, greatest benefit to your CMS and blow off the core architecture because problems there will make me much more bitter in the long run.