Carrying the earth on our shoulders

At last week’s STC Summit, I attended a couple of presentations that probed the same question. It’s an old question, but it’s still a thorny one.

atlas_rockefeller_center

I used to see this guy on childhood trips to New York. Now he reminds me of my Tech Pubs colleagues.

How can we integrate content into a unified presentation when the content comes from all over the place? When different teams — communication specialists and nonspecialists — are creating content using different tools and different styles, often with different objectives in mind, how can we present it to customers as a unified whole?

Both presentations showcased successful case studies for integrating content. Both placed the Tech Pubs department at the center of the action. Yet both left me wondering why this whole thing — integrating content produced independently and content produced as part of a collaborative effort — isn’t easier.

How tech writers drive brand language

Rhyne Armstrong and Nate Wolf showed how their Tech Pubs department acts as a focal point for applying consistent branding for content across a division of Cisco Systems. My ears perked up with they described applying consistency to content that came from more than a dozen mergers and acquisitions over the past couple of years.

How tech writers support SMEs

Søren Weimann described a setup, using DitaExchange, in which field-support specialists put content into “topics” that look to them like Word templates. Weimann’s Tech Pubs department then performs its background magic to integrate, review, and apply a consistent format to the topics.

Tech Pubs at the center

In both scenarios, the Tech Pubs department provides and supports the infrastructure for creating, reviewing, storing, and publishing the content. It’s a good fit: Tech Pubs has the expertise and the motivation to take the leadership role. But does it have the time and the wherewithal?

As I prepared to write this article, I wondered what image I could use for an illustration. I quickly hit on one: Atlas carrying the earth, just as the Tech Pubs department carries the whole process for integrating content across the enterprise.

atlassian_old_logo

The Atlassian logo (until 2017)

I quickly realized that a company, Atlassian, had already appropriated that image for its name and (until recently) its logo. And that one of its flagship products, Confluence, is built for just the kind of integration and collaboration we’re talking about.

Here, from its corporate website, is how Atlassian describes Confluence:

Easily publish, organize, and access company information in one central location so you can help your customers help themselves….
Confluence combines the speed of creating on your own with the advantages of working together.

That sounds just like what we’re after.

So why isn’t everyone using Confluence, or a similar offering like DitaExchange? Because while the tool might be part of the answer, it’s apparently not the whole answer. (I’m not here to disparage Confluence. In fact, we use it at work, not for cross-department collaboration but for internal knowledge sharing, and it serves us well.)

The rest of the answer

If the tool doesn’t provide the whole answer, why not? I have a couple of ideas.

First, SMEs live in a different world, tools-wise, than technical communicators. Programmers, engineers, and field-support staff don’t talk about content-management systems. They talk about GitHub. They don’t want to hear about authoring systems, although most will deign to use Microsoft Word.

Marketing? They often inhabit a whole other world (or other universe).

That’s too many differences to reconcile in a one-size-fits-all solution. Although multiple teams within a company might agree on a set of tools and a workflow for collaboration, as Søren Weimann described, there’s no single solution that works for everyone.

Second, in many companies I suspect that the Tech Pubs department, even when it has the desire and the technical know-how to set up a system for collaboration, lacks the funding and the political clout to make it happen.

What do you think? What are the barriers to content integration and collaboration at an enterprise level? Is Tech Pubs the right organization to take the lead? If so, how can we do that, given the resources and the limited influence we have?

Do you have a success story for integrating and collaborating on content? If so, I’d love to hear about it.

Advertisements

3 thoughts on “Carrying the earth on our shoulders

  1. Pingback: 2018 STC Summit - Cheers to a milestone birthday and the future! - STC San Diego

  2. Pingback: Carrying the earth on our shoulders – Technical Writing World

  3. Mark Baker

    HI Larry,

    Indeed, there is no one system that fits everyone. Indeed, there is often not one system that fits all the needs of even one group. This is because “content” covers such a wide range of deliverables that there is no one tool that is well suited to producing all of them, no matter if all of the contributors come from one department or several. In particular, there is a line between page-designed content and flowed content that no one tool can handle with equal grace and efficiency.

    Page-designed content is created by hand. It is formatted by eye and not by rule. It is an essentially manual task. Different departments can all use the same tool for doing the design work but the win is not very big because there is limited scope for reuse or collaboration in such a manual task.

    The interesting question is, can we take all the content that is or could be formatted by rule and have that all be created by a common system used by multiple departments? Here the opportunities for wins are substantial. Doing things by rule can lead to greater efficiency and consistency, but rules can be expensive to define and implement, so if everybody is doing their own thing, then those costs are born multiple times, which often means such systems are not implemented at all.

    This issue here, though, is that when we use a system that performs any operation by rule, the writer has to supply the data used by the rules. That is what markup is for — to supply the data used by the rules. The problem is, writers in different departments have different concerns and different levels of skill, knowledge, training, and patience to devote to learning how to supply that data and validating that they have done it correctly. Many markup systems in current use, such as DITA and DocBook, ask for data in terms that make sense to technical writers and desktop publishing people, but no sense to the rest of the corporation. In other words, the data semantics that make sense to one group don’t make sense to another group, and so they choose different tools with different data semantics that make sense to them.

    So the question becomes, can we find a set of semantics that makes sense to each department but which can still be used to feed a common publishing tool chain with all the rule based automation we are looking for. Clearly the answer is not going to be any complex publishing-based system like DocBook or a content-management based system like DITA because the semantics of publishing and content management (what I call the document domain and the management domain respectively) don’t make sense to them.

    If we are going to find an answer, it is going to lie in the subject domain, with markup that does not describe content in publishing or content management terms, but in terms of its rhetoric — markup that locates the content in the subject domain. Every writer, no matter what department they work for, can mark up content in the subject domain because they understand the semantics of the content they are writing. Getting them to agree may be another matter, but at least the data semantics you are asking them for are semantics they understand.

    There is no one universal subject-domain content format because subject-domain markup is specific to the subject matter. That is how we know that the writers will be familiar with the semantics — they are the semantics of the subject they are writing about.

    But the real question is, can we do all the content management and publishing automation we want to do based on subject-domain semantics alone. The answer is, by and large, yes, though there are definitely some caveats.

    All of this will be covered in detail in my forthcoming book, Structured Writing: Rhetoric and Process, coming real soon now from XML Press.

    Reply

Tell me what you think

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s