The wall is not scaled gradually. There is a point in time when a single writer can no longer keep up with increasing volume in an expanding product line. That point may come when a single product’s Release to Market is held up while a translation cycle is extended past the scheduled Ship Date. Or when a single regulator requests proof of what was shipped and when it was shipped.
First though, a very brief overview of the main mechanisms in a component content management system (CCMS) and the trade-offs for each.
Reuse only pays when the component boundaries are right
Although high reuse ratios are often cited as a goal for using a CCMS (Component Content Management System), they are in fact a poor lagging indicator of good information design. The only relevant statistic is the reuse ratio for that small percentage of content that is reused frequently, that of the safety warning in 90 outputs that was written once and corrected once thereafter.
Over-fragmentation leads to an enormous number of very short topics which are almost impossible to find. Assembling these in long documents also will lead to chaos because out of context topics will break. Under-fragmentation leads to topics containing too much product specific information which need to be forked the first time a new variant is introduced.
Choosing what becomes a component
- Content that appears verbatim in three or more deliverables and has a single owner. Warnings, prerequisites, and legal statements almost always qualify.
- Procedures that differ only in a value, which should be handled with variables or conditional attributes rather than duplicate topics.
- Conceptual content tied to a feature rather than a product, so it moves with the feature across the portfolio.
If your single-use topic doesn’t meet one or more of these tests, then don’t manage it as a component. It’s not worth it. The cost of managing a single component is not zero.
Workflows that survive a team of forty
Collaboration on content in a shared file system depends on authors remembering conventions that hold for a small number of authors (8 or so). For 40 or so authors, spanning three time zones, spread over two contractor agencies, they inevitably fail in some way. A CCMS embeds conventions for a single author in the check-out process, and for others, in permission to modify and to use in builds released as product.
How many states should you have? If you have too few, your review process may devolve to not being formalized at all. And if you have too many, then all of the authors in your organization will be clicking through a long pipeline of states to publish their topics. Most organizations end up using four to five states to manage their review process, draft, in review, approved, published, and under legal review or regulatory review.
Reviewer access is the usual failure point
Subject matter experts will not learn to use a structured authoring tool. However, they will comment in email if you require them to go through the review path in the structured authoring tool. Test the browser-based review interface with the actual subject matter expert engineers, not with a demo account.
Translation economics change when the source is structured
Translation cost can also reveal huge savings. While documents revised even slightly go in full re-translation to the vendor, translation memory in a component-based content approach means only the changed topic is translated with very high match rates for the remainder of the topic.
Meanwhile, approved content can now be translated in parallel with later chapters. As content scales, so does the organization supporting it. Large portfolio organizations supporting more than a dozen languages find that the ability to schedule content translation based on topic approval in multiple versions of a product is worth more than the cost savings of translation.
Version management for products that ship in parallel
Complex portfolios need to support many different released versions. Branching content as one would code in a software project and then being able to merge in changes to topics already released to customers is what a mature CMS can deliver.
| Approach | Best suited to | Main risk |
| Conditional filtering in one topic set | Variants sharing most content, such as tiers of the same product | Condition logic becomes unreadable past three or four dimensions |
| Branched topic versions | Long-lived releases needing independent maintenance | Fixes must be propagated deliberately, and are sometimes missed |
| Separate topic sets per product | Genuinely distinct products with different owners | Reuse drops to near zero and duplication returns |
Typically three levels of applicable components are used for most portfolios, shared, department-specific and project-specific. Deciding which components to use is Governance, which should be decided by the information architect for the team, not individually by each writer. Teams that want this branching and governance handled for them out of the box are usually well served by a purpose-built platform such as MadCap IXIA CCMS, which was designed around exactly these parallel release patterns.
Publishing at volume without manual assembly
Automated Output Generation, Use Your Single Source to Generate All Required Deliverables. In most cases a single source will support generation of a company’s help center, PDFs for filing with regulators, in-product help and knowledge base feeds.
Where the build time actually goes
- Resolving reuse references and conditions across the map, which scales with content volume.
- Transforming to each output format, which scales with the number of outputs.
- Publishing to targets, which is usually fast but fails loudly when credentials or schemas drift.
Schedule full builds, not individual components, and consider a failing full build a blocker to automated publishing. Finely automate to fail fast, and lose confidence in the automation quickly if you allow failures to accumulate.
