Looking for a name for a CS practice area

[Rahel Bailie]

To put what I'm looking for into perspective, let me use content
management as an example.

People would say "content management" when they actually meant "Web
content management". So when trying to tell stakeholders why they
couldn't manage technical documentation content with a WCMS, they
didn't get it. (And even today, many of them still don't get it, no
matter how much you explain it). There was no industry-adopted name
for what we did, for ages. Then, one day a couple of years back, a
Gilbane analyst writes a blog post calling it "component content
management" and it stuck. Now, there is a clear delineation between
WCM and CCM, though there are still many people who simply insist that
"content management" is a single entity. (More ranting about that in a
blog post on my site.)

So now we come to Content Strategy, and we're in the same boat. People
talk CS, and what they really mean is a Web Content Strategy. Then
there's the other kind of content strategy, the one thta involves
technical material, that spans techcomm and training and support, that
outputs to multiple channels, not just to a site of some sort, and
includes the variations that include localized content. But how do we
differentiate? Ann Rockley subtitled her book "a unified content
strategy" and I know what she means, but thta's not particularly
catchy. I can see people asking "unified between what and what"? So do
we call it component content strategy? Convergent content strategy?
Topic-based content strategy?

Personally, I disliked the term component content management when it
was adopted, but now that it's widely adopted, my vote is for
component content strategy because that's the level of content we're
managing. Any thoughts, feedback?

Rahel

===
Rahel Anne Bailie, Content Strategist / CM Consultant
Intentional Design Inc. www.intentionaldesign.ca
Content strategies for business impact Tel. 604.837.0034 (PT, GMT -8)
Social apps (skype, twitter, etc): rahelab
LinkedIn: www.linkedin.com/in/rahelannebailie

[seamus walsh]

Rahel, a quick question on taxonomy. What is Component Content a component
of?

Seamus Walsh
Founder
VAZT Global, Inc.
www.vazt.com

802-879-6787

Optimizing People, Process and Technology®

[Richard Sheffield]

Interesting question Rahel.

 

To continue your content management analogy, in my area we differentiate between Web Content Management and Enterprise Content Management. ECM involves creating/managing multiple file types and outputting in many formats to various channels. WCM focuses mainly on creating/managing Web content and outputting to HTML or XML.

 

Do we need an Enterprise Content Strategy label? I wasn't real clear if you were looking for something with a peer-to-peer relationship to CS or a parent-child relationship to CS. Obviously throwing the word Enterprise in there implies a higher level, parent relationship to CS.

 

Sorry if I muddied the waters a bit. Just thought we should deal with the Enterprise label and get that out of the way while we are talking about taxonomies :)

Richard

[Rahel Bailie]

Replying to both Seamus and Richard, I want to differentiate between
"enterprise" and "component", both in the CMS world and, with any
skill, I'll have done so for the CS world, as well.

Enterprise Content Management, over the years, has meant several
things. The theory was that by capturing all business critical
documents, unstructured content (email), and so on within the
enterprise, you could improve findability and get business
intelligence out of it. At conferences, listenin to vendors,
enterprise content seemed to mean "Web content management plus
document management across a couple of department silos". Industry
analysts started talking about emporers and clothing (actually, lack
thereof). As the years went on, ECM has morphed, but it's not the same
beast as component content management. Component content management is
like "content mash-ups" - you can re-use small content components
within topics, and you can re-use topics in multiple contexts, and
publish them either as topics or aggregate them in multiple ways for
multiple outputs.

Technical documentation is a good example of this because you can have:
- Topics
- Content re-use at a phrase level (good example is warnings and cautions)
- Content re-use at a word level (product names are a good example)
- Components imported from other sources (for example, part numbers
from an ERP system)

These topics get:
- aggregated into a series of topics, determined by a map (TOC), that
gets published as a manual
- served up as help files through a search (and/or aggregated into a
series of topics and published to a help file that is navigable
through a TOC)
- partially re-used, according to whatever rules have been
implemented, by other departments, particularly training and customer
support
- transformed into other types of XML so that select pieces of
content can automatically be sucked in (yeah, technical term) to
another system automatically (an example could be product descriptions
that get incorporated into a Product Information Management system for
publication into a catalogue, or user assistance information that gets
displayed directly in a product interface)

Obviously, the content strategy for this type of scenario is quite
different from that of Web OR Enterprise projects. The complexities of
each of these types may be equally demanding, but they are quite
different, and the understanding of the back-end requirements can be
quite specialized. (I've not done much enterprise stuff at all, but
have done the other two types, so I speak from experience). So ...
seeing as how we're just out of the gate onto the content strategy
track, I was hoping that someone saw an emerging trend, and we could
nail down a name. (It certainly would make it easier for me to discuss
the difference between this group and the CS SIG over at STC, and tag
my blog posts with some consistency/longevity.)

Here is some related info that helps illuminate:
http://gilbane.com/whitepapers/X-Hive/Xhive_Gilbane_Whitepaper_CCMS6-final.pdf
http://www.billtrippe.com/archives/2003/09/
http://intentionaldesign.ca/2009/09/11/component-content-management-as-content-mashup/

[seamus walsh]

From my view I see you saying that component content resides as an example
in technical documentation and ERP, which could be broken down further into
HR, supply chain, finance, IT, etc. etc.

You mentioned mapping, aggregation, and formats you don't mention people or
process. Maybe, morphed, mashed and re-used is where the politics of data
silo's resides?

I like it. I think component content allows us eat the elephant one bite at
a time.


My two cents.
Seamus

[rsh...@gmail.com]

Thanks Rahel,

Yep, I agree, I just wanted to get the ECM conversation out of the
way :)

I guess I've been doing CCM for the last 7 years, so I forget there
are other ways! Our site is built by packaging one or more content
modules into a page structure and generating HTML or XML from that
page structure. The modules are designed for re-use as well as
localization. They can vary in size from an entire page of content
down to a single sentence or link. Each module has associated metadata
so it can dynamically appear, or not appear, based on how it is
tagged.

We just refer to this as a Modular Content Management structure, but
that's really no better than Component Content Management.

Dealing with these modular issues is what our content strategists
spend much of their time doing. At the start of each project they must
inventory all the affected modules, then decide which ones can be
changed (because the the project change is appropriate for all
contexts) and which ones need to be versioned (because the new project
change would not be appropriate for everywhere the module is currently
used). It is certainly a specialized skill set within content
strategy.

But what to call it?? Back to square one.

Component Content Strategy
Modular Content Strategy
Structural Content Strategy
Object Content Strategy

I'm just throwing stuff out there :)

Richard

[Rachel Lovinger]

Well, it sounds like Component Content Management is a particular approach to Content Management (even if it's so pervasive that most of us have forgotten it's just one approach out of many). It seems odd and limiting to talk about "strategy" in terms that imply an approach.

 

Also, I'm not convinced we need to toss out Enterprise Content Management, just because "Enterprise" has been misused or misapplied in the CM world.

 

-Rachel

[Rachel Lovinger]

Maybe we need a little more definition of what this practice area of CS does and doesn't include.

 

-Rachel

[Rahel Bailie]

Just to be clear about my original question, it's not to toss out ECM.
I think of ECM as the "warship" level of content transportation
vehicle, as compared to "minivan" or "dump truck" level of vehicles
for the other two. Just vast difference in scale.

Rahel

[Coleman Yee]

This kinda reminds me of the concept of "Learning Objects" in elearning.
(See http://en.wikipedia.org/wiki/Learning_object)

Some ideas could be stolen from there.

Content Object Strategy?

coleman.

[Larry Kunz]

I've posted some thoughts at
http://www.sdiglobalsolutions.com/Default.aspx?tabid=77&articleType=ArticleView&articleId=51

I'll be interested to hear what you all think.

Larry Kunz

[Hilary Marsh]

I agree that we do very different things under the umbrella of "content strategy."

As Rahel said, she and Ann Rockley, for example, are primarily concerned with technical content, which lends itself really well to chunks of information that can be reused and repurposed in multiple ways. That's why Rahel's elevator speech is concerned so much with business processes.

Web content strategy, which involves news, marketing, program information, etc. is very different. In those cases, it's more about planning what content is needed, where goes, and how it's connected (and ensuring that the information is properly created for effective Web presentation) than about breaking large content blocks down into smaller parts or creating something in one format and ensuring that it can automatically export to multiple formats. It's about identifying what information needs to be on a page, and what happens to the page when the information gets outdated. It's about taking information from multiple sources and making sure it has a common voice and tone, and it's about governance for that content and the site overall.

Technical content usually lives deeper within an organization and deeper within a site, so it has different concerns.

So, what should we call each part? I wish I could offer really compelling practice names, but all I've got is "Web content strategy" and "technical content strategy."

Hilary

[John Hawkins]

I'm gonna go with "knowledge strategy." I prefer to think about this
stuff in terms of who needs to know what, where is the information,
and how does each audience prefer to receive it? Which leads you into
how information is created, produced, governed, and delivered within
and outside organizations, preferably in a way that is consistent with
the organizational mission.

Hilary's comments about website governance apply to technical
documentation too (and marketing communications). I don't think it's
really a different conversation.

The differences for different layers of organizational knowledge (or
content) are audience, preferred communication channels, preferred
styles, and audience goals, and that should be what drives the back-
end knowledge architecture (not the other way around).

john

[Rahel Bailie]

I've bounced the term knowledge strategy off of potential clients, but
they don't understand it at all, and find it offputting, as in "I'm
not looking for a knowledge management [sic] strategy" so I'm going to
keep searching.

Rahel