Saturday, August 5, 2006

What's the big deal with the business rules approach? (FAQ #17)

FAQ #17

  • What's the big deal with the business rules approach?
  • What's wrong with the traditional hard-coding approach?
  • How do business rules compare to hard-coded rules?

Click to enlarge

The problems with traditional hard-coded or hard-wired rules include:

  • Duplicate rules must be coded & maintained in many systems
  • It's hard to isolate rules from code during maintenance
  • It's even harder to change and test applications
  • It takes months to change ‘hard-coded’ business logic
  • Redundant development & maintenance costs

The benefits of the business rules approach include:

  • Shared rules (Reuse)
  • Rules coded once
  • Rules are isolated from code
  • Externalizing rules results in smaller applications
  • Smaller applications make it easier to change and test applications
  • It takes days to change business rules --> Faster Time to Market
  • Lower Development & Maintenance costs

Business Rules Knowledge Base - Strategies



Wednesday, May 31, 2006

What rules belong in the BRE and what rules should be hard-coded? (FAQ #2)

Here's a great way to decide which rules belong in the rule engine and which rules could be hard-coded. The idea is that rules that you have no control over, such as compliance rules, must be rule-based so you can react quickly and implement them as soon these rules are changed. When a regulating authority tells you when the new rules become effective, you have no control whatsoever, and a rule engine enables you to change fast.

Rules that you control, where you can take your time and decide when the rules shall become effective, can be hard-coded if so desired. There still may be benefits to rule-basing these rules, but at least you can hard-code them if necessary.

Rules that should be in the BRE:

  • Business Rules
  • External rules
  • Governing rules (Regulatory rules / Legislative rules / Compliance rules / etc.)
  • Rules that you do not control
  • Rules that change often (Promotion rules / etc.)
  • Industry rules
  • Market rules (Competitor rules / Pricing rules / etc.)
  • Environmental rules (Seasonality rules / Weather rules / etc. )

Rules that could be hard-coded

  • System Rules
  • Internal rules
  • Rules that you control
  • Rules that never or rarely change

Idea credit to Paul Ulshafer. See PowerPoint slide of this idea.


Labels: ,

Wednesday, May 3, 2006

Business Rules FAQ

Here are a few of the frequently asked questions about business rules. I'd like to share my thoughts and answers about each of them in future posts, but I also want to learn what others have to say. Please send me your comments or links to more information about:

  1. How do you know when you're finished harvesting all the rules?
  2. What rules belong in the business rule engine (BRE) and what rules should be hard-coded?
  3. What is the real ROI of the business rules approach and technology? (according to actual customers, not BRE software vendors)
  4. If business rules are that great for business, why haven't more business people heard about the business rules approach and business rules technology?
  5. How will business rules affect the IT application development process/lifecycle?
  6. What's a rule?
  7. What's the difference (if any) between business rules and business requirements?
  8. How do you know you're not missing any rules?
  9. What is the best way to organize an enterprise business rules team: Should it be centralized with one group writing rules, or should departments have their own BR teams?
  10. How do you select the right and best rule engine for your company?
  11. How do you handle situations where experts cannot agree on one answer?
  12. How can we track rule metrics and rule status during the rule harvesting project: how many rules were harvested? by who? how many rules are draft, approved, tbd, etc.?
  13. How is the business rules development lifecycle different from the traditional software development life cycle? (similar to #5)
  14. How can we design one enterprise rule-based system to support business units that need different rules?
  15. What is the difference between data-based, rule-based, and knowledge-based systems?
  16. Should we extract rules from legacy code? If so, what is the best way to do it?
  17. What's the big deal with the business rules approach? What's wrong with the traditional hard-coding approach? How do business rules compare to hard-coded rules?


Tuesday, September 13, 2005

Who are the Subject Matter Experts and Super Experts in your company?

Every company has Subject Matter Experts (SMEs). But great companies also have what I call Super Experts.

Everyone knows who the Super Experts are: They are the people that even the Subject Matter Experts call when they need help making a decision. They are the people that lead executives to seriously wonder, "what do we do if Peter gets hit by a truck?". Super Experts are the "brains" behind key, complex, and high-value decisions.

Subject Matter Experts

Subject Matter Experts are the people who make a lot of decisions in a little bit of time. These are microdecisions. SMEs seem to know a lot about a few topics.

SMEs could easily make hundreds or thousands of microdecisions in a day. Yet each decision is a crucial step in a larger process, such as building a product, making a sale, or taking a reservation. And each microdecision is crucial: A mistake at any point in the process will make the entire entire product, service or process defective.

Microdecisions are things like:
  • Is this customer eligible for this particular product?
  • What discounts is this customer entitled to for this particular transaction?
  • What is the commission for this booking?
  • What should I up-sell to this customer?
  • What should I cross-sell to this customer?
  • Do I have all the information I need to save this record in the system?
  • How do I work-around the bug or limitation in the system?
  • Who should we assign as the company contact person for this sale?
  • Does the customer want window or aisle?
  • Does the customer want a double bed or king bed?
  • What credit card does the customer want to use?
Super Experts

Super Experts are the rare individuals who solve the toughest problems in the company. They routinely make complex decisions, and they make it look easy. Their phone is constantly ringing. A Super Expert is the only one in the company who has the knowledge, experience, and expertise to make the right decision every time. Instead of making a hundred microdecisions a day, the Super Expert worries about making one big decision. Super Experts seem to know everything about lots of topics.

Super Experts may only make one decision a day. They may take a few days, or even weeks, to make an final decision. But each decision can save the company millions of dollars. Each decision can determine how thousands of transactions will be handled, and how millions or dollars will recorded in the books.

I'm talking about bottom line decisions... million dollar decisions like:
  • How do we solve this customer's mission critical problem right now?
  • What is our underwiting strategy and policy?
  • How do we design this plant so as to prevent and contain fires?
  • How do we clean up this oil spill?
  • Where should we build the plant?
  • Where should we build the product?
  • Where should we hire the employees?
  • What will our price program structure look like next year?
  • What will our discount policy be next year?
  • What promotions should we run?
  • What do we do to improve improve yields and revenue?
  • Should we create a new legal entity for this deal?
  • What Legal Entity structure should we use for this company?
  • What is the best way to structure this deal?
  • How do we minimize tax and maximize revenue for this contract?
  • What Legal Entity should we use for this contract?
  • How should we record these types of accounting transactions?
  • How do we calculate this quarter's tax provision?
  • What is the best product or right product that we should recommend for this customer situation?
  • How do we troubleshoot this problem?
Who are the Subject Matter Experts and Super Experts in your company?

If you are going to work on a business rules management project, one of the first things you need to do is identify who the true Subject Matter Experts and Super Experts are. You need to work with and elicit knowledge from both types of experts in order to succeed.

Labels: , ,

Monday, August 22, 2005

Database vs. Rulebase vs. Knowledgebase

Most information systems today are databased. That's too bad for many companies because they are going to fall behind as their competitors build and deploy intelligent rule-based and knowledge-based applications.

Click to enlarge

Data-based systems are limited to processing data and outputing information. The result is often information overload. Users don't know what information is really important, and they don't even know if they have all the information they need to make a good decision. Too many choices confuse people and slow down their decision-making process. Too many shopping carts are left behind as browsers give up and browse somewhere else. People want answers not more information.

In databased systems, business rules are usually hard-wired in code, stored procedures, or triggers. Only programmers can change these rules.

Rule-based systems are more powerful and more flexible than databased systems. They process data and rules to make decisions. They are good at processing lots of simplistic business rules, like pricing and promotion rules, and they can handle a broad scope of reasoning. They are best for real-time decision-making and decisioning applications.

In rule-based systems, business rules are usually externalized so that business analysts and sometimes even SMEs can change the rules. Inference (IF/THEN) and pattern-matching rules are commonly used in rule-based systems.

Knowledge-based systems are smarter than databased systems. They process data and use expert knowledge to output answers, recommendations, and expert advice. Customers get a personalized answer or product recommendation tailored to their unique requirements. Sellers get pre-qualified customers ready to buy. They are good at processing deep logic and very complex business rules. They can handle more complex rules and a deep scope of reasoning.

In knowledge-based systems, business rules are externalized and can go beyond inference and pattern-matching rules. They can also handle probabilistic reasoning, case-based reasoning, fuzzy logic, and other advanced AI reasoning techniques. The more complex the business problem and the business rules are, the more likely a knowledge-based solution will work.


Saturday, July 2, 2005

What is the difference between a Business Rule and an IF-THEN Statement?

Business Rules derive inferences and arrive at conclusions by reasoning about facts or premises using either deduction or induction.

An if-then statement in a declarative rule-based programming language is a business rule. Business rules are designed to solve complex problems that require thinking and knowledge in order to make intelligent decisions. Business rules can explain their reasoning process in order to justify their conclusions, decisions, and recommendations. Business rules are commonly used to create Intelligent Systems that reason and apply knowledge.

An if-then statement in a procedural programming language is not a business rule. It is simply a type of conditional statement designed to either control program branching or to conditionally execute sections of program code. If-then statements are commonly used in conventional programs that process data and manage information.

This was originally published here.