Explaining CCM (component content management) to clients is sometimes difficult. The concept of combining content at the component level to create topics, which then get combined to create publications – or not; sometimes, topics just remain topics – is complex to understand to people who aren’t typically involved in the production or management of content.

Ironically, one group that has a hard time with the concepts of CCM are the IS/IT groups. For a while, this flummoxed me, as I thought that an understanding of the technology side would be an advantage to understanding it. Then it dawned on me that knowing the general principles of content management could actually become a barrier. Content management has become synonymous with WCM (Web Content Management), with CCM considered an obscure niche within the broader field, and WCM does not handle content at a sufficiently granular level. The final two words, “content management” are the same, but it’s the first word that makes the functional difference. It’s a little like thinking a truck is a truck, whether the prefix is “moving” or “dump”.

The difference is a little like that. For the average WCM system, content is input directly into the content management system, and managed at whatever level the content is input – generally, at the page level. A change to made to a page, and an edit udpates the entire page.

For the average CCM system, the content is created in smaller-than-page chunks, and assembled, much like a content mashup, to create a larger-sized page for output. A change is made to a component, which can be a single word, phrase, paragraph, or larger, which is then compiled, much like a software “build”, which generates a presentation version of the specified sources. The aggregated content can be pushed out to a Web page, a PDF, or a print destination.

When we think of mashups, we think of the Wikipedia definition of a mashup, which is combining data from two or more sources to create a richer information set. A common mash-up is an address with a map, that displays that includes both components as a single, integrated screen, with more meaning. A content mashup is similar – for example, when an ecommerce retailer pulls product descriptions from one data source and the prices from a financial system to mash together and display according to the requested content.

The technology that allows content to be mashed up before making it to the end display is an XML editor. The editor allows authors to determine how the components will be mashed together, whether that be through a manual mechanism such as a content map, or automated through an information retrieval system such as a taxonomy or thesaurus.

Whether understanding CCM as a mashup application is helpful for purposes of explaining to the technical parties remains to be seen. I do suspect that the analogy will strike a chord with a certain client segment, though, and that’s about all I can ask.

I would argue that, depsite the perception that websites consist of marketing content, for many sites, the marketing content is only the top layer – the icing on the cake, and what supports that top layer is a substantial amount of technical content – the cake itself. 

Layers of content on a website

That technical content is often far more valuable to the corporate or product brand than the persuasive content. In doing user research for one client in particular, a manufacturer of power generators and inverters, I saw how guys used their site. Consistently, they would bypass all of the marketing material and go right for the specs. (Of course, before the site revamp, a lot of the specs were missing or buried in a PDF in some obscure area of the site, but that’s a whole other story.) They knew what inverters did, and what to look for, and went directly to find what was, to them, the important piece of information.

In effect, the technical specifications were the marketing material; if the inverter had the right oomph to it, that’s what the users wanted to know. And had the content been wrong, had the inverter been used with some disastrous results, then the ensuing fall-out would have become a marketing problem. The artificial siloing of content between organizational departments – marketing, techdocs, training, support, engineering – is reminiscent of the discussions we had about information arhcitecture, some 8-10 years ago. The difference is that for many organizations, these larger silos have become de facto standards in which they bucket their information for consumers. They assume that when a content consumer arrives on their site, they want to see a certain type of content. They try to funnel the user through their site navigation or constrain the path to the cash register. But if you look at the way consumers actually use a site, you can see that they will not be constrained. In this case study, Jakob Neilsen reveals that consumers will breeze past the feel-good content and head right for the techincal information, product reviews, and other information pertinent to their decision-making process.

The content that was sought out by the consumer, in this example, is probably produced by a department that publishes to multiple channels, not just the Web. Their content strategy likely has to take into account single-sourcing for print as well as Web, and other channels such as training materials (possibly print, e-learning, and a Web output), manuals, product data sheets, and other end products. The Web is but a slice of a greater strategy. When we talk about content strategy, then, my contention is that the type of content we include in the definition needs to broaden beyond Web content, as does the recognition that the content, even if just for the Web, includes not only persuasive content, but instructive/informative, user-generated, and even entertainment content.

If you’re the type of person who likes to write, think, edit, and then publish , tink about the pain of re-using content from an article created in a word processing program to a blog entry. You had to go through and check things like apostrophes, quotation marks, and dashes to make sure you didn’t end up with question marks in the middle of your carefully-crafted prose. That can be called “dumb work” – silly rote tasks that don’t add any value at all.

Now, multiply that dumb work by millions when content gets locked into a proprietary system. You may have a million-dollar content management installation, but what happens when you want to use your content elsewhere, or when you need to migrate content between your behemoth system and specialty systems, such as a component content management system?

Unless there is a vested interest by, say, a competitor in providing some sort of import wizard from a specific proprietary format into their own format, your content is now held hostage by the vendor’s system. This used to be considered good business sense, as it locked you into their system for long periods of time. In today’s world, however, it’s considered a pretty bad move on everyone’s part. The recognition that content is a valuable corporate asset whose value increases with its potential for re-use has changed the game.

Re-use is a concept that is often discussed at too low of a level within the corporate sphere. There are several kinds of re-use:

• Single-sourcing. This isn’t a particularly sexy type of re-use, but is the industrial workhorse of re-use that is the backbone of any product or service provider that produces technical content (user, installation, maintenance, and quick-start guides, training material, knowledge bases, and so on). The ROI on standards-based, re-usable content becomes critical, particularly in cases where translation are involved.
• Integration. Content among departments, divisions, or partner companies may need to be mashed together to create a cohesive whole. Saving troublesome conversion steps toward a common format is a huge time-saver, and eliminates the worries that the conversion process has eliminated or corrupted critical content that affects the quality and integrity of the end result.
• Convergence. This re-use case is bringing together content from various types of sources, such as mixing single-sourced content with user-generated content in a knoweldge base. The need to “round-trip” content relies on being able to get content in and out of systems easily and quickly, with as much automation and as little human intervention as possible.
• Syndication. Content flies (or should fly) outside of the organization, in the form of news releases, event announcements, and so on. If content doesn’t conform to the standards-based formats – microformats is the most common example – then the value of automating syndiations is lost, with a default position of cutting and pasting into multiple sites.

Having content that can “play nice” with other systems is a key component of a good content strategy. Because large-scale content projects are dependent on the technologies that manage the content, it’s critical to look at how the system treats the content, and how open the content is for re-use in strategic ways.