Category Archives: S1000D Business Rules

Contributing to Mekon’s Bitesize on Business Rules – 12: Understanding the Business Rules Document (brDoc) Schema

The new Business Rules Document (brDoc) Schema, introduced in the S1000D Issue 4.2, possesses excellent potential, and I believe it will help reduce the duration and costs of the business rules production and maintenance as well as increase their quality.

But like any new construct in a standard and specification, it raises the question, “What is it good for?”

And when it comes to the S1000D business rules, especially the specification’s seasoned users will naturally ask such questions as, “Doesn’t the Business Rules Exchange (BREX) Schema, which was introduced earlier, already cover the business rules aspects?”

I have given answers to these questions from my point of view in the latest article for the Mekon’s Bitesize series on business rules.

Click the title of the article to find out more: “Understanding the Business Rules Document (brDoc) Schema.”

(Credits: Photograph ©librestock.com under the keyword “document”)

Contributing to Mekon’s Bitesize on Business Rules – 11: Why Does It Make Sense to Generate a Business Rules Index First and a Guidance Document Second?

In the previous articles, I contribute to Mekon’s Bitesize articles on Business Rules, I mentioned about the importance of defining the business rules before signing contracts, and also about the sequence or order in business rules definition.

In the most recent article in this series, titled “Why Does It Make Sense to Generate a Business Rules Index First and a Guidance Document Second?”, I address the flow of business rules definition process in more detail, but especially the form of it.

In my opinion, it is much more sensible to have all business rules recorded as an index with all the necessary information and guidance attached to each entry, than to start with a flowing text, as it is usual for contracts and statements of work.

And above that, I think you should start with creating an index (before signing contracts) and keep it as a master knowledge base of all decisions, and then extract information out of it to create all the guides, the contracts, and statements of work.

You can find the reasons why I think so in this article here.

(Credits: Photograph ©canva.com under the keyword “format”)

Un-publishing “S1000D Issue 4.1 Untangled”

In a book I published earlier this year I wrote the following:

“Not many want to think about terminating the existence of their product or service, hoping it will be there forever.

But it won’t. At least not in its very first shape or version. Besides, the updates might be so crucial that at some point you will have something entirely new and different than merely an upgraded product or service.

I can guarantee that sooner or later you will need to discard one (and most probably more) of your products or services or various parts of them.”

“Take Control of Your Business: Learn what Business Rules are, discover that you are already using them, then update them to maximize your business success.”

I didn’t think I would need to terminate one of my books that soon after the start of my business (not yet two years), but I know it is a correct decision.

What happened is the following. Last year I published a resource for the S1000D community titled “S1000D Issue 4.1 Untangled.” It arranged 552 Business Rules Decisions Points (BRDP) defined by the specification and also added several new ones into a sequential chain for the S10000D implementation. The book was very well received by the community.

This year I have published a follow-up resource named “S1000D® Issue 4.1 and Issue 4.2 Navigation Map.” It could not serve as a new edition of the “S1000D Issue 4.1 Untangled” because this time the book covered two issues of the specification and also showed the relationship between them when it came to the Business Rules Decision Points.

The “S1000D Issue 4.1 Untangled” continued to sell after the publishing of the second book. I realized that it only sold because of its lower price and that situation didn’t feel good.

If we compare the “S1000D Issue 4.1 Untangled” and “S1000D® Issue 4.1 and Issue 4.2 Navigation Map,” it is clear that the former is of the lower quality than the latter. Therefore, I have unpublished it.

To compensate for the possible inconvenience, I have considerably reduced the price for the “S1000D® Issue 4.1 and Issue 4.2 Navigation Map.”

You can find the reasons of un-publishing “S1000D Issue 4.1 Untangled” and the new prices for the “S1000D® Issue 4.1 and Issue 4.2 Navigation Map” on the “S1000D Issue 4.1 Untangled” page here.

Contributing to Mekon’s Bitesize on Business Rules – 10: The S1000D community is a big family – an S1000D project is a big family too

When I gave my presentation at the S1000D User Forum in Amsterdam in June this year, with the title “How to Accelerate S1000D Implementation by Slowing Down”, I have mentioned that users working with it sometimes complain about too many players in an S1000D project. I then named several of the many different roles involved in or related to a project implementing S1000D.

This statement was met with nods during the presentation. Later at the coffee break, several participants at the forum stressed how true this statement was and how this fact was sometimes forgotten, ignored, or even that many in a department or organization implementing S1000D were simply not aware of that.

This recent memory of discussions at the forum moved me to write a short article for the Mekon‘s Bitesize on Business Rules series to point this out again and also explain why knowing who is involved in the S1000D implementation process (even if remotely) is so important, also for business rules definition.

Click the title of the article to find out more: “The S1000D community is a big family – an S1000D project is a big family too.”

(Credits: Photograph ©librestock.com under the keyword “family”)
  

P.S. These two books were displayed at the User Forum (click on the image to check out the book details):

Contributing to Mekon’s Bitesize on Business Rules – 9: Exploring brdoc Schema – Why there is a dedicated element for a business rule decision and none for a business rule decision point

As the new brdoc Schema gets explored and implemented, I receive questions on the intention of one or another construct in it.

I have written an article in frames of the Mekon‘s Bitesize on Business Rules series to share the reasons behind the structures and element names in the Schema for the primary business rules constructs: Business Rules Decision Points and the Business Rules Decisions. There is a seeming discrepancy in the way we (at the Business Rules Working Group, BRWG) have structured it: one having a dedicated element and the other not. But the deliberate and conscious decisions on the part of those who developed and reviewed the Schema stand boldly for the reasons behind this and I wanted to share them with all who might be interested.

Click here to find out more: Bitesize Business Rules: Exploring brdoc Schema – Why there is a dedicated element for a business rule decision and none for a business rule decision point.

At the end of this article, you will also find an invitation to a webinar (planned for June 28) with the title “S1000D is More than a PDF file, default BREX, and XML Schemas.”

Click here to find out more: “S1000D is More than a PDF file, default BREX, and XML Schemas.”

(Credits: Photograph ©librestock.com under the keyword “decision”)

P.S. Check out the two new books on Business Rules and S1000D Issue 4.1 & Issue 4.2.