If you tell someone that you have to implement S1000D into your project or organization, one of the very first pieces of advice you will get will be: “Don’t forget to define business rules! They are one of the most important, if not the most important, steps while implementing the S1000D.”
I thought so myself for many years. The common belief, I used to join in, was, “S1000D implementation process is much bigger than business rules definition.”
In the meanwhile, I followed my passion to spread the word about Business Rules, including the world outside S1000D and wrote a book with the title Take Control of Your Business: Learn What Business Rules Are, Find Out That You Already Know and Use Them, Then Update Them Regularly to Maximize Your Business Success
In that book, I developed a classification of the business rules as I see it, defining them along the word MANIPULATE, where each letter stands for a phase in business rules definition and make parallels to the life-cycle of the product or service in focus. So these start with the Management, Attraction (look-and-feel and marketing), Navigation (structure and access), and go on further to the Production, Use, Legality, Acquisition for, Termination of a product or service, and finally pressing the “Execute” button where the product or service is launched.
You will be correct if you think that the letter “I” in the word MANIPULATE stands for Implementation. It will take you only a millisecond to deduce why Implementation of a product or service needs its own business rules defined. There are always certain rules to the implementation game, in the same way as it is to any other phase in a product life-cycle.
But what about the statement at the beginning of this article? Is it wrong that business rules definition is a part of the implementation process? Does this mean that your implementation plan should not take business rules definition into account? Or does this even imply that they are the same thing and one of them could be abandoned?
The answer to each of the latter three questions is a No.
Now I realize that relationship between the business rules and implementation documents resembles very much “the chicken and the egg” causality dilemma. You need to set up rules for the implementation process, and when you do those, you need to think of business rules and plan how to set those up, who will do it, and when, etc.
You might ask why this is important? The reason for this is that if you address only one and not the other, then your project will undoubtedly suffer. If you implement your project and neglect business rules (or pay them too little attention), you will lose control over the decisions you make on your product and service, which will lead to multiple mistakes during production and other stages of your product’s or service’s life-span.
That is why I strongly recommend that you reserve enough time and pay careful attention to your business rules when you develop your implementation plan. Further, keep the rules on implementing something new up to date in your business rules, since the latter are the knowledge base of all the decisions during all stages of your product’s or service’s life-cycle. And remember that your implementation plan is one of the business rules documents.
Join Victoria Ichizli-Bartels for her webinar: S1000D is More than a PDF file, default BREX, and XML Schemas.
In this 2-hour webinar, you will learn about the richness of information and tools S1000D is offering in its download packages, will learn what those objects are suitable for. Book your space on our webinar which will include:
● Various objects inside an S1000D download packages for different Issues of S1000D (including Issue 4.2),
● Which of the objects are highly useful, and which are less useful, for example they are covered by other more comprehensive objects,
● What bits of information inside S1000D text are great tools on their own and should often be used,
● Secrets on how information changes from one S1000D Issue to another.
To book your place call +44 (0)20 8722 8400 or email firstname.lastname@example.org.