Top 10 excuses to avoid business rules: #10 we tried before

I thought I would re-run a top 10 list from a while ago – an oldie but a goodie – on the top 10 excuses for not adopting business rules and a Business Rules Management System.

#10 – We tried before and got no results

There are two root causes for this excuse – over-hyping and previous failures, especially of expert systems, and the misuse of the technology in pilots. Over-hyping of decision automation was rampant in the time of expert systems. There were many expert-system fiascoes but although business rules definitely evolved out of the whole expert systems world, business rules management systems are not expert systems.

• Expert systems were attempts to lay out not just a way to approach control of decisions and actions (which is basically what business rules do), they also imposed entire ways of solving a business function. So you would buy a vendor’s offering that said something like “This software decides whether to approve or decline a loan. You can tweak it and tune weights, but we’ve established the way you will do business.” Many companies chafed at that kind of restriction.
• Expert systems also used specialized software and dedicated (expensive) hardware that didn’t fit in with companies’ systems. Nowadays business rules software has become much better about using standards to fit in with existing hardware, software, and data instead of requiring specialized proprietary components.
• Expert systems were often extremely difficult to work with, especially for the “experts” whose knowledge was being embedded while a BRMS allows “power” users to easily change rules through decision tables or point and click templates.
• Expert systems typically suffered from performance and integration problems where today’s BRMS offerings are fast and easy to integrate.

Expert systems are not business rules management systems. Don’t let a bad experience with the one blind you to the value of the other. More problematic is misuse of the technology, typically in a pilot or first project. So what can cause pilots to go wrong when trying business rules technology?

• Many pilot projects over constrain the technology, forcing a procedural design on to a declarative approach.
  They try and use Use Cases and other design approaches without thinking about how to separate out and manage decisions as first class objects. Treating business rules as just another programming language might work but probably won’t – it requires a shift in thinking to decisions.
• Some fail because they are trying to solve too much of a problem.
  Don’t try and solve the whole problem, try and prove the technology works for a scoped decision. Also, be mindful of what is and is not the decisioning component of the problem. Don’t try and use  business rules for the wrong parts of the problem.
• Don’t start until you have determined the specific decision problem you are trying to solve.
  You should have justified why that is the best decision to start with (such as being the best for rules technologies, being reproducible, having corporate visibility), and checked the scope.
• Don’t wait until the pilot has started to get the appropriate resources scheduled and trained and don’t do it without expert resources to help the process stay on track, in scope, and done following best practices.
  Business rules can be very straightforward to use but they are not the same as approaches you may have taken in the past. Get the right training and help.

Don’t let an expert system failure in your past, or a misjudged pilot, blind you to the value of business rules. Lots of companies are getting great results from business rules and you can too. You can get the business and IT to collaborate on managing the decision logic and you can inject the results of analytics into decisions to improve them and you can manage decisions as corporate assets. You can prove that this will work with a pilot. You can also mess it up. Don’t.