Perspective 4 – Business Rules (Part 2)

In my last post we discussed that a business rule defines or constrains how business operations work.  That the outcome of the rules should either be true or false and can be identified in a variety of ways.

Now that you have some context around how a business rule is created, lets discuss how to store these rules once you have identified them.

Technique 7: How to store business rules

There are many different tools you can leverage to store business rules. You can use a database container, excel spreadsheet, and even a Word document. No matter what mechanism you use here are some items you should consider to store regarding the business rules:

• Unique Identifier – each business rule should have a unique ID assigned to it. This is an easy way to track the business and trace the business rules to processes, requirements, architectural or test documentation.
• Business Rule – once you have the unique ID then document the business rule description. We discussed how to write business rules in Part 1.
• Conditions – if certain conditions must be met in order for the business rule to be invoked, or fired, then you should include that information as well, as that information is very telling.
• Ownership – this attribute describes what area of the organization, or business, owns the rule.
• Date Added – it’s important to capture when was the business rule was added to the database/application.
• Modified Date – it’s important to capture the last time the business rule was modified, as rules can change over time.
• Status – this attribute describes what is the status of the business rule? For example, is the business rule “active” or “suspended”? In some cases, you may not want to remove the business rule from the application/database as there is a chance it could be used later, or may be needed for audit purposes.
• Traceability – the business rule should trace back to an activity in a process, or the process overall, as stated above when we discussed the “unique identified”. If there is a requirement documents the business rules should trace back to the requirements documents. In addition, the business rule may trace back to test scripts or technical documentation. Business rules may also link to other business rules.
• Revision History – as you make updates to business rules, or as you add them to the application in which they are stored, you will want some type of version history. Again, depending on the tool you leverage this may happen organically, but in the case you need to store these manual this is an item to consider for audit trail purposes. It will help to track who has touched the data and why.

Here is an example of what this may look like in an Excel table.

Depending on the application available to you in your organization, there may be other attributes required for capture.  If you are using an excel spreadsheet the above considerations are a great place to start.  This list is not an all-inclusive list and your needs may require more attributes to be stored.

If you are using a tool like iGrafx, these rules or requirements can also be stored within the platform and all corresponding relationships can be identified and then easily reported on in a dynamic manner.

As you can see, business rules are very powerful.  They advise how the organization conducts business.  The rules also help mitigate risk to the organization to ensure compliance with policies, rules, or regulations.  Ensuring they are written well and stored correctly is critical and can provide a lot of insight, and knowledge, to all who consume them.