Mapping, Single Sourcing, odd situation

[Gwen Thomas <gthomas -at- PAYSYS -dot- COM>]

Folks, here's an unusual one.

Someone sent me a private e-mail telling me how misguided my approach to Single Sourcing is. The arguments are well-thought out and beautifully presented.  As a matter of fact, I completely agree with parts of it!

So what's up?  What the writer was opposing (and calling me to task over) is NOT what I was proposing. Just the opposite.  I'd hate to think anyone else had the wrong impression of what Single Sourcing actually means, so I'm posting his e-mail (with name removed, since if he wanted his name up here he could have done so) followed by my response. Together, they're pretty long.

<snip_Mr._X>
You [GT] said:

> By the way, the ability to leverage related sets of information in such a
> manner is one of the strongest arguments for using a database approach to
> Single Sourcing of certain kinds of documentation.

 The problem is that you are mapping facts not language.
Single-sourcing, as TWs see it, implies language rather than facts. It would
be fine if we could write the facts or assertions once, and leave the
generation of the multiple treatments up to some mechanism. And, this is
possible right now. But, it doesn't look like writing.

 For the present, single sourcing implies a compromise on treatment.
I've seen document sets that did not leverage treatment. Every description
was the same. The user manual and the training manual said the same thing
with the exact same words. This redundancy was a waste of my time, and my
company's money. Single sourcing is a production technique that saves the
ISV money, but allocates costs to the user. The IT industry, as buyers, are
beginning to wake up to the post-purchase costs of software. And, most of
the complaints about the apparent lack of productivity stem from those
costs. Vendors are focusing on eliminating administrative costs for their
customers, because the customer sees those costs. The costs of reading,
tutorials, training, technical support calls, experiments, and the costs of
the impedance between the user's conceptual model and the application's
conceptual model are much more transparent. Gartner Group already looks
broadly at the numbers, so you can expect that negative use costs will get
more attention. When attention is paid to this issue, ISVs will begin to
lose customers. Single-sourcing at the language level only makes matters
worse, not better.

                The only argument for single-sourcing is reduced cost for the ISV.
And, that's fine if you work in a cost center, and have no value add at the
customer's end.
</snip_Mr._X>

<Gwen>
I COMPLETELY agree that redundancy is a waste of the user's time and the client's money.

I suspect you have assumed that I advocate an approach to Single Sourcing that I vehemently DO NOT.  I do not under any circumstance believe in writing one piece of "language" and then throwing it onto multiple paper books and help.  That's not Single Sourcing, no matter how many people call it that.

I'd have trouble disagreeing with someone who said that such an approach is an insult to the user, and - as such - a VERY expensive mistake for a company to make.

So what do I mean when I speak of Single Sourcing?  You hit the nail on the head - it's usually all about facts, not language.  It's about maintaining a single source of information that is then inserted into multiple documents.  (Remember, Single Sourcing is shorthand for "Single Source/Multiple Use."  The premise is that content is separated from presentation.  No one said anything about presentation no longer including the responsibility to communicate appropriately and effectively.)

What kinds of data sets lend themselves to Single Sourcing?  Usually, those that consist of big bunches of facts surrounded by predictable language AND which appear in multiple documents.

For example (I've made facts bold - hope your reader shows it as such):
The Account field, which is 18 characters long, can be added to Report ABC by blah blah blah...
The LastName field, which is 25 characters long, can be added to Report XYZ by blah blah blah...
The City field, which is 22 characters long, can be added to Report ABC by blah blah blah...
----
Report ABC contains the following data: Account, ShortName, City, State, Postal code.
Report XYZ contains the following data: FirstName, LastName, ShortName, Social Security Number.
---

Is the above nice, fluid writing?  Of course not.  This is where skill as a writer comes in, and a reason why DBAs with no writing skill are probably not the best people to do Single Sourcing projects.  A good writer would be able to look at the above (untruncated) sentences and know a better way to present the information surrounding the facts.  "Hm... If the blah blah blah is short, perhaps the template should include a table.  If it's long, then perhaps paragraphs are OK and the repetitive language at the beginning of each section would be a plus rather than a minus.  Or then again..."

If I dealt with this kind of data (facts) a lot, I would probably know how to store the data so it would be available to multiple kinds of "language"-based presentations.  But I wouldn't be able to begin to know how to approach the actual documents from a writing standpoint without knowing a lot more.  No one would.

And that's an important point about Single Sourcing. If you concentrate on only the data and ignore the writing, you'll end up with good data and bad documents.  Period.  You have to pay just as much attention to the document and the flow of the language as you ever did.

Likewise, if you try to cram data into a Single Source solution that isn't right for it, you will be doing your readers a huge disservice.

For instance, if you're writing typical help topics, then probably most if not all of your content is not a candidate for Single Sourcing.  I agree that you're cheating your users if you craft a single paragraph to serve as reference, online instructions, and training material.

However, if your documentation includes large amounts of repetitive information (this is more typical in reference work) or if you have complex and dynamic cross-references, then Single Sourcing might be an option.

Mr. X said, "Single sourcing is a production technique that saves the ISV money, but allocates costs to the user."

I would say that is true of some multi purposing.  And perhaps of bad Single Sourcing.  But good Single Sourcing should be entirely transparent to the user.

And, Mr. X said, "The only argument for single-sourcing is reduced cost for the ISV.
And, that's fine if you work in a cost center, and have no value add at the customer's end."

It's not the only argument.  Increased quality can be a big incentive.  But there's a lot of truth to what he says. You can save money, and that's going to appeal to many execs.  In the near future, a lot of pointy-haired bosses could be saying "Make it so!" to ambitious database administrators who come up with a proposal that includes "eliminating some of those overpaid writers."

So here's the real question:  Are TWers going to abdicate Single Sourcing to DBAs who might not have a commitment to effective communication?

Gwen Thomas
Knowledge Management Consultant
CIBER Information Systems, Inc.


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=