Business Rules for Everyone

Can Business Rules Management Exist Without Business Process Management?

The Business Process Management (BPM) is an interesting one. Most recently i heard an industry analyst complaining that process management as a practice was always there - it was called workflow! “Workflow on steroids” is BPM. In the same vein he was confused on the relationship between business rules and processes and whether the rules market would stay independent.

Some prospects sometimes wonder the same and i tell them well, unless the software market consolidates in a big way ala Larry Elison’s analogy with the automotive industry i doubt thats going to happen.

Indeed in our 140 off customers we have seen hardly 20% of those customers use rules in conjunction with process management.

I for one feel that ultimately the business rules market would be competitive with process management. Why? Process management is an internal efficiency driven market. You want to manage processes in a structured fashion when you need to automate. Rules market is driven by effeciency, regulation and competition - especially regulation, thats something that is hard to ignore. When process efficiency needs to happen, one of the first inefficiencies that needs to be weeded out is human intervention. This calls for decision automation. Once one talks of decision automation it is hard to see how business rules engines can be left out of the party.

Invoking Business Rules as of a Date.

One of the major requirements we often keep hearing from our customers is the need to go back and execute business rules as of a date that has previously passed. It looks like this is a requirement across industries and leads to significant ineffeciencies in settlement processes.

To think of it any settlement process has two major requirements:

1. Execution Audit trail: Why did a event get processed the way it has. The need is quite simple, the settlement party (lets say a customer) is going to ask for the reasons in 90% of cases.

2. Understanding the execution audit trail as of a previous date: If a settlement party does require how it was processed there definitely would be this need to process or view the execution audit that has previously occurred.

Consider a traditional IT system where the business rules have changed. You need to pull down the system and run the transaction or better, store the execution audit trail and have that viewed.

Now storing execution audit trails automatically means that the business rules are externalized. In essence you are trying to build a mini business rules engine.

Our product QuickRules provides for such a capability. A free 30 day trial is available as well.

An interesting incident - value versus commoditization

I recently met the senior IT management at a leading bank. This was the final stages of negotiating a license agreement with the customer. Over small talk i wanted to find out the perception from a senior management side? What was the value they perceived from the rules engine?
The answer came down to “IT maintenance”. it was clear tht the enterprise had not really thought through what the rules approach could bring to the table in terms of agility. Considering that the banks frontline agents were doing eligbility manually (despite having a recently installed Loan Origination System).

I asked them why the elgibity criteria were not captured - pat came the answer “Well the LOS vendor takes way too much of time and by the time the changes are done there are new ones and there are backlogs”. So in other words there were certain rules where the change cycles were way too fast. Understandable, in a competitive home equity loans kind of environment this is bound to happen. What was the implication? The eligibility process became a human to human process. Any manual process was bound to be full of errors and by the time the processing moved to underwriters it was a lot of loan applications that needed to be looked.

Now add the impact of training all these agents for enabling eligibility. Get the picture? Inability to match the cycle of change really ballooned to a much bigger problem than just IT maintenance.
Arguably, one could say that throw enough number of developers and it should be solved. It wont! There is a fundamental bottleneck of understanding those rules, implementing them and doing that correctly. Not unless you go in for a business rules approach.
So that bunch of developers at the very least need to externalize those rules - using some good design patterns or in essence build a rules engine.

Whats the point of ranting? Some classes of problems (where the constraints and rules are high) would invariably require a rules driven approach - whether it is a build or buy. How does one identify such classes of problems then?

The result was fairly perceivable - a time to close a loan reduced by 19% which is fairly significant considering that there were no fundamental changes to the process.

Business Rules - a pain in the software application

About 3 months ago one of my colleagues started having severe back pain. Sometimes it would manifest itself as numbness in his hands. It virtually made him quit working diligently. He would ‘take off’ few hours in a stretch. He tried ’self medication’ in the form of some Yoga exercises.

About 15 days back he finally visited a good doctor- a general physician. The doctor asked him a few questions. Then he finally ‘referred’ him to an orthopedist.

Then this good friend of mine delayed visiting the orthopedist. The pain got worse and finally he did visit the orthopedist. The orthopedist had very few pointed questions. One question that he zeroed in on a typical day my friend lived through. When he woke up, how he slept, what kind of a profession he was in and questions like that. Then with a few tests he then prescribed a treatment(By this time you would have guessed that it was indeed a stress related injury). Along with the treatment came some changes that my friend had to adhere to. My friend had several followup visits where the doctor saw how the progress was.

Enough of Story telling

Now why this story you ask? It was a bit intriguing and here are some reasons why:

1. No doctor ever, zilch, called him saying you need treatment. I dont recall a doctor ever peddling his service.

2. Self medication never worked. The ailment required a doctor

3. Correct the statement above! The ailment required a specialist, actually.

4. The disease was there - it required a change in lifestyle.

Whats this got to business rules?

See the analogy - business rules form decisioning logic. And this decisioning logic is known to the experts - ‘business users’, ’subject matter experts’, ‘domain specialists’ or ‘business analysts’. Unfortunately - simply because it is ‘written’ in a programming language, it is deemed that the IT developer is the specialist.

The true specialist is never approached. At best he says: “the following is the change required”. There ends his role.

The true specialist never even diagonizes the reasons for the pain. He wont.

How do you handle business rules today?

Here are a sequence of steps in today’s software application:

You follow RUP (Rational Unified Process) or some form of process (maybe XP) - whatever.

You ‘collect’ requirements - potentially a program manager, functional expert or business analyst does storyboarding or writes use cases.

After these use cases are reasonably known - they are implemented using some standard software programming language.
Some amount of unit/integration testing takes place. Depending on your software process maturity you have rigorous unit test cases defined-all of them focussed on application code.
The process is iterative. Depending on your software maturity you include some sort of code review.
Finally it is ‘dispatched’ for User Acceptance Testing.
Users test the functionality.
The application is migrated to production from staging environments.

What is happening in this process?

In this process you:

1. Give no thought to managing your business logic. Oflate with the advent of N-Tier applications there has been an endeavour to atleast restrict this to some layer - but it is still no good.
2. Initiate User Acceptance Testing - users test functionality but not business logic. Its definitely not a thorough testing of business logic.
3. Code reviews are conducted. Usually the reviewers are some good developers. Care is taken to ensure that coding standards, comments and good design patterns are used.
4. You even review database design (if its a greenfield application).
5. There is no business logic or business rule review! How can it be done really! Business users just cannot review programming logic! Functional experts cannot see code and say if it is right or wrong.

I hope you understand where we are going. This is not a problem if the business rules are minimal & manageable. But it is a problem when you have a larger number - something greater than 30-50 business rules.

6 Symptoms You are Likely to Encounter

Symptom 1: “They cook strategies in months and expect IT to implement them in weeks!!” Familiar with that?

As far as your business goes - it IS a simple change. They just want to change a product, a plan - it is not an application change. It is the same old application. And why should it take so looooong.

Symptom 2: “They Laughed at me when I said it would take the next release”

Symptom 3: “Joe wrote this application, now where should i change this”

Symptom 4: “Quick, The Campaign has some Errors. Please Fix Them”

Symptom 5: “The Campaign Isnt What Marketing asked for. Now they want something different”

Symptom 6:”Its John Q Customer And He Wants To Know How We Billed Him The Amount On His Invoice”

5 Reasons Why the application will have a Pain that requires a Cure(and this doesnt include all the rest of the 50 others that have been seen).

Reason #1: Changes to Business Rules Simply Cannot Wait

Lets face it. Application changes involves functionality changes. Even simple Business Rules changes have profound impact. What do we mean by this statement? Take the example of a simple discount change - its got to happen at the right time, during christmass or a special campaign. It simply cannot wait.

How do current IT processes enforce such changes? By tagging such changes with application changes - by linking them to release cycles!. The standard story goes like this, lets have changes to the discount policy AND the new offer module in release 2.0. Now the whole ‘release’ cycle is a long process.

Reason #2: You CANNOT afford to have the Wrong Business Rules

Its the same logic. Even a small discount rule has profound effect.

Reason #3: The Business Rules MUST be inline with the Business Intent

Reason #4: If You Dont Test It, It is Bound to Be Wrong.

Reason #5: If you Dont Know How Something Was Arrived At, You Cannot Explain Why-not to your Customers, Not to Your Regulators and Not to Yourself

Will The True Expert Stand Up Please?

It should now come as no surprise. The real experts of business rules should at the very minimum be involved in the process of executing the change. Just initiating changes is not enough.

Examples of Business Rules

See my previous posting “What are business rules?” for an introduction to business rules.

Business Rules have been made difficult to understand. I stand by this statement, 20 years of artificial intellingence background has really made this technology a pain. It has been experimented in the backrooms of universities (which new technology isnt) and made to look more difficult than it really is.

Why these examples?

A typical question that is oft-heard is “Can i have a few examples of business rules?”. In most cases the question is really another re-phrased question ” What are business rules and how can i differentiate a business rule from a rule”. In this particular section we wont address the how-to differentiate a business rule from a rule yet, but start with a few examples for business rules.

Examples are a great way to learn simple concepts especially if you are starting from scratch. That was the way you and i learnt as kids in any case, our parents would say, “John remember the apple you ate that day it is a fruit and yes grapes too are fruits”. It is tough to imagine learning what a fruit is by going through a text book - a fruit has seeds and blah blah blah. The first thing you want to do is show a few categories and say ok these are fruits, then come up with some patterns that make it easy to recognize a fruit. Thats the endeavour in this section. Ok ok, the analogy with fruits and business rules is a bit cheesy, but it helps.

Examples - here we go, but wait.

Lets first start with what this section is NOT about:

• This section is not about differentiating a rule from a business rule
• This sction is not about trying to identify business rules
• This section is not about types of business rules representation (though that is another topic that we should address at some point).
• This section doesnt cover when you should externalize rules and when you shouldnt attempt to externalize business rules (again another great topic that is recurrent and which we shall address at an appropriate time)

The goal of this section is to cover as many domains as possible to give a broad idea for someone starting to gloss over business rule examples. The examples are representative, not necessarily found in the domains that we are talking of. Lets review some domains and some examples there.

At this stage of business rules market evolution the following domains have been early adopters of business rules technology:

• Insurance
• Banking
• Mortgage
• Financial Services (probably covers the earlier three bullets and hence the first two are redundant)
• Travel and logistics

Insurance domain

Insurance is by far one of the major early adopters for business rules technology. You can safely assume that if one is trying to automate business processes within insurance, invariably business rules automation is requirement. Why is this the case? Insurance industry is a heavily regulated industry. The cost of not following regulations is quite severe. The process of ‘policy automation’ and superior visibility is a must have. Any regulated industry would have a virtually guaranteed requirement for business rules automation. I can’t avoid this but some said: “Never watch someone making sausages or laws”, both processes are messy! And where there are laws there are business rules - since compliance is a requirement. Non-compliance of these regulations is also severe on customer satisfaction(Just think over, if there is a law suit on an insurer which states that the insurer is wilfully not paying claims it could be disastrous!).

Anyways Claims processing and underwriting are the major business processes within insurance industry. Why is the case? Because the operating profits of an insurance company are part of a very simple equation that includes premiums collected, claims settled and operating expenses. So any efficiency that can be brought into undewriting and claims procesing virtually is a driver of overall financial performance of an insurance company. We will go into insurance industy and usage of business rules at some other point of time. At this point lets go into some simple examples:

A Fraud detection Rule in claims processing

If

The claim is for serious dental problems and the speciality of provider is not an Oral Surgeon or maxillofacial surgeon

then

Do not process the claim
Call the claimant to confirm

Clearly if there are serious dental problems and the claim doesnt include ANY service provider with the right speciality then there are some serious issues. (As a side note if you actually go into the exact rule you might find that there are some mistakes in the way it is structured - will leave that as an exercise !)

Example of product specific eligibility rule

Product “No Super Product “ does not cover varicose veins or desensitisation to any allergic condition

Validation/Eligibilty rule example

If

The claim has not been submitted within 30 days of the incident

Then

Do not settle the claim

Send to manual resolution queue

Taxation

Is there any ‘industry’ that is more ‘regulated’ than government, the tax collection agencies (IRS)? Show a country where there are no tax ‘rules’ and i will show you where you can research the missing link to mankind (seriously not since the days of cave/stone age would one have heard of ‘no tax rules’ - have fun folks kind of governments). That being said, here are some interesitng taxation rules - you can check some of these next time you look at paying your taxes.

§ 11.145. INCOME-PRODUCING TANGIBLE PERSONAL PROPERTY HAVING VALUE OF LESS THAN $500.

(a) A person is entitled to an exemption from taxation of the tangible personal property the person owns that is held or used for the production of income if that property has a taxable value of less than $500.

When there are some more intersting tax rules that one can find by searching.

Mortgage

Mortgage is a a heavily regulated industry with lot of guidelines that are specific to each state or region. This is not just in US but a worlwide phenomenon. Here are some examples of mortgage specific rules you might encounter

Some eligibility rules:

Restrictions on temporary interest rate buydowns for investment properties:

• Maximum buydown not to exceed 1% below the Note rate
• Maximum LTV is 70%.

The maximum loan amounts are as follows:

The rules are self explanatory for example:

if The applicant is applying for a loan for a 1 - unit condo and applicant’s residence is one of the 48 contingious states the maximum loan amount is 300, 100 USD.

Deciding which rules to apply

Often one would encounter scenarios where the decisioning logic itself is spaced around when to apply what kinds of rules or ‘blocks of rules’ (commonly known as rulesets in most business rules management systems).

Here is an example that does that:

There are a series of steps here. The point is not whether the logic used is correct or incorrect but that its easier to view.

In fact most business users might use some sort of decisioning logic representation as the figure on the left if one were to ask them to what should be done. The decisioning logic would be very complex though.

Come back for more examples

As one can see from some of the examples this is a work in progress. Many more examples would be added in these sections so that there are tonnes of examples for anyone to spot a business rule. Please understand that the examples given below are still ‘rules’ and NOT business rules. Why is this so? Because a business rule has to be very pertinent to a particular business function, use case or business process. Business Rules might exist stand alone by themself but they are what one would call ‘trivial’ business rules - they dont impact any business performance metric and hence should necessarily be not of interest to anyone - atleast not for the business rules approach.

Disclaimer:

I am associated with a business rules management system provider-YASU Technologies (QuickRules Business Rules Engine). I will try and avoid specific comparisions amongst products, but you know no matter what prejudices stay.
You can read more about the company and its products at http://www.yasutech.com/. There are lots of interesting tools to externalize, manage and align business rules that could be of interest.
“If you are a developer then there is a free 30 day trial download available” - dont blame me for thinking in rules cos i live and breathe by it!

What are business rules

Long long ago, actually less than a 100 years ago, a car was worth a fortune - 2500 dollars actually. By todays standard that is about 50000 dollars. The most recent lookup i did of a far superior version of a simillar car showed me that it costed less than 20000 dollars. What changed between then and now?

One word- Automation. And ofcourse you find this not just in car manufacture but virtually in every product that is being produced or will be produced. Automation is the essence of life. Nothing in the world can prevent automation - nothing has in the past.

What has automation got to do with Business Rules?

Everything! Today business rules are the heart of automation systems that involve replacing human-to-human processes with software systems. They are the heart of decisioning logic.

We wont go into classic definition of ‘What business rules are?’ (by the way you can find many classical definitions by googling around).

Here is a definition (picked these from answers.com) of a rule(not necessarily a business rule):

“A usual, customary, or generalized course of action or behavior”. In other words a constraint that typically prescribes an action.

So now what is a business rule?

The essence of business rules in simple terms represent decisioning logic and is pertinent to a particular business function. That in one way differentiates a rule from a business rule. This definition is still not complete. For it would include procedures (which in many cases are associated with a business function but are not executable business rules). At this stage this definition would suffice for us, but please understand that identifying business rules is probably the most difficult thing in software development. You can have 2 million java programmers but it is unlikely to have 2 million Business Rules expert. Part of the problem is the ability to differentiate between a rule and a business rule.

Whoa, wait a minute can you give me a simple example of a business rule?

Ok. Do you have a mobile phone? Depending on which country you are from, you would definitely have atleast 2 or 3 major mobile phone provider options. For example:

Onto the left are some geographical markets and some providers that have been listed. Most of these are familiar ones.

Go to any of these websites. In all likelihood you would see some ‘campaigns’ running there. Try to purchase a mobile phone plan. You would be greeted with some basic information (that is being used to qualify you as a user) and then you are offered a series of options as a consumer.

Surveying a list of plans from a single provider would give you a table that looks somewhat like whats there on the left.

If you choose any one of the plans, you are constrained and obliged to pay for your usage as per the terms and conditions laid out in the plan. In this case for example if you choose plan 2000 you would pay 25 cents for every additional minute over the 2000 minutes. At the end of the month (or billing cycle as the case maybe) the provider would send you a statement of charges that lists your usage and a bill that needs to be settled by you. Lets get into the billing system that is actually generating such a bill, undoubtedly the contract between you and the service provider is going to govern the way the statement of charges is going to be calculated. All the constraints that service provider uses to calculate your statement is dictated by this plan’s outline. All such constraints are business rules.

Ready for another example?

Try to get an online quote from a healthcare insurance. In virtually almost all cases you would be asked the question (or a variant) “Are any of your family members tobacco users?”. Some healthcare companies (depending on the answers you give) have higher premiums if you are a tobacco user. Thats an example of a premium calculation business rule which attributes a higher pricing factor based on the risk profile of the applicant. So in effect there is a constraint that is simillar to the following:

if

the applicant is a smoker

then

pricing factor = (pricing factor)*(risk factor for smoker)

Obviously i have simplified and demystified the whole example so that you can get the hang of it. But essentially that is what it is.

In the future pieces we will:

• More examples of business rules
• Different types of business rules.
• Why business rules change and why its a pain in the neck
• How to differentiate a rule from a business rule

Disclaimer:
I am associated with a business rules management system provider-YASU Technologies (QuickRules Business Rules Engine). I will try and avoid specific comparisions amongst products, but you know no matter what prejudices stay.

You can read more about the company and its products at http://www.yasutech.com. There are lots of interesting tools to externalize, manage and align business rules that could be of interest.

“If you are a developer then there is a free 30 day trial download available” - dont blame me for thinking in rules cos i live and breathe by it!