Content Management Systems: Who Needs Them?

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.

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.

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.

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.

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.

Products

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:

• Versioning, so that groups of individuals can work safely on a document and also recall older versions.
• Workflow, so that content goes through an assessment, review or quality assurance process.
• Integration, so that content can be stored in a manageable way, separate from web site design ‘templates’, and then delivered as web pages or re-used in different web pages and different document types.

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.

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’.

Developments

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:

• Funded case studies of CMS evaluation exercises (or at least funding to encourage institutions that had already undertaken such exercises to share their findings with the sector)
• The formation of both formal and informal consortia
• A mailing list to facilitate the formation of consortia and over which UK experiences could be shared
• A generic template which might be used in invitations to tender
• The purchase on behalf of the sector (in the manner that was done for reports on information security) access to reports on CMSs from consultancies such as Gartner Group or Forrester Research

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].

Acknowledgements

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.

References

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).