Sharing data modules – efficient or not?

Is a shared DM always the best route for use in multiple publications?

In today’s blog post, ONEIL’s Lead Technical Writer for Aerospace, Mark Hatfield weighs in on the importance and efficiencies of the sharing of data modules.  Some organizations and experts believe the reuse of data modules (DMs) for multiple publications is a no-brainer decision and can be easily justified. Developing a single DM is an appropriate route (and maybe the best route) to take when the content applies to multiple manuals. However, there are situations where this could be costly. That’s why it is important to consider who will ultimately use the data. Then, decision-makers can determine if a shared, single DM is appropriate.

Data can be shared between publications by creating one DM containing content relevant to multiple publications in a group or series. The shared DM is then added to the publication module (PM) of every applicable publication. This idea is most efficient if the creator and consumer of the data are the same entity. If changes to the shared DM become necessary, the change would be made to the individual DM within the creator’s CSDB (Common Source DataBase). Then, the change would automatically be filtered down to all affected publications within said CSDB. Now the information is readily available to all who need it with access to the CSDB. Simple, effective, and best of all, cost-efficient!

What happens if the data is consumed by a user with no access to the creator’s CSDB?

Let’s say an update is required to a process or procedure detailed in the DM, shared in multiple publications, and delivered to a user outside of the creator’s organization. Let’s keep in mind that any issued changes, require an official upissue of the entire publication, with change markings and <rfu> tagging to detail the changes made. As with any update, the procedural change is directly made in the shared DM. However, now the task of updating more than just the shared DM exists. Front matter data modules are required to be revised to reflect revision histories, and a new transfer package and/or PDF is published to deliver to the outside user. This is completed for every publication that uses the shared DM. Reuse of a DM in this instance has now become quite a burden with multiple publications, all requiring upissue and redelivery. This cycle will continue every time a change occurs to the shared DM. Precious time has now been wasted making redundant changes in multiple publications.

Alternative Options

One potential alternative to the use of a shared DM could be to develop a standalone publication under the guidelines of S1000D. Utilizing the externalPubRef, a reference to the standalone publication can be inserted in every applicable publication. Now, if any changes are required to the content of the standalone publication, only the standalone publication itself will require the update. The modification and delivery of multiple publications has been avoided, which saves time and money. The key is to identify the requirement for shared content and develop a plan as early as possible. As plans for publications in S1000D are developed, it is crucial to invest time up front to consider future releases of publications so projects can begin on the right foot and be easily maintained.

Learn more about how ONEIL can help with our S1000D expertise.