Having to continually answer the question around the use of the Common Source Database (CSDB), I am always amazed by projects that are trying to ignore the vital need of a CSDB and try to mend and make do with a file system or a legacy content management system.
ALSO AVAILABLE AS A PODCAST – DOWNLOAD THE TDW APP NOW
Let us not ignore the fact that the S1000D specification itself calls out the CSDB on its cover page “Using a Common Source Database” – it can’t get much more prescriptive than this.
There are real reasons why the specification calls out for the use of a CSDB. S1000D is specific about the production of structured data modules, and the management of these modules requires particular functionality within the supporting database, way beyond traditional content management systems.
S1000D is about information configuration, exchange and application. Defined S1000D methodologies tell us how we produce, identify, validate, transfer and publish the data modules.
The CSDB (assuming you have a good one) looks after all of the S1000D processes for you. From quality assurance, to issue numbers and language information through to the complex codification of content and a lot more aside.
One of the most significant tasks a good CSDB must be able to perform is link management, ensuring all references resolve and available for use by any reader of the published content.
I continuously reference ‘a good CSDB.’ There are reasons for this. A CSDB is a CSDB, and a good CSDB will consider technical publication processes outside of those defined within S1000D. A good CSDB will work with standard technical publication processes in mind, beyond what S1000D requires.
Projects that try to ignore the function a CSDB plays in any successful S1000D project will quickly learn the hard way.
A story for you
I was asked to head in to see a major component supplier in the aerospace sector. The team I was asked to see understood technical publications, they knew the need from substantial, usable technical information assets to support their products.
When it came to delivering their first S1000D project, the bean counters decided that an investment in a CSDB was overkill and unnecessary.
Everyone had previously agreed with the thinking behind this as it was a small S1000D need that contained around 700 data modules. So a complex set of spreadsheets and file systems were set-up to ‘manage’ the S1000D project.
Appearing to work well, right up and until the project had to deliver its first set of S1000D data modules. The client asked for a DDN, and all associated content required per the specification. A good CSDB will build this for delivery in minutes. The project took hours of manual effort and reading the spec to understand what the need is from a DDN.
After manually creating the DDN and securely transferred to the client, a message received from the client that the DDN imported into the master CSDB but had failed numerous validation checks and rejected the delivery.
It turned out that references were not resolving, i.e. had any ultimate destination. Illustrations were called that did not exist, and the list went on. The data immediately rejected, and a world of obligatory contractual discussions opened. I was called in to help fix the delivery problem that a good CSDB would have avoided.
If a good CSDB had been in place, the end client would have confidence that the project was executing correctly and as desired, we could have all gone home for tea and biscuits.
My immediate suggestion was ‘get a good CSDB’, and this stuck in the throat of many as they were involved in the decision not to buy one in the first place and focus on world-class spreadsheets.
The CSDB is a must have on any S1000D project. There is no nice to have here, and there are no shortcuts to be taken. Ignore the vital role of the Common Source Database at your project peril.
Have you managed to support an S1000D need without a CSDB? Let me know I will happily doff my cap to you.
What CSDB do you use? Is it a good CSDB? Let Mike know firstname.lastname@example.org