Step 6 of 10 Steps towards the Agile Enterprise

By this step, the business policies that drive decision making are well known and centrally controlled. As I had discussed in my previous post, many of the business decision could be taken by the system itself.I had concluded Step 5 with this line,

Your rules are locked away in code, and the only guys who can see it are the IT. You tell me, which MBA is ever taught to understand java or C# code, or taught how to read stored procedures.

With time, and more automation, it becomes more and more difficult for the business to participate in the change process (change to the policies).

Now, there are four immediate problems here as you can see.

1. The business policies are locked away in code, db stored procs or in excel sheets
2. If the policies are in excel , you cannot automate them
3. If the policies are in code, db stored procs or any other IT artifact, the business cannot see them
4. Many policies are very complex, and very difficult for IT to implement in a modular

We somehow need to find a solution that

1. Will allow IT to model the complex business policies and execute them at the same time
2. Will help IT externalize the business policy execution so that changes to policy have a minimal or zero impact on the IT system
3. Will help IT to make changes to business policy much faster
4. Will help IT provide a executable plan for eventual involvement and transfer of control of business policies to the business

The keywords here are “model complex policies”, and “externalize”. Now, any solution that you would employ MUST give you at least the following capabilities

1. Provide different ways for representing your Business Policies, because Business policies come in all kinds of flavors and shapes.

• There are many policies that live in Excel. It is not uncommon to see Insurance or Loan agents consulting a printed or a Excel version of pricing/rate tables. Now, lets call these as Decision Tables
• Policy constraints on business information and data. For example, consider this rule, If AssetValue > 5 million, then Classify as Super Platinum Customer.
• Some times decisions are the resullt of certain policies that have to be applied in a specified sequence, like in a Flow chart. Lets call these Flow Rules
• Some times, you need to be able to specify that when two business policies are applicable in a certain scenario, which policy will override the other. Lets call these Mutex Rules)
• There are of course Information Validation rules that need to be applied, like in a Form, or on Supplied Business data like a Stock Trade

2. Provide a runtime decisioning component (engine) that will apply your business policies on the business information supplied to arrive at a business decision.

The software technology that provides the above outlined solution is called a Business Rule Management System and the runtime Decisioning software component is called a Business Rules Engine.

In this post, I am introducing only the Rule Engine & the Rule creation capabilities available in a Business Rules Management System. I will be introducing the other features in the next set of posts

The Business Rule Engine then becomes the decision making component in your process. You feed it information, ask it to make a decision based on a specified set of rules, and it will give you back the business decision.

The other problem area is how to represent all the different types of rules. Now, Business Rules Engines need to be supplied business Policies in a specific format, lets call that a Ruleset. Now, a Ruleset will be a logical collection of rules that can be in multiple rule formats like If Then, Decision Tables, Mutex, Validation, Flow Rules etc.

Now, how will the Business Rule Engine know in what order the rules in the ruleset will have to be applied to arrive at a Decision?

If the Ruleset contains a flow rules, then one of the flow rules can be designated as an entry point, and the rule engine will execute the rules in the Ruleset in the order specified in that flow.

(Note: The word flow here != Workflow. This is just the sequence in which certain rules have to be applied to arrive at a decision.)

A Ruleset, then is a logical collection of related business rules (or policies). Now, A Ruleset can contain any of the types of rules that I have discussed in a section earlier , like If Then Rules, Flow Rules, Decision Tables etc.

What if the Ruleset does not explicitly specify a sequence? In these cases, the Business Rule Engine can employ an algorithm to determine the exact rule execution sequence for the supplied information. One popular rule engine algorithm is Rete.

All this is fine, but how does this still help solve the problems stated at the beginning of this post?

1. Most complex rules can be captured using the rule formats that are supported by Business Rule Engine. This greatly resolves the automation problem. There are many well documented case studies of Enterprises achieving 99% Business Decision Automation
2. The rules are external to the application and not buried inside of it, so changing the rules can now become independent of the application itself. This will immediately bring down the change management pains
3. The Business Rules (Policies) captured as Decision tables, Flows etc, can be shared. These are far more easier to understand and work with that code. So visibility into the Decision making process is achieved instantly once the rules are written.

Now, the next logical step is How to involve the Business and handover all this Decisioning to them. That will be the subject of my last four posts in this series.