Component content management enables reuse, single-sourcing and consistent output to channels where your products appear. The promises of a CCMS are not fulfilled by treating the tool like a pure purchase of a tool. The decisions that are made prior to importing the first piece of content will be the determining factor for achieving the objectives of component content management.
The greatest value is derived from asking a few key questions prior to purchasing a CCMS. What content models will be utilized? What will be migrated to the CCMS and what will be authored in the CCMS? What will the editorial workflow look like? Who will have the authority to change the structure of content after it has been structured?
Where component management actually pays off
Value from reuse only comes when content actually belongs in more than one place, be it in more languages, in more products, or in more customer-facing publications. If a single manual is published once a year from a single location then the effort to restructure that content for possible future reuse will not be recovered. However, if you have product families with shared subsystems, or you have very large amounts of regulated content that must be published identically in multiple geographies, or your product information is published in eight languages and revised on a quarterly basis, then the economics of structured content are very favorable.
Signals that justify the move
- Translation spend that scales with document count rather than with changed content
- Safety, compliance, or legal text that appears in dozens of deliverables and must be updated in lockstep
- Variant explosion, where configurable products force manual maintenance of near-identical publications
- Output to print, help centers, embedded interfaces, and support systems from source material that currently gets copied by hand
Then again, even within existing tools, establishing and maintaining a structured authoring discipline can often yield most of the desired benefits at minimal additional disruption.
Getting the content model right before the tool
The granularity of the components is key. If the components are too coarse, then there will be little reuse value. On the other hand, if the components are too fine then the authors will be spending most of their time figuring out how to assemble the components rather than actually writing. Reviewers will then have to wade through a lot of contextual information to approve the assembled document.
A good rule of thumb for components is that they should be the smallest unit of communication that can be understood by the subject matter expert (SME) and approved by him/her in isolation, e.g. A procedure, a set of specifications, a warning, etc. And the boundaries between the components (Section Anchors) should be natural, i.e. Where the SME would naturally draw a line. Usually this is not a single sentence, and not a whole chapter.
Standard model or custom schema
DITA provides a mature set of specializations as well as a large body of pre-existing tools and a workforce of authors familiar with DITA. On the other hand, a custom or even a very light-weight XML model would probably be able to specialize more perfectly for a given task or domain than DITA. However, this custom model would entail a host of problems and costs (especially for the organization) which would more than likely outweigh the benefits for all but a handful of special cases; in general, DITA is the way to go unless you can describe a specific requirement that DITA cannot meet.
Migration is a content project, not a data transfer
Note that converting legacy content from past projects and years of written documentation to structured content typically will reveal many old workarounds to having used headings for visual purposes, tables for laying out content as opposed to summarizing data, and writing procedures with the implicit understanding that readers will read surrounding material. Full editorial rewriting is typically required.
| Approach | Best suited to | Main risk |
| Full migration up front | Small, high-quality content sets under tight compliance deadlines | Cost concentrated before any benefit is visible |
| Migrate on revision | Large libraries with uneven quality and predictable release cycles | Two systems running in parallel for years |
| New content only | Products with short lifecycles or imminent redesign | Reuse benefits delayed until coverage reaches critical mass |
| Selective high-reuse subset | Organizations proving the case before committing | Model decisions made on unrepresentative content |
Auditing before you estimate
You should actually sample the content from the prospective components to get a more accurate number for the proportion of duplicated content (called “content reuse”). This will give you not only an estimate of the cost required to restructure the information for reuse in CCMS (content component management system), but also will give you an estimate of the value of the information as it can be reused to justify the program to finance.
Workflow and review under reuse conditions
Once content is organized into reusable components their approval processes change too. Instead of signing off on one document the approver for a given component now signs off on all occurrences of that component throughout the organization. Some of these occurrences may be in contexts the approver has never even thought of.
Acknowledge this when designing out the workflow and define whether it’s the component, or the published document that requires approval, and be aware that approving both will require additional review cycles. Make sure a report of where-used is available for the approver at the time of approval, ideally within the same system where the content is managed, and if you are still mapping out those responsibilities it is worth reading a guide to the component content management system before you finalize the process.
Practical workflow controls
- Define ownership per component type, so no fragment is orphaned between teams
- Set branching rules for variants before authors invent their own conventions
- Separate translation state from source state, and block publication when they diverge
- Log approval against a specific revision, not against the component identifier alone
Governance determines whether the system holds
Structured content is a self-destructing resource because it is written under pressure by people who search instead of duplicate, use elements that others have not yet thought of instead of asking, and write text that contains local information that is released three times later and then does not work any more.
Assign an information architect to your team to govern the structuring of content. Periodically audit your component library for duplicated content, and for unused fragments. Track and report the reuse rate of your content to ensure there is value in your investment.
