Why a CCM is Not a CMS
Or Why You Shouldn't Confuse a Whale with a Fish

People are beginning to realize it is a mistake to call some systems a "CMS" (content management system), when they are really referring to a "CCM" (component content management) system. The difference is critically important. By making this category mistake and confusing a CCM for a CMS, some organizations are failing to convince their management that they need a specialized system called a CCM. Their management or IT organizations think they already have one, when in fact they do not. Just as a source control system (which does versioning) is not a CMS and just as a Web content management (WCM) system is a specialized type of CMS, so a CCM is a unique specialized system for the management of another critical enterprise function: namely the management of technical information.

To understand this question of categorization, it is perhaps helpful to look at a less technical analogy. At first blush, it would seem reasonable to classify a whale as a fish. After all, a fish is a sea creature that swims and lives in the water. And by these criteria, a whale certainly would fit the category.

But we know to reject this categorization, because our scientific classifications trump the more intuitive categorizations. A whale is a mammal and not a fish; therefore, we give scientific classification priority on how we organize our thinking.

This analogy is useful when we decide what kinds of systems to include in the category of CMS (our "fish"). It is not the case that the systems we are calling a CMS (our "whale") can’t fit into that CMS categorization. They can. But that categorization misses something essentially important about these specialized systems. A CCM has capabilities that are not in every old CMS. A whale could be a fish but....

The Content Management Evolution
This kind of category mistake is common when there is a paradigm shift occurring in technology adoption and a new technology category is emerging. We have seen this before in the emergence of the content management category itself. Remember the days when we had only document management systems? When content management systems first emerged, no one had heard of them either and they had to differentiate themselves from document management systems. Then HTML and the Internet came along and imposed new expectations on corporations for managing their interaction with customers over the Web. With this change emerged the Web content management system. A WCM differs from other kinds of content management systems because it is focused on particular problems and processes in the enterprise that have distinctive challenges and business objectives.

The same paradigm shift is now happening with the emergence of CCM as a system distinctive from a CMS. This emergence is part of a much broader shift that is occurring in how organizations manage technical information across the enterprise. What is driving this transformation is the shift from a book-oriented writing paradigm to topic-based writing using the XML standard called DITA (Darwin Information Typing Architecture).

The manifestation of this shift is the changing role of traditional technical writers or authors into true "information developers." Technical publications as a discipline is becoming much more like software development in that many individuals contribute "modules" or "topics" in their own particular area of expertise. They create these "disembodied" or "contextless" topics and then roll them into larger blocks of content that ultimately culminate in publications or content delivered to customers. The implications of this shift are enormous; organizations have crossed the chasm from "book methodology" into "topic-based authoring."

One such implication is the need for technology infrastructure that was not previously needed. In the past, when working in book methodology, technical publications 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 cutting and 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 files system or with source-control systems.

With the move to DITA and topic-based authoring, what once was a suite of documents has now become thousands or millions of topics that all have to be managed and versioned. These topics, moreover, may need to be managed in multiple languages and may be used across many different deliverables such as administrative guides, user guides, Web pages, PDFs, help files and other outputs. There may be variations for advanced and new users. Tracking the version of each topic and graphic that goes into each deliverable is simply not possible with a file system... especially if you have documentation of any substance or need to manage versions and their relationships to each other and to larger publications.

Confusion Between CMS and CCM
When many organizations 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 http://www.sdlxysoft.com.) After trying DITA on a file system in some prototypical way, organizations quickly realize they will need a process to manage the tens of thousands of topics they have.

So they opt for a CMS. This is when they are in danger of making a significant category mistake. What they really need is a CCM—not a CMS. What’s the difference? There is a whale of a difference.

Forget for a moment the names CMS and CCM—names don’t really matter. What an organization needs in order to manage DITA is a system that can track not only versions of topics and graphics but relationships among topics, graphics, maps, publications and deliverables. The problem of managing DITA is not the versioning of discrete "objects"—it is the problem of versioning all the objects in relationship to each other at the same time. Tracking the moving relationships of all these components presents the problem of managing information in a topic-based architecture. Without understanding DITA, the tracking system can’t possibly manage the relationship of all the moving parts. It is this linking of versions to each other, to larger blocks and to publications that the standard content management system can’t manage out-of-the-box.

The name CCM is now being adopted by analysts and users to describe a system which has this key layer of functionality, above and beyond the standard versioning and workflow of every basic content management system. This layer of logic is at the heart of what allows DITA to deliver an ROI.

What is ultimately at stake for those in technical publications or information development is to realize that CMS is a category that hurts them more than it helps. If they ask for one, they will likely find that the IT organization has already invested in one. And chances are that that CMS or "collaboration platform" is not one that can understand DITA natively. But those who understand DITA know that the key issue is managing the relationship of versions to each other.

And to do that, the CCM must understand DITA. This is why a CCM is not a CMS and why a whale is not a fish.