Main

September 25, 2008

Ten Rules for Wall Street

Ten Rules for Wall Street

What are the rules? Did people break the rules, bend the rules, or ignore the rules?

Confidence in Wall Street went down the drain last week. The credit crisis gave business a bad name, and it gave government a bad name for not doing anything about it. Trust disappeared. 

It's time to rebuild trust in business and government.

Here are ten rules for restoring trust in business and government. These rules apply to everything from the global financial system, to Wall Street; from federal governments to local jurisdictions; from global corporations, to organizations and small businesses.

Companies that learn to define transparent rules that are sensible, consistent, easy to understand, and easy to follow will be easy trust. On the other hand, companies that rely on opaque rules that are complicated, confusing, illogical, inconsistent, or deceptive will be hard to trust. They will go out of business.

Rule 10 - Have guiding principles. Act on principles, independent of influence by greed or friends.

Rule 9 - Follow policies and guidelines about what is permissible and what will not be tolerated.

Rule 8 - Establish rules of behavior concerning what is right and wrong. Success in business depends on understanding the rules. The rules of the business are the way the business really operates. Design transparent rules that are logical, sensible, easy to understand, and easy to follow.

Rule 7 - Leverage knowledge and judgment. Know what you know, and know what you don't know. Document and retain what your experts know and how they think so their knowledge can be shared with those who need to know. Use wise judgment. Know when to follow the rules, when to bend them, and when to forget them.

Rule 6 - Make smart decisions informed by facts, rules, knowledge, principles, and judgment. Decide using clear, logical, and unbiased rules that explain each decision clearly. Use sound reasoning to make rules-based, principles-based, and knowledge-based decisions.

Rule 5 - Create enterprise architecture to deal with change and complexity. Use architecture to simplify complexity, and to understand how the whole business and the whole system works; Understand who, what, when, where, why, and how. Design the architecture to ensure that all the parts fit (interoperability), connect (integration), work (quality), work as intended (alignment), last (reliability), and can be shared (reusability). Design the architecture so the business can handle increases in complexity and increases in the rate of change (flexibility). Design the architecture to reduce time-to-market and reduce operating costs. Design the architecture to support rules-based and principles-based compliance.

Rule 4 - Do the engineering, to design systems that work, change, and last. Apply architecture and engineering design principles to ensure alignment, flexibility, quality, interoperability, integration, reusability, reliability, compliance, reduced time-to-market, and reduced costs. Build in risk management safety factors so the business and the systems can handle extreme stresses and excessive loads.

Rule 3 - Have a clear vision. Stand for brand.

Rule 2 - Instill confidence. Improve the quality, consistency, and accuracy of decisions and actions.

Rule 1 - Build trust. Align actions, decisions, and transactions with management's intentions. Align execution to goals, strategy, and mission. Align systems to business. Align implementation to intention.

Sept. 25, 2008   Rolando Hernandez   BIZRULES

April 05, 2007

Why business rules? Why not expert systems?

James Taylor over at Fair Isaac has a really good list of "Why business rules?" I agree with most of the points, except the stuff about expert systems.

Maybe the question should be "why not expert systems?"

The dirty little secret is that a lot of the rule engines out there were originally called "expert systems" or "inference engines", then they were called "business rule engines", and today they are known as "business rule management systems. (See the business rules hype cycle)

Of course, everything is better today. And faster. And connected. When expert systems first came out, the Web wasn't even born yet, and PCs were running at 10 mHz. 

The biggest problem we had at Mobil Oil between 1988-1994 when we were building the Global Expert System Strategy and Lube Knowledgebase Strategy was making and mailing floppy disks to all our affiliates.

I remember one day we were showing the customer (an executive in Mobil Marine division) a demo of the expert system, his comments were:

  1. This is like an intelligent checklist, it never asks un-needed or dumb questions!
  2. I like that I can click on an underlined word (a hyperlink) and popup a definition, photo, go to the next page, or whatever!
  3. This is not like our other DOS or mainframe apps. Our users will not like the fact that this works on a "one page at a time" metaphor,
  4. because we're forcing users to fill out information or answer questions on the page (screen), then they have to press enter to go to the next page (screen).

That one page at a time metaphor he described was basically how the World Wide Web works. We were doing this in a business rule engine (BRE), aka an expert system (ES) in 1988. Before WWW. Before Windows.

(Want proof, go here and click on the photo on the right. There's a picture from back then, in my younger days... the program on the PC behind me is 1DirPlus or something like that.... Definately B.W. Before Windows). And so back then we built expert systems that did reasoning, chaining, hypertext / linking, and of course inferencing. Basically they would fire rules exactly the same way a modern rule engine would today. And give the same answer the expert would give,

Even after the experts retired long ago!

We did that in AION. We could have used Neuron Data (which evolved into Fair Isaac Blaze Advisor), or we could have done it in ILOG. Or any number of other ES tools at the time. Some of them are still around today. (See BRE Family Tree)

Distribution of expert systems, and access, is one of the reasons they "never took off". People used to say expert systems were a solution looking for a problem. Deploying expert systems on the web solves those problems.

I think the Web is "the problem" that expert systems were looking for. The Semantic Web is reigniting a lot of the good stuff from the AI/ES days. Adding intelligence and reasoning to applications is what expert systems have been doing all along.

And by the way, not everyone agrees that expert systems never took off. I certainly don't.

As Richard Barfus, CEO of MindBox, (an ES/BRE/BRMS firm) likes to say, "Expert systems didn't really go away. They went undercover."

 

August 05, 2006

What is the difference between data-based, rule-based, and knowledge-based systems? (FAQ #15)

The chart below summarizes the key differences between data-based, rule-based, and knowledge-based systems:

Click to enlarge
The problem with legacy data-based systems is that they are hard-coded and limited to processing data and outputting information. It's still up to the human being to analyze all the information to make decisions and recommendations. The result is often information-overload and costly mistakes.

Rule-based systems process data and output information, but they also process rules and make decisions. They are good at processing lots of simple business rules with broad logic. They are commonly used for real-time decisioning systems, straight-thru processing (STP) systems, and compliance systems.

Knowledge-based systems also process data and rules to output information and make decisions. In addition, they also process expert knowledge to output answers, recommendations, and expert advice. They are good at processing deep logic and very complex business rules. They are commonly used for advising systems, expert systems, and knowledge automation.

Database vs. Rulebase vs. Knowledgebase

Deciding between a Rule-Based or Knowledge-Based solution

List of Applications where Rule-Based and Knowledge-Based solutions are Most Effective

Business Rules Knowledge Base - Articles

FAQ

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?
ANSWER

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

FAQ

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.

FAQ

May 03, 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?
  18. Who are the Subject Matter Experts and Super Experts in your company?

September 13, 2005

Who are the Subject Matter Experts and Super Experts in your company? (FAQ #18)

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.

July 02, 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.
Locations of visitors to this page