May 2013
M T W T F S S
« Jun    
 12345
6789101112
13141516171819
20212223242526
2728293031  
 
  »

How to Avoid CMS Selection Confuction

The backstage manager was pacing all around by his chair
“There’s something funny going on” he said ” I can just feel it in the air”
- LILY, ROSEMARY AND THE JACK OF HEARTS

Let me tell you a secret. I probably shouldn’t, but I’ve been reading a few more “How To Select A CMS” posts recently and, truth be told, they’re the same as they were when I stopped reading them way back in 2011. Exactly. The. Same. Which is a bit depressing really.

So this is just between you and me: The features of the CMS don’t matter. At least not in the long term compared to the big things that’ll fuck you over. You know that big RFP feature matrix? Horseshit. The lovely demos in the vendor Dog And Pony shows? Yawn. Interviewing all your stakeholders? Ho hum – they don’t really have a clue.

Sure, you might have a decent idea of the features you need today. Maybe even in six months? But you don’t have a scooby what’ll happen next year. You could get broadsided by your vendor going to hell. Or that new CIO who wants to (de)centralise. Or that company merger. Or your department mandating Technology X or Open Source or Some Insane Security Policy. Or the thing that doesn’t exist yet that’s going to disrupt your ass back to the stone age.

Here is what matters. Your content needs to be able to outlive the technology that houses it. This is the most important question you should ask in any selection process:

Question 1: “If we select you, and it all goes tits up, how would we get our content out of your system and into something else?”

If it is painless to get your content out in a sensible form, you can’t go too badly wrong on your product selection. This is especially true if you don’t need to shell out a whole lot of cash up front for the software, but you are paying-as-you-go.

So that’s the software problem solved. But, as we all know, it is actually the services where you’re spending a whole lot of cash. So you’ve got your integrator estimate of a few tens or hundreds of man days. That’s a lot of bodies scuttling around on your project doing a whole lot of very important things. So take a step back and ask yourself the next most important question.

Question 2: “What the fuck are all those people actually doing, and what part of that work could we keep if we moved to another system?”

Some of the work is independent of (and should probably predate) the technology selection. Strategy, design, information architecture, content type modelling, business process modelling and all that good stuff. But on the technology side, there are some pieces that take a fair bit of time and should result in a portable asset. At the very least, all work creating the actual HTML should be independent of the system. If you’re using a standard templating language like XSLT (bite me, @pmonks) or FreeMarker or mustache.js, parts of your templating layer could migrate. And of course any hardcore business logic should be exposed by an API that could outlive your CMS. But if all these busy systems integration bees are plodding away on tech that you need to chuck should you change system, you’re probably doing something wrong.

So it is as simple as that. Read your Darwin again. Change happens. And it will keep happening at an ever increasing rate. Pick something that can change with it. Make portable content and portable technical assets. Don’t make monoliths.

  • del.icio.us
  • Facebook
  • Google Bookmarks
  • Digg
  • LinkedIn
  • StumbleUpon
  • Technorati
May 13th, 2013 | 2048 comments | Category: Future of CMS, Ramblings

2,048 comments to How to Avoid CMS Selection Confuction