By Deane Barker | November 28, 2006 | 3 Comments
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?
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, “manipulatable” 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.
What This Links To
What Links Here
Thanks for posting this, Deane. I think it’s a great round-up of criteria not only for selecting a CMS app as a customer but some great general considerations for the programmers of any app (CMS or otherwise) when they’re sitting down to design the system. It strikes me as a good start for a checklist of good code hygiene.
Any app that’s been thoughtfully designed and provides a good class interface should, almost as a natural result, provide the necessary hooks to get at data (and define new data collections) in the broad, neutral ways that you describe. That kind of tidy design isn’t just a marketing nicety, but just plain survival: it makes it easier for the developer herself to maintain and extend the application. And hey, whattya know, if that API is documented and customers have access to the source, that means that they can extend and customize the app, too, just as you describe.
Big Medium 2 is the CMS that I’ve built (thanks for all the attention lately!). Even though it falls squarely in your category of “boxed” products aimed at an end user audience, it has a clean API that other Perl programmers can use to add new content types (from scratch or via inheritance), create new content relationships, new output formats, browse the data, climb the taxonomy tree, validate data, etc.
I built Big Medium 2 to be flexible and expandable because *I* need it to be that way to maintain and extend the code without losing my mind. Happily, that means that others will be able to do the same thing, too. Folks can use the same code that I do to create plugins without touching the core modules. (Er, that is, as soon as I get around to actually documenting the API, which I plan to do shortly after the commercial release of Big Medium 2.)
But let’s not undersell the value of having those finished, polished features there, too. Finding an app with pre-established content types and features that match your own needs can often mean avoiding the need for additional programming entirely. “Boxed” doesn’t necessarily mean “boxed in” as long as the general design matches your needs and the box offers you room to grow.
Your point is well taken, though. The box is even better when it comes with a pair of scissors and extra cardboard for your own customizations.
Nice posting Dean and I went ahead and took an excerpt of your post for my front page of my site (hope you don’t mind). By the way, it looks like you are already stealing some of my “fans”. :-)
I think many in IT have a hard time talking about the architectural flaws in their CMS simply because what do you do after you’ve identify the flaws?
A feature in a CMS usually can be added, modified, or deleted from the application without too much impact to the rest of the CMS. However, what if your CMS has architectural design issues? When you address a flaw by making changes in the architecture you’re likely having to restructure the entire CMS to actually address the “real” problems. Costs and alienating customers are usually the main concerns of any system architecture redesign.
Then again, as you point out, if core architecture problems are not properly addressed the customers are likley to get very bitter.
This is a very complex topic. Architecture and functionality are hard to balance in a CMS. No CMS can foresee what it will be used for in the future, and it just can’t develop an architecture and functionality that will encompass everything.
I work mainly with Joomla and Drupal. One of the missing functionalities in Joomla is user profiles. Well this can be thought of a having an open architecture to build your own profile system. This however has the effect that every developer wanting a community or social networking site has to develop their own, when there could be a single API they could have worked with. In the case of Joomla, the first decent extension was Community Builder, because of this, you have numerous extensions based on the Community Builder code even though it didn’t have an API. So you have hundreds of broken extensions in upgrades, and now that they have other extensions available for profiles, if you develop an extension, you have to actually build support for more then one functionality.
Now it is hard to see just whether profiles would be functionality or a framework in that case since Joomla never was intended for Social networking. If it was, then it would have had a different architecture. So architecture depends on the features you are aiming for in the end user, which means they closely affect each other.
Now on the other hand, if Joomla had provided a profile functionality, then you would be bound to that functionality. Something like integrating OpenSocial would be a headache when with the current open framework, it is trivial.
So it really is two sided.