WebReference.com - Chapter 1 of Content Management Systems, from glasshaus (8/9) | WebReference

WebReference.com - Chapter 1 of Content Management Systems, from glasshaus (8/9)

To page 1To page 2To page 3To page 4To page 5To page 6To page 7current pageTo page 9
[previous] [next]

Content Management Systems, Chapter 1: Foundations of CMS

Tools or Systems?

The term "content management system" is often used generically to refer to products that offer the basic technical infrastructure: a repository, template engine, and an asset management interface. However, it is sometimes useful to draw a distinction between the tools or products and the broader context – or system – in which those tools operate.

We'll discuss such tools, and the process of buying and building them, in Chapters 5 and 6.

You may want to think of the products that are marketed as "content management systems" as content management tools (or CMS tools). Making this distinction leaves room for a broader definition of content management systems themselves as the organizational context in which the activity of content management occurs. It has three qualities:

It Occurs in the Business Environment

The surrounding environment includes the business' goals, company culture, and the decision-making processes. Content management does, in some ways, reflect the people who undertake the activity. It does not happen in a "clean room".

This has a couple of corollaries. First, content management is a people-centric activity. In the broadest sense, as organizations and people, we use web sites to communicate. While that communication is not the same as speaking on the phone or writing a letter, it is, ultimately, person-to-person communication. Content management is about facilitating the technical aspects of this type of communication.

The second corollary is that content management is also a people-intensive activity. Although the focus is often on the technology and the products, the aim is to apply that technology to help people get their jobs done faster and more efficiently.

In this book we will examine the technology, but we also talk about our experience with applying technology to real human problems. This means that you'll need to train people, and explain what the content management product you purchase or build does. You'll need to set expectations, and you may have to do some internal evangelism.

Successful content management implementations always take account of the human aspect.

It Is a Set of Processes

The processes involved marry and merge the human and the technical. While most vendors would have you believe that their technology can solve all your content management problems, the nature of the problem is such that a product on its own cannot solve the problems you may have with your people processes.

In any organization, there are agreements about how to get work done. Content management is no different – it is an agreement between people. An agreement or contract concerning how things get done is not new to business or programming. But in content management the agreement has to be more explicit and the enforcement of the process needs to be programmed into the workflow.

This workflow enforcement can also change the nature of the agreement. In many cases this can be an improvement – a simpler process can emerge, for example. In other cases, the technical enforcement of a poorly conceived workflow serves merely to calcify it.

Business processes change all the time. Once workflow is introduced, and people rely on it, it's important that the workflow reflects the current business agreements. It follows that accurate, flexible workflow tools are a must.

It Is an Infrastructure

This infrastructure supports the many mundane tasks of content management. For instance, reminding people to submit content, approving the content, and pasting it into a template. By using tools to automate as much of that as possible, we can support the most important aspects of content management and allow people to work at a higher level.

Authors can focus on what they write, rather than on waiting for a production person to make changes for them. Designers can think about site navigation, usability, and redesigns, rather than tedious, repetitive HTML coding. Developers can tweak the system for performance and improve their code, rather than getting called in to fix a broken deployment of the site.

To page 1To page 2To page 3To page 4To page 5To page 6To page 7current pageTo page 9
[previous] [next]

Created: August 22, 2002
Revised: August 22, 2002

URL: http://webreference.com/authoring/languages/html/cmsystems/chap1/8.html