Home |  We Consult |  We Educate |  About Us  

CM Domain Concept of the Week Archive

Concepts are bite-sized chunks of information on content management. Each week, we extract a short concept from the CM Bible and send it via email to our subscribers.

This archive contains the following past concepts:

21 Nov 2004

A deployment specification details the process that you undertake to roll out your CMS.

14 Nov 2004

Understanding acquisition sources

24 Oct 2004

A CMS steering committee can keep all the players in your organization at the table.

17 Oct 2004

A virtual community's host provides the CMS behind the community.

10 Oct 2004

Communicators know all about audience analysis.

3 Oct 2004

Functionality can be treated like content too.

19 Sept 2004

A collection design document can help you organize the authoring and acquisition process.

12 Sept 2004

A personalization approach can include a messaging as well as a personalization strategy.

29 Aug 2004

A software analyst plans how best to accomplish all of the programming that must be accomplished to start and run your CMS.

22 Aug 2004

A CMS administrator is responsible for all of the end-user tasks required to set up and run the system.

15 Aug 2004

Electronic communities serve the same purpose as real ones but have a CM infrastructure behind them.

18 July 2004

You do e-business using the concepts and techniques of content management.

6 June 2004

Localization and content management go hand in hand.

16 May 2004

Localization is the process of making content as understandable as possible in the variety of cultures in which people view it.

9 May 2004

Workflow is a task initiated by a trigger that is performed on an object by an actor.

25 Apr 2004

Project cutbacks are hard, but you are not without tools.

18 Apr 2004

A CM project manager holds the CMS startup together.

12 Apr 2004

A content manager needs a handle on a range of disciplines.

21 Mar 2004

Creating sponsor profiles can be a tricky business but it is always worth the trouble.

15 Mar 2004

A conversion analyst figures out how to get source information into the right format for your repository.

8 Mar 2004

There is nothing new in CM. On the other hand, there is nothing like it.

29 Feb 2004

You should test the code that produces pages rather than the actual pages created by a CMS.

22 Feb 2004

Technical drilldown sessions during vendor selection can be of enormous value in getting to know your potential support team.

16 Feb 2004

If you are smart, you will develop standard processes once and then roll them out across the organization.

8 Feb 2004

Editors have to stay one step ahead of authors to make your CMS work.

1 Feb 2004

A CM traffic cop keeps the information flowing from creator to system.

25 Jan 2004

With the right perspective, the editors in your organization can help your CMS span business units.

19 Jan 2004

To serve the whole organization, free authors and publication teams to do their own thing.

11 Jan 2004

Regardless of how many physical databases you have in your CMS repository, try to have only one system of structure and access.

4 Jan 2004

You can look at a CMS as a balance of the forces within your organization.

21 Dec 2003

You can move progressively toward a deployed CMS by powering it up slowly.

14 Dec 2003

Templates are programs. Template processors create publications by interpreting the commands in a template.

7 Dec 2003

There is no absolute right way to divide content. There are, however, better and worse ways.

23 Nov 2003

Content components are a lot like programmer's objects.

16 Nov 2003

In a CMS, anyone can be an author, so you had better be prepared to service a wide range of needs and abilities.

9 Nov 2003

You can stumble around till you happen on a good system, or you can move slowly but surely toward one.

2 Nov 2003

A logical design for your CMS helps in every other stage of the project.

26 Oct 2003

Cataloging is one of the main skills of the content manager.

19 Oct 2003

I propose a quite different requirements gathering process than what might happen in the usual software development project.

12 Oct 2003

Authors are the kinds of people who create content directly for you.

5 Oct 2003

Metadata is about creating standards for sharing and integrating information across its various users.

21 Sept 2003

The word meta gives a lot of insight into what you must do to manage content.

14 Sept 2003

For the consumer, format and content are inseparable. Not so for the content manager.

6 Sept 2003

The publishing industry knows all about collection.

24 Aug 2003

Metadata comes in a variety of types.

15 June 2003

The CMS team must seek out contributors and go to them.

8 June 2003

Binary format is a way to encode any type of information for computer use.

1 June 2003

The important parts of your business are digital and can be delivered as needed electronically.

25 May 2003

Of the few ways you have to find out how to personalize for your audiences, asking is still the best.

11 May 2003

The dependencies between a CMS and its environment make testing a particular challenge.

4 May 2003

In the heart of the information age we will know the value of information and the kind of system it takes to create and distribute it.

27 Apr 2003

An administrator's guide puts together all of the configuration information for your CMS in one place.

20 Apr 2003

Templates build pages and can be themselves composed of templates.

13 Apr 2003

Templates use logic to specify the operations that they need to perform to build a page or section.

6 Apr 2003

A cross reference is much better characterized as an association.

30 Mar 2003

An index provides a map between the words and concepts of the seeker and those of the system.

24 Mar 2003

A community is not the same as an audience.

16 Mar 2003

Before you begin preparing requirements, put together a plan of attack.

9 Mar 2003

A requirements document makes the transition between the language of the organization and the language of a CMS.

2 Mar 2003

For humans its the content that matters, but for the computer, it's all just data.

23 Feb 2003

Work on the discipline of content management has to continue if CM is to deliver the value that organizations demand of it.

16 Feb 2003

You use an access structure to organize and get to your content components.

9 Feb 2003

Acquisition sources are the preexisting places where your information comes from.

1 Feb 2003

It's never a good idea to force a CMS on the organization.

26 Jan 2003

One group may originate the idea for a CMS, but the rest of the organization become part as well.

19 Jan 2003

There's more to link checking than first you might suspect.

12 Jan 2003

A good search and replace function in a CMS could do wonders for you.

5 Jan 2003

You can treat computer functionality as a form of content.

22 Dec 2002

Look within your organization to reveal your audiences.

15 Dec 2002

Markup languages vary in their range of coverage.

8 Dec 2002

Content Management in the Information Age.

1 Dec 2002

You can save yourself trouble by creating a rigorous product selection process.

24 Nov 2002

Product selection can be quite political.

17 Nov 2002

A template has to know a lot about the world of the publication it produces.

10 Nov 2002

A template bridges the gap between the repository and the publications a CMS creates.

3 Nov 2002

Signs of the dawn, if not the full light, of the information age are beginning to emerge.

27 Oct 2002

While users expectations of what a computer can do have changed, the guts of the computer have not.

20 Oct 2002

eBusiness is a process not a product.

13 Oct 2002

Start your CMS selection process with a high level statement of your aims.

6 Oct 2002

Designing a publication in the context of a CMS requires a significant amount of up front planning.

29 Sept 2002

A variety of people on your CM team can benefit from knowing XML.

22 Sept 2002

Computers were first used to solve problems where content could be reduced to simple data.

15 Sept 2002

e-Business is the process of delivering any part of your business to any audience wherever it is.

8 Sept 2002

To start, cast a wide net around your organization's content.

1 Sept 2002

The CMS team needs a variety of analysis skills to figure out where to begin.

25 Aug 2002

To justify a CMS, look for pain in your organization.

18 Aug 2002

Your content domain helps you distinguish what content you are interested in and what you are not.

11 Aug 2002

Cutting back is not only necessary at implementation time, but it's also just a part of the ongoing design process.

4 Aug 2002

Metatorial is a word I use to denote metadata related activities.

28 July 2002

XML is most used not to manage content, but as a data interchange language.

21 July 2002

As a content manager, XML should be very important to you.

23 June 2002

You need a CMS if you have too much content to process by hand.

16 June 2002

Before you can load source content into your CMS, you must understand how elements in the source correspond to elements in the CMS.

9 June 2002

Components are the basic units of content management.

2 June 2002

As much as possible, your collection efforts ought to reach into the contributors' authoring tools.

28 May 2002

The content management entities are the basic players in a CMS.

19 May 2002

Any of a large range of events can trigger a workflow.

12 May 2002

How do you do e-business?

6 May 2002

References are just about the last step that you take on the path to your decision on what CMS to buy.

28 Apr 2002

Inside the CMS, access structures are for management. Outside the CMS, access structures are for navigation.

22 Apr 2002

Templates streamline the process of creating publications from the neutral content in a CMS.

14 Apr 2002

In a complex CMS, you need more than one outline of content to perform many tasks.

7 Apr 2002

XML can stand behind most electronic information initiatives, including content management.

31 Mar 2002

The majority of CMS products base their repositories on commercial relational database products.

13 Mar 2002

Personalization is the process of matching the data that you collect on a user with the metadata with which you tag your content.

1 Mar 2002

Audiences are identifiable groups of people you have chosen to serve.

24 Feb 2002

There's a good reason why HTML and XML are termed "open standards," why they're so verbose, and why they don't load terribly quickly.

22 Feb 2002

One way to think about your CMS is as a supermarket of content. You are the grocer.

17 Feb 2002

A piece of data is the end of a conversation, but a piece of information is the beginning.

10 Feb 2002

A CMS provides an appropriate infrastructure for handling the challenges of an advanced site.

3 Feb 2002

Organize your CMS team by function to help you scale.

27 Jan 2002

The more a CMS is entwined in the organization, the more value it can deliver.

13 Jan 2002

Computers were invented to work on data because it is easier to pin down than information. On the other hand, we want our computers to work on information.

23 Dec 2001

Content management, as the name implies, is a manager-type activity. It is, in fact, antithetical to the startup mentality that's permeated Web activities so far.

16 Dec 2001

The job of the content manager encompasses all of the parts of a content management system.

9 Dec 2001

Personalization is the last piece of management that happens to content before you lay it into a publication.

31 Nov 2001

Web sites are publications. You can learn a lot from the publishing industry.

CM Domain Concept of the Week
21 November, 2004
A deployment specification details the process that you undertake to roll out your CMS.

The deployment specification, which I describe in this section, you actually want to develop along with the other specifications during implementation. It details the process that you undertake to roll out your system. The deployment specification includes the following parts:

  • The power-up schedule: This schedule details the plan that you devise for powering up the system. Especially during the earlier stages of development, it's critical so that each team knows your expectations for when you need its deliverables to continue building out the production system.
  • The CMS system architecture: This architecture includes all the parts that I mention in the section " The production installation," earlier in this chapter The system architecture should include system diagrams as well as hardware and software requirements for the generic and production installations.
  • Integration plans: These plans include schedules and techniques to use to connect the CMS to all third-party products and enterprise systems.
  • Staff rollout plans: These plans detail how and when you deploy the collection system to different contribution groups (author groups and acquisition groups).
  • Publication rollout plans: These plans describe the order and timing in which CMS-produced publications replace the current publications. This plan shows exactly when the old ones stop and the new ones begin. If you're planning a period during which the old and new publication productions overlap, the plan needs to show how you're handling staffing and synchronization.
  • The beta plan: This plan describes the timing and participation that you expect in a beta release. If you're including certain audience groups, the plan needs to state how you plan to ask for or notify them of their participation.
  • Expected and allowed volumes: The deployment plan needs to set the expected range and the maximum values for the page views and other transactions that occur in the CMS at release. It should include contingency plans for how to bring more hardware or bandwidth to bear if the actual volumes (of page requests, database queries, or other publication pages, for example) exceed the maximum.
  • The distributed system plan: If the CMS system or databases is spread over various locations, the specification should provide a schedule and staffing plan for how the deployment spreads through the set of locations.
  • A deployment staffing plan: This plan shows how many and what types of people you need to power up and roll out the system.
  • Setup and configuration data: You need this data for all the end-user tools that you must deploy to contributors and other CMS staff.

The deployment specification dovetails with the implementation specs. Whereas each implementation specification shows how to build a particular part of the CMS, the deployment specification shows how all the parts come together as you build them to form the production system and how you intend to progressively release that production system to staff and audiences.

***

Excerpted from Chapter 18, "Rolling Out the System," in the section titled "The deployment specification."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
14 November, 2014
Understanding acquisition sources

For each acquisition source, ask yourself the following questions to help you understand and design for the constraints that the source owner puts on your process:

  • Owner: Who owns or is responsible for this source of content? If it has multiple owners, do they all subscribe to the same rules or procedures? If not, consider creating multiple sources. To consider sources the same, multiple owners need to behave similarly.
  • Influence: What influence do you have over the timing, structure, or format of this source?
  • Agreement: Can you form a binding agreement with the owner? If so, what form does it take - a formal contract, a memo, an e-mail message? In any case, seek to form the contract in writing so that you're sure that even an informally arranged agreement is specific. If forming a binding agreement isn't possible, how do you ensure that the content is delivered consistently enough to enable you to adequately plan for it?
  • Source units: In what sorts of units does this source arrive (for example, individual files, database tables, or CD-ROMs full of content)? How many and what types of components are in each unit. PLAN, for example, may receive a file each week containing news stories from an international distributor. Each file may contain between 50 and 100 stories that give rise to three or four press-release components (stories that PLAN wants to modify and redistribute) and 30 to 40 news components.
  • Delivery: In what format or formats does the source arrive? How does it arrive (via direct connection, FTP, and so on)?
  • Escalation: Who do you contact if the content doesn't arrive in the way that you expect? To whom do you escalate the issue if it isn't quickly resolved?
  • Start-up quantity: How much of this source do you need to process before the CMS launches? When does it need to arrive for you to make it ready for launch?
  • Run quantity: How much of this source do you expect to receive on an ongoing basis? How far in advance of a publish date do you need it delivered?
  • Changes: How can you make sure that the content that you receive is the latest or master version of the source? What provision can you make for parts that arrive late or change after they're officially passed off to you?
  • Feedback: What provisions can you make for feeding back information from the CMS team to the content owners for improving the delivery process?

***

Excerpted from Chapter 25, "Accounting for Acquisition Sources," in the section titled "Source Relationship."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
24 October, 2004
A CMS steering committee can keep all the players in your organization at the table.

The steering committee is the ongoing remnant of the mandate and requirements processes. They are the people in the organization that have a continuing interest in the system and enough authority, expertise, or both, to determine the direction of the CMS. The steering committee can have representatives from the CMS project sponsors, members of significant contribution and publication groups, and CMS analysts and other project team members with continuing knowledge and responsibility for the system. The steering committee can do the following:

  • Set CMS standards, including content modeling trade-offs, when to make a custom collection or publishing process into a standard process, and when and how to extend current standards to include new groups.
  • Work with new teams to determine whether they should become part of the CMS initiative, and, if so, when and how to integrate them into the current process.
  • Resolve content-sharing conflicts between groups with competing needs.
  • Serve as the ultimate supervisors of the CMS and repository teams.

***

Excerpted from Chapter 12, "Working Within the Organization," in the section titled "The CMS steering committee."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
17 October, 2004

A virtual community's host provides the CMS behind the community.

The community's host is the organization that's in charge of the site's infrastructure and maintenance. This organization must implement a CMS, communication services, and member-administration services. It must also input enough content to get the site off the ground. You find the following two typical types of hosts online:

  • Commercial hosts: A commercial host has the members as a target market for goods or services. This host is willing to trade the cost of maintaining the site in return for exposure to the members. In a typical scenario, the host has the original idea for the community, creates an initial implementation of the site's system, fills the system with enough content to make it viable, and then launches the site and opens it to members. The host continues to feed content in, administer user data, and create communication events. The major issue to resolve in this circumstance is what right the host has to market to the members or sell member data to outsiders. Members can leave if they feel exploited. On the other hand, the host may stop if it sees a lot of cost and little return from the community.
  • Member hosts: A member host is one or more potential members who decide to create a Web presence. Typically, some existing trade or interest organization with a current membership organizes and funds the initial system. As in the case of the commercial host, the member host creates an initial implementation of the site's system, fills the system with enough content to make it viable, and then launches the site and opens it to members. The key issues here are: continued funding of the site from often cash-strapped organizations, and sufficient attention paid to the site maintenance by what is often volunteer-run organizations. Of course, selling member data is also an issue for member-hosted communities.

For both the commercial host and the member host, the primary issue is to make the site truly belong to the members. As time goes on, members should become the major contributors to the site, with the host needing to supply less and less content. In a high-affiliation community, members even plan and execute the communication events (chats, online meetings, and so on). If the community is successful, then its success comes from the host's creation of a system that promotes affiliation and targeted knowledge-gathering - among a group of people who naturally gravitate to a clearly stated and well-founded common interest.

In any case, for the community to become successful, it must have a full-featured and robust CMS behind it. Without a CMS, the site can serve neither its members nor its host. At best, it becomes an enhanced bulletin board, and at worst, it becomes an unenhanced bulletin board.

***

Excerpted from Chapter 10, "The Branches of Content Management," in the section titled "The host."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
10 October, 2004
Communicators know all about audience analysis.

Writers, public speakers, and other communication professionals, have used the concept of an audience analysis for a long time. A lot is written on this subject, appearing in textbooks and the popular press. Most of the work that I've seen boils down to the following seemingly simple points:

  • Who are these people objectively? What are their ages, interests, jobs, and other relevant data?
  • What does this audience already know and believe about this subject?
  • What are people's needs and desires for new information in your subject area?
  • What kind of presentation style are they likely to respond to favorably?
  • What publications do they already trust, and to which are they likely to compare yours?
  • What's the author's relationship to this audience? Is she a peer, an expert, or an outsider?
  • How do you establish credibility with this audience? What do audience members consider good information sources, arguments, and examples?
  • What tasks and purposes have they in mind as they approach your material?

This sort of analysis has motivated communicators from the ancient Greek rhetoricians to the modern technical writer and journalist. I believe that it's a pretty good list of the sorts of information that you need so that you can understand how to communicate with an audience. Most of the time, you conduct this analysis quite informally, and it results in an intuitive feel that the communicator gets for how to approach an audience. For a CMS audience analysis, you need to make the answers to these questions explicit and relate them to the parts of the CMS that they're going to help structure.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "Audiences and communicators."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
3 October, 2004
Functionality can be treated like content too.

In the software world, a computer-based process is known as functionality. The functionality that a computer application offers casts a human process into a series of human-computer interactions using a user interface. From the standpoint of the organization, you can say that functionality is the way that you do business by using a computer.

Simply put, functionality is the stuff that you do on the computer. Unlike text, sound, pictures, and motion, which you experience (by reading, hearing, or seeing), you do functionality (by requesting or responding to something). A user interface represents functionality as a set of buttons, menus, dialog boxes, and other controls that give you a particular capability. Microsoft Word, for example, provides table functionality. The functionality is available from the Table menu at the top of the Word window. If you choose the Table › Insert Table command, Word displays a dialog box full of buttons and other controls that enable you to specify how you want the Insert Table functionality to perform. On the Web, functionality is programming code that lives in a Web page or on a Web server. It does useful things such as performing calculations, allowing you to submit data via a form, carrying out financial transactions, verifying your credit card information, and so on.

Functionality's taken the following two major steps over the course of computing:

  • It's moved away from monolithic programs, where all the functionality is built-in, toward mix-and-match programs, where the functionality exists in small chunks known as objects.
  • It's moved away from applications with the single purpose of presenting functionality toward Web sites in which functionality and content intermingle and become hard to tell apart.

Taken together, these two steps enable you to treat functionality as a form of content.

***

Excerpted from Chapter 4, "Functionality Is Content, Too!," in the section titled "What Is Functionality?."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
19 September, 2004
A collection design document can help you organize the authoring and acquisition process.

To logically design your collection system, you decide, and then document, how content will move from outside the CMS to the point where it is ready to be used in publications. Following my discussion of what occurs in a collection system, the collection design document will have to cover these topics:

  • Who are our authors and how will they be tied into the CMS?
  • What are our acquisition sources and how will they be tied into the CMS?
  • What components will be created by which authors and sources and at what rates?
  • What conversion processes will we need to transform the format and structure of the information we receive?
  • What staff will be needed to collect content and what will their tasks and processes be?

You can use the information provided in the chapters of this work to decide what you need to say about these topics. As far as how to construct the document, consider its audiences. First, the staff it mentions will want to read this document. It should therefore have well-marked sections that divide responsibilities by position name. Next, specification writers will want to read it to understand how to set up the collection systems. Thus, you should make sure that it divides the information by functional units (for example, authoring tools, conversion systems, acquisition procedures, and so on). Finally, it will be used as input to the system selection process, so it should call out any information that should be included in the selection process.

If you are starting to think that you need a CMS just to produce the various cuts on the design of your CMS, you are on the right track.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "The collection design document."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
12 September, 2004
A personalization approach can include a messaging as well as a personalization strategy.

Even if you will have only a couple of audiences, for starters, and a static Web site as your only publication, it is worth your while to study and document an approach to personalization. This approach can include the following deliverables:

  • A messaging strategy: This document combines audiences, publications, and components together at a high level. It defines what each audience is supposed to get from each publication and which components and publication design features will be used to communicate with them. It is a high-level precursor to personalization analysis. Particularly for publications targeting external audiences, it provides a marketing context within which to do personalization. For internal publications, your messaging strategy clearly identifies which types of information are appropriate for each audience.
  • A personalization strategy: This document goes into detail about exactly how you intend to do personalization in each publication. It specifies a personalization rule for each combination of publication, page, audience, and component. The core of this document is the set of personalization rules. The rules state how to fetch components from the CMS repository, based on what you know about the user, plus the values of the component's management elements. The rules also say which elements to display and how to lay out the components on the publication page.

***

Excerpted from Chapter 15, "Doing Requirements and Logical Design," in the section titled "Personalization strategy."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
29 August, 2004
A software analyst plans how best to accomplish all of the programming that must be accomplished to start and run your CMS.

Like the other analysts I have described, the software analyst strategizes and plans. The software analyst plans how best to accomplish all of the programming that must be accomplished to start and run the CMS.

In particular, the software analyst is responsible for the following:

  • Choosing the development environment (or environments) that will be used. There are quite a few competing environments from which to choose. The right one is the one (or ones) that requires the least retraining of the programmers you intend to use, fits most cleanly into the required system architecture supplied by the deployment analyst, and, of course, provides the tools you need to create the needed functionality.
  • Creating a development framework. In a CMS, there is code everywhere. From the programming macros in a Microsoft Word document template, to the stored procedures in an enterprise resource planning (ERP) database, there are more programming sites than anyone in her right mind would call a single system. It is the job of the software analyst to get all of these different parts of the system corralled into a single programming framework. The framework organizes the creation of code, its versioning and testing, its deployment, and the sharing of code modules and objects between applications. This is no small task in an enterprise CMS.
  • Deciding which features of the CMS should be custom-coded and which should be done using commercially available tools. For example, should the organization use the database connectivity code supplied by the CMS manufacturer or should they extend the code they have now, which works well with their ERP system?
  • Writing the specifications and development plans for the programming tasks that require them.
  • Creating estimates and plans for the staffing needed to accomplish all of the programming to start and run the CMS.

As with the deployment analyst, there are people in the world who have done this sort of thing before. Still, someone who is a good general analyst but also has significant experience programming content-manipulation applications would serve you best. This is not a rare skill set, but it is not the most common. People of this ilk can be found in the back rooms of Web sites that use Perl extensively, or in the documentation groups of large companies that have had to use Structured Generalized Markup Language (SGML) to structure and manipulate massive document databases. In any case, stay away from the people who think that content can be treated just like data. They will underestimate the complexity of their task every time.

In addition, like the other analysts, this person cannot be a back-roomer. She must be able to negotiate among the competing development interests (which are no less, and often more, vehement than the business interests) and come to a workable compromise between competing platforms.

Finally, be careful not to choose someone who is more interested in writing code than getting other programmers organized. Note that the software analyst's job description does not say "writes a lot of programs." Even if you are in a position to have only one person who is both analyst and developer, because there are so many different places where code will live, it is essential that this person really be interested in staying organized, creating standards, and adhering to them, rather than simply writing code.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Software analyst."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
22 August, 2004
A CMS administrator is responsible for all of the end-user tasks required to set up and run the system.

Someone must set up and run the CMS. I call that person the CMS administrator.

Note   

I might have chosen to list this position under information architecture, even though most often it is thought of as an IT position. Here is why. The basic purpose of the CMS is to organize information and make it as available and flexible as possible. Thus, the person who runs the CMS should have this perspective above all else. Just as it is preferable to have a person with a background in finance running your enterprise accounting system, so it is preferable to have someone with a background in content running your CMS. This is not to say that CMS administrators do not need to be quite technical - of course, they do. Rather, it is to say that they need to be able to confront content problems as well as infrastructure problems.

The administrator is responsible for all of the end-user tasks required to set up and run the system. Like all administrators, the CMS administrator is neither a programmer nor a network professional (although experience in these areas helps). Rather, CMS administrators are responsible for tasks such as the following:

  • Configuring the chosen CMS. The administrator enters or imports all of the component definitions, user profiles, publication definitions, and other data that the CMS needs to begin working.
  • Inputting content. Where content comes into the system in bulk (for example, as the result of a conversion process), the administrator oversees the process and takes action when anything fails. Where content comes in one component at a time (for example, when authors fill in Web forms), she is responsible for ensuring that the proper methods are up and working. This may entail creating new Web input forms, distributing appropriate end-user software, or simply receiving e-mail attachments and importing them into the system.
  • Fully understanding the chosen CMS software. The administrator ought to be able to make the CMS do anything it can do without additional programming. In many commercial systems, there is quite a bit that does not require programming. Much of what a CMS is capable of, however, requires you to understand content management concepts and to be able to find the right combination of options (which are often buried in text files and the system registry).
  • Maintaining users and workflows. The administrator is responsible for ensuring that all staff that have access to the system are accounted for by the system. Staff may need to be profiled and added to groups in order to get access to the resources they need. In addition, the administrator needs to set up and maintain the system workflows. This may be as simple as dragging and dropping icons onto a page, or as complex as modifying a massive XML structure in a text editor.
  • Triaging bugs and finding fixes. After the system is running, the administrator will be the first line of defense against problems that arise. From rebooting after a crash to spending days tracking down why one user can't seem to log in, the administrator must ensure that the train keeps running. Of course, many problems will need to be escalated past the administrator, but like the triage nurse in an emergency department, she sees them all first.
  • Ensuring data hygiene. The administrator ensures that the content stored in the repository is in the best state possible. This responsibility includes making sure that required data is supplied, that content is archived or deleted on the specified schedule, and that periodic reviews and updates to content and system configurations happen as scheduled.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "CMS administrator."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
15 Aug, 2004
lectronic communities serve the same purpose as real ones but have a CM infrastructure behind them.

In society, communities are groups of people that share some common purpose or kinship ties. The situation is no different online. Although many people talk about creating online communities, few do so from this sort of understanding. The most popular concept of community I have heard is to become "the place" to go for some sort of information. If you add a chat room or a threaded discussion, and collect user data, it is called a community. Many community sites hope to "own" the attention of their users and sell it to advertisers or direct it toward other organizational goals.

Without real community, however, which offers a core of common purpose or kinship (in the widest sense of sharing some important aspect of life), these sites can never really be communities. To be a real community, an online community needs to fulfill its members' needs for affiliation and knowledge. Affiliation is the members' desire to belong to something. Knowledge is the members' desire to know something. More to my current interest, a Web-based community needs a system behind it to support both affiliation and knowledge.

<

***

Excerpted from Chapter 10, "The Branches of Content Management," in the section titled "Online Communities."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
18 July, 2004
You do e-business using the concepts and techniques of content management.

I believe that you can do e-business the same way you do content management. That is, you can create a process to collect, manage, and publish information and functionality to a set of target audiences. Information and functionality are the content of e-business. To do e-business or content management, you must do the following:

  • Collect content. Your organization must set up systems that efficiently capture the information and the functionality you want to deliver. To collect content, you need editorial and metatorial systems. Editorial systems ensure that the content has appropriate and consistent format and style. Metatorial systems ensure that the content is appropriately and consistently tagged to be part of the organization's content scheme.
  • Manage content. Your organization must set up a system to store and organize information and functionality outside of any particular delivery channel. Management systems are usually databases of one sort or another that store and categorize content, making that content easy to find and retrieve.
  • Publish content. Your organization must set up a system to design and deliver the right information and functionality in the ways that your audiences expect and respond to favorably. The publishing system undoubtedly will manage a comprehensive Web site, but could and should manage the other sorts of publications your organization needs.

If your organization is wise, it will look past the hype and vague promises of e-business and focus instead on how to use the new technologies that become available to do what it has always needed to do. This work ought to give you an approach to all of e-business, not simply to the application of content management.

***

Excerpted from Chapter IN, "Three Good Reasons to Do Content Management," in the section titled "How do you do e-business? ."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
6 June, 2004
Localization and content management go hand in hand.

Localization and content management go hand in hand. In fact I'd go so far as to say that the central issues of localization are one form of the central issues of content management, as the following list discusses:

  • Collection: How do you author or acquire content in a way that frees it from its context by explicitly stating its context? For localization, you make content free from its locality by tagging the parts that are locality bound. In content management in general, you make content free from any particular audience or publication by tagging the places that are audience or publication specific. In both cases, you're not trying to remove the context of the content but rather to explicitly state it so that you can formulate and implement logical rules for the use of the content. In a collection, for example, you can tag each example with the localities that it's useful for. You can develop alternative examples for your other localities.
  • Management: How do you store and administer content in such a way that people can find, access, and most easily use it? In localization, the point is to deliver content to the localization team as efficiently as possible. Doing so may mean delivering only the examples that need translating to a particular language because you're tagging them for the locality that uses that language. In the wider content-management world, of course, management is responsible for delivering content to wherever it needs to go.
  • Publishing: How do you ensure that the right content gets into the right publication in the right locations? In localization, this task is a matter of selecting the localized version of the content. You may, for example, want to make your CMS select and display only examples that you tag for the locality of the current user. In content management in general, of course, this concept is the central purpose of the entire publishing system.

Localization can come into play in any or all portions of your CMS design. Thus I leave the detailed discussion of localization analysis and design to the specific applicable sections throughout this work. I leave this section with the following two general principles of content management that apply especially well to localization, and I offer them as general guides to localization:

  • Conservation of work: A CMS doesn't reduce the amount of work that publishing content takes; it merely shifts the burden of that work from a human to a computer. In localization, you want to adopt the attitude that your job is to put as much of the work as possible onto the CMS. You can, however, only shift it so far. If you want content that's useful to people, you can't escape that fact that people must do a core of the work.
  • Balance of generality: The more general that you make your content, the easier it is to reuse. The more general it is, however, the less it communicates. You must balance a CMS between the constraints of reusability and strong communication. Similarly, you must balance the need to communicate at all with your key localities with your need to communicate well with your primary locality. Whenever I say, "on the fly," I tip the balance a bit toward my primary locality to give them deeper and wider understanding at the expense of other localities that may get less understanding.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "Localization and content management."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
16 May, 2004
Localization is the process of making content as understandable as possible in the variety of cultures in which people view it.

Localization is the process of making content as understandable as possible in the variety of cultures in which people view it. I'm going to work back from this definition to one that's more useful in the context of a CMS.

The definition has the following three major concepts:

  • Culture: I want to keep this very complex issue as simple as possible and define culture as a set of shared communication and behavior standards that a group of people adopts and upholds. Not all that long ago, geography was the main indicator of culture. People who lived near each other shared a culture. Today, that's too simple a way to look at it. As anyone who's walked down the street in any major city of the world can tell you, cultures aren't countries. Today, I'd define culture as a dynamic mix of language, region, ethnicity, and other affiliations. To stay within the general bounds of the accepted localization terminology, I use the word locality and not culture to capture the concept of localization.
  • Understanding: What makes content as understandable as possible? Clearly the language in which you write any text is the biggest factor. But it's not just language. As I discuss in the following section, translation is only the start. You must recognize and change a world of other, more subtle local conventions.
  • Process: Localization is a process. In fact, I'd say that, by and large, it's an authoring process. Content that someone authors for one locality someone else must then reauthor for another. The localization process encompasses many mechanical parts, where bits of content move from person to person for processing. But after the content arrives on the localizer's screen, the mechanics end and it becomes a human process of knowing what "works" in one locality or the other.

***

Excerpted from Chapter 21, "Cataloging Audiences," in the section titled "What is localization?."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
9 May, 2004
Workflow is a task initiated by a trigger that is performed on an object by an actor.

A workflow, as I present it in this work, is a sequence of tasks that a staff member performs and that some event triggers. A workflow entity is a collection of data that specifies the tasks, staff, and triggers for a particular workflow.

Workflows involve steps that form a set of sequenced operations. For each step, you must collect the following kinds of data:

  • An object, which is the part of the CMS that the step affects.
  • A task, which is a discrete activity that makes some change to content, publications, or the CMS structure or configuration.
  • A staff member, who performs the tasks as part of her job.
  • A trigger, which is an event that signals that the step is to begin.
  • A duration, which says how long the step is to take.

***

Excerpted from Chapter 19, "The Wheel of Content Management," in the section titled "Workflow and staffing."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
25 April, 2004
Project cutbacks are hard, but you are not without tools.

Cutbacks may be natural, but they're not easy. Someone's desire is thwarted for this version, and she isn't pleased. In addition, you must go back and redo some amount of the planning process to account for the change in project scope.

You have a few tools for coping with unhappy campers. First, you have the prioritized requirements that you originally collected and had approved. Your cuts should start at the low-priority content and publications, to be fair to all and to avoid conflict. Second, you have your sponsor group, which is in place to help with just these sorts of events. Make your case for cuts to your sponsors, not to the people whose requirements you must deny. Finally, you can console hurt feelings with the assurance that a high-priority implementation in version 2 can produce a much better result in the long run than a low-priority implementation in version 1.

Tip   

Resist the temptation to keep all content classes and publications and just do less volume. In a CMS, most of the work consists of setting up the component classes and publication infrastructure. So cutting volume rather than types of publications and content gives you less bang for your cut.

You also must decide how far back in your planning to make the cut, as follows:

  • Do you simply need to scale back the logical design? If so, you can get by with some markup on your design documents, showing which parts must be postponed. In addition, you must make whatever changes are needed to your project plan.
  • Do you need to drop requirements? If so, you need to get the requirements reworked and approved again. Then you can mark up the design documents and project plan.
  • Do you need to change the goals? If so, you need to reconvene the mandate group to make the change. Then you can make the corresponding changes to the requirements and get them approved again. Finally, you can change the design documents and project plan.

Obviously, the further back you go in the process, the more work it is. On the other hand, the further back you go, the bigger the change you can make. Personally, I think you derive collateral benefits from reengaging your mandate or requirements group. Doing so gives members a chance to stay active as a part of the process and to reassert their support. You want this to remain everyone's project.

***

Excerpted from Chapter 17, "Implementing the System," in the section titled "Cutting back."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
18 April, 2004
A CM project manager holds the CMS startup together.

All project managers attend to the scope, schedule, and budget of their projects. It is really no different in a CM project. Project managers usually appear most in the start-up phase of a CMS. After the CMS is running, the other sorts of managers tend to step in and take charge.

Project managers do the following:

  • Manage project staff, apprising them of their deliverables and schedules. Perhaps the most difficult thing in managing a CMS project is the potentially long list of characters whose input is needed. Especially during the requirements-gathering phase for the CMS, there are a lot of meetings, phone calls, e-mail messages, and small documents that have to be scheduled, accomplished, and accounted for.
  • Manage budgets, assuring that the money allotted for the project lasts as long as the project does. Conversely, a good project manager will see an overrun a mile away and let the world know that some sort of change is needed long before the money actually runs out.
  • Create and enforce the project plan. It might well be beyond the ability of a project manger to create the plan for a large CMS, but it should be fully within her ability to make sure it is updated and adhered to.

The kind of project manager that you want is the kind that can keep a lot of balls in the air and make sure a thousand little things get accomplished and no one is left out. Project managers with strong technical skills but little ability to negotiate competing constraints need not apply.

A good CM project manager (PM) will have strong negotiation skills and a streak of insistence. The successful CM project is a careful balance of stopping the unending conversation about what content and functionality will be included, and assuring that all relevant and necessary content and features are fleshed out and used. Finally, although your PM need not be an expert in any of the CM skill areas, she should have somewhat the same ability as the Content Manager to understand the staff's subject matter enough to know a big problem from a little one.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Project manager."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
12 April, 2004
A content manager needs a handle on a range of disciplines

All in all, the Content Manager is the head of the CM endeavor in the organization. Because there is no degree (that I know of) in content management, there are no recognized curricula to pass to get credentials for this position. In addition, few people can say they have much experience being in such a position. Still, there is a core set of skills that you can look for in a Content Manager. The person must be capable of understanding the multiple disciplines involved in CM. They ought to have a good head for at least the following subjects:

  • Web technologies, including server and client software and the construction of Web sites and Web applications. She does not need to be a Web developer, but a good Content Manager understands the Web.
  • Editorial processes, including the writing and review process. She does not need to be a writer or artist, but a good Content Manager must recognize well-constructed content when she sees it.
  • Cataloging and information organization. A Content Manager does not need to be a librarian, but she does need to be good at finding structure and making sure it is enforced.
  • Information technology infrastructure, including database and network administration. Because the system has to integrate with the enterprise communication infrastructure and because the collection, management, and publishing systems of a CMS are all network and database applications, some knowledge in this area is a must.
  • Analysis and abstraction. This may be the most important, but least measurable, skill of a Content Manager. If you haven't noticed, content management requires you to think very abstractly about information. If you get too stuck in the concrete details of how one page or another looks, you will lose sight of the main goal of CM, which is to break information away from its presentation and instead focus on its structure and how that structure can be used to make any of a range of pages. If this lightbulb has not appeared over your Content Manager's head, you will never have a robust system.

***

Excerpted from Chapter 11, "Staffing a CMS," in the section titled "Content manager."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
21 March, 2004
Creating sponsor profiles can be a tricky business but it is always worth the trouble.

To really study your sponsors, you can create written profiles that answer all of the learning questions I listed earlier in this chapter Now, if you are truly a consensus builder, you immediately will be questioning the wisdom of this endeavor. Taking notes on people and creating files on them is not the way to gain their confidence and trust. So, if this seems just too risky or Machiavellian, skip it and content yourself with thinking about the questions and discussing the answers you find with the sponsor and your team.

On the other hand, if you can get past the feeling that you are acting like the next J. Edgar Hoover, this approach can be of immense value. If you act covertly and sequester the information you collect, then you will indeed be doing espionage. If you are open about your motives and up-front about your techniques, however, you are just being conscientious. Moreover, if you have the sponsors participate in filling out their own profiles and openly discuss the profiles in group meetings, then the profiling process can be as innocuous as any survey.

The point of profiling is to be explicit about how you will approach each sponsor. The more open you can be with this information, the better for everyone. In fact, the degree to which you feel like you can be open with your profiles indicates the degree of general openness in the organization. If you can manage to create a climate in which it is all right to share your approach to sponsors openly, you will be creating just the right climate for honest debate and real agreement.

Still, you can only be an idealist for so long. To my mind, it is always best to lead with complete openness and retreat, as required, to retain you personal comfort and your job.

One way or another, you should have in mind a profile for each sponsor so that you can think explicitly about how to get each one to agree.

***

Excerpted from Chapter 14, "Securing a Project Mandate," in the section titled "Sponsor profiles."

If you own the CM Bible, click here to go to this section in the Web version of the book.


CM Domain Concept of the Week
15 March, 2004
A conversion analyst figures out how to get source information into the right format for your repository.

Someone must be responsible for the overall design and creation of the system you will use to change the raw information you acquire into finished content. I call that person the conversion analyst. Her responsibilities include the following:

  • Selecting or designing the tool set that the team will need. Given the set of information inputs and content component outputs that the content analyst has specified, the conversion analyst will need to figure out what tools to buy, or create, to make the transformation as efficient as possible.
  • Creating the specifications for the programs that tool developers will follow.
  • Designing the methods the team will use. Given the inputs, outputs, and selected tool set, the analyst must determine the right set of methodologies to move information quickly through the system.
  • Designing the facilities and needed infrastructure if the team is going to be large. For example, you might need to create a large work area where dozens of people can sit and easily interact.
  • Planning and estimating the staffing levels and skills that you will need to process the expected throughput of information. It can be difficult to accomplish this task if (as often happens) there will be wide swings in the amount of information that will be received per week.