I was with one new customer the whole of last week helping them out with their first taste of Business Rules technology. I had to help them understand how they can use Business Rules in their application.
Business Rules Management Systems introduce a completely new paradigm into the software systems world in organizations that are new to them.
So, here are 7 tips for you, if this is your first Business Rules project
#1 Identify clearly the Business Decisions you are automating
The first thing that you need to do is to identify, understand and be able to clearly state what the business decisions are, that you are trying to automate. For example, here are some business decision statements!
- Decide if an applicant is Eligible for a particular loan
- What are the products that I can recommend for a certain applicant
- Compute the compensation for a specified employee using his current salary structure
- Compute the claim amount that needs to be approved for the given claimant
Doing this upfront clarifies your goals. If this not done, then you run the risk of losing yourself into an Analysis paralysis attack.
#2 Identify your Integration touch points, but worry about it last
I mean it! Integrating the business rules engine is just the easiest thing in the world. For example, with QuickRules.NET or QuickRules java it is about 3 - 10 lines of code depending on the circumstance.
It helps to integrate early because your application shell will be ready.You can fill in the rules later as they are built.
#3 State your rules first. Don’t worry about rule formats or formalism too much to begin with (Rule Capture)
Some of the deadliest fights and confusions happen when people mix up Business rule design and rule requirements.
Your first objective is to determine what are the business policies that form the basis of the business decisions that we stated in #1.
Don’t worry too much about rule formats or formal methods (if you are not comfortable with them). If you can capture them in plain English, Excel tables, visio diagrams, it would just work out fine.
Get this right! You need to understand your rules first. Digest the information, let it sink in, the design will take shape, take my word for it.
If you are not clear about some areas, that is OK too. Remember, your rules are externalized already. You can always add to them later.
#4 Business Rule Design. Keep your Business users in mind when writing the rules.
Once you understand your business policies and how they apply, it is time to start your Business Rule design using formats offered by your BRMS.
- Identify and group your rules logically by use case. Keep them modular! Sets of logically related rules are referred to as Rulesets. Identify rulesets first.
- Then identify how you would apply the policies in a Ruleset to arrive at the decision that the ruleset applies for. You MUST be able to state it!!
- You can capture this rule sequence either using a Flow Rule (sequential & graphical) or as a Rete Ruleset (where the rule execution sequence is determined using the Rete algorithm.
- First do Step 2#. You can always change it as you learn more !
- Then identify and write the If Then Rules, Decision Tables etc.
NOTE
Business Rules represent your business policies. Your Business owns them. When you write them, keep in mind that the people who need to see them are not techies.
In most organizations, business rule implementation always begins with IT. With experience and maturity, you can hand over rule development, and maintenance over to your business analysts. But that mostly will not happen if this is your first business rules project.
#5 Never forget your data models. Rules finally apply on Business Information
Keep this in mind always. Business Rules Management Systems are also software that work in your application.
If you have stable data models, like say MISMO or your own in-house object model, then go ahead and write your rules directly on your data model.
If your data model is also evolving and you want to allow your rules and data models to evolve independently, then,
- Identify your Business terms and capture them using the BRMS. In QuickRules, for example, you can capture business terms as Definitions.
- Write your rules on these business terms.
- As and when you believe your data model is ready, you can map it to these business terms and your integration is done.
- You can keep on remapping them as and when you want to test for a milestone or whatever.
#6 Get business scenario test cases. Get the business to give them to you.
You are writing executable business policies. Remember that! You MUST do this!
- Get Test cases for the business decision that you are trying to automate.
- If you can, you could even get test cases for each ruleset, which will be best.
- You can do one better. Capture the test cases as Excel, and teach your business analysts how to test using their data.
- This is an absolute MUST. DO not rely only on application level testing. That is late in the cycle. Test early and upstream, not downstream.
#7 And finally, start small. Don’t over do it.
- Not every If Then statement is a Business Rule. A Rule is a Business Rule if and only if it is a policy statement
- Remember your reasons for adopting the business rules approach. Visibility for the business, ease of change, centralizing policy management & administration.
- Business rules offer a structured approach to capture business policy. Don’t overdo it. To begin with, you may capture only volatile rules using a BRMS
- Other business rules that never change, they may be hard wired in the application itself.
### Finally, some things that we forgot to mention above..###
Of course, it is not possible to mention everything in a blog post. Even in a very very long one like this.
I have not covered Policy governance, maintenance, access control, security, versioning issues here. Integration, is something that I have not covered at all.
But the 7 tips I have talked about, they are the basic ones. The others, may be some other day.
