One of the most common questions for someone getting started with business rules is “where do business rules come from”. As you might imagine, the stork does not bring them, you have to go find them. In general there are 5 key sources – regulations, code, manuals, people and data. Let’s consider these one at a time.

Regulations
Regulations can be a great source of business rules for those decisions that must comply with them. Often the reason for all the manuals and code that exist is to implement the regulations. It may well be simpler to go back to the regulations, and perhaps court rulings, to see what the rules are than to try and read the code or manuals that were interpretations of those regulations at various points. Working from the regulations also offers a chance to get the folks who work with those regulations day to day to participate. Ultimately you are going to want them to be part of the team that reviews, maintains and develops these rules.

Note that regulations will contain much that should not be implemented – remember you are trying to create the rules for the decisions you must take not all the rules. Thus, rules in the regulations about how inspections are done or about data storage requirements etc may well not be relevant for transfer to your business rules environment. In addition they may contain rules about the rules such as forbidding the use of certain information in making certain decisions (the use of race in lending is largely prohibited for instance). Capturing these rules is useful but separate from the process of capturing the decision rules themselves.

Code
Mining code for business rules is one of the most overused approaches. Most projects that try this end up with far too many rules at far too low a level. If the rules approach you are using maps well to traditional code then you are probably using a poor rules approach – there’s little value to rules if you cannot increase the level of abstraction and clarify the syntax. Business rules must map more closely to the business than the code does. As such it can be very hard to map code to business rules, especially automatically, as there is often a many:many relationship between a business rule and code fragments. Most modern business rules environments also support constructs like decision trees or patterns and these will not be properly exploited if too narrow a view of code mining is taken.

All that said, code can be the only source for some rules. When this is the case, use some of the wide range of code analysis tools to find out where your decisions are made, what data elements are used and to get a sense for what the code does. Then try and build rules to mimic the results without getting sucked into the detail of how the old code worked. Try re-factoring the code to make it easier to compare results and be prepared to invest heavily in testing.

Manuals
The third classic source for business rules are manuals – policy and procedure manuals typically. Ideally these can be clear and easy to map to business rules, much like regulations but with the added benefit of having been made more “readable”. That said there are issues with mining manuals for rules. Firstly the “rules” in the manual may not be in use – they might be documented as “policy” but no longer enforced for some reason. You will need therefore to invest some time in watching how people use the manuals and comparing what is actually done in practice with the theory. They can also often be contradictory – there is nothing in a manual production process to ensure consistency other than painstaking review. All too often therefore manuals will contradict each other or the regulations to which they are meant to relate.

People
Getting rules from the minds of experts is a time honored approach and much has been written about it – I won’t repeat the basic techniques here. Two notes though. Firstly beware disagreements – you will get some and it is important both to make sure you do (by interviewing multiple people and cross-checking) and that you resolve them. Secondly this is typically essential no matter what else you do. Very few rules projects make it into useful production without the need to extract some rules from the heads of experts.

Data
The fifth and final category is the data you have collected over the years. Data mining for rules and particularly for the thresholds that belong in your rules can be very productive. For instance, you could use the CART (Classification and Regression Trees) algorithm to extract segmentation rules from a set of data about customers. The data about how customers have behaved in the past will allow you to effectively segment them and from that you can generate business rules in a decision tree format, for example. Simpler kinds of data mining, or even just reporting, can help with thresholds for rules. For instance, if I am writing a rule to handle products of above average reliability one way and others another, then I could use some simple analysis of my historical data to determine a threshold rather than calculating it live each time, which is unlikely to perform.

One general note to close. It will be much easier to get the business involved if you can first identify the kinds of rules to be documented and then have them specify the instances needed. Thus I might identify that the policy manual contains knock-out rules that exclude someone from consideration and that these rules use a subset of all possible attributes in this process (excluding certain ones because they are illegal to use in this context perhaps). If I define a template for this kind of rule and then ask those who understand the policies to document the rules against that template I make it easier for them and easier for me at implementation time.