The Unexpected Analogy of Technical Data and Fictional Novels

A data module and a scene — the not so unlikely “doppelgängers.”

Are you one of the many people who think there is a huge gap between technical information and storytelling?

The recognition of storytelling’s value and benefits is growing more and more in the business and management world. After a brief research online, I discovered at least several books having in their titles the words “storytelling” and “data.” Here is one of the articles listing nine of them:

Even so, we might still not see that connection between technical information, especially between technical manuals, and engaging stories.

Why does it make sense to search for such a parallel?

There are two main reasons:

1. Stories are engaging. By telling one successfully, you might help those you try to relate the data, make the story more personal for them, and make their engagement in the project through that even more efficient and successful.
2. You can make a difficult concept much more understandable and relatable.

I was fortunate to have stumbled upon and experienced the second reason as a big epiphany when I was also writing fictional novels while being active in an international technical community.

The international community was that of S1000D, “International specification for technical publications using a common source database.”

Here is an article with a glimpse into this fascinating world:

The unexpected epiphany about at least one of the parallels between technical publications and fictional novels came to me for the first time at a discussion during one of the breaks between the sessions of the international conference titled “S1000D User Forum,” which took place in Seville in 2016.

I got a question about Data Modules. It is a brilliant concept of S1000D and is defined as follows:

“Data Module (DM): A self-contained unit of data for the description, operation, identification of parts or maintenance of the Product and its support equipment. The unit of data consists of an identification and status section and contents section and is produced in such a form that it can be input into and retrieved from, a database using the data module code as the identifier.” — S1000D Issue 5.0, Chapter 9.2.1 “Terms, acronyms and subject index — Glossary of terms”

Here is why the concept of a data module is so brilliant. You can create it once and then reuse it in many different contexts: training material, maintenance, and operational manuals, parts catalogs, and so many others. And the same data module (the same file) can be presented in so many various formats for different users of different nations and user communities.

But however ingenious the concept is, many who are new to S1000D have difficulty to understand it. The phrase “self-contained” implies that a data module must contain “not too much and not too little, but just enough” information for the user to take a step in learning about or working with a complex piece of technology. But how much is not too much and just appropriate?

I had written and self-published several fictional books by the time I participated at the S1000D User Forum in Seville at the end of September 2016.

So when I got challenged to explain what a data module actually was, I suddenly had an idea. I exclaimed, “Data modules are so much like scenes in a novel!”

Right after that, I couldn’t stop the flow of realizations.

“Just as scenes,” I said, “data modules have a start (for a procedural data module, it is preliminary requirements), the middle (the procedure itself), an end (close-up requirements), and one setting (a unit or assembly, where the operational or maintenance procedure takes place). And in a way, just like the scenes in a novel, they tell a concise and self-contained story, or a future short story, that is how the given procedure is to take place.”

This epiphany might also have been facilitated by a statement I made during the presentation I made at the same User Forum in Seville before the above discussion took place. During that presentation, I claimed that technical manuals were books, whatever format they are in or however interactive they might be.

The presentation and the discussions afterward only strengthened this flow of parallels between novels, books in general, and S1000D conformant technical publications.

After the User Forum, I jotted down a list of topics I could think of when relating S1000D and its constructs to storytelling, and I came up with at least seven of them immediately. Today, I guess that you can find an equivalent in a technical manual to any tool or construct the fictional writers use in their novels so artfully.

Already at the User Forum in Seville, and later, at the subsequent training courses on S1000D, I started bringing up these parallels, and the result was inspiring. Many reactions demonstrated aha-moments to have taken place, and broad smiles of finally understanding a complex topic were the reward.

Above that, I felt that bringing such parallels forward about S1000D to those who were starting to deal with it and dreaded it — like I did many years prior — helped them to begin to like S1000D and the ideas behind it, or at least to start looking at it with curiosity.

The second reason above — of helping to understand a seemingly complex concept — became the main one for me as an S1000D consultant to uncover the parallels between beloved fictional books and technical manuals. After uncovering those parallels, I am even more convinced that the latter ones deserve as much admiration as the former.

Thank you for reading!

If the article above made you curious about the fascinating world of technical publications and S1000D, then I invite you to check out the resources I offer on this topic here. If you like, you can also browse through the earlier articles published on my S1000D blog.

P.S.

To stay in touch, join my e-mail list, Optimist Writer.