JoAnn Hackosさんが成功のカギとしている最初のカギは
"Adopting single sourcing, and creating modularized, topic-based content"
と記述されています．いわく「シングルソースを採用し、モジュール化したtopicベースのコンテンツを作成する」．（何かそのままの訳になっていますが...）というものです．
シングルソーシングというのはあきらかに出力メディア別にコンテンツを書かない、すべてのメディアは一つのコンテンツから展開する、例えばDITAからPDF, EPUB, HTMLを作るなどという感じなのでしょう．
これと逆の例があります．この数年聞いた話なのですが、InDesignで出版用なりのPDFを作成する、最近はEPUB（EBook）も流行なので、どうしてもそっちも作りたい．ではどうするかというと出版用のPDFからEPUBは作れませんか？というものなのだそうです．私に言わせれば、PDFは言ってみれはWindows GDI（Graphic Display Interface）のゴミ捨て場のようなものでおおよそ元の論理的な構造を持っていません．（現実にはこれがまったく理解されていないようです．）これからEPUBを作れというのですから気が遠くなります．ワークフローの順序が完全に逆なのです．もしDITAでオーサリングし、そこから出版用のPDFを作りEPUBも作ると言えばなんの問題もないでしょう．
つまりシングルソーシングというのは実は簡単なようで実に難しい、現実世界のワークスローを変革しなければならない場合も存在するということなのだと思います．（でもpublicationという意味ではInDesignが圧倒的に強く、ワークフローを変えるのはたぶん困難ですね．）
2014年のDITA FestaでSAPが全社的にDITAを採用というプレゼンテーションを聞きました．SAPは世界的なIT企業だから思い切ってそんな改革も出来るのかも知れません．たぶんまだすべてがDITAではないでしょうけれども、妙な想像をするとSAP本社の住所はconref（またはconkeyref）できるように、IXIASOFTのCMSの中にちゃんと納まっていて、すべてpublicationはそれを参照しているのではないかと思います．何故こんなことを妄想するのかというと、日本の大手企業で本社移転に伴い、ありとあらゆるpublicationの本社住所を変えなければならず、それに億というレベルのお金をかけたという話を聞いたことがあるからです．DITAではどうでしょう．conref先（conkeyref先）の本社住所を期限を決めて変更し、あとはそれを参照するすべてのpublictaionをリビルドしてdeployするだけで済んでしまいます．
シングルソースはそういう意味で非常に大切です．でも現実の複雑な企業の中のpublictaionの流れを見ているとそう簡単にはできないのでしょうね．
「モジュール化したtopicベースのコンテンツを作成する」というのも相当訓練を積まねば難しいのではないかと思います．日本でも2000年代に先進的にXMLパブリッシングに踏み出した企業は大抵DocBookを使用しています．DocBookは全体がsetもしくはbookという巨大なXMLで分散化するために、実体参照を使用したり、XIncludeを使っています．ですので．トピックベースのオーサリング、モジュール化という考え方はないように思えます．また再利用もせいぜいできるのは実体定義/実体参照のレベルでしかなくオーサーはDITAの考え方に慣れていません．これはあきらかにDocBookでかかれたな？と感じる技術文書は、どちらかと言えば読み手のためにあるのではなく、書き手の都合でどんどん書かれているという印象をうけることはしばしばです．
またDocBookからDITAに移ったといわれるpublicationであっても、読んでみると相互参照（xref）のオンパレードで到底topicとしての「完結性」をまったく求めることはできずがっかりしたことがあります．
ですので、シングルソース、モジュール化されたtopicベースのコンテンツを実現するというのは、言うのはたやすく、実は相当努力しないとできない課題ではないかと思います．
