Business Rules for Everyone

Business Rules in “Vicious Cyclic Markets”-Fraud detection An Example…

Anti-virus software market is a market that I like to call the “Vicious Cycle Market”(VCM-There is my first three-letter acronym -TLA!). A “Vicious Cycle Market” market feeds on itself. Its characteristics are:

1. Drivers Promote the Market: The Primary Drivers of the market benefit with each new advancement. It serves as a challenge. For example each new version of an anti-virus software prompts a hacker to create a better virus and vice-versa. In other words lack of a virus means a doomed anti-virus market.
2. Time is of Essence: If the solution to the problem takes too long then it is no longer useful. The cost of not taking corrective action is way too high.
3. It is Viral: Looks obvious, but the fact is the driver multiplies and moves through the community.
4. The market lags the driver: In other words, the solution is a post-facto event.

Fraud detection is a simillar market. The primary critical challenges are:

1. Time is of essence: If it takes too long to detect it or the detect the underlying conditions the system fails.

2. Manual processes aid fraud: Training personnel to detect fraud is not always easy, if systems can prevent fraud or detect it that would be ideal.

3. Understanding conditions for detecting fraud requires stakeholder involvement: A surveillance inspector is required here - a developer would be a misfit.

The avoided costs are significant when you think of automating the fraud detection conditions using a BRMS. besides even throwing a number of people around for detecting fraud may not help - it simply wont solve the problem, especially if the number of transactions is very high.

We recently worked with a stock exchange to help them implement a fraud detection system. About 10 surveillance inspectors create fraud detection rules that form the heart of the system. Given that it is a stock exchange, it was interesting to see the peak transaction activity.

Benchmarks For Business Rules
I found this posting (referring to JBoss site) on Manners and Waltz.

It is true there are significant number of rule formats, that impact decisioning . Decision Tree, Procedural Logic Flows, Decision Tables and more. So its confusing out there.

IMHO this is going to be another stumbling block for the business rules apart from others:

1. Standards: Lets face it. There are none, and from what little i can glean from other initiatives (SBVR included) - the movement isn’t there. JSR-94 was JDBC to Databases (and yet it didnt address critical questions) and you have no SQL equivalent. This defeats the whole purpose of standardization. SBVR is to Business Process Modelling and there is is no BPEL in the rules market. SBVR itself sounds fairly difficult to master! I wonder if a Human Factor expert is on board at SBVR.

2. Benchmarks: I really dont understand when any vendor talks of 10 times or 100 times better performance.

3. Standard Rule Representations: I doubt if this is codified anywhere. Practically each tool has its own formats and ways of doing things.

And then finally the BIG question, where does BRMS fit into the Software Development LifeCycle.

Now as someone who feels that business rules has value, you might feel i am doing my cause a disservice. No, all i am saying is that the value of the technology has not yet taken shape and there is much confusion out there- it should have a much wider acceptance than it has now.

BPM Versus SOA - David Ogren’s Blog

Was reading David Ogren’s BPM Blog at:

http://www.ebizq.net/blogs/bpmblog/2006/03/soa_versus_bpm.php

I think its a thoughtful and well written article. The difference between SOA and BPM is thin but it has been well explained.

My opinion is, the line is blurring further down.

The last statement he makes does go well my thinking: “But the more strategic a BPM project, the more it will be intertwined with a company’s SOA strategy.”

“Oops! Trader mistakenly spends $251 million” - Another Business Rules Example

“TAIPEI, Taiwan - A Taiwan stock trader mistakenly bought $251 million worth of shares with a mis-stroke of her computer, meaning her company is looking at a paper loss of more than $12 million and she is looking for a new job.
The trader with Fubon Securities made a typo while filling in a small order from Merrill Lynch on Monday, creating confusion when many small firms inexplicably surged past the 7 percent trading limit.
“Something like this is difficult to explain to superiors,” a Fubon executive said on Tuesday.”

Read more at http://msnbc.msn.com/id/8382753/?GT1=6657

… my guestimate is that the poor soul, just added a couple of extra zeros there. well dont want to play the blame game, but really….

Bad testing? Bad User Acceptance Testing? I really dont know. My take? Form validation rules

-
NO TRADE, SHALL BREACH THIS:

If
The trade amount is greater than 25 million$
Then
……
(Do whatever, dont execute the trade…).

The result: some stocks inexplicably rose 7% that one day. (Apart from the obvious losses to the company).

In hindsight perhaps it is easy to talk about this. Sitting in front of my comp, sipping my coffee and writing this blog its easy to see. Visualization before the event would have been really tough. I empathize with the IT there and more so with the trader who lost his job. The article goes on to say that the trader was not familiar with the new computer system, but give the poor guy a break!

One could argue that its poor testing. But think of it, if within the process we have a “validate trade” ruleset (or group of business rules) along with perhaps a decision tree or whatever (some form of sequential logic really - call it workflow rules whatever or just plain procedural code) and this was visible to a business analyst, there was perhaps a much better chance of identifying it.

Better yet if the business rules were unit tested - it would have been flagged. It beats me, if for code the idea is to unit test, do integration testing and then user acceptance - why dont we do that for business rules - isolated independent business rules. Thats what the business rules approach will bring to the table - a discipline that could avoid errors.

So when one talks of “costs of correction” you know what it means - it is precisely these avoided costs that are de-risked. For critical form data, least one can do (whether you are going in for a Business Rules approach or not): Externalize the business rules-make sure the execution is visible. I would say externalize the rules (jar file, dll whatever) - just that act of having it externalized and tiered will help.

Am i going overboard and suggesting that Business Rules approach would solve everything? Perhaps even without a BR approach, good disciplined programmers would have caught it or perhaps users …, the point is you need the right tools for the right job.

We helped a leading investment bank in “Trade Lifecycle Management” a few years back. At first i couldnt believe it that the folks there were investing that kind of money in the project (and to think of it most rules there were validation rules).

My company’s(YASU Techologies) product architect wrote an interesting white paper on testing business rules. You can download a copy at:

“How Conventional Testing Methods are not equipped to handle Business Rules Implementations”

Control and Business Rules In Spreadsheets dont go hand in hand

For those organizations that are looking for control (compliance -SOX, Basel) whatever, here is the take. You never can have your policies embedded within the spreadsheet.

Sounds commonsense? Huh. But give me a dollar for every person out there who is using a spreadsheet with CRITICAL business rules embedded in it in organizations that *must* comply to such regulations and you will have a new millionaire.

Its true and its all out there. There are critical functions in financial institutes and its not a secret really. Perhaps i was the last one to recognize this, but it is true.

Forget about compliance it doesnt make business sense!

When you have 10s of frontline agents it becomes difficult to control where this information goes. It doesnt take deliberate action, it just needs to be an inadvertent one.

And let me make no appologies here - business rules engines (decision management) whatever fancy TLM(two or three letter acronym really) you call this by, helps you avoid this.

Google - YouTube acquistion and then Business Rules and Efficiency

I know, i am late to this. But its an interesting acquisition, nevertheless. video blogging is the future. Undoubtedly if expressing views and the notion of a community are important, video blogging should expand reach further.

By now you may have realized that i am pretty new to blogging and video blogging (i doubt if i will ever take it up-really).

Sometimes i wonder what is google really doing. I mean if one were to put a 5 year strategy map for google where is the thought process, what are the trends?

I dont know folks but did audio blogging ever come up? I mean i would love to express views on camera but i am way too shy for doing that. Voice hmmm … perhaps yes.

I call the google strategy as “Channel Creation For Expression”. And then there is this word “Sense”-Ad-sense and what not - so should it create a channel for sense? Search, Writing and then video. I know its stated in a much simpler fashion that it is truly but seriously - search, i think its such a fundamental utility. I would be willing to pay google for allowing me to search, the amount of time it saves is phenomenal. Where is the business rules portion you ask? well there is none - wanted to write about this and get it off my chest so had to write it. But efficiency is my fav topic.

I guess the primary reason that business rules market could grow and survive is the kind of business efficiency it brings to the table. And yet… i think its one of the most ignored markets because that efficiency is never truly recognized. Why is this the case?

The utlimate efficiencies that business rules brings is to the key performance indicators to the business and building that bridge is not easy - it requires visionaries to bring this out. And the momentum has never carried it forward-never made it go over the bell curve to mass majority to become a commodity software market (which would have been great).

So is this a perennial early adopter market? I mean even if Fortune 50s adopt it, lets face it-the market size is not big enough. It is still fragmented.

An interesting comment i heard recently was I can hire 1 out of 2 million Java Programmers to code in Java-business rules or no rules, how many business rules experts can i hire! Agreed, not many - no matter how easy the tool is you are still talking of IT efficiency. Thats not true value.

I have some ideas(!?) for this and for reasons of confidentiality i can’t discuss. I dont think right now any company in the rules market has the muscle to execute that strategy(aha there is the execution catch always). But it can be a winning one that could propel the market to the over 1 billion mark. Tough talk? Thats what blogs are there for, i thought.

Grammar, Phrases and the bells and whistles of natural language…..

Oflate many times i come across this notion of “building rules by natural language” - phrases, grammar-like….

Its an interesting notion and perhaps feasible with 1 language. Maybe i am missing something here….I feel that it hits out against the very foundations of internationalization. I feel most software applications are just about grappling with the notion of a global market and internationalization. Then you bring in the mix of grammar.

For would the same grammar & syntax work in German, Mandarin? And if one takes the average life of a software application to be 5-7 years - what does one know of the enterprise’s M&A strategy, growth into new markets. Would it work there?

Most recently a leading enterprise (Fortune 1000) was looking at business rules for a performance management application. 8 months back they had operations in mostly English speaking countries. They then ventured into China(over the last 8 months) - the change was pretty dramatic. The implications were all there to see…

I am not saying that natural language is not the way to go - but should marketing hype create the mindset.

Reducing Closure Time in Mortgage Lending - a Customer Perspective

We recently worked with one of the leading retail secondary lenders. In a market that is having a downturn cycle this customer has had little effect. Competitors for this customer i believe are seeing 30% drop in the number of loans they are closing.

With about several 100s of sales agents and 100s of employees - whose jobs are intact (when you consider that across the country in this industry it is that much harder to keep people!) it was truly humbling to know that we had a part to play.

About two years back the CIO of this company was visionary and embarked on automating eligibility and pricing guidelines from various lenders within their system. Prior to this sales agents needed to be trained in each product, and then there could have been a lot of mistakes. In fact the existing system hardly captured a few simple products.

Why was this and what does a rules engine have to do with this?

1. It turns out that the primary critical issue was that capturing these loan products within the IT system was time consuming.
2. Intra day rate changes were happening and this would often take 2 days to reflect within the system.
3. Rate lock-ins were handled manually by sales agents.

Reducing the closure time by about 20% - just about the efficiency required to manage the downturn

1. The business rules paradigm using QuickRules solved this by allowing product guidelines to captured rapidly.
2. Within a short while most product guidelines were up and running. Intra day changes now take less than half a day and hence there is very little in terms of manual pricing - its accurate and reflects the current pricing.
3. Since the rules engine supports invoking business rules as of a previous date rate lockins are automated - no manual processing.

End Result- Number of leads handled per agent increased. Since the manual steps reduced, the wait period reduced as well. A lot of the decisioning including suggesting the best product to the customer is now done by the rules engine.

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.