What Is a Component Content Management System and Why Is It Useful?
In content operations, a crisis is waiting to happen. While volume, channels, and product numbers are increasing dramatically, the basic model of authoring entire documents for single output channels has not changed a bit. To avoid having to re-write the same information over and over again in different documents, companies should support their authors in creating content once that can then be used everywhere.
A CCMS manages the content in a different way than a regular CMS for documents. As opposed to managing whole documents, in a CCMS the content is organized in separate, individual components of content. These components of content are assembled into the various deliverables as and when required. Organizing teams, budgeting for translations and the speed with which corrections to the content will be implemented in a product line all change when using a CCMS.
What a CCMS manages
You start with a repository or a component content management system (CCMS) to store your content in single components instead of full documents. The components can be a warning, a procedure, a specification table, a topic or even a simple phrase like a product name. All reusable pieces of content are stored as single components.
Between the author and the publication system there is placed the content management system. The author creates his content within this system, using an authoring tool integrated into the content management system. The publishing system retrieves the content from the content management system to render it as required, e.g. As PDF or online help on a web site or as printed documentation. The content can even be delivered by APIs to other systems.
How this differs from a web CMS or a DAM
A web content management system (WCMS) manages Web pages including the structure of their content and layout of a single page. A digital asset management system (DAMS) is used to manage binary assets (e.g. Images) and manage their copyright. A component content management system (CCMS) is used to manage the individual structured parts of your content and their relationships with each other.
Component-based authoring in practice
Each topic is authored to read as a ‘single idea’ and to complete one task / to describe one concept / to be reference material. In a structurally authored CCMS, the authoring of content in isolation of its subsequent use means that the content can then be reused in many different contexts and combinations.
You map deliverables out of components in a so-called assembly file or map. The components and the map are two entirely different things and there is no chance of content being repeated between them.
The habits that have to change
- No transitional sentences that reference the previous section.
- No hard-coded product names or version numbers where a variable will do.
- Conditional attributes rather than parallel copies for audience, region, or model differences.
- Titles written as standalone labels, since they will appear in search results and navigation panes.
Reuse, and where the savings really come from
Reuse typically adds much more value in the downstream processes than it does in the authoring process itself (e.g. Translation charged by the word). The key benefit is that a piece of content that is translated once can be reused in other manuals within a product line, leading to high reuse rates (often in excess of 50%) and a resultant downward pressure on translation costs.
Anyone weighing reuse should first get clear on what a component content management system is, because there are many things that can be called reuse and most of them actually create more problems than they solve.
| Mechanism | Best for | Main risk |
| Topic reuse by reference | Shared procedures across manuals | Edits ripple into contexts the author cannot see |
| Fragment or element reuse | Warnings, legal text, common steps | Fragment library grows unmanaged |
| Variables and keys | Names, versions, units, URLs | Values resolved late, so errors surface at publish |
| Conditional filtering | Model or audience variants of one topic | Combinatorial explosion of untested outputs |
Versioning and control at component level
Track the version history of individual components. To answer the question of what a manual said on a certain date, the documentation system must track the versions of the single components. Additionally, track who approved a change and which released deliverables contain which versions of the information.
Branching, baselines, and release discipline
The organization already has a branching strategy for new products prior to migration and can then retroactively set up the repository for the legacy content (i.e. All the shared topics) to work under that same strategy (i.e. To be used in new products without bringing in new content for that product).
Deciding whether the investment fits
The only way that content volume can be used as a justification for a CCMS is when several of the following are also true.
- Content is published to three or more channels or formats from the same source.
- Translation costs are significant and growing faster than headcount.
- Product variants share most of their documentation.
- Regulatory or safety requirements demand traceable change history.
- Several authors work on overlapping material and collisions are routine.
When one or two of the issues above are happening with a team, it is typically cost-effective to go with a simple structured authoring application paired with a good version control system (e.g. GIT). But when 4-5 of these types of pain points are being experienced across the resources of an organization (even if the manual processes are already spread across those same resources), the hidden costs of those processes are likely already buried in their time.