Web content management systems: find the appropriate solution

By David Walker (Google profile)

This is a long, evolving essay about choosing the software you will use to run your Web site - your Web content management system. It's for small and medium-sized organisations who do a limited number of Web-based transactions and who can't spend thousands of dollars a day maintaining a team of programmers and database administrators. If you're planning an online banking system or a 1000-hits-per-minute online commerce set-up or an airline reservation network, nothing below the next full stop applies to you.

For the rest of us, the bottom line is this: you probably can't solve all of your Web content management problems immediately. Start with a Web content management system that addresses your biggest and most intractable challenges and opportunities. Solve 80% of your problems, and get the solution in place, so that you can learn fast. Then find shortcuts for the rest. Find the appropriate solution, rather than the perfect one.

The Web content management problem defined

Web content can be articles, pictures, products, email archives, Flash presentations, streaming audio, whatever. There's an enormous range of things you might want to do with this content. You might need systems for creating the content (authoring), describing it (metadata tagging), changing and updating it (editing), letting several people edit it together (collaboration), letting the right people do the right things to it (workflow), stopping the wrong people from manipulating it (security), keeping track of how it has changed (versioning), deciding when to display it (scheduling), displaying it in the right standard format (templating), allowing it to be displayed by others (syndication), allowing it be displayed differently to different visitors (personalisation) and more.

Your system may start as a couple of junior staff with HTML editors and the Windows file system. But that solution doesn't scale. The average organisation's Web site or intranet has anywhere between one thousand and one million pieces of content. By the time the organisation has reached this size, it has a substantial Web content management challenge. You can meet this challenge by hiring more people or by scaling back your ambition - a smaller site, less adaptable, updated less often, with lower quality. Or you can bring in software to automate pieces of the challenge.

When you go looking for software to handle this automation, you'll find yourself like a shopper in some exotic bazaar, besieged by a hundred content management system (CMS) vendors all promising to fix your problem. And whichever solution you choose, you risk ending up out of pocket and unhappy.

The One Big System appears achievable

We have lots of examples of software that automates problems away. Excel makes it simple to recalculate huge collections of numbers. On a larger scale, accounting packages and bank computer systems do much the same thing. What we're after is software that does the same for web sites, their content and applications. The user opens it up when they want to do something, closes it when they're finished, and never worries about it. That's the whole point of information technology: create "silent machines" that organizations use but do not really notice, let alone spend time and money on.

And it certainly seems feasible. After all, the basic operation of a Web content management system was set out clearly in the 1990s by the then MIT (now Harvard) database expert Philip Greenspun (see http://philip.greenspun.com/internet-application-workbook/). Greenspun turned it into code in the late 1990s with the ArsDigita Community System (ACS), which in its early incarnations was for a time the world's most competent content management system. It has since been documented even more clearly by people like Bob Boiko (author of "The Content Management Bible") and David Rodriguez (http://dvrodriguez.com/), a former colleague of Greenspun's at the ArsDigita company. These basic operations are relatively simple to implement. Surely it can't be so hard to take this basic theoretical structure and build a single system that runs sites painlessly?

Since the late 1990s, software entrepreneur after software entrepreneur has pursued this goal - from one-man shops with a few lines of code, to content management specialists like Vignette and Stellent, to document management outfits like Documentum, to giants like Microsoft and Oracle. For a long time, analytical firms like Forrester, Jupiter and Gartner predicted the dream of painless site management was just around the corner.

High-end systems lack return on investment

The great surprise of the past half-decade of content management is that despite all the hundreds of systems, no clear winners have emerged. The powerful solutions remain mostly expensive

Early content management software often fell a long way short of ideal. The Harvard CMS pioneer Philip Greenspun was paid by a client in 1997 to talk with Vignette, a company set up to market the content management system built for the CNET site. He later posted on his site the report he'd sent to his client:

Vignette's StoryServer product does not do any of the things that their marketing literature claims it does. It is not a content management system. It is not a version control system. It is not a personalization system. The only sense in which it might be any of these things is that a programmer could use it to build one of these things. However, you could say the same thing about the raw Unix operating system plus a C compiler. Sitting through a meeting with them was for me a rather surreal experience. It would be rather akin to hearing Adobe pitch PhotoShop as a payroll check processing system.

[Link: Greenspun's 1997 Vignette report ... and the newer one]

(Having looked at Vignette, Greenspun threw himself into developing his own content management system, the open-source ArsDigita Community System (ACS). It failed for a complex series of reasons explored in his colleague Eve Andersson's Diary of a Start-Up and Michael Yoon's ArsDigita: An Alternative Perspective.)

As Greenspun later noted, Vignette also lifted its game. By the turn of the millennium it was actually performing a bunch of serious content management tasks for clients with enough money and programmers. But that didn't mean clients were happy. In 2000 I was offered a copy of Vignette's software by one frustrated technology manager. That same year I did a short consulting job for a start-up whose site launch had been delayed three months by - among other things - delays in getting a Vignette system in place. (The start-up eventually went bust a few days before the site was due to launch.) Whatever Vignette's merits, there was clearly a gap between what buyers expected and what the product delivered. And other vendors of six-digit price-tag Web content management systems seemed to attract similar angst.

You can't keep this stuff secret forever. In 2001 an established technology research firm, Forrester Research, began warning buyers to stay cautious. It examined a dozen commercial CMSs, including well-known solutions from Vignette, Broadvision, nCompass and Interwoven. Forrester's 2001 winner, Open Market Content Server, scored a mere 3.0 out of five. In a report entitled "Managing Content Hypergrowth", Forrester concluded that 2001's CMS offerings were "immature", that none adequately addressed all needs, and that the vendors all had very different visions of how the CMS will evolve. It also warned that organisations that have bought CMSs are going to run into problems maintaining and customising them - and that they are likely to discover nasty mismatches between their CMS and other software, such as application servers and outside systems. "Owner satisfaction will be short-lived", Forrester concluded bitingly.

Oh, and Forrester estimated that putting place a "basic content management system" in 2001 would cost a large organisation over $A1 million ($US650,000), and a fancy solution would cost much more. The now-defunct Scape.com, the most extreme example of an expensive Australian content start-up, spent several million dollars on a Vignette-driven Web site (and packed it full of barely-readable text) before packing it all away when the cash ran out.

One of the first analysts to see the business implications of this was Ovum senior consultant Alan Pelz-Sharpe. In an interview for this site in 2001 he declared that "a lot of the time, there's no business value" in a commercial content management package, that most packages left buyers with a lot of work to do themselves, and that vendors were delivering more complex and expensive systems than most users needed. (The interview was summarised on this site as "Interview with a content management heretic",

That was 2001. How much have things improved since? Not enough. In 2002 and 2003 Jupiter Research's Matthew Berk published pair of studies saying that Web content management systems often failed to live up to their promise:

"Today, more than 60 percent of companies that have deployed Web content management solutions still find themselves manually updating their sites ...

"Overcomplicated, end-to-end packages can as much as quintuple site operational costs over human labor alternatives. Unfortunately, the breadth of many vendors' all too-inclusive 'silver-bullet solution' vision has left these companies struggling with platform lock-in, overengineered site infrastructures, exorbitant technical maintenance costs, and per-business-user costs averaging as much as $25,000 per year ..."

• Jupiter found many commercial systems require "exorbitant technical maintenance" and reported "site managers frequently railing against the high costs of managing complicated content management software". And commercial packages were supposed to cut IT support costs ...
• Along with the cost of commercial packages comes risk, "with managers complaining of rigid or simplistic workflow, awkward interfaces ... [and] difficult integration with other applications".
• Among the biggest risks is that users will shun your expensive new system. "Nearly one-quarter of executives Jupiter surveyed [complained] of sparse adoption by end users".
• The best-known and most flexible systems only make sense for very large-scale Web sites. How large is very large? Jupiter's example: "A large hotel chain with over 700 international properties, each with its own Web site and local content requirements". If that sounds like you, call Vignette or Interwoven now.

Prices have come down in the past three years, especially among the companies flogging top-end systems, like Vignette and Interwoven. But top-end Web content management still costs serious money.

And the real cost isn't in the box of software. It's in the cheques you write to the people who install, adapt and maintain the software. And it's in the business opportunities you miss out on when badly-designed software makes Web site updates too hard - and users simply don't change the site.

In practice, Cheap and Simple trumps Costly and Complex

So some influential voices are starting to argue that many sites should, in effect, wait out this immature phase of Web site management. For the moment, they should content themselves with limited automation.

Among the most aggressive voices in that movement is Matthew Berk, the bloke who wrote those damning 2002 and 2003 Jupiter reports. Berk has been reporting on what sites are actually doing, rather than describing the idealised world portrayed by technology vendors and integrators.

Berk's core complaint: site management system vendors are creating generic solutions that actually increase the cost of running a site. Meanwhile, most businesses either have very simple needs that require only cheap, simple systems, or they have specific needs that the generic solutions handle poorly - or both. That means the vendors' ideal of a generic site management system "is completely wrong". "The development overhead is very, very high", says Berk, "and for 90 per cent of the problems, that's too much overhead."

A tiny technical team armed with Perl scripts and an Oracle database ran the first sites Berk worked on back in the mid-1990s. Berk recalls his fascination as he saw larger and larger teams implementing more and more complex platforms in the late 1990s and early 2000s to achieve essentially the same result.

Berk's experiences left him with a simple recipe. "Use the tools that are simple and cheapest," he says. That may mean:

• Perl or PHP scripts, which can range from very simple to sophisticated products like Mason, TYPO3, ExpressionEngine and Mambo. Many of these solutions have a cash cost of $0. Mambo has both an open-source variant and a supported commercial version.
• A low-end solution for Microsoft's IIS, of which Ektron's products are the best-known and most frequently lauded.
• Simple-to-use blogging packages such as MovableType and pMachine, which are increasingly being tweaked to meet broader site management needs.
• A multi-user desktop content management tool like Fog Creek's CityDesk, which assembles static HTML pages on demand from templates and content, then sends them to a server. (CityDesk can also manage templates for server-side technologies like PHP and ASP.Net.)
• A low-level tool like Macromedia's Contribute, designed to let non-technical users update carefully-marked pieces of sites.

Jupiter itself has proved an example of the power of simple and cheap. It bought Broadvision, then merged with INT Media Group, which was using Vignette in an implementation Berk describes as "an absolute nightmare". The Jupiter sites resolved those problems by going all the way back to the mid-1990s solution - Perl.

Patchwork systems compete with the monoliths

While simple and cheap is trumping complex and expensive, another pattern also persists: monolithic site management systems continue to be outrun by patchwork solutions made up of many technologies from many vendors. The combination of PHP and MySQL, for instance, increasingly dominates the business of serving interactive Web pages on the cheap - but Perl solutions still play a healthy role in Web site search. Java solutions tied to Oracle databases can site side-by-side with static pages served straight out of the Unix file system and edited via Contribute. A portfolio of different page, template and software technologies can all be maintained from CityDesk.

Traditionally, Web site managers have preferred not to admit their site tools look like a patchwork quilt. But this is the way the business is. Few sites are managed using just one perfect tool.

With time, this reality is morphing from guilty secret into best practice. In July 2004, the CMSWatch site editorialised in favor of the "growing - and we think healthy - trend in the marketplace towards assembling content management solutions from individual components".

This pattern isn't isolated to the niche of Web content management. It's part of a larger trend away from using expensive, monolithic packages to run complex sets of business processes. CIO magazine's June 2004 edition quotes McKinsey's Ken Davis: "People are looking for functionality in much smaller bites than are typically sold by the large vendors. So they’re going to niche vendors or writing their own ..." [Link: "Small is beautiful" at cio.com] Davis is commenting on CRM software. But the fundamental trends driving organisations away from what CIO calls "rapacious" large system vendors are also driving those organisations away from huge integrated Web content management solutions.

Keep your eye on the main game

Why do highly complex content management systems so often fall short of their aims, and why do simple collections of tools often perform surprisingly well? Probably because Web content can be so many things. It can be a Web-based software application. Or it can be an online diary. Or it can be both, right next to each other. Each of these things - and everything else you put on a Web site - has behind it a different set of complex needs. Your content management system is supposed to meet all those needs.

"Content management remains highly situational," says consultant Tony Byrne, founder of the CMSWatch site. "Your content is unique, and your management requirements will vary."

Figuring out those requirements is no small task. James Robertson of Step Two Designs offers a content management requirements toolkit and a free list of possible content management requirements that are worth looking over. But however you devise your requirements, bear four things in mind:

• Your content creators must use the system. That means that it needs an interface that rewards use. It must react fast. It must protect the user from losing their work. It must make content easy to find. It must ease tasks like including links and images. (I moved from a home-built ColdFusion system to the CityDesk desktop CMS for the shorewalker.com site because CityDesk's interface made me look forward to writing.)  
• Your programmers must use the system. If your organisation has a bunch of Java Web apps created by in-house programmers that interface with an Oracle database, you may want to find a CMS that uses the same technologies - or one that's so simple that the programmers won't spend much time working with it. (The original ArsDigita Community System, for a time probably the best CMS in the world, ultimately failed because it used the AOLServer Web server and the TCL scripting language. Both worked just fine. But barely any technologists or programmers wanted to work with those technologies.) If you don't have in-house database expertise, you may want to keep your high-traffic Web site running on static HTML pages, rather than getting yourself into the business of keeping a database running live on the Web 24/7.
• Not all requirements are created equal. For instance, many CMS texts stress the importance of complex workflow and versioning. In large publishing businesses, these are important. In most smaller organisations they don't matter as much. Workflow will consist of one person putting content into the system and another approving it to go live - the sort of task that can be accomplished with a staging server and email. Versioning may be adequately covered by a regular back-up.
• Content publishing is about more than technology. If you're updating your site regularly, your biggest issues may be about enforcing house style, or creating copy that actually provokes users to buy your product, or creating a usable interface to your Web apps. You may need fewer, more effective pages. "Even the most thoughtful projects may be misguided," suggests Adaptive Path's Jeffrey Veen. "Over and over I've heard the same complaint about these projects, 'Turns out, after all the budget and time we spent, we really didn't need a content management system at all. We just needed some editors.'"

All these conflicting demands and tensions mean that your CMs almost certainly won't do absolutely everything you want. It will be a compromise. In my judgment, most smaller organisations with limited budgets should accept that need for compromise, and get on with figuring out what's most urgent. Then you can put something in place and move on. 

How did Web development get itself rushed prematurely into the dream of generic, all-encompassing site management platforms? Matthew Berk blames the spirit of the late 1990s, with its belief in technology's magical ability to solve business problems. "That's a painful fact," he admits. "My hope is that analysts of the future will ... ask the hard questions."

It's also the case that vendors ... aggressively explore the boundaries of "truth". The Acme CMS Corporation will tell you that its product lets your decentralised business units harness the power of information and technology to seamlessly drive return on investment. But that verbiage is aimed at a business manager who doesn't really understand the complex net of technical and business challenges that content management presents.

The uncomfortable fact is that single-platform Web site management only works for large businesses and government organisations - and even then, often works at a surprisingly high cost. "I would not have believed we could get to 2004 and there would still be no great content management software," says Joel Spolsky, the programmer and entrepreneur. (Spolsky's software company, Fog Creek, created and markets the lightweight CityDesk content management system.) The biggest change in the environment over the past two years is that more people now acknowledge the challenges of content management software.

So address your content management needs with those challenges in plain view. Start by assessing what your content really needs to accomplish. Then invest time and a little bit of money on one or two of the cheap solutions described above. See what they do and don't do. Chances are that you will learn a lot - and you may decide that one of these lightweight systems does all you need for now.