Evaluation criteria for component content management now has to focus on details that tend to get left out of a vendor demo, since most credible platforms these days support DITA, have a browser-based editor, and provide various types of reuse metrics. It’s the finer points that determine whether a system actually works at scale or quietly accumulates workarounds to apparently minor problems.
Structured authoring that your writers will use
Authoring a model is only as good as the experience to enter content into it. Ensuring that specialization rules are enforced at authoring time as well as at publish time helps to write good, semantic content (as opposed to flat topics that only validate). Everything else follows.
Be sure to test the editor on your toughest content. Find out how the platform handles things such as conditional profiling of inline elements, nested tables with complex spans, embedded math or code, and very long topics with dozens of keyrefs. Find out how the platform handles a broken conref, whether it can resolve keys live in the editing view, and how long it takes to open a topic deep within a map that contains several thousand topics.
Accommodating non-specialist contributors
SMEs don’t learn DITA. A contribution path of some sort that adds content without having to delve into the tag view is likely required, potentially even a form-based editor that contributes valid DITA, a review-and-comment path, etc. When source formats are changed, who now owns the mapping to feed into the platform?
Scalability that holds at repository size, not user count
First, the typical way that vendors spec out their authoring systems is by concurrent user counts. Much more limiting though is how a system will handle scale in terms of query performance for things like link resolution and where-used. How will a system handle hundreds of thousands of components with lots of cross references?
The larger concern for how long content will live in your repository and how often it will be translated and maintained (by how many authors) is scale for things like link resolution and where-used lists on very large repositories. How long does it take to render a full product library of 10K pages? 11 hours for a 1.5G File Repository means your release process has a constant that you can’t change.
- Time to open a large map and resolve all references
- Where-used query response across the full repository
- Full-library publish duration and whether renders can run in parallel
- Behavior of search and faceting once metadata volume grows
- Backup and restore windows at production data volumes
Localization economics as a design concern
Of greater value to you would be the architecture for translation that is integral to your documentation platform, as this will typically represent the largest recurring cost in documentation for large enterprises. See what unit of work is sent to your TMS for translation.
Does it send topic-level (or even segment-level) change detection information so that one corrected sentence in a warning notice document does not require review of 40 copies of that document? How does it handle translation memory alignment with re-organization of the source information (as opposed to simple edit)?
Managing language variance
When evaluating authoring requirements for markets outside of the enterprise, components of content that need to be authored may be completely different. Also consider whether content variants for languages can be authored and have these components appear in Reuse reports as well as track changes made to the original Source component. Compare various enterprise CCMS systems, and if translation volume dominates your budget it is worth putting a platform such as IXIA CCMS on the shortlist for how it handles localization at the component level.
Workflow and governance that survive an audit
Note that workflow engines vary greatly in what they can model. Of course a simple linear process like draft -> review -> approve can easily be modeled, but also more complex reviews in parallel, conditional routing, approval by regulatory persons for specific content types, and escalation in case of delay are typical test cases to find the limits of a workflow engine quickly.
| Capability | Basic implementation | Enterprise requirement |
| Approval routing | Fixed sequential steps | Conditional branching on metadata values |
| Audit trail | Version history per topic | Immutable record of who approved which rendered output |
| Permissions | Role-based folder access | Attribute-based control down to component and branch |
| Release control | Manual snapshot | Baselines with locked references and reproducible builds |
Reproducibility
Can reproduce exactly to two years ago (including stylesheets and references), and lock in transitive dependencies in the ‘baseline’.
Reuse governance before reuse volume
High reuse percentages are easily achieved but can also be easily regretted. Uncontrolled reuse of content leads to components that no one owns, changes have unexpected effects on products written by others, and a very hard to manage repository that cannot be easily refactored.
Look for tools that allow for ownership metadata to be added to components, impact analysis to be completed before content change is checked in, and that allow for components to be marked as locked/deprecated with a replacement component. Also, look for strong governance reporting to identify components with no owner, not reviewed in X time, and near-duplicate components that should be merged.
Look for all of these issues and weigh them against your own requirements. Run a proof of concept on your own content using your own translation volumes. The vendor’s demo will work; your own repository won’t.
