It’s quite common for companies to spend a lot of time and effort on writing, agreeing upon and managing their S1000D business rules; not to mention the time spent on updating BREX data modules whenever authoring rules change. You can save both time and money by using an S1000D business rules management tool. Based on our experience, it takes companies an average of 1.5 FTEs over 2.5 years to develop a complete set of acceptable S1000D business rules.
By using a management tool for your rules, it is possible to reduce your time to completion down to 6 months with an average of 0.5 FTE over that shortened timeframe. Essentially, your return on investment will come out to be nearly 4 FTEs! If you multiply this by your internal loaded rate, you can easily calculate the cost of completing this effort without a management tool.
Your costs without a business rules management tool:
- 1.5 FTEs = average FTE working full-time to complete the effort
- 2.5 years = Duration of business rule development
- X = your loaded rate
Therefore, your cost = 3.75X
For example, if you have a loaded rate of $60/hour your total cost comes out to $468,000:
Your costs with a typical business rules management tool:
- Software price = $50,000 – $90,000
- Duration of business rule development = 0.5 years
- Cost savings: $418,000 – $378,000
- Time savings: 2 years
The Business Rules Exchange Data Module (BREX DM) is used to programmatically enforce business rules that govern what can and cannot appear in an S1000D data module’s content. The BREX DM uses XPath statements that verify that authored content conforms to the project’s business rules. For example: to ensure consistency in the units of measurement used in a program a BREX rule could specify and enforce the use of only metric values.
Note: There are business rules that are defined by a project that cannot be enforced programmatically. Business rules that cover general policy (such as publishing to an IETM environment) are dictated in a Business Rule document, but are not part of the BREX.
At a company that I once worked for (I won’t name names, but they once enjoyed a good reputation in the SGML/XML world), we developed and marketed a process for how data moved through a system, from creation to distribution. It served as a very effective tool for explaining to our customers exactly what we did and why our services were valuable.
I think a similar approach is needed for detailing the activities in instantiating an S1000D-based system. I’ll come up with a fancy term such as “S1000D Process” – see Mom, all my years of schooling are finally paying off!
The S1000D Process:
We have identified six components of the S1000D process:
- Determine which version of S1000D you are going to use.
- Identify content to be managed.
- Determine data module granularity.
- Determine publishing strategy (electronic, print, both).
- Complete the Functionality Matrix available from the S1000D website.
- Business Rule Definition
- Detail your S1000D business rules.
- Determine which rules can and should be enforced by the BREX.
- Generate or develop your BREX document.
- CSDB Selection
- Determine which tool best fits your organization’s needs.
- Decision is based on S1000D version, existing infrastructure, desired functionality and, of course, $$$.
- Note this right off the bat: You WILL need customizations.
- CSDB Implementation
- Integrate with existing systems.
- Develop customizations to fulfill the totality of your requirements.
- Coordinate with engineering.
- Technical writers are creating content utilizing S1000D schemas and the appropriate BREX document.
- Create illustrations.
- Publishing and Distribution
- Publish to electronic and/or print.
- Distribute worldwide!
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