Richard Machin

Single Sourcing and the Naming of Parts



Posted: Tuesday, December 29, 2009

by Richard Machin
readytext

The realization that information of all kinds is an asset isn't new but it's certainly gained popularity of late, perhaps because the tools to store, manage, and manipulate information are more readily available. It's easier than ever before to manage what we call ‘content', that is to say information that we decide may be useful to us or to our consumers. So now we can store all our help documentation, designs, meeting notes, e-mail messages, presentations and even phone calls – not simply because we can, but because in future we may be able to use that information in the creation of new content.

When you treat information as an asset it's natural to look for ways to more efficiently extract value from it. Writers recycle information in periodicals, presentations and books. Engineers' ideas appear in e-mail, design specifications and patents. It's the same principle by which Honda builds a number of different cars from a common set of components. You increase the value of your work when you develop core reusable assets that can then be combined to build new deliverables. That's the essence of single sourcing; create once, use many. If the whole is greater than the parts, then more wholes must be even greater.

Information Parts

These information parts must be as self-contained as possible if they are to be re-assembled in this way. For Honda, this may mean a chassis design that is generic enough to be used in a truck, two SUVs and a passenger car. For Microsoft, this might lead to a paragraph titled connecting to a network that appears in the operating system help, in Web browser popup help, and in internal user support documentation.

The key to maximizing reusability of these parts is to identify them clearly, and avoid unnecessarily limiting their reusability. In single sourced trap information parts, don't mention mice when the same trap comes in three sizes: mouse, rat and gopher. Instead, compose your documentation from clearly labeled and distinct common trap, mouse, rat and gopher parts. Here's an example:

The Gizmo trap is made entirely of exotic hardwoods and surgical steel, for years of trouble-free use. The trap comes in different sizes, depending on your pest control requirements. The mouse Gizmo traps house and field mice and has an integrated cheese dispenser. The rat Gizmo traps rats up to nine inches. The gopher Gizmo traps gophers the size of small dogs. Gizmo traps are guaranteed for five years, and come complete with instructions and a handy storage box.

The good

The gizmo company implemented single sourcing for all its information from day 1. When it develops the third version of its gizmo product, G3, the benefits are clear:

The bad

A single sourcing strategy means that poor information continues to be propagated until it's identified. Also:

The ugly

Single sourcing hinges on the accurate and comprehensive ‘cataloging' of information parts, if those parts are to be readily identified and reused. This leads to the generation of huge amounts of ‘meta information', information about information, that itself then needs to be managed. In fact, in the age of the single sourcing, meta information is easily as important as the information itself, and must be used as carefully and as sparingly as possible. We need to be able to quickly ‘tag' new information parts with meta information when we write them, and quickly identify those parts when it comes to re-use.

This problem is hard enough when we are starting from scratch with a new content strategy that is based on single sourcing. It's compounded when we are faced with legacy content we need to distil into information parts.

Consider the previous example of the bad:

My entirely accurate part on how to use Gizmo feature X may become inaccurate if in future not all Gizmo users are licensed to use that feature.

A perfect single source implementation would of course have tagged the original content and the new licensing option such that the dependencies were clear. Introducing the licensing information would trigger a warning that the feature X part now needed an additional disclaimer part regarding licensing. But our composite documentation may still end up ugly and repeatedly betray its single sourced origins, much like the gun parts lecture in Henry Reed's Naming of Parts:

This is the lower sling swivel. And this
Is the upper sling swivel, whose use you will see,
When you are given your slings. And this is the piling swivel,
Which in your case you have not got.

More on single sourcing and developing a comprehensive and usable meta information strategy in future posts, and in more depth in the rewrite newsletter which as yet you have not got – but it's coming soon.

This Article has been viewed 131 times. (Not updated in real-time.)
No comments yet.
We want your comments! If you can read this, you don't have javascript enabled, so you can't use this comment system. Please enable javascript.