As with any computing application, the choice an organisation faces when selecting a content management system (CMS) is to build it or to buy it. Compared with many other areas of business, IT holds out the promise that anyone, anywhere can come up with an idea and realise it in the form of a computer application. All you have to know how to do is make the computer understand what you're after. Or else employ someone who speaks computer-speak.

!Of course, it's never that simple. Speaking computer is not only harder than any foreign language speaker could imagine, but people produce frustratingly unreliable results and often cost a king's ransom. Enter the shrink-wrapped, boxed software product. All the work has been done, just plug it in, twist a few knobs, and it's working.

Anyone who works in IT or has encountered an IT system knows that "twist a few knobs" is in line for understatement of the century. More commonly known as "implementation" or "configuration", this has become its own gigantic industry, with massive consulting firms rolling out products like SAP, Microsoft Exchange or Lotus Notes for their own heaps of gold.

In content management, both extremes of build and buy co-exist. Because much of content management remains focused on the Web (or, by extension, intranets and portals), the legacy of Web design has permeated the industry. In no other business application does interface and graphic design, along with that fuzziest of notions, content, receive such priority.

And nowhere but in graphic design and authoring content do things get quite so customised and creative. Every marketing department worth its salt wants a website that is "different, exciting, beautiful and blows people away". And, as every IT person knows, the requirement for "unique" introduces a serious problem for anything standardised and shrink-wrapped.

For this reason, many websites and intranets having grown from the front-end were custom-built to suit that front-end. Development environments such as Microsoft ASP and Macromedia (now Adobe) Coldfusion offered Web developers a way to quickly and flexibly bolt functionality such as content authoring and retrieval right onto the glossy front-end pages made by Web designers. Witness the birth of countless thousands of proprietary content management systems built once for one website, to do just what that website needed it to do.

On the other side of the virtual battlefield, content management systems proper grew out of the online publishing paradigm of sites such as CNET and Hotwired in the US. Faced with overwhelming amounts of content needing frequent updating, often by multiple authors, as well as the ability to repurpose content across multiple pages and sites, they slowly invented what we know now as the CMS. At its heart: doing things not uniquely or creatively, but consistently and routinely. Every page, in essence, would look and be structured the same way. Each piece of content added would conform to the same guidelines. The point here was to deliver a predictable result to the user every single time.

In the corporate website and intranet environment, these two polar opposite approaches come face to face. Marketers still want sites that will "blow people away" and CMSs - often the domain of IT or other more technical roleplayers in the business - continue to pull toward standardisation.

And so, in today's CMSs, we have a rather uncomfortable marriage. Systems that attempt to standardise marketing and content originality. That try to provide a generic way to create something unique. Often in the hands of the very people who don't want to work in a standardised way.

The question facing organisations in the market for a CMS, therefore, is this: do we build a system that can satisfy our needs, and face all the commensurate time and cost overhead of that route. Or do we buy a CMS off the shelf that best matches our needs, and then try and to twist its knobs till it fits?

It's almost impossible to make a business case for that option. Few companies have the time or expertise to pull it off - particularly in a market that is rapidly becoming commoditised, is complicated and is full of products that are, at the very minimum, good solid content management systems.

How to select your off-the-shelf product has been covered at length elsewhere, but it is important to consider the issue of customisation, using the CMS's inbuilt extensions or development environment to fill in the gaps.

Consider this example: a piece of content on a home page that updates every five minutes by retrieving a piece of content from another website in the back-end, formatting it, and displaying it. Let's assume most CMSs could do this kind of job, but work with RSS or some standard syndication format, which this requirement doesn't meet.

This kind of requirement is exactly why no matter how flexible and packaged a CMS is, it will always come with the ability to be extended. While this is sold as a feature, it's actually just re-introducing software development into the mix. Yes, in a more controlled and less risky way. But it's the same kind of work.

Why is this? Because the front-ends in particular of websites or intranets are so flexible, it's practically impossible to genericise all the possible back-end functionality required to deliver them. How expensive a CMS system is, is often directly proportional to how many of these flexibilities the company has tried to genericise. In other words, how many custom front-ends the system can deliver.

Of course, as in the example above, there's no guarantee that with extra expenditure the system will perform to spec. And "precise" is the key, because as any technical person will confirm, if the requirement is changed even slightly, it can make the generic tool useless. And invoke the need for the same programmers the shrink-wrap option was meant to obviate.

And this is almost guaranteed to happen, at least once but probably many times on any CMS implementation. The trick, as it turns out, is to find a CMS not that has all the features, but which also meets the basic requirements of usability, performance and basic content management, and which then offers a quick, intuitive and friendly development environment to build all the bits it lacks.

This is true in many corporate software applications: it's not unique to CMSs. But it is a vitally important factor to consider when making a choice and when planning a project. And when you buy that shiny new CMS because it says "supports feeds and syndication", don't take that or anything like that at face value. The devil, and the money, and the effort, is very much in fine detail that differentiates the standard, generic feed from the one you and your team have set your hearts on.

An article from Bizcommunity