I hope you are well and staying healthy out there! 😊
We discussed Part 1 of business rules a couple weeks ago, where we discussed what business rules are, how to write them and how to analyze them. If you missed Part 1, have no fear, you can find that blog post here. We are now moving on to Part 2, which is all about how you can 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.
In conclusion, as you can see, business rules are very powerful. They advise how the organization conducts business. The rules can also mitigate risk to the organization to ensure compliance with policies, rules or regulations. Ensuring they are written well, and stored correctly are critical and can provide a lot of insight, and knowledge, to all who consume them.
Until next time, signing off,
The BA Martial Artist🥋
P.S. Sign-in and leave a comment below on how you have identified business rules in the past.