Welcome to the Astoria WebLog

A variety of Content Management Systems (CMS) exist today, providing a wide range of solutions to various content challenges. Each CMS provides a common set of features including -- but not limited to -- librarianship, version control, workflow, metadata, access controls, and so forth. Usually, a CMS is designed with a specific set of applications in mind: managing Web content, documents, scanned images, rich media, XML, etc. To expand into new markets, CMS software vendors oftentimes extend functionality though product development, partnerships, or acquisitions.

Not all content management systems are alike, however. They vary greatly in the ways that they manage the actual content itself –- the text, media assets, cross references, and links -- and how they manages the changes to these items over time. The ability to manage the changes to content over time is a key way to differentiate various CMS applications.

CMS applications to support Dynamic Product Documentation require very demanding approaches to maintain conformity to product releases. Typically, this content is delivered in multiple formats such as PDF, HTML Help, etc. and is subject to frequent changes/updates and requires tracking these changes at a very granular level.

Many of our customers need to maintain complex documentation sets. Efficiently managing the creation and delivery of these information products involves keeping track of multiple versions and the changes made to each, as well as publishing the right information for each target audiences in the appropriate languages. The ultimate challenge is to maintain older products (and their legacy documentation) at the same time you create and deliver newer configurations of the same or derivative products. These information products all share a common set of content and require a very granular management approach to track the differences and configurations for each release. These variants all need to map to customer deliverables and are typically published in multiple languages.

A dynamic solution calls for a very fine-grain content component management system to manage complex deliverables. These requirements go beyond a typical document or file management system. Dynamic content solutions need to manage the complex product variations, versions, languages and links typical of documentation, help files, service guides and training materials. Managing the relationships of the content and their changes over time requires extensive management of content components –- text, graphics, rich media –- and all of the links tying them to product deliverables.

Content component management systems like Astoria provide a very easy approach for creating and managing content for reuse. Components of larger documents (or components of DITA Topics) can easily be shared between deliverables. An advanced, object-oriented content component management system does not require you to define “minimal revisable units” or MRUs to reuse content nor do they need to “burst” a document into “chunks.” This saves significant time and effort when designing component reuse models and lets you easily adapt your reuse model in the future.

The higher percentage of reuse within a deliverable, the greater the consistency of information provided to your customer. Reuse also builds in protection from future product changes by minimizing the time required to make changes. With advanced content component management systems like Astoria, you can easily change the content reuse model without any programming or database administration. A component approach also provides applications with the ability to automatically assemble documents based on search queries, customer profiles, or specific content. This greatly expands the potential derivative documents that you can provide –- customers can receive custom- tailored documents on-demand designed to meet their specific needs.

However, not only are you required to manage component changes, but you also need to manage the changes to the component relationships over time. For example, a newer version of your product may have dropped support for Windows NT, but the older version continues to support it. Without a CMS, you are forced to mange two (or more) sets of documentation, even though 80 to 90 percent of it is identical. Differences usually are just in screen captures, procedures or menus. Add localization into several languages, and you have a configuration nightmare that can grow to become unmanageable when storing this content on a typical file system.

Finally, your customers do not want to figure out what documentation applies to the products that they purchased from you. Customer satisfaction surveys show that consumers believe that they are often provided too much documentation, much of which is not related to the specific version of the product purchased. Too often, they report, they are forced to cull through content that does not apply to them at all. This leads to customer dissatisfaction, and in many cases, increases in calls to your support center. In some circumstances, customers get fed up and take their business elsewhere.

Often in customer meetings the discussion moves towards the “ripple effect” that Engineering Change Orders (ECOs) have on documentation. Product changes always have impact throughout an organization. The closer it is to the product ship date, the larger an impact ECOs have on product documentation and the ability of the technical documentation team to manage updates in a timely fashion. ECOs have a compounding effect when content has already been sent to the translation vendor -– people have to work all hours of the day and night with costs skyrocketing. The better prepared you are to manage them, the smoother the process for implementation.

A component management system is designed from the beginning to anticipate the ripple effect providing several critical features to minimize their impact. First, you can quickly identify what content components are reused -- and where (and by whom) -- within the information products you create. When you update a source content component, it automatically updates all other references to it. In this scenario, only the source content requires review and approval, saving critical time. Finally, only the components that have been changed will need to be re-translated, again minimizing time as well as costs.

In conclusion, a content component management approach provides the disciplines of a CMS while providing an easy way to manage and adapt to future business requirements that were not relevant during your initial implementation.