Business Rules for Everyone

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!