Web Magazine for Information Professionals

Content Management Systems: Who Needs Them?

Paul Browning and Mike Lowndes explore the CMS concept and look at the available tools.

Content management? That’s what librarians do, right? But we’ve already got a library management system (LMS) – why should we consider a content management system (CMS)?

The second initial is perhaps misleading – “manipulation” rather than “management” might better summarise the goals of a CMS. Content creation and content re-purposing are fundamental aspects which tend to lie outside the current LMS domain.

Actually, from the point of view of workflow (and to lesser extent content re-purposing), the CMS and LMS have much in common. With an LMS acquisitions staff use Web-based templates to create records for new stock. Cataloguers add value to the record (with less experienced staff being subject to an approval process). Metadata is recorded automatically detailing who entered/modified content and when. A subset of the record is then re-used in several ways - as a page on the Web OPAC, as paper recall notice or an e-mail recall notice.

It will be interesting to see whether the content re-purposing demands of accessibility legislation will be readily met by the LMS; any CMS worthy of the name should have no problems automatically generating Web pages in large fonts, or in the right mix of colours or in text-to-speech optimised ways.

So, if an LMS is capable of workflow and modest content re-purposing, then it must be the content creation aspects of a CMS that are the principal discriminant. But librarians don’t do content creation, right? They sit lower (or is it higher?) in the food chain.

Well, it rather depends on your view of what libraries and librarians will be doing in the future. Job descriptions and system specifications are rapidly blurring. We are all hybrid now.

The boundaries of the CMS space are fuzzy. Substantial overlaps exist with document management systems, knowledge management systems, enterprise application integration systems, e-commerce systems and portals. There are also significant (but as yet not generally recognised) overlaps with intranet groupware and virtual learning environments. Indeed, it may turn out that one institution’s ‘managed learning environment’ is another’s CMS.

The hybrid librarian embracing things like the Open Archives Initiative or Virtual and/or Managed Learning Environments cannot avoid becoming involved in the process of content creation.

Will the LMS enlarge its feature set to cater for the demands of content creation? It seems more likely (and greatly preferable) that the growing demand for products based on open architectures will lead to the right hooks and sockets being provided so that interoperability between systems can be achieved. Hybrid librarians would do well to maintain a watching brief on the CMS space so that they are in a position to cherry pick the most appropriate features in the future.

The Concept

A Content Management System (CMS) is not really a product or a technology. It is a catch-all term that covers a wide set of processes that will underpin the ‘Next Generation’ large-scale web site.

The pervasive nature of the Web means that it has become the preferred vehicle for content delivery. ‘CMS’ should therefore be read as ‘Web Content Management System’. Institutions have no shortage of ‘content’ - be it data, information or knowledge. When the creation and publication of content is well managed then the organisation functions more cost-effectively; it is also likely to lead to better decision making.


Prospectus example

Engendering the re-use of information by allowing the ready integration of data from diverse sources.

A Web prospectus page describing a programme might draw together information from such sources as the student record system (for curriculum data), the personnel system (for details of teaching staff ) and an imagebank (containing attractive pictures).

Permitting the efficient re-purposing of information.

The same prospectus page might be rendered a PDF (for high quality hard-copy), as plain text (to be sent as an e-mail message) or optimised on screen for a partially-sighted user.

Allowing information maintenance to become devolved but at the same time preserving central control.

The prospectus entry can be devolved to its academic director but, before going live on a pre-assigned date, a member of the marketing department would first check the amended text for factual and stylistic consistency.

Ensuring presentational consistency by separating the design of Web pages from the content they display.

The academic director would be provided with a template to enter the information about the programme ….

De-skilling the task of putting information on the Web.

…. which reduces the task to no more than ‘filling in the boxes’ on a Web form or a word-processor document.

Facilitating good information management practice so that appropriate metadata are captured at the time of content creation or modification.

The relevant prospectus page is ‘stamped’ with the name of the maintainer, the creation or modification date, an expiry date (which would later cause the automatic generation of e-mails to the maintainer of the information at regular intervals before this date) and incorporation of keywords to ensure indexing by search engines.

Permitting some past state of the Web site to be re-created or restored.

The edition of the prospectus from two years ago can be re-constructed.

Table 1: The business benefits of a CMS

The key goal of a CMS is the increased integration and automation of the processes that support efficient and effective Internet delivery. The means by which this is achieved, placed in the context of a university prospectus, are summarised in Table 1.

We limit the scope of this report to those features that might be regarded as ‘mandatory’ for a CMS in the HE/FE sector. This feature set can be expected to change in the near future. There are several related applications that are often included in the feature lists of content management software. We will not cover e-commerce systems, though several large-scale commercial CMSs are essentially e-commerce management packages. We will not discuss post-deployment applications such as Web site personalisation, searching, noticeboards, guestbooks, etc.

The present report therefore concentrates on the content management issues relevant to the ‘outward facing institutional Web’. It is ironic that, because of the growth of intranets, the outward facing Web will become a quantitatively minor part of the institutional Web (Fig.1). However, in the context of current challenges and risks, the outward facing Web will continue to exercise the minds of senior managers in the medium term.

graphic showing evolution of the Institutional Web
Figure 1: The evolution of the Institutional Web

Within this scope, we have placed the functions of a CMS into four categories: Authoring, Workflow, Storage and Publishing (Fig. 2). A CMS manages the path from authoring through to publishing using a scheme of workflow and by providing a system for content storage and integration.

Authoring is the process by which many users can create Web content within a managed and authorised environment, whether it be a simple line of text (e.g. ‘The University administrative offices will be closed next Monday’) on a ‘What’s New?’ page, an entry in an online course discussion group, or the entire Postgraduate Prospectus.

CMS functional scope and content life-cycle diagram
Figure 2: functional scope and the content life-cycle (after Ort [1] and Vidgen et al. [2])

Workflow is the management of steps taken by the content between authoring and publishing. Typical steps could be link checking and review/signoff by a manager or legal team. If workflow has existed at all in traditional Web site management it has been an off-line affair and not built in to software processes.

Storage is the placing of authored content into a repository. Beyond this it is also the versioning of the content, so that access conflicts between multiple authors cannot arise and so that previous versions can be found and restored if required. It can also mean breaking down content into structured, meaningful components such as <job title>, <course> or <description> which are stored as separate elements. These can be stored as records in a database or as Extensible Markup Language (XML) files.

Publishing is the process by which stored content is delivered. Traditionally this has meant ‘delivered to the Web site as HTML’. However, it could also mean as an e-mail message, as an Adobe PDF file or as Wireless Markup Language (to name but a few). In the near future multiple delivery mechanisms will be required, particularly as accessibility legislation starts to bite.

We have summarised the advertised features of CMSs into a ‘CMS Feature Onion’ (Fig. 3). The feature sets typical of the different styles of CMS are reviewed in greater depth below.

The Issue

Institutions are struggling to maintain their Web sites. Out of date material, poor control over design and navigation, a lack of authority control and the constriction of the Webmaster (or even Web Team) bottleneck will be familiar to many in the HE/FE sector.

The pre-millennial Web has been characterised by highly manual approaches to maintenance; the successful and sustainable post-millennial Web will have significant automation. One vehicle by which this can be achieved is the CMS.

The concept of ‘self-service authoring’, whereby staff do not need special skills to edit the content for which they are responsible, can be regarded as a major step towards acceptance of the Web as a medium for communication by non-web specialists. Providing this is the key advantage of a CMS. As local information systems integrate and become more pervasive, self-service authoring extends to the concept of ‘write once, re-use anywhere’, in which the Web is treated as just another communication channel along with email, word processor files and presentations, etc.

CMS Feature Onion (diagram)
Figure 3: The CMS Feature Onion

The market place is very crowded and continues to grow (Faulkner Information Services estimates the market will grow to $65 billion by 2003 [3]). A list of 98 products claiming to offer a CMS (or components of one) was compiled in September 2001. The preceding year saw a number of new products and the loss or re-orientation of many others, although the number of products available continues to increase and diversify. Currently, therefore, investing in a CMS is potentially more of a risk than for other, more mature categories of information system.

This state of affairs, however, should not dictate inaction. The core features offered by most CMSs are sufficiently well developed to make the conversion of a traditional web site an undertaking that should be welcomed by all stakeholders, without the fear of having to re-engineer the web site again in the future.

The boundaries of the CMS space are blurred. Substantial overlaps exist with document management systems, knowledge management systems, source control systems, enterprise application integration systems, e-commerce systems and portals. We also contend that there are significant (but as yet not generally recognised) overlaps with intranet groupware and virtual/managed learning environments. Indeed, it may turn out that one institution’s ‘managed learning environment’ is another’s CMS.


The core features of a CMS

In order to provide the functionality required by a complex, large scale, multi-author anddynamic web site then many features are desirable. Some CMSs try to contain them all, but it is unlikely that everything you may need will be available in a single product. It is the authors’ experience that a pragmatic ‘buy and build’ approach is best for the HE/FE sector [4]. The features likely to be of interest to the HE/FE sector are displayed in the ‘Feature Onion’ (Fig. 3).

To be called a CMS a product or set of tools will, in our view, provide three core functions:

This core feature set is augmented by a list of additional functions that varies significantly from product to product. These additional CMS features can be grouped into the five major categories shown in Table 2. A complete product – feature matrix is beyond the scope of this report, though others have attempted this [5, 6, 7].

The CMS product marketplace

There is a tendency for those new to the technology to lump all CMSs together. In some comparative reviews of CMSs, products with widely different origins, functionality and goals are compared as like with like, often because not enough information about the systems is readily available.




User Management

Assigning a role to a user, providing access rights and perhaps the level of interaction with the system. This can often use existing authentication schemes.


Active Directory, ACAP

User Interface

Preferably a browser-based application for both content provision and CMS and/or web site administration.



Java, HTTP,


Data Sources

These include the managed storage of created content, plus external data in so-called ‘legacy systems’ (Word or Excel files, for example, could come under this heading) or other CMSs. Storage methods can be file systems, flat file databases, relational databases, and more recently, object oriented databases and XML files. The key is in the flexibility of the system to cope with its intended use. Storage also requires that the data itself is described. This is known as metadata, and creating it should be a requirement of storing content.


Dublin Core,



These integrate the content with existing data and authentication systems, and perform specific software manipulations on the content to aid consistency, simplicity and management. The key application is usually a form of ‘templating’ allowing control of web site ‘look and feel’ to be centralised and making style and navigation changes simple to implement. It can also include the ‘middleware’ that connects database records to dynamically created web pages.

Perl, PHP,

Java, Python,






Publishing the web site to the live web server(s). Some CMSs do not distinguish between development and production servers, running the web site itself from the same software as the development system, creating pages dynamically on demand. Popular pages can be built in this way and then ‘cached’ in memory or on disc, speeding up future retrieval. Other systems have a strict partitioning of ‘staging’ and ‘public’ environments requiring separate web servers, often residing on separate machines. In this case the entire structure may need to be replicated if all pages are dynamically created. In other cases, certain elements of pages are pre-rendered and published as static content, with only specific dynamic content being accessed via the public server. It can be said that there are almost as many different methods of live publication as there are products available.




Table 2: Non-core CMS feature categories and related ‘standards’





Document Management Systems

Software designed to manage the storage and internal publication of ‘corporate’ information

Document lifecycle workflow, metadata, document translation

Documentum, Panagon 2000, ChangingPages

Electronic news/magazine publishing

Tools developed to aid online publishing of magazines and news websites, and electronic discussion groups

Simple workflow, speedy publication of simple content, authoring tools, information management (structure), timed delivery

Eroom, Expressroom, Conversant, SlashDot, Frontier

E-business / E-commerce

Software underlying online shopping and electronic customer relationship management

Simple database management, website personalisation, built in transactional systems

Vignette, Broadvision, ATG Dynamo, Open Market

Source / versioning management control

Software engineering process control/source control among groups of programmers

Roles-based authoring and version control, workflow, templating systems.

Content Management Studio, Interwoven TeamSite

‘Middleware on steroids’

Tools for dynamic web site creation from filesystem and database assets. E.g. PHP, ASP, ColdFusion, JSP. Products such as WebObjects, Cache Objects for the Web and Tango 2000

Asset management, dynamic delivery and simple authoring environments.

Enhydra, Midgard (PHP), Dmind DSM (ColdFusion), SiteGenesis, Obtree.

Web content management frameworks

‘Second generation’ tools, built from the ground up for dynamic website creation and management. Can have very diverse conceptual grounding.

Variable, most try to cover all functions.

ACS, eGrail, Engenda, Mediasurface, NetObjects Fusion, Spectra, Xpedio, Zope

XML processors

A ‘third generation’ of CMS products appearing based upon XML technology.

Granular control and re-use of content. Though many of the above systems can now utilise XML, these products are written specifically to create websites using XML to store data, and related technology (XSLT, RDF) to manage and deliver it.

Cocoon, Interwoven TeamSite Templating, Lychee, Rhythmix, Tamino, POET

Table 3: Different CMS types

Vendor literature is generally over-hyped and jargon-ridden. Terms like ‘personalisation’, ‘syndication’, ‘asset management’ and ‘re-purposing’ abound. This can cause confusion among those who are confronted with major technological and financial decisions.

However, it is possible to define several generic types of CMS based on their apparent provenance, and this can help in assessing their suitability for a particular use. Feature sets are converging, though products are often aimed at different markets.

Table 3 provides a list of the broad approaches that appear to have been taken by CMS developers and gives selected examples.

Which of these could be a best fit for the HE/FE sector? Given the diverse nature of content that an institutional web site must deliver, it would be misguided to consider a product with a specific focus on e-commerce, or with a single database as content repository for all applications. Similarly systems with a document management provenance are likely to be tuned for intranet usage rather for the outward facing institutional Web.

Generally, more ‘open’ and framework-like products are more likely able to handle the broad range of content a HE/FE institution wishes to communicate. Care should be taken to examine the ‘out-of-the-box’ features as this will define how much post-purchase customisation is needed. The experience of mainstream business is that many large scale CMSs cost more to implement than to purchase. It is never a case of simply ‘buy’, but ‘buy and build’.


The large number of competing products in the CMS space has already been noted. Many analysts see a market shake-out as inevitable (not unlike that which occurred as the relational database market matured). The recent acquisitions of NCompass by Microsoft and Allaire by Macromedia are perhaps the start of a pattern, which will be repeated by other big players. Once this happens it will be hard for minnows to compete if they have an orthodox business model.

An alternative approach to web content management is to build a CMS from scratch using ‘middleware’ plus other component tools (only some of which are listed in Table 3). This option has been fuelled by the open source movement (and some high profile expensive failures [8] of CMS projects using ‘market leading solutions’). It has led to the emergence of a new business model (which is perhaps exemplified by Digital Creations - the providers of Zope) in which a company ‘gives away the family jewels’ but then generates revenue from consultancy work.

As well as the ‘buy’ and ‘build’ routes, a third option is also available - ‘rent’. The ‘application service provider’ (ASP) model has attempted to get a foothold in many sectors and the CMS space is no exception. However, the same issues (e.g. security of information, vulnerability of service) that have led to a slow embrace of the ASP option in other sectors, applies equally to CMSs [9].

Standards in this area are still forming, with no clear ‘winner’ beyond the consensus that XML will be an important framework for inter-application communication. XML and XSLT can be used to separate content from presentation, but are far from universally accepted, as they require a fundamental restructuring of ‘legacy’ content. On the authoring side, few tools are yet available for easy creation of XML content. For new content initiatives however, the ability to use XML as a ‘container’ for content will be desirable. We can also expect interesting developments that are driven by a maturing WebDAV standard and the commercial mainstreaming of object databases.

The UK government has recently made recommendations for metadata in the public sector, using the Dublin Core [10], and we expect this endorsement to accelerate developments in this area.

Assessment and Recommendations

The pre-millennial Web can’t scale. The Webmaster bottleneck has been replaced by a Web Team bottleneck and our information systems are hard to join-up. The CMS can allow users to bypass the Web Team bottleneck and allow integration and re-use of information.

We feel that at the core of any CMS one should find a robust set of tools for content versioning, content integration and process workflow. This core feature set will augmented by a list of additional functions that varies significantly from product to product.

Typical future uses within HE/FE are easy to identify. At a workshop run by the authors [4], participants identified the following as the most desirable features of a CMS:

  1. Template-based self-service authoring for non-technical content providers (‘frictionless publishing’)
  2. Roles-based security
  3. Workflow management – submit, review, approve, archive
  4. Integration with existing data/databases and user authentication systems
  5. Metadata management
  6. Flexible output – write once, publish many times

We recommend that these functions form an initial set of global requirements through which prospective CMS systems can be filtered.

In an immature market place the risks to investment are substantial. If you ‘buy’ you cannot be sure whether your vendor will survive or whether the product will turn-out to be a technical cul-de-sac. If you ‘build’ (and smaller institutions may not have this as an option) you carry the overheads and risks of recruiting and retaining specialised staff.

At present it appears unlikely that a single product will cover the requirements of a complex organisation. There seems little argument that the solution will be a mixture of ‘buy and build’. The key issue is one of balance - ‘How much must be built before we get what we need?’. Institutions will also be exercised by the question of ‘Who builds it?’

We detect resistance within traditional campus computing services and MIS departments to the concept of the CMS (and indeed the need for an automated, post-millennial Web). Fundamentally a CMS devolves control over content to the owners of that content (rather than the technician), and then scales without increasing management overheads. The investment can run to a six-figure sum if the perceived market leading systems (e.g. from Vignette, Broadvision and Interwoven, though the former two are heavily biased towards commercial applications and thus, perhaps not a good fit) are considered, though many more modest (and indeed no-purchase cost) products are available.

The emergence of ‘portal frameworks’ (open source or otherwise) has done much to highlight the overlap and convergence of document management systems, knowledge management systems, enterprise application integration systems, e-commerce systems, intranet groupware, virtual/managed learning environments and CMSs. There is a pressing need, in our view, for institutions to think holistically (reinforced by their work on information strategies) and to invest in and develop open and extensible information systems.

Senior managers need to be aware of the costs and consequences of not embracing the post-millennial Web. The cost of investing in a CMS can be on a par with procuring a student record system - but which, in terms of efficiency and effectiveness, is likely to give the biggest return on investment? In fact, there is no choice, because both will be essential items. But we suspect, in terms of competitive advantage, it will be the CMS (perhaps as part of an overarching portal framework) that will be more important in terms of differentiating institutions.

We know that readers of this report would prefer if Table 4 were more exhaustive. A proper evaluation of a CMS, as with any information system, is a major undertaking. Moreover, pricing information is notoriously hard to come by [11].

As it stands Table 4 is based on anonymised feedback from participants in the CMS Parallel Session at the Fifth Institutional Web Management Workshop held at Queens’ University, Belfast during June 2001. Each vendor or product had been investigated (however briefly) by at least one of the participants’ institutions.

In terms of what the sector might do next in the area of CMS, participants voiced support for:

Price range


Evaluated by College/University X


Communique (£2k)

Frontier (£99)

NetObjects Fusion (£10k)

RedDot (£20k)

Zope (£0k)



Communique (£30k)

Obtree (£40k)



ATG (£200k)

Communique (£100k)

Interwoven (£120-200k)

Mediasurface (£170k)

Diagonal (£120k)

Radius (£120k)



Interwoven (£200-500k)

Vignette (£500k)


Table 4: The information HE/FE needs

Two resources are highly recommended if you want to stay up to date in this rapidly evolving field. Probably the best actively maintained list of CMS vendors and products is Clueful Consulting's Content Management Systems Directory [12]. The mailing list cms-list is a relatively low volume, high quality resource and which is generally free of vendor-speak [13].


Rob van Buuren, Richard Vidgen, Geoffrey Ford, Barry Taylor, Bruce Dupee, Stuart Brown, James Currall, Darren Chapman, Amanda Wheatley, Jethro Binks, Jacki Hargreaves, the participants of the CMS Parallel Sessions at the Fourth and Fifth Institutional Web Management Workshops and contributors to the cms-list.


  1. Ort, E. (2000) Ten Things to Know About Selecting a Content Management System, Dot-Com Builder, http://dcb.sun.com/practices/howtos/selecting_cms.jsp
  2. Vidgen, R., Goodwin, S., & Barnes, S., (2001) Web Content Management, In: O'Keefe, R., Loebbecke, C., Gricar, J., Pucihar, A., & Lenart, G., editors, Proceedings of the 14th Bled Electronic Commerce Conference, Bled, Slovenia, June 2001, pp. 465-480.
  3. Faulkner Information Services, http://www.faulkner.com/
  4. Doyle, L. (2000) Content Management Systems Workshop Report, Fourth Institutional Web Management Workshop, University of Bath, http://www.bris.ac.uk/ISC/cms/summary.htm
  5. Barrett, C. (2000) Content Management Systems http://www.camworld.com/cms/
  6. Rapoza, J. (2001) Get A Grip On Your Site, PC Magazine http://www.zdnet.com/products/stories/reviews/0,4161,2688945,00.html
  7. Thomas, M. (2001) CMS decision matrix http://www.cornerconsulting.com/wcm/ (cited at http://cms.filsa.net/archives/cms-list/2001/Feb/0225.html)
  8. Walker, D. (2001) Content management systems: short-lived satisfaction http://www.shorewalker.com/pages/cms_woes-1.html
  9. Sweeney, T. (2000) ASPs Answer The Security Question http://www.informationweek.com/789/asp.htm
  10. e-Government Interoperability Framework http://www.govtalk.gov.uk/egif/home.html
  11. Kontzer, T. (2001) Vendor Selection: Beyond The Hype http://www.informationweek.com/839/online_cmside.htm
  12. Clueful Consulting's Content Management Systems Directory http://www.clueful.com.au/cmsdirectory/
  13. CMS-List Archives http://cms.filsa.net/archives/cms-list/

This article is a revised and abridged version of JISC Technology and Standards Watch Report TSW 01-02 Content Management Systems which was published in September 2001 (http://www.jisc.ac.uk/techwatch/reports/index.html).

Author Details

Paul Browning
Information Strategy Co-ordinator,
University of Bristol
E-mail: paul.browning@bristol.ac.uk
Mike Lowndes
Web Manager,
The Natural History Museum,
E-mail: mikel@nhm.ac.uk