Personal tools
You are here: Home To CMS or not to CMS?

To CMS or not to CMS?

by Justin Alan Ryan — last modified Mar 13, 2008 05:26 PM

What is a CMS for? What advantages does it offer an average business or organization? A web consulting business? What core considerations should go into its' design? Who cares?

For a few years now, I've been working primarily as a web application developer using the Free and Open-Source Plone Content Management System.  That's a pretty loaded statement, and probably the most loaded bit of it is that TLA, CMS.  I can rant on for hours to a S.W. Eng. crowd about the merits of componentized development - something the Gartner Group recently said is more important than Programmer Productivity - of using a consistent framework, the beauty of the Python language syntax in simplicity and power, where I think this technology should all go, and how "Content Management" can really encompass almost anything that you would normally label as a "Database".  Rather than do that, just now, I'm going to keep it simple and answer one simple question:

What the hell is a CMS?

A CMS is an editable website, pure and simple.

CMSes are primarily advantageous to people who really don't understand how websites work - oh, and people who *do* and who want a consistent, manageable look-and-feel.  A CMS is an editable website, pure and simple.  If you think that Plone and Zope are stupid and you want to use Drupal or Joomla or OpenWhokavetzit or spend a million dollars on an Oracle-powered Vignette or Documentum solution, the fact is that CMS' are worthwhile and that flat HTML enforces a Tyranny of Competence on the most important people in the technology chain - innocent users.

Most people are familiar with today's common breeds of web applications: things like forums, galleries, blogs, social networks, and webmail.  All of these are content management applications, much like all of the "programs" on your "laptop" or "desktop" boil down to "computing" at some level, and in fact, the need for true, flexible content management solutions arose from people's abuse of these simple tools to accomplish wildly different tasks than they were designed for.  Charles Darwin could have told us this would happen, we're adaptable animals, but we forget sometimes that computers are intended to adapt to our needs, and that even if sometimes accomplishing the simplest thing with them seems futile, they actually can adapt to our needs very well, if we just ask nicely.

Following that, those of us who deal with content management are really just looking at the world through the glass of a new abstraction paradigm.  For some years, a lot of folks including myself have promoted the idea that it's far more efficient to use a pile of simple, goal-driven web applications and that 'integration' is an ivory tower, as any developer will tell you how innately incompatible almost any application developed even with tomorrow's best practices will be.  I didn't cling to that idea for very long, though, as I found myself reinventing the same few wheels in each of these supposedly "simple" applications - esp things like security and navigation, not to mention the umpteen browser-specific fixes that must go into each site.

Why one big thing and not lots of small things, haven't you heard of K.I.S.S. ?

I have two answers for this question, one of which is explained in another post, and the other I'll express here: If you've ever tried to make a bunch of tangential web apps look like they are part of a coherent information space, you know that the story ends with your employer saying "it's okay, it's good enough."  Then, later, you might get fired - welcome to the information age. ;)

I must say that my favorite answer to this question, linked above, really pertains more to what sort of technology you should choose for your website, whether you want to call it "content management" or not, so it may be a bit unhelpful to people who have trouble promoting other technologies.  Even if you throw away Python, Zope, and Plone and use some PHP and MySQL Hoobajoo like Drupal, the answer to this question is really still the same: all of those "small things" - the weblogs, the galleries, the forums, become much smaller things when they are developed on top of a CMS, have much more consistent interfaces, are easier to migrate to alternative solutions using the same CMS technology.

Get to the point, already!

a good CMS is a toolkit for building web applications and a program for making simple, editable websites

You're right, I'm tired of talking in circles.  I'm really talking about using Free and Open-Source CMS software, but many of the tenets will even shine true for commercial solutions, if you don't care about the pricetag.  The revelation I'm trying to drive here is that a good CMS is a toolkit for building web applications and a program for making simple, editable websites.  If you're considering that you'd like both of those problems solved, and you've spent droves of money for years and years chasing this goal, maybe you should consider the potential harm of forcing your web apps to be more like angsty siblings than connected hemispheres of one mind.  Further, if you're concerned about the cost of investing in learning much about a given CMS product, you should really revisit the cost of being an expert in ten systems, instead of one system and ten or fifteen add-ons.

The whole thing makes more dollars and sense than a lot of people would like to believe, and some reasons for people hanging back from launching a CMS are entirely valid, just as with any technology transition - change is painful, it brings risk, shakes up expectations and routines, and may even threaten people's position in the world.  Many organizations are just beginning to adopt technology, and while in fact this is the absolute best and possibly only opportunity for them to leap the hurdles of mediocre software, once people are introduced to a tool, it becomes infinitely harder to change.

So, what?

Use a CMS already.

Document Actions