Real Story Group. Make Better Technology Decisions.

Adriaan Bloem

Do you need a simple or a complex CMS?

7-Jul-2010

Tags: Web Content Management, Marketplace at Large, Open Source, Selecting Technology, DotNetNuke, Drupal, Drupal Commons, Joomla!, TYPO3, WordPress , WordPress

I sometimes warn that a vendor's content management system is well suited to "simple" scenarios, but not necessarily a good fit for "more complex" cases. That's a bit problematic: "simple" and "complex" are very subjective. So let me elaborate.

First, to illustrate: about a year ago, I read Jon Mark's blog post: "when most Twitter users say CMS, they mean WordPress, Drupal or Joomla!. [...] So I panicked a bit. I know WordPress. We very occasionally see Drupal in a vendor selection, and never see Joomla! at all. I've never been involved in an implementation with either. [...] So, are we really that out of touch?"

I'm sure there are many out there that would immediately have thought Jon really was out of touch. Because WordPress, Drupal and Joomla account for millions of implementations. To the general public, if they even know what a CMS is, those three have almost become synonymous with the term. To the point that even a serious newspaper like the Guardian would suggest WordPress as the ideal CMS for the Birmingham City Council, lamenting WP never got a fair chance: "Why wasn't it good enough for Birmingham? It seems that there's a prevailing mindset in some parts of local and central government that thinks that if you (actually, taxpayers) aren't paying through the nose, then you're not getting value for money."

Stop right there.

Yes, millions are using these systems and are perfectly happy with them. (In fact, I've commented a few times how, for instance, WordPress is one of the few systems that casual editors actually like to use.) That's why they rate very well in the "simpler" scenarios we describe in our Web Content Management evaluation research. And most of those millions of implementations fall in one of those categories. On the other hand, there are, for instance, no multinationals running all of their online efforts on simple open source PHP systems. Not because they're against open source, or because they think PHP isn't good enough, or because they're eager to "pay through the nose." But because these systems don't really work in their scenarios. (As a side note, I'm not even generalizing all open source PHP systems here -- some, like Typo3 for instance, are quite complex; and a .NET open source system like DotNetNuke is quite straightforward.)

Saying you could do "anything" with any given CMS is true to an extent. But it's like saying that the bicycle that's so healthy for your daily commute, would also be great for a ride to the South Pole. Sure, you certainly could, but the real question is: would you really want to? And if all you know is bicycles, wouldn't planning a trip to the pole be a great occasion to find out what other transportation would be available?

So what does make a project more "complex" than those "simple" scenarios? Well, we could talk about that for a long time (in fact -- it's what we do on this blog most of the time). But to give just a few examples of what would go beyond a "simple" scenario; some of the things that quickly add up complexity:

• Scale of the CMS deployment: Having hundreds or thousands of contributors, and tens or hundreds of thousands, or sometimes, millions of content items. If a CMS tends to display users or content items simply as lists (newest on top, or alphabetically) you can imagine this becomes rather unmanageable at this scale. You really need a lot more sophisticated controls to deal with it, such as efficient search. It gets quite hard to find out who's doing what, where, and when in your system without repository services, audit trails, integration with directories -- and so on.
• Scale of the published websites: Running a simple PHP CMS on a hosted LAMP server is quick and easy. However, you may find that what works for thousands of visitors doesn't at all scale to millions. Many of the simpler systems we cover are actually much harder to run when you try to use them for high traffic (because they aren't really prepared for it, so you'll have to customize, adapt and use a toolbox of tricks) than complex systems which come with out-of-the-box functionality for massive scaling.
• Content re-use: When you want to use the same content in multiple places in a website, and/or in multiple sites or channels. Especially when this involves placeless content, deployed based on different criteria (automatically and manually). It will quickly build up the complexity of both the core system, but also the interfaces in order to keep it all manageable and intelligible for users.
• Globalization: Just take a look at an airline website. There's not a shocking amount of content, but usually it'll have to be available in at least dozens of languages, in multiple websites targeted at various countries. This means content needs to be translated, but also adapted to nuances of local requirements. Managing this effectively is quite hard, and complexity tends to increase exponentially for each locale added.
• Workflow: In many cases complex workflow is overrated, and straightforward "save - review - publish" would be more than enough. But there are scenarios that won't do at all. If, for instance, content has to be checked by legal, or translated into multiple languages, preferably (to save time) in parallel, you need to be able to design complex branching workflows to deal with this.

Of course, there's a lot more, and if this interests you, I'd suggest you have a look at the introductory chapters of our Web Content Management research. But suffice it to say, when I say "this system is great for simple scenarios, but don't think it'd be just as great for complex scenarios" -- I really do mean complex scenarios. (But that doesn't mean I hate bicycles.)

In the end, what it boils down to is using the right system for the right job. Use something simple and cheap for a simple problem. But don't forget that sometimes, complex problems demand complex solutions. It would be ridiculous to buy a train to get groceries; just as ridiculous as getting a bicycle to haul tons of bricks.