Last week we introduced the topic of educating our Managers on what they need to know about S1000D to ensure you achieve the most from the technology.
The first item essential to a solid implementation of S1000D is the BREX or Business Rules EXchange data module.
Everyone working with S1000D should be able to give a one sentence description of what a BREX is and why we need to reference a BREX when authoring S1000D content. The logic or proper understanding of what a BREX actually does when utilized in an S1000D Authoring environment, would immediately answer the follow-on questions:
- Why do we need to develop a custom BREX for our Program?
- Do we need to invest in developing a BREX at the start of the project, or can it wait?
If BREX is based on the projects Business Rules, and the Business Rules are the decisions that the project (or organization) has made on how they are going to implement S1000D to achieve the final delivery of the content; then without making the decisions on how S1000D is going to be used for the project early, the project has the potential to fail.
The S1000D Specification has provided assistance to help with the development of your Business Rules and BREX. The Specification has identified Business Rules Decision Points (BRDP) which can be the basis of the projects implementation of S1000D. In both Issue 4.1 and 4.2, S1000D provides a spreadsheet of the BRDPs and this can be used for you to document your decisions. Once these decisions have been made, you can then use the S1000D Schema brDocs. This schema has been specifically developed to allow you to write your project implementation of S1000D.
The development of your Business Rules will then provide you with information that needs to be documented into your BREX. The Business Rules are the human-readable information of how S1000D is to be implemented, whereas the BREX is the computer programmable information that software can use to validate the information that the authors have entered into the individual Data Modules.
As we start to dig into the information that is provided in the Business Rules, we find that they do not just cover the requirements for the authoring of the content, but can cover all aspects of the project from implementation through to delivery and onward to maintenance. These Business Rules become a living document and will continue to be developed and modified based on the requirements of the project.
If the BREX and Business Rules have not been developed and the authors are using “word of mouth” to define the decisions, it means that the authors have to rely on the memory to ensure that the content that is being written is valid. The authors are required to either rely on their memory or each person writes their own information down. If each author writes their own notes down then no one is working to one common set of rules.
Based on the above information we can start to see the importance of Business Rules and BREX and how these become the basis of the implementation of S1000D into a successful completion of a project. For technical authors, the focus will be on the authoring/writing requirements that are contained in the Business Rules and this information is adapted into the BREX. Therefore, the importance of S1000D authoring tools that validate against a BREX to provide the Technical Writers with the means to programmatically verify the information that has been entered into the Data Modules, will reduce QA load and rework later.
Based on the above information why would a manager think it is OK to not develop a BREX or to wait till further down the track to build a custom BREX?
Have we educated our Manager on the data validation that can be automated by using a BREX? Has the Program Management analysis shown how the quality can be increased and reword decreased by utilizing a BREX?
Let’s make sure we educate our Managers on exactly what a BREX does, along with the QA statistics and costs (shortfalls) associated when we don’t work with a well-defined BREX!