Even the most ardent defender of S1000D has to agree that it has limits. It is a great specification for capturing complex technical data in a complex fashion. And, while long, the Data Module Code (DMC) is good at uniquely identifying S1000D data module content. I admit I still have to, on occasion, look up all of the components that comprise a DMC. For a more detailed explanation, visit our S1000D Glossary. For your reference, here is a quick explanation:
However, just as S1000D is not an ideal fit for someone creating a poem, a DMC is not a good means of identifying non-S1000D content. For example, using pseudo-DMCs while creating supporting content for the specification, including creating unique IDs for business rules is a bad idea. Pseudo-DMCs create additional complexity and do not provide additional value in return. Using a simpler ID syntax provides all the capabilities you will need. The methodology we use is simple: take the chapter from which the rule came and append a -1, -2, -3, etc. (e.g. 3.9.1-1 correponds to the first rule within chapter 3.9.1).
Based on our experiences, DMCs should be used solely in identifying S1000D data module content.
We at Crowell have been knee-deep in S1000D Business Rules for the past couple of months. And that has resulted in our thinking of ways to improve the process of creating and managing business rules. In my previous blog, I mentioned how storing business rules in a spreadsheet application is a bad idea. In this post, I’d like to propose an additional idea for creating business rules: Standardization! This should be a no-brainer for all of the people in the S1000D world, as we are all about standardization. Alas, we have failed to standardize the means of creating business rules. Programs, groups, and individuals are free to create business rules in any form and by any means they deem appropriate. The problem is that programs are going to want to view, “borrow” and reuse other groups’ business rules. The fact that there isn’t a standard model for creating business rule decisions means that sharing this content is a slight pain in the you-know-what. Here’s a practical example: we have a customer who is developing a set of business rules for a new program. In developing these rules they are referring to a governing set of rules developed for an entire branch of the military. However, we are using chapters as the foundation of business rule ids and they are using pseudo Data Module Codes. Secondly, these governing business rules have imperatives in the description column of the particular rule. That is, there are “shalls” and “shall nots” in both the description of the business rule and in the business rule decision. These two items, coupled with the fact that the guiding business rules are in a spreadsheet (my previous angst on this expressed above) and thus not easily reusable, makes the job of mapping the governing business rules to our customer’s business rules somewhat of a Sisyphean task. I propose a simple solution: A standard means of capturing business rules. I think this could be fairly easily accomplished, as most business rule documents have a similar structure, even if the content is in a spreadsheet. That structure is:
- A business rule ID – Every business rule needs an id. I hate the concept of pseudo Data Module Codes, and will “rant” about that in my next blog post, but if I lose that small battle for the sake of the larger victory, I am fine with that. The bottom line is that every business rule needs an id.
- Heading or Title – This is the informative title of the particular business rule, such as “Use of Graphics within Titles”.
- Business Rule Description – This component of business rules lays out the problem at hand, such as “Projects must decide whether or not to allow graphics within the title element.” As noted previously, this descriptive content should not have any imperatives. There should be no directives here, only a description of the content.
- Program Decision – This is the group’s decision with respect to a particular business rule. Continuing the example, a good business rule decision would be “Program X will not allow graphics to be located within titles”, or, “Authors shall not place graphic elements inside of title elements”.
These business rule components, and any others deemed necessary, can be captured in a very simple and easy to use XML syntax. It could look something like this: I suppose someone could argue that we simply use the syntax located in the BREX for this, but the BREX isn’t designed for human exchange of business rules. Rather, it is designed to be machine processable. I suppose that’s what I am getting at: A standardized syntax for the human consumption of business rules. –Rick
There’s a trend emerging with respect to creating S1000D Business Rules, and for a couple of solid reasons, I’d like to see it nipped in the bud. The trend I am referring to is storing business rules in an Excel Spreadsheet. Why is this a bad idea you ask? I’ll give you a couple of reasons:
First, storing business rules in an Excel file renders the business rule completely useless if you wish to reuse it for anything else at any point in the future. The OBVIOUS reuse opportunity is the generation of BREX rules. BREX rules are derived directly from your business rules. As such, is it not the most technically and analytically sound decision to have your BREX rules literally derived from your business rules?
If you store your business rules in an application that is capable of reusing them, you immediately gain the following advantages:
- You don’t have to write a BREX document…that’s right, you don’t have to write a bunch of XPath statements or pay somebody a boatload of money to do it for you.
- You can link business rules to BREX rules. Then, when your business rule changes, your BREX rule is changed and all you have to do is press the “go” button to generate a new BREX document.
My second reason for wanting to do away with maintaining S1000D Business Rules in a spreadsheet has to do with the concept of “layered” Business Rules. Right now, entities such as the Air Force, Army, and Naval Aviation Departments are creating business rules. Individual programs will want to use those rules as a baseline and also create their own rules that further define their policies and guidelines with respect to S1000D. And guess what? They’ll probably want to see and use other programs’ and departments’ rules as well. The more columns that are added to a spreadsheet, the more unreadable it becomes. And, adding a new column does nothing if a group wants to actually use a business rule from another source.
I wrote up a white paper that dives further into this topic. It can be downloaded from White Papers.
Next Blog Entry: Creating a Standardized Means of capturing S1000D Business Rules
Welcome to our new and improved website and our new blog page. We are going to post blogs on a regular basis, and we will try to stick to topics that are essential to us and our customers – that is S1000D, content management, Tech Pubs, document management, etc. As per the norm, this will be informal, and it will include opinions, likes and dislikes. We encourage feedback, regardless of whether you agree or disagree, and we certainly hope you find it useful and informative.
Rick Schochler, COO Crowell Solutions