Really Strategies

• Articles
• Presentations
• White Papers
• Newsletters

Content Delivery Isn't Necessarily Part of Content Management

by Lisa Bos    Oct 2003

Among publishers who have been "doing" content management for a while and who have significant electronic publishing opportunities, we've recently noticed a trend towards separating content delivery functions from core content management activities (e.g., content creation, editing, and organization). By "content delivery" we mean tools for delivering the right content in the right format to the right location and at the right time. Syndication, licensing, web publishing, and output to print systems, CD-ROM, or handheld devices are all examples of content delivery.

There are several reasons this trend makes sense for publishers:

1. The delivery capabilities of the content management systems publishers have developed or purchased are often weak compared with the need, and so it's not necessarily an obvious choice to use the CMS for delivery.
2. For many publishers delivery functionality looks more and more discrete from content development activities. This is because publishers have many different kinds of delivery opportunities, and supporting those opportunities efficiently requires a high degree of automation and therefore relatively little interaction from people. This is very different from the CMS environment, where the whole point is to facilitate human interaction with content. CMS uses automation as part of that facilitation, but it's a supporting role. In delivery systems, automation is the name of the game.
3. A content management system includes in-progress content that is not appropriate for output. The delivery system captures snapshots of content in time.
4. The users of the two systems are very different.
5. Content for delivery often comes from multiple internal and external sources, not only the CMS. It's often useful to avoid loading some of that content into a CMS.
6. Content is often transformed from its CMS format to optimize it for delivery purposes (e.g., to better enable search, to speed performance, to conform to industry standard DTDs, to automatically apply categorical indexing). Although this is typically done in a fully automated way, for performance reasons it is preferable to perform such transformations prior to the point in time at which delivery (especially delivery to satisfy real-time requests such as those from a web site) is needed. This points toward needing a separate data architecture and therefore a separate delivery system. The transformation is performed prior to or during loading into the delivery system.
7. It can be useful to integrate a delivery system with business systems (e.g., fulfillment, user management, usage tracking for market analysis) that have little relationship to pure content management activities.
8. For security and performance reasons, it is often desirable to physically separate the CMS and the delivery platform.

Publishers' delivery systems are as diverse as their content management systems. Some use web content management systems for delivery. This can make sense if the publisher has multiple sites that change frequently in organization or look and feel, or that have a lot of web-specific content. Apart from support for delivery to web sites, most web content management systems are not quite flexible enough to fully meet publishers' delivery needs, so be sure to fully document your requirements and thoroughly evaluate any web CMS you are considering for delivery purposes.

We've observed that most delivery systems are custom-developed, and are designed around the publisher's database of choice. Oracle is becoming more and more popular for these purposes because of its XML capabilities. This also seems an obvious space for native XML databases, although we haven't seen much activity in that area.

A few of the publishers we know have chosen to focus on a delivery system prior to developing a unified content management environment. This is not necessarily a bad choice, especially if the publisher has multiple distinct content groups that use different processes and technologies but who are able to deliver content in a way that is appropriate for loading into the delivery system. This approach can also make sense for publishers who lean heavily on vendors to supply content development and production services. (Many book publishers fit this description.) Such publishers are acting in the role of a content aggregator, and a delivery system might be all that they need. A content management system often doesn't serve an obvious purpose in such organizations.

The bottom line for publishers is that it's worth considering a delivery system that is independent of your content management system(s). And fortunately, because delivery needs are becoming more and more obviously distinct from content management needs, adding a separate system can actually simplify the process of defining and architecting both solutions.