Masterminding Content Management

Page 2 of 3

      Bookmark and Share

BEST PRACTICES SERIES

Managing Metadata
To put it simply, metadata is data about data. Metadata simplifies searching for, cataloging, and personalizing content. If personnel require accurate intranet searches across document repositories or the Web site provides a personalized browsing experience, then metadata tagging is necessary.

To implement metadata tagging, a taxonomy must be defined. Information architects and domain experts should be integral members of the team responsible for defining the taxonomy. While you may begin to feel omnipotent as you define your own taxonomy, you will quickly be staring into the abyss if you ignore industry-standard taxonomies. This issue bears strong similarity to the growing pains suffered by XML; if you want to dispense useful information, inside or outside of your enterprise, you need to talk in terms that have common understanding. Start with the Dublin Core Metadata Initiative (DCMI—http://dublincore.org). DCMI provides the resources, tools, and software that can help you interoperate for fun and profit. Keep DCMI's slogan in mind—"Making it easier to find information"—as you define you taxonomy. And remember to keep it simple. The International Federation of Library Associations and Institutions (IFLANET—http://ifla.inist.fr) also offers excellent resources.

MSCMS provides very flexible metadata definition and assignment, and is assigned on a page basis. Metatags can also be easily populated through the templating interface.

Dependable Deployments
Deployment, migration, or exporting moves content and Web components out of development environments into production. Frequently, new content and functionality need to be isolated from the production environment until fully tested. Testing must always occur and is more important as a site grows and becomes more complex. Although deployment integrates with all functional areas, you can start with manual deployment and add it later with minimal impact because the deployment engine only needs to read the CM system's repository and follow business rules.

When evaluating deployment functionality, look for minimal manual interaction aside from initial configuration requirements, high reliability, redundant and fail-safe file transmission, transmission and error logging, status reporting, and scheduling. If the deployment requires significant manual interaction, you might as well continue to manually FTP files. If the deployment subsystem constantly fails and cannot resend content, gracefully recover, and log all of those activities, the manual procedures begin to look like a much better option. Deployment should allow for easy status spot-checking and other audit reports, drawn from the log and error files, requested through a user-friendly interface, and displayed in concise, easy to read reports, allowing you to verify the process. Finally, scheduling a deployment, either within the system or through the operating system removes the last manual touch-point. Once you have implemented, configured, and tested a deployment subsystem, moving content from staging into prime time becomes an assumed part of the content management process.

Interwoven's OpenDeploy provides powerful, highly customizable deployment functionality. File date/time stamp comparisons determine which files are copied. File clean up prevents the build-up of unused files on your server and deployments may occur in any direction—a truly powerful feature for bringing a new development environment or another production server online. OpenDeploy integrates with the auditing subsystem to allow the Web site to be reverted to a previous version. You can configure the deployment to execute arbitrary Perl script to accomplish just about any other tasks that must occur in and around the deployment event. Finally, secure content deployment occurs through encryption and file system security integration.

Dependable Deployments
Deployment, migration, or exporting moves content and Web components out of development environments into production. Frequently, new content and functionality need to be isolated from the production environment until fully tested. Testing must always occur and is more important as a site grows and becomes more complex. Although deployment integrates with all functional areas, you can start with manual deployment and add it later with minimal impact because the deployment engine only needs to read the CM system's repository and follow business rules.

When evaluating deployment functionality, look for minimal manual interaction aside from initial configuration requirements, high reliability, redundant and fail-safe file transmission, transmission and error logging, status reporting, and scheduling. If the deployment requires significant manual interaction, you might as well continue to manually FTP files. If the deployment subsystem constantly fails and cannot resend content, gracefully recover, and log all of those activities, the manual procedures begin to look like a much better option. Deployment should allow for easy status spot-checking and other audit reports, drawn from the log and error files, requested through a user-friendly interface, and displayed in concise, easy to read reports, allowing you to verify the process. Finally, scheduling a deployment, either within the system or through the operating system removes the last manual touch-point. Once you have implemented, configured, and tested a deployment subsystem, moving content from staging into prime time becomes an assumed part of the content management process.

Interwoven's OpenDeploy provides powerful, highly customizable deployment functionality. File date/time stamp comparisons determine which files are copied. File clean up prevents the build-up of unused files on your server and deployments may occur in any direction—a truly powerful feature for bringing a new development environment or another production server online. OpenDeploy integrates with the auditing subsystem to allow the Web site to be reverted to a previous version. You can configure the deployment to execute arbitrary Perl script to accomplish just about any other tasks that must occur in and around the deployment event. Finally, secure content deployment occurs through encryption and file system security integration.

Graceful Aging
Most content has a lifespan of relevance. Aging allows you to control content availability. Content contributors should have the freedom to create content whenever convenient, regardless of the publication date. A content contributor could create content now that should not be published for a month and place it under control of the CM system. The content contributor would indicate that the content should not be published until the appropriate time. The content creator must also be empowered to define the archiving (i.e., available through an URL or search, but not by direct navigation) and not available timeframes.

When reviewing aging functionality, ensure that it contains enough granularity to define the three states of content detailed earlier. Alternately, aging functionality may not be necessary if the deployment subsystem meets the requirements. For example, MSCMS allows configuration of two of those three dates—available and not available timeframes. Custom script can extend the functionality to include archiving and to automate the aging process.

All-Important Audit
Audit functionality captures and stores a snapshot of the Web site. The snapshot is versioned, so that it can be reviewed and reverted. Audit functionality can be thought of as a very structured system backup procedure.

For highly regulated business (e.g., financial services) or highly fluid content, audit functionality is necessary. Audit functionality is closely related to version control, focusing on the Web site while version control focuses on the Web site source code. These are frequently, but not always, the same.

Audit functionality integrates with deployment and can be easily added to a CM system. Best practices are similar to those for system backups—rotate the tapes that store the snapshots, maintain a disaster recovery plan, such as storing some tapes off site, etc. Auditing functionality requires storage space, and configuring the audit procedure so that content with differing publication frequencies is captured at proportional rates maximizes the efficient use of storage space. Essentially, content published daily is captured daily, while content published weekly is captured weekly.

Interwoven TeamSite creates Web site snapshots called editions. These snapshots capture the development environment, and prepare it for deployment to production. Combined with the OpenDeploy functionality already outlined, users have the power and flexibility of identifying a particular version and migrating it into production.

Page 2 of 3