and then roll these topics into larger blocks of content that ultimately culminate in publications or content delivered to customers. The implications of this shift are enormous for organizations that have crossed this chasm from “book methodology” into “topic-based authoring.”One such implication is the need for technology infrastructure of a sort that was not previouslyneeded. It is in this context that the emergence and importance of the CCM becomesunderstandable and critical. In the past, when working in book methodology, technicalpublications organizations only had to version whole documents or chapters, for the most part. While they did seek to reuse content across publications, they typically did so only by cuttingand pasting from book to book or chapter to chapter. Since books or chapters were the unit of tracking, versioning was important but could be handled with naming conventions on the filesystem or with source controls systems.For example, with the move to DITA and topic-based authoring, what once was a suite of 200documents for one of our clients has become 70,000 topics that all have to be managed andversioned. For other clients with a larger suite of documents, the number of topics can reach intothe hundreds of thousands or even millions. As these topics go through versions, the number of topics that are shared in the repository will increase. These topics, moreover, may need to bemanaged in multiple languages (70,000 times the number of languages). With 10 languages,for example, the 70,000 topics will become 700,000 topics. And both the English and translatedtopics will be going through revisions and versions. To complicate matters further, these topicscan be used across many different deliverables. The same topic may have to appear in anadministrative guide and user guide. It may also show up in Web pages, PDF, Help files and other outputs. It may have variations for advanced and new users. Tracking the version of each topic andgraphic that goes into each deliverable is simply not possible when managing on a file system,especially if you have documentation of any substance or a requirement to manage versions andtheir relationships to each other and to larger publications.
Confusion between CMS and CCM
This brings us to the current confusion over the content management system. When manyorganizations begin to understand DITA, they ask themselves, “Do we need a CMS?” (See our earlier white paper, “Dare I Do DITA Without A CMS”, available at www.sdlxysoft.com/en/knowledge-center/white-papers.After trying DITA on a file system insome small prototypical way, organizations of any size quickly realize that they will need a processto manage the tens of thousands of topics that they have. They will also need a way to track whichversions go into which deliverables or releases. In addition, they will have to track all the variousversions of their graphics and screenshots and on top of that they will also have to track all thelanguage variants of everything“Aha,” they say to themselves, “We need a CMS.” But here is when they are in danger of making asignificant category mistake. What they really need is a CCM (Component Content Management)system – not a CMS. What’s the difference? There is a whale of a difference.