Getting Serious About Content Management @ XML JOURNAL

Getting Serious About Content Management

For some time the text information world has known instinctively that something called "content management" should be part of its planning and operations. Prior to the Internet and Web, however, managing one's content, while perhaps valuable, often wasn't perceived as critical to the success of information efforts, and where it was, technological "cats and dogs" could be made to work well enough to get by.

Things have changed. Today an organization's very survival can depend on its ability to create or acquire, manage, and deliver rich content on ever-tightening schedules to audiences increasingly impatient with any lapse in currency or usability of presented information products. In the face of this growing demand that providers better manage and share what they know, the need for a closer look at what works well is making itself increasingly felt. The demand is further escalated as more content is designed and created in XML - enhanced by the rich structures and tagging conventions made possible by this rapidly growing worldwide family of standards, but complicated by the growing complexity of the XML movement itself. Indeed, this article is intended for organizations using or considering XML to create, manage, and deliver content in an information world increasingly impacted by the Internet. Organizations with data in RDBMS software have already developed a structure and discipline that may be used to "wrap" content on the way out. While this approach doesn't work well for richly structured document content, it's an effective way to manage and deliver simpler, less complex data.

Take a Functional View of CM
The very nature of the term content management is often misunderstood. Content management is something one does, not something one buys or builds. This misunderstanding has created a CM marketplace in which every vendor claims to do CM, and many prospective users, with no working definition of what CM means to them, have no idea whether the claims are true or false, often with serious and costly results. Moreover, with the growing trend among Web management vendors to advertise themselves (often with little merit) as "end-to-end" content management providers, the stakes have become even higher and the penalties for error even more costly. Gartner, for example, categorizes CM systems into three functional groups:

1. Web content management: Managing content ready for delivery

2. Digital assets management: Controlling the source, consumption, and rights to content

3. Document content management: Managing the process of creation, review, and finalization of content for delivery

For the most part, vendors in one area don't understand or do a superlative job in the others, although you'd never know it from their presentations.

Develop a Detailed CMS Function List
A key best practice related to content management is to carefully investigate your own content life cycle, developing a detailed description of the functions required to fully support its information objectives. These descriptions will become the road map you need to confront a world in which many vendors want to sell you content management, but in which few are selling what's described above. Indeed, for any particular organization, there's no adequate definition of CM outside this list of required functions. While some CM functions - check-in and -out, and locking, for example - are common to most organizations, many other functions appear in differing patterns across organizations, even within the same industry. For instance, you should include in your CM function list such items as:

How your content is designed for presentation to your target audiences and media: Your target deliverable will determine your optimum CM approach.

How you want your authors and contributors to mark and manage revisions: Some CM architectures are incapable of developing a coherent record of revisions.

How you author and represent links and associations among portions of content: Your CMS must be able to link at the levels you need, but not all products can.

How you support your authors' productivity and accuracy: They spend only 5% of their time in the CMS, so they shouldn't have to fight it to get their jobs done.

How you capture, store, and communicate information about your content and its status: Some CMS approaches are forced into a tortured process to link "metadata" to the content it describes.

How much and how soon you can expect your environment to evolve into something different from the form in which it was originally set up: Scalability covers more than volume and traffic.

Armed with a carefully developed functional CM list, you'll be able to plan and communicate with the vendor community from a position of strength. While most vendors will answer in the affirmative if the question is, "Do you offer CM?" the answer may be very different if the question includes a list of specific functions and the request that vendors sign up for each one or explain why they don't offer it and include their proposed alternative.

The most successful CM project I've ever seen, for example, used an RFI comprising nearly 400 pages. Among the 56 vendors contacted, over half opted out immediately after reading the requirements. The end result was a system that met every functional goal, supporting nearly a thousand authors producing over 200 information products in up to five media simultaneously.

Take a Holistic View of CM
Organizations seeking to establish CM in their environment often view it as a discrete component that can be acquired and dropped in, largely on its own merits and without consideration for other portions of their information life cycle. This isolation of CM from the information flow it's supposed to support can have serious implications for how (or whether) the resulting architecture works. Viewing CM as "plug and play" benefits the vendor community, so software salespeople virtually never raise this issue, preferring instead to get the sale and let the buyer deal with the resulting problems later.

A more holistic approach to information and its management would suggest that because value in the endeavor begins with the design and capture of rich content and matures in its easy and successful use by target audiences, management of the entire process is part of the content management equation. For example, functions like linking, reuse/variant management, and content modularization, although normally thought to be outside the realm of content management, will significantly impact and be impacted by the CM system acquired to support them. Moreover, the system's architectural characteristics will inevitably impact the ability of content contributors to perform their critical functions, and likewise the ability of delivery tools to organize and create the output products users want and will accept as successful.

Given this interdependence of phases in the information life cycle, CM tools should be evaluated and acquired only with a clear understanding of the complete set of challenges they will be asked to address. Because every tool is different and every manufacturer has personal technological preferences, you can't assume that because a system is advertised as "Content Management" it will meet a particular set of needs.

This approach, admittedly, makes for somewhat more work on the front end, but it pays rich dividends, not the least of which is a working environment that meets its own and its customers' needs. Most everyone has heard at least one horror story about what can happen if CM is acquired in a vacuum: poor performance, out-of-control costs, dissatisfied users and customers, even complete failure.

When Choosing Technology, Keep It Simple
Every design component and every tool acquired to support it presupposes a technological approach. Where CM is involved, a key technology component is the underlying repository in which the content is stored and on which the CM functionality is based. A valuable precept in this choice, inherent in any CM planning or acquisition, is simplicity. While technology can be argued in detail, in general the best approach, especially where CM is involved, is the simplest one (with thanks to William of Occam, who clearly stated this principle nearly 700 years ago).

There are several discrete approaches to the storage and processing of content; four of the most often encountered follow:

1. Fragment the content for storage in RDBMS tables, keeping metadata in other, linked, tables.

2. Store document content "as is" in database BLOBs (binary large objects), keeping some metadata in the content and some in linked DBMS tables.

3. Store document content on the file system, using RDBMS to store metadata.

4. Store XML content in a native XML repository, storing metadata in the content, keeping metadata in the content itself, and using DOM (Document Object Model) software to access both.

Each approach and the software based on it has characteristics and limitations that will materially affect its ability to properly support your CM requirements. Through application of the functional and holistic views of CM described above, it's possible to understand how a particular CM approach and product will function in your environment. That accomplished, you'll be able to choose the simplest, most straightforward option consistent with your needs. Moreover, coming to a choice on functional, holistic, and simplicity grounds will allow you to make the oft-required trade-offs between functionality and cost on a rational basis.

Recap

Design your overall environment first; you can't decide how to manage until you know what you're managing.

Flesh out your CM function list and send it to prospective vendors as an RFI; you want their thoughts before you ask them to bid.

Ask vendors to detail how they plan to support your requirements; only vendors with an idea of how to solve your problems will want to run this gauntlet.

Call in only those who return direct answers to your questions and ask them to explain their answers in even more detail; don't allow canned demos, they always workand almost always muddy the water; if you feel a demo is appropriate, ask each vendor to demo with your data and to show only those functions on your list.

Base your acquisition plans on which vendor does the best overall job of meeting your needs; beyond prudence, don't worry about who is the largest or the most aggressive, but look carefully at a vendor's existing clients in circumstances similar to yours.

About Barry Schaeffer
President of XSystems